•

Peer Reviews
• Documentación
de Arquitecturas
• Seguridad en
Aplicaciones Web

Software Guru CONOCIMIENTO EN PRÁCTICA

No.21 • Agosto - Octubre 2008 • www.sg.com.mx

[ ENTREVISTA ]
Christian Lemaître
Guru fundador de las
Ciencias de la Computación
en México

Industria del Software

México. $65 MXN
I SSN 1 8 7 0 - 0 8 8 8
en México
21

9 771870 088009

[ Tutorial ]
Noticias • Eventos • Fundamentos • UML • PM Corner • Tecnología • Biblioteca Silverlight
 // CONTENIDO
Editorial
Sí, aun seguimos ¡vivos!. Después de
meses habitando la oficina, comiendo
pizza y bebiendo agua (¡somos muy salu-
dables!), los días 21 a 24 de junio se reali-
zó el congreso SG’08 Conferencia y Expo,
en esta ocasión en conjunto con PMTOUR
México 2008. Estamos muy contentos
de que hubo personas que asistieron por
tercera ocasión, nos da mucho gusto sa-
ber que gente nueva asistió al congreso y
quedó muy satisfecha con lo ahí mostrado.
Aunque cambiaron algunas cosas (como el
tiempo de duración de los tutoriales), todo
salió muy bien. ¿Quieren saber más?, en el
interior de la revista encontrarán la reseña
más completa.
Nada de esto hubiera sido posible sin el
esfuerzo y trabajo del equipo que forma a
02 AGO-OCT 2008
SG, y a todos ustedes porque además de
asistir, nos han hecho un elemento más en
sus preferencias.
Retomando nuestras actividades cotidianas,
ahora toca el turno a este número 21, en el
que encontrarán los comentarios de los ex-
pertos en el desarrollo de la Industria de
Software en nuestro país. Es interesante sa-
ber cómo vamos creciendo en este aspecto y
lo que podemos hacer para mejorarlo. Ade-
más encontrarán la última parte del tutorial
de Ruby on Rails y la continuación del artículo
sobre documentación de sistemas, así como
cada una de las columnas que ya conocen.
Gracias todos por su preferencia y por
hacer que SG’08 Conferencia y Expo haya
sido un éxito.
» Equipo Editorial
directorio
Dirección Editorial
Pedro Galván
Dirección de Operaciones
Mara Ruvalcaba
Coordinación Editorial
Sonia Sánchez
Arte y Diseño
Grisel Otero
Fotografía
Gabriel González
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
Christian Lemaître, Alejandra Herrera,
Martín Álvarez, Luis García, Carlos Ortega,
Omar Gómez, Erick Frausto, Rafael Bernal,
Gunnar Wolf, Germán Domínguez,
Marco Dorantes, Guillermo Morales,
Edith Martínez, Beatriz Velázquez,
Andrés Simón Bujaidar, Miguel Armas,
Héctor Obregón, Germán Domínguez.
Ventas
Claudia Perea, Natalia Sánchez
Marketing y RP
Dafne Vidal
Circulación y Suscripciones
Daniel Velázquez, Edgar Dorantes
Administración
Araceli Torres
Contacto
info@softwareguru.com.mx
+52 55 5239 5502
SG Software Guru es una publicación trimestral
editada por Brainworx S.A. de C.V., Malinche no. 6,
Col. El Parque, C.P. 53398, Naucalpan, México. Queda
prohibida la reproducción total o parcial del contenido
sin previo aviso por escrito de los editores. Todos
los artículos son responsabilidad de sus propios
autores y no necesariamente reflejan el punto de
vista de la editorial. Reserva de Derechos al Uso
Exclusivo: 04-2004-090212091400-102. Certificado
de licitud de título: 12999. Certificado de licitud de
contenido:10572. ISSN: 1870-0888. Registro Postal:
PP15-5106. Se imprimió en julio de 2008 en Roma
Color, S.A. de C.V. Distribuido por Sepomex.
www.sg.com.mx
 contenido
ago-oct 2008

20 EN PORTADA
Industria del Software en México
Presentamos un compendio de diferen-
tes perspectivas sobre nuestra industria.

Especial 16
Reseña de SG’08.

Productos
LO QUE VIENE 10
JBoss en EC2, Probe 8.0,
ADO.NET Entity Framework y TBB 2.1.

TUTORIAL 12
Silverligth.

Herramientas 14
Control de acceso basado en roles.

Prácticas
Columnas
ASEGURAMIENTO DE CALIDAD 38
Tejiendo Nuestra Red 06 Prueba de Software 54 Revisiones entre colegas
por Hanna Oktaba por Luis Vinicio León Un vistazo a los roles, tipos y fases de las revisiones
entre colegas, así como sus beneficios.
Mejora Continua 08
por Luis Cuellar Tendencias en Software 56 PROGRAMACIÓN 40
por Luis Daniel Soto Ruby y Rails
Columna Invitada 34 Última parte de este tutorial introductorio al lenguaje
por Héctor Obregón de Programación Ruby y el framework Rails.

ARQUITECTURA 44
En Cada Número Más allá del manual de usuario
Segunda parte sobre la documentación que
Noticias y Eventos 04 GADGETS 60 debe considerar el arquitecto de software.

FUNDAMENTOS 52 COMUNIDADES 62 SEGURIDAD 46

Aplicaciones Web seguras ¿mito
INFRAESTRUCTURA 58 o realidad?
Conozcamos los diferentes tipos de vulnerabilidades
exstentes en este rubro de las TI.

UML 48

18
Reconociendo los Diagramas
Mostramos las reglas básicas para reconocer
un buen diagrama de secuencia.

Entrevista PM CORNER 50
Christian Lemaître Mejores estimaciones para el
desarrollo de software
Conozcamos la técnica llamada Poker de Planeación.

www.sg.com.mx AGO-OCT 2008 03

 // NOTICIAS

Sun Tech Days México 2008

Del 21 al 23 de mayo el tour Sun Tech Days se hizo presente en
la ciudad de México festejando su décimo anversario. El even-
to de 3 días reunió a más de mil entusiastas de las tecnologías
de Sun, tales como Java, Solaris y Net Beans.

Este año se hizo notar el empuje que Sun le está dando a

NetBeans, de hecho en palabras de algunos asistentes el evento
consistió en “NetBeans, NetBeans y más NetBeans”, y es que
en la gran mayoría de las sesiones se demostraba cómo utilizar
esta herramienta en diferentes ámbitos, desde el desarrollo y
depuración de aplicaciones para dispositivos móviles hasta el
modelado y orquestación de web services.

Congreso Internacional ANADIC 2008

La Asociación Nacional de Distribuidores de Información y Co-
municaciones (ANADIC) realizó su octavo Congreso Internacional
2008, el cual se celebró en la ciudad de México del 12 al 16 de ju-
lio. El congreso contó con la participación de más de mil socios, y
una agenda conformada por talleres, conferencias, paneles, expo
y actividades recreativas. Durante la inauguración, Francisco
Wilson presidente de la asociación, habló sobre el papel funda-
mental que el canal desempeña en el mejoramiento de la indus-
tria. Durante el congreso se presentaron diferentes logros como:
Ciudades Inteligentes, Centros Autorizados de Servicio (CAS), y
ANADICSoft, proyecto que a través de la iniciativa “México va por
TI”, colocará las aplicaciones desarrolladas por los asociados en
las microempresas del país, con el apoyo de los gobiernos federal
y local, y con el compromiso y aportación de los asociados.

Encuentro Nacional PROSOFT 2.0

Bajo el lema “Consolidando la calidad de nuestra industria de TI”,
apoyando la misión de convertir a México en una potencia desarro-
lladora de software, se llevó a cabo el Encuentro Nacional Prosoft
2.0, del 27 al 28 de mayo, en la ciudad de México. Eduardo Sojo,
Secretario de Economía, aseguró que el gobierno es un gran impul-
sor de la industria de TI, y comentó que para consolidar este apoyo
se requiere de un trabajo conjunto entre todos los sectores del país:
público, privado, gobierno federal, estatal, e instituciones educati-
vas. De acuerdo a Rocío Ruiz, Subsecretaria de Industria y Comercio
de la SE, el encuentro permitió reflexionar sobre las acciones que
todos los sectores hemos emprendido en pro de nuestra industria
de TI, la cual hemos observado se ha ido convirtiendo en un motor
de nuestra economía.

04 AGO-OCT 2008 www.sg.com.mx

 // EVENTOs

14 al 15 de Agosto 2008 1 al 3 de Octubre 2008

5ª Reunión Regional CIAPEM ANIEI XXI Congreso Nacional y VII Congreso
Pachuca, Hidalgo Internacional de Informática y Computación
Info: www. ciapem.hidalgo.gob.mx ITESM Monterrey, Nuevo León
Info: www.aniei.org.mx

3 al 5 de Septiembre 2008
CIISA 2008 1 al 3 de Octubre 2008
Hotel Hilton, Guadalajara, Jalisco Cutter Summit América Latina
Info: www.ciisa.gda.itesm.mx Hotel JW Marriott, Cd. de México
Info: www.cutter.com.mx

8 de Septiembre 2008
IDC 4ª Cumbre de Gobierno y Tecnología 9 al 11 de Octubre 2008
Centro Banamex, Cd. de México Creanimax 2008
Info: www.idc-eventos.com/cumbregobierno08.html Expo Guadalajara, Guadalajara, Jalisco
Info: www.creanimax.com

23 al 26 de Septiembre 2008
XXXII Reunión Nacional del CIAPEM 29 al 31 de Octubre 2008
Mundo Imperial, Acapulco, Guerrero Gartner Future of IT
Info: www.guerrero.gob.mx/ciapem2008 Centro Banamex, Cd. de México
Info: www.gartner.com/it/summits/mex30ls

50 Años de la Directores TI 2008 Concurso e-Quallity 2008

Computación en México
Con el objetivo de conmemorar el ani-
versario de los 50 años de la computa-
ción en México, se están realizando di-
ferentes eventos de carácter nacional e
institucional, con la misión de integrar y
lograr una celebración que promueva el
conocimiento actual y las perspectivas
tecnológicas, reconociendo el esfuerzo
y trayectoria de todos los actores de la
historia durante estas cinco décadas. Se
invita a participar a todos los universita-
rios, la industria, asociaciones, cámaras,
gobierno, instituciones educativas y en
general a la comunidad de interesados
en las tecnologías de información y co-
municaciones. Mayor información en:
computo50.unam.mx
Enfocados en la problemática de
¿cómo cerrar la brecha entre el perfil
de los egresados y las necesidades en
el sector productivo?, se reunieron Di-
rectores de Informática y Computación
en la XVII Reunión Nacional organizada
por la ANIEI, los días 11 al 13 de junio
en Cancún, Quintana Roo.
Por medio de mesas de discusión inte-
ractivas se analizó la situación actual
de las instituciones, se identificaron
las necesidades de la sociedad, se ge-
neraron propuestas de cómo mejorar la
calidad de los egresados, y finalmente
se acordaron actividades que permiti-
rán definir el rumbo de la educación y
formación de profesionales en el área
de TI en México.
Por segundo año consecutivo este con-
curso convocó a la comunidad nacional
desarrolladora de software a enviar
productos pequeños terminados, para
encontrar los de menor densidad de de-
fectos. Aplicando pruebas exploratorias
se detectó una primera capa de errores;
utilizando esa información y su Modelo
Predictivo, e-Quallity generó una esti-
mación de las fallas todavía presentes;
el costo de detectarlos, y su compara-
ción contra la media de calidad de los
productos probados. La premiación se
realizó durante el congreso SG’08. Los
ganadores: 1o SAB- Sistema de Adminis-
tración de Bóveda versión 1.0 (Tbanc);
2o TEP- Teclado en Pantalla ver 2008.3
(Compucaja); 3o DSM versión 3 (Proeza TI)

Empresas recientemente evaluadas en CMMI:

Empresa Evaluación Fecha Lead Appraiser Apoyado por
Hildebrado Software Factory CMMI Nivel 5 septiembre 2007 Giuseppe Magnani Avantare
Vision Software Factory CMMI Nivel 2 diciembre 2007 Miguel Serrano Avantare
T-Systems CMMI Nivel 2 marzo 2008 Mariana Pérez-Vargas Avantare
Imagen Soft CMMI Nivel 3 abril 2008 Cecilia Scauso Innevo
Telepro CMMI Nivel 3 mayo 2008 Mariana Pérez-Vargas Avantare
Coppel CMMI Nivel 2 julio 2008 Cecilia Scauso Innevo

www.sg.com.mx AGO-OCT 2008 05

 // COLUMNA
Entre Lima y Berlín
Noticias de COMPETISOFT y de ISO/IEC WG24
La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tec-
nología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Actualmente es miembro de International Process
Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.
A finales de abril de 2008 tuvimos la reu-
nión del proyecto COMPETISOFT en Lima,
Perú. Asistieron 24 personas de diferentes
países como: España, Colombia, Argentina,
Chile, Uruguay, Ecuador, República Domini-
cana, Perú y México. El objetivo era revisar
resultados de pruebas controladas de im-
plementación de procesos de perfil básico
(Administración de Proyectos Específicos y
Desarrollo y Mantenimiento) en empresas de
estos países. Se siguió un proceso de mejo-
ra ágil PmCompetisoft diseñado, con base
en una propuesta colombiana, por Francisco
Pino. Los colegas académicos y sus alumnos
fungieron como consultores de las empresas.
El diagnóstico inicial arrojó los mismos resul-
tados, que en pruebas controladas en México,
es decir las empresas tienen prácticas muy
precarias. La generalización de esta situación
ayudó a ser más sinceros en el intercambio
de las experiencias. A pesar de trabajar en
países distintos, las pequeñas empresas re-
piten el mismo patrón, sacan buenos produc-
tos gracias a los individuos, pero no compar-
ten ni transmiten el conocimiento para que se
aproveche en la organización.
Lo interesante de PmCompetisoft es que tra-
baja en ciclos de mejora de 4 meses lo que
ayuda a las empresas tener un resultado visi-
ble a corto plazo. El denominador común de
las pruebas fue que, a pesar de no tener nin-
guna promesa de “certificación”, las empre-
sas expresaron su interés de continuar con el
esfuerzo de mejora de procesos. También fue
elogiada la versión coloreada por niveles de
capacidad de procesos. En particular, lo mar-
cado de amarillo ayuda a centrarse en cosas
básicas para la adopción del modelo.
No son muy significativos los cambios pro-
puestos al modelo de procesos como re-
sultado de más de dos años de revisar y
experimentar MoProSoft en los países ibe-
roamericanos. La más interesante propuesta
es la de separar el proceso de Mantenimiento
06 AGO-OCT 2008
/*TEJIENDO NUESTRA RED*/
del proceso de Desarrollo para poder atender
principalmente los mantenimientos rápidos
no planificados. Con respecto a otros proce-
sos se han propuesto las mejoras en algunos
detalles y nombres pero no en la estructura.
Se puede decir que el modelo sobrevivió la
prueba de revisión de hispano parlantes.
Como efecto lateral de este proyecto se ha
publicado en octubre de 2007 un artículo
en la popular revista IEEE Computer, titu-
lado “Software Process Improvement: The
Competisoft Project”, (H. Oktaba, F. García,
M. Piattini, F. Ruiz, F. J. Pino, C. Alquicira).
También, acaba de salir en abril de 2008
el libro editado por H. Oktaba y M. Piattini,
titulado“Software Process Improvement for
Small and Medium Enterprises: Techniques
and Case Studies”, de la editorial IGI Global.
En este libro encontrarán por supuesto un ar-
tículo sobre MoProSoft, pero también otros
cuatro capítulos escritos por autores mexi-
canos, entre ellos está el de Luis Vinicio León
Carrillo mi colega de la columna vecina en SG.
En mayo de 2008, Ana Vázquez y  su servidora
atendimos en Berlín la siguiente reunión del
grupo WG24 del ISO/IEC JTC1 SC7 (perdón
por tantos iniciales), en otras palabras, del
grupo en el cual se trata de incorporar los ele-
mentos del modelo de procesos MoProSoft
de la norma mexicana MX-I-059-NYCE en el
estándar internacional ISO/IEC TR 29110.
En esta ocasión teníamos que revisar los
comentarios recibidos de diversos países al
primer borrador del estándar (working draft).
El trabajo duró 5 días y fue bastante intenso
porque se tenía que decidir por cada comen-
tario si se aprobaba, si se aceptaba en princi-
pio o se rechazaba. En los dos últimos casos
se tenía que definir qué se iba a hacer en con-
creto o por qué se rechaza. Revisamos los co-
mentarios a las cinco partes del documento.
Afortunadamente, la parte 5.1 del estándar,
la cual contiene la aportación mexicana, tuvo
solo comentarios que servirán para mejorar
su presentación y explicación, sin modificar
el contenido a fondo. Ahora nos toca generar
la nueva versión de las cinco partes incorpo-
rando los comentarios y presentarlos nueva-
mente a la revisión internacional en calidad
del Comeetee Draft.
Lima me sorprendió por ser una ciudad mo-
derna y limpia (por lo menos la parte que me
tocó conocer) y que en Berlín todo mundo
anda en bicicleta y no solo los fines de se-
mana. De regreso aterricé en el evento de
Prosoft del 27 y 28 de mayo. Hay muchas
cosas que muestran los cambios favorables
que están sucediendo en nuestra industria
de software. La bolita de nieve echada a an-
dar hace pocos años empieza a crecer. Se-
guiremos acompañando su paso.
» Hanna Oktaba
www.sg.com.mx
www.sg.com.mx AGO-OCT 2008 07
 // COLUMNA
Logrando Metas
La Importancia de Identificar los Problemas
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.
El problema está en no ver cuál es el problema
H ace algunos días apoyé en una reunión para mejorar el proce-
so de administración de requerimientos en un proyecto. Dentro
de la discusión participaban varias personas, una de ellas decía: “El
problema es que tenemos que generar una forma automática de ad-
ministrar los requerimientos”. Otro decía: “Lo que pasa es, que el
cliente no sabe lo que quiere y cambia mucho los requerimientos”.
Finalmente una persona más decía: “Yo creo que estamos bien, sólo
tenemos que hablar con el cliente para que administre sus requeri-
mientos”. Después de un rato de que esto siguiera adelante, empe-
cé a preguntarme si realmente alguien sabía ¿cuál era el problema
que se quería resolver?, ¿para qué necesitamos digitalizar?, ¿por
qué es un problema que se cambien los requerimientos? o ¿por qué
es importante que se administren estos?
Cientos de veces grupos de personas se unen a discutir la forma de so-
lucionar algún problema, sólo para que la mayoría termine frustrado,
con la sensación de que no fue escuchado o que la decisión final no
arreglará nada. Terminan discutiendo lo que cada quien cree que es la
respuesta para lo que cada quien cree que es un problema y como es
de imaginarse, los resultados no siempre son los más adecuados.
¿Cómo hacemos más eficiente una reunión de resolución de pro-
blemas? y ¿cómo aseguramos que aplicamos nuestros recursos al
problema adecuado?
¿Cuál es nuestro problema?
Según Wikipedia se define como problema: “Un obstáculo el cual
hace difícil lograr una meta, objetivo deseado o propósito. Se refiere
a una situación, condición o asunto que no se ha resuelto. En un sen-
tido amplio un problema existe cuando un individuo se da cuenta de
una diferencia significativa entre lo que actualmente es y lo que es
deseado”. La parte clave desde mi punto de vista en esta definición
es: una meta, objetivo o propósito.
Dependiendo del contexto de la reunión, la frase:  “el cliente no sabe
lo que quiere y cambia mucho los requerimientos”, no es un problema,
dado que normalmente no tenemos un objetivo sobre el número de
requerimientos máximos que puede tener un cliente, sólo lo sería si en
nuestro proceso establecemos un número máximo de requerimientos
que estamos dispuestos a aceptar y el cliente está de acuerdo con esa
definición o si el objetivo de la reunión es: ¿Cómo controlamos las po-
sibilidades que tiene el cliente de  atrasar el proyecto?. Esta diferencia
entre cual es el objetivo de la reunión y algunas veces el objetivo de
cada individuo dentro de la reunión, es uno de los elementos que ha-
cen verdaderamente complejo el definir claramente un problema.
08 AGO-OCT 2008
/*MEJORA CONTINUA*/
¿Qué es primero el problema o la solución?
Otra limitante en esta definición, se debe al hecho que nuestra cultura
se enfoca principalmente a resultados y tiene fuertemente arraigada
la idea de valorar a la gente que trae a la mesa soluciones. Todos los
libros de administración y liderazgo, enfatizan la importancia de dar
soluciones en lugar de problemas. Esto es bastante lógico, yo mismo
espero que la gente que trabaja conmigo esté siempre buscando so-
luciones a los problemas que enfrentamos. Pero creo que en algunos
casos, estamos llevando la situación más allá de lo debido, estamos
brincando por completo la fase de identificar el problema y estamos
saltando directamente a encontrar soluciones.   En la frase “tenemos
que digitalizar el proceso de requerimientos” el objetivo es ser más
eficientes en la recepción de estos, el digitalizar se consideraría más
bien una forma de resolver el problema.
Adicionalmente en el punto anterior existe otra complejidad, qué su-
cede si yo ya revisé todos los elementos para hacer más eficiente la
administración de los requerimientos y ya concluí que la única forma de
arreglar ese punto es a través de digitalizar el proceso. ¿No sería enton-
ces válido decir que el problema es digitalizar el proceso e iniciar desde
ahí en lugar de volver a analizar esa parte? La respuesta es un definitivo
“Sí”. Pero las confusiones surgen cuando el grupo no concuerda con el
problema o no entiende las causas que los llevaron a donde se encuen-
tran. Por lo tanto es imprescindible que al presentar la propuesta sea
como la solución a un análisis previo y el grupo este de acuerdo con
esta premisa. De esta manera no puede haber malos entendidos.
 
El problema es la mitad de la solución
En conclusión encontrarse en una reunión donde se discute un pro-
blema deben de considerarse los siguientes puntos.
1. Al inicio de toda junta de resolución de problemas debe de quedar muy
claro qué es lo que se pretende resolver y por qué se pretende resolver.
2. Cada vez que escuchemos una frase planteada como un problema
nos debemos de preguntar ¿por qué? Es importante hacer esta pre-
gunta por lo menos hasta llegar al punto que realmente represente
una diferencia entre una situación real y una meta deseada.
3. Finalmente a la presentación de un problema siempre utiliza las
palabras mágicas: ¿cuál es el problema?, ¿qué lo provoca?, ¿dón-
de está?, ¿quién lo genera?, ¿cuándo surge?; estas preguntas darán
mucho mejor idea de lo que se quiere resolver.
Como responsable de cambiar a la organización a ser mejor, es su-
mamente importante tener claro el problema a resolver. De tomar
una acción, normalmente los recursos son limitados y el avance es
mayor cuando está claro hacia donde se va.
» Luis R. Cuellar
www.sg.com.mx
www.sg.com.mx AGO-OCT 2008
 // PRODUCTOS /* LO QUE VIENE*/
JBoss disponible en EC2
Servidores de aplicación desde la nube
Una de las noticias más significativas de las últimas semanas
en el ámbito del cómputo en la nube, o cloud computing, es
el hecho de que Red Hat ya ofrece el servidor de aplicaciones
JBoss a través de Amazon Elastic Compute Cloud (EC2).
Técnicamente, no hay nada nuevo. Después de todo, un usua-
rio puede entrar a EC2 e instalar lo que quiera dentro de su má-
quina virtual. Sin embargo, aquí lo notable es que ya estamos
hablando de una oferta comercial de clase empresarial.
Este esquema le permite a Red Hat distribuir su software (y co-
brar por él) a través de un nuevo canal, sin necesidad de tener
que atender directamente a los clientes. Por su parte, Amazon
agrega una oferta de clase empresarial que le anota muchos
puntos en su búsqueda de posicionamiento como una opción
real para los corporativos.
Veremos que tal responde el mercado a esto, y cómo es que
los demás proveedores de software empresarial se van su-
biendo a la nube.
JProbe 8.0
Profiling de código Java
Quest Software anunció la disponibilidad de JProbe 8.0,
la versión más reciente de su legendaria herramienta de
“profiling” de código Java. Esta nueva versión ahora se
ofrece como un plug-in de Eclipse, lo cual facilita signifi-
cativamente su uso.
JProbe 8.0 permite a los usuarios de Eclipse rápidamente
identificar y resolver problemas de memoria y cobertura
de código en sus aplicaciones Java, fomentando así el de-
sarrollo de aplicaciones de alta calidad. En los próximos
meses, Quest le agregará a este plug-in capacidades de
análisis de desempeño, para que los usuarios puedan in-
vestigar cuellos de botella en sus aplicaciones desde el
mismo ambiente de Eclipse.
10 AGO-OCT 2008
ADO.NET Entity Framework
Mapeo objeto-relacional para .NET
Uno de los aspectos de mayor importancia en cual-
quier plataforma moderna para desarrollar aplicacio-
nes empresariales, es cómo resuelve el mapeo entre
los objetos de negocio y los datos de una base de da-
tos relacional. En el caso de la plataforma .NET, a pe-
sar de que cuenta con algunos mecanismos (como el
objeto DataSet) que ayudan un poco a resolver este
problema, hasta ahora no existe una solución com-
pleta de ORM (object-relational mapping).
El ADO.NET Entity Framework viene a llenar ese hue-
co, y será el primer framework ORM que Microsoft
introduce para la plataforma .NET. El ADO.NET Entity
Framework forma parte del service pack 1 del .NET
Framework 3.5, el cual ya se encuentra disponible
como beta y cuya versión final se espera sea liberada
antes de que termine el año.
Thread Building Blocks 2.1
Threads a prueba de tontos
Intel liberó la versión 2.1 de Thread Building Blocks
(TBB), que es una librería de C++ para facilitar la im-
plementación de threads en las aplicaciones, mejo-
rando así su desempeño en procesadores multi-core.
Una de las principales fortalezas de la versión 2.1 de
TBB es el nuevo mecanismo de correspondencia en-
tre tareas y threads (task-to-thread affinity) que pro-
vee grandes mejoras de desempeño.
TBB 2.1 es software libre licenciado como GPLv2 y
está disponible para plataformas Windows, Linux,
Solaris y Mac OS X. En el caso de los desarrolladores
de .NET, también pueden aprovechar el nuevo plug in
de TBB para Visual Studio.
www.sg.com.mx
www.sg.com.mx AGO-OCT 2008
 // PRODUCTOS
Desarrollo de Aplicaciones con Silverlight
Parte 1. Introducción
Por Guillermo Morales
Silverlight es la tecnología recientemente
propuesta por Microsoft para desarrollar
aplicaciones web de alto impacto visual. El
objetivo de esta serie de artículos es enca-
minarlos a cómo crear su primera aplicación
con Silverlight.
Los archivos de una aplicación
Silverlight
Todo lo que podemos hacer hoy en día con
Silverlight 1.0, se puede crear mediante
cualquier editor de texto. En nuestro caso,
usaremos al famoso Notepad. Pensemos
que tenemos una página llamada Default.html
en donde queremos crear nuestra primera
aplicación de Silverlight.
Entonces, los archivos que necesitamos
crear son:
• Default.html - Esta será la clásica página
web a donde navegaremos. Invoca al plugin
de Silverlight.
• Silverlight.js - Un archivo con las instruccio-
nes en javascript para validar que el browser
tenga el plugin de Silverlight. Este archi-
vo viene incluido en el SDK de Silverlight
y está listo para usarse, por lo que no es ne-
cesario modificarlo.
• Archivo *.xaml - Este archivo contiene las
instrucciones en lenguaje XAML (eXtensible
Application Markup Language) que definen
los elementos de la interfaz de usuario (UI)
de nuestra aplicación.
• Archivo *.js - Contendrá el código javascript
necesario para invocar el plugin de Silverlight
e indicarle el XAML que debe cargar.
Guillermo Morales colabora actualmente en InterSoftware, empresa dedicada a la capacitación especializada en desarrollo de software. Con un perfil técnico,
se ha desenvuelto en varias áreas del proceso de desarrollo de aplicaciones, desde la implementación, hasta la administración de proyectos. Es cofundador de la
comunidad de desarrollo en México www.developersdotnet.com en donde, frecuentemente se reúne con otros expertos de desarrollo de aplicaciones para la
difusión de tecnologías nuevas.
12 AGO-OCT 2008
/*TUTORIAL*/
hostdelplugin, // Variable que apunta al DIV host.
Veamos ahora el contenido inicial de cada “miHostdelPlugin”, // El ID de la etiqueta DIV host.
archivo. {
width:’300’, // Ancho del plugin en pixeles
Listado 1. Default.html height:’300’, // Alto del plug in en pixeles
<html> inplaceInstallPrompt:false, // Indica si pregunta si se
<head> // instala el plugin si no es la
<title>Primer Ejemplo Silverlight</title> // versión correcta
<script type=”text/javascript” src=”Silverlight.js”> background:’#D6D6D6’, // Color Background del plugin
</script>
<script type=”text/javascript” src=”crearSilverlight.js”>
isWindowless:’false’, // Determina si el plug in se
// muestra en modo sin ventana
</script> framerate:’24’, // Número de cuadros por segundo
</head> version:’1.0’ // Versión Silverlight a usar.
<body> },
<!-- Este DIV será el contenedor del Plugin de {
Silverlight--> onError:null, // Manejador de función cuando hay error
<div id=”miHostdelPlugin”> onLoad:null // Manejador de función carga del plug in
</div>
});
<script type=”text/javascript”> }
// Obtener el DIV host del plug in.
var hostdelplugin = document.getElementById(
“miHostdelPlugin”); Este archivo contiene la función que invo-
// Creación del plugin camos desde el html, lo que hace es indi-
crearPluginSilverlight(); carle al navegador que hay que invocar al
//Llamada a la función del archivo de abajo método createObject del objeto Silverlight
</script> para poder crear un plugin de acuerdo a
</body> ciertos parámetros.
</html>
Listado 3. mixaml.xaml
Como se dan cuenta, esta página es muy sen- <Canvas
cilla. Carga un par de archivos de javascript e xmlns=”http://schemas.microsoft.com/client/2007”
invoca una función para cargar nuestro com- xmlns:x=”http://schemas.microsoft.com/winfx/2006/
xaml”>
ponente de Silverlight.
</Canvas>
Como ya se indicó, el archivo Silverlight.js ya
viene incluido en el SDK de Silverlight y no se
modifica, así que solo necesitamos ponerlo Como habíamos indicado, el archivo xaml
en un directorio de donde podamos cargarlo. define la parte visual. Por lo pronto, lo único
que tenemos definido es un canvas vacío,
Listado 2. crearSilverlight.js el cual vamos a utilizar para desplegar ele-
function crearPluginSilverlight() mentos visuales.
{
Silverlight.createObject( Si se echa a andar la página web, obtene-
“mixaml.xaml”, // El XAML a pintar.
mos la siguiente pantalla por el momento:
www.sg.com.mx
 “El archivo XAML define los elementos
de la interfaz de usuario (UI) de nuestra
aplicación”.
Figura 1. Canvas en blanco
El color del fondo del plugin debe ser el in-
dicado de acuerdo a los parámetros que di-
mos en nuestra función. Ahora crearemos el
contenido visual de nuestra aplicación.
Modificando el archivo XAML
Como ya vimos, nuestro archivo mixaml.xml
contiene el XAML para definir el contenido
visual. Todo se pinta dentro de un lienzo
sobre el cual se puede pintar y posicionar
elementos. De esta manera, si modificamos
nuestro archivo mixaml.xaml para que que-
de como el listado 4, obtendremos un des-
pliegue como el de la figura 2.
Listado 4. mixaml.xml invocando elemen-
tos visuales
<Canvas
xmlns=”http://schemas.microsoft.com/client/2007”
xmlns:x=”http://schemas.microsoft.com/winfx/2006/
xaml”>
<Rectangle
Canvas.Top=”30” Canvas.Left=”30” Fill=”Blue”
Height=”100” Width=”100” />
<Rectangle
Canvas.Top=”80” Canvas.Left=”80” Fill=”Red”
Height=”100” Width=”100” />
<Ellipse
Canvas.Top=”130” Canvas.Left=”130” Fill=”Green”
Height=”100” Width=”100” />
</Canvas>
www.sg.com.mx
Figura 2. Canvas con elementos visuales
¡Perfecto! Has creado tu primera aplicación
Silverlight. En la siguiente entrega de esta
serie estaremos viendo como poder res-
ponder a eventos del mouse y lanzar algu-
na animación.
Conclusión
El desarrollo con Silverlight está basa-
do en una serie de archivos que con-
tienen indicaciones para:
• Creación del Plugin de Silverlight (ar-
chivo crearSilverlight.js)
• La declaración de los elementos
visuales a crear (mixaml.xaml)
• La página web que hostea al plug in
(default.html)
• El código de validación de la exis-
tencia del plug in, este archivo es
parte del SDK de Silverlight y general-
mente no deberíamos de modificarlo
(Silverlight.js).
Referencias
[developersdotnet.com]
AGO-OCT 2008 13
 //PRODUCTOS
Control de Acceso Basado en Roles
Factores a Considerar en Una Solución
Por Equipo Editorial
Prácticamente todas las aplicaciones em-
presariales requieren contar con capacida-
des de control de acceso. Es decir, restringir
las operaciones que puede realizar un usua-
rio. Uno de los esquemas más comunes es
el control de acceso basado en roles, tam-
bién conocido como RBAC por sus siglas en
inglés (Role Based Access Control).
Es muy común que en nuestras aplicaciones
implementemos nosotros mismos el control
de acceso como parte de su desarrollo. Sin
embargo, también existen productos listos
para usarse que resuelven este problema.
En este artículo explicamos las principales
características que debe cumplir un buen sis-
tema de control de acceso basado en roles.
Funcionalidad
Un sistema RBAC debe proveer como míni-
mo tres diferentes grupos de funcionalidad:
autenticación, autorización y auditoria.
• Autenticación. Capacidad de validar la
identidad de un usuario. Típicamente se
realiza por medio de nombres de usuario y
contraseña.
• Autorización. Es la definición de qué es lo
que un usuario específico puede hacer den-
tro de una aplicación, es decir a qué infor-
mación y operaciones tiene acceso.
• Auditoría. Se refiere a la capacidad de man-
tener un registro de las transacciones sensi-
tivas de una aplicación. La auditoria permite
saber quién hizo qué, cuando lo hizo, y quién
le dio los permisos necesarios a ese usuario.
Componentes
• Repositorio. Se requiere de un lugar se-
guro para almacenar los usuarios, contrase-
ñas, roles y permisos.
• Interfaz entre aplicación y repositorio.
Este es el componente intermedio que sirve
de interfaz entre una aplicación y el reposi-
torio de seguridad.
• Consola de administración. La consola que
permite administrar las cuentas de usuario,
14 AGO-OCT 2008
/*HERRAMIENTAS*/
roles y permisos. Debe ser sencilla de usar,
de forma que gente no técnica pueda reali-
zar estas tareas.
• Documentación. Un elemento comúnmente
olvidado, que sin embargo es necesario para
tener un proceso de seguridad confiable y
que no dependa de personas específicas.
Es altamente recomendable que los detalles
para el control de acceso a aplicación no es-
tén definidos dentro del código de la aplica-
ción misma, sino que se realicen a través de
un componente externo que interactúe con
un repositorio de permisos, tal como se in-
dica aquí. Esto permite tener independencia
entre el código de la aplicación y el control de
acceso, lo cual es deseable ya que así no ne-
cesitamos modificar la aplicación y lanzar una
nueva versión cada que tengamos que hacer
un cambio en la política de accesos. Otra ven-
taja es que no necesitamos a personas que
entiendan el código de la aplicación, para po-
der hacer ajustes en el control de acceso.
Factores a considerar al diseñar
un sistema RBAC
Estos son algunos de los principales fac-
tores a considerar al diseñar o escoger un
sistema RBAC.
• Repositorio centralizado. Considera si es
que necesitas centralizar el manejo de permi-
sos de varias aplicaciones en un solo reposi-
torio. Incluso podrías requerir que los roles se
puedan compartir entre varias aplicaciones.
• Single sign-on. Single sign-on se refiere a
la capacidad de que los usuarios se auten-
tiquen una sola vez al inicio de una sesión
y posteriormente puedan utilizar varias apli-
caciones sin necesidad de estarse autenti-
cando para cada una.
• Soporte a diversas tecnologías. La mayo-
ría de los ambientes corporativos cuentan
con múltiples plataformas aplicativas, así
como tipos de cliente (desktop, web, móvil).
Desarrolla o escoge un sistema RBAC que
funcione adecuadamente con las diferentes
plataformas tecnológicas que se utilizan en
tu organización.
• Granularidad. La forma más básica de
control de acceso consiste en restringir el
acceso a pantallas o menús. Sin embargo,
frecuentemente se requiere de una mayor
granularidad, como podría ser tener control
a nivel de cada campo de información, o que
un listado contenga datos diferentes para
usuarios dependiendo del rol que tengan, o
que un proceso de negocio tenga diferentes
pasos dependiendo del perfil del usuario.
Opciones en el Mercado
La mayoría de las organizaciones optan por
desarrollar su propia solución para control
de acceso. Sin embargo, difícilmente toman
en cuenta todos los aspectos que hemos
mencionado en este artículo y por lo tanto
terminan con soluciones que no resuelven
todas las necesidades y que además son di-
fíciles de mantener.
En el otro extremo se encuentran las plata-
formas empresariales para manejo de iden-
tidades y acceso. Gartner identifica como lí-
deres en esta categoría a proveedores como
IBM, CA, Oracle y Sun. Estas plataformas
brindan poder y flexibilidad, pero a costa
de complejidad y en la mayoría de los casos
requieren in
Como un punto medio entre las soluciones
desarrolladas internamente, y las platafor-
mas empresariales, tenemos herramientas
comerciales dirigidas a asegurar aplica-
ciones individuales, de forma sencilla y no
intrusiva. Entre las opciones más notables
de este segmento está Visual Guard, de la
empresa francesa Novalys. Esta herramienta
ofrece un muy buen balance entre el poder
de sus capacidades, y su facilidad de imple-
mentación. La limitante es que solo está dis-
ponible para plataformas .Net y PowerBuil-
der, pero si desarrollas aplicaciones sobre
estas tecnologías, bien vale la pena echarle
un vistazo.
Referencias:
[ Gartner Magic Quadrant for Web Access
Management, 2H07 ]
[ Novalys Whitepaper: Role Based Access
Control for .NET applications ]
[ visual-guard.com ]
www.sg.com.mx
www.sg.com.mx AGO-OCT 2008
 n la
xpo e
re n c ia y E MTOUR
nf e P
’08 Co onjunto con Capítulo
g re so SG e n c P M I
el co n alizó por ntes,
v ó a cabo vento se re organizado a los asiste oft-
lle le s r s
io se ión, e oyecto or valo esarrollo de de
l 2 4 de jun n esta ocas cción de Pr rindar may d e d a m p li o
a E e b s
Del 21 de México. reso de Dir ración fue conferencia pectro más nió a más
d ng bo a es u
Ciuda 2008, el co e esta cola ron asistir vieron un congreso re otras 400
ic o o d u d ie y t u g. E l ás ed
Méx tiv p s, xpo
x ic o . El obje ismo precio e proyecto r networkin ncias, adem nte a la e n
Mé u n m c ió n d s h a c e n f e re o la m e a ra u
a q u e por o de direc on quiene n t e s en co istieron s u n id ad, p
y ware sc iste e as com tentes
.
colega de 400 as rsonas qu niones de 00 asis
pe y reu l d e 8
tota

16 AGO-OCT 2008 www.sg.com.mx

Keynotes
Las conferencias magistrales de software co-
rrieron a cargo de Jon “maddog” Hall, Terry
Quatrani, y John Crupi. Maddog, como de cos-
tumbre inspiró a la audiencia y les hizo ver di-
ferentes opciones de cómo hacer dinero con
software libre. Terry, quien fue la más laurea-
da del congreso, se enfocó en compartir ideas
prácticas sobre modelado ágil de software.
Su plática bien pudo haberse titulado “Cómo
modelar sistemas de software de forma que
sea útil y sin que llegue a convertirse en una
pesadilla”. Por último, John, quien nos ha-
bía quedado a deber su participación desde
SG ’06, nos dio una muestra clara de cómo se
pueden aplicar mashups en las empresas, y la
audiencia no pudo hacer más que quedarse
boquiabierta ante las cosas que vio durante
esta presentación.
Sesiones paralelas
Como de costumbre, las sesiones paralelas
corrieron a cargo de profesionistas locales,
buscando así dar una muestra de lo que
realmente sucede en las organizaciones de
nuestro país. En esta ocasión se llevaron a
cabo cinco tracks paralelos, algunos con te-
mas de dirección de proyectos y otros con
temas de desarrollo de software. Esto resul-
tó en más de 35 sesiones paralelas en dos
días, con lo que se logró cubrir una
amplia variedad de temas.
De las sesiones paralelas, la mejor
evaluada fue la de Héctor Obregón
www.sg.com.mx
titulada “De 0 a 300 a 0 en 6 años”, con una ca-
lificación de 4.63 en escala del 1 al 5, seguida
por “CMMI para Adquisiciones” de Carlos Pérez
(4.60) y “CMMI Ágil” de Ernesto Elizalde (4.55).
Agradecemos a todos los conferencistas, que
son quienes hacen realidad este congreso.
Tutoriales
Posiblemente, el aspecto en el que más tra-
bajamos para mejorar este año fue el de los
tutoriales, ya que estábamos concientes de
que había sido el aspecto más irregular en
años anteriores. Así que para este año hici-
mos varios ajustes, tales como realizar los
tutoriales el fin de semana previo a las con-
ferencias, e invitar exclusivamente a empre-
sas de servicios educativos con un record
demostrado. El resultado fue favorable, ya
que logramos una muy alta satisfacción de
los asistentes.
Agradecemos a todas las empresas que par-
ticiparon impartiendo tutoriales, y hacemos
un reconocimiento especial a Activ, cuyo
tutorial “Desarrollo de Rich Internet Appli-
cations con Flex” fue el mejor evaluado de
los tutoriales relacionados con desarrollo de
software.
Evento social
En esta ocasión el evento social consistió
en una fiesta donde los asistentes se junta-
ron en grupos para jugar el videojuego rock
band. Esta dinámica brindó diversión y con-
vivencia (y conbebencia también) entre los
asistentes. Finalizamos con un concurso en-
tre bandas, y los ganadores fueron el grupo
denominado “Los Twitteros Rabiosos”, inte-
grado por personas de la empresa Intellekt.
¿Qué sigue?
SG ’08 marcó la tercera edición de este con-
greso. A lo largo de estos años hemos ex-
perimentado diferentes opciones de temas,
actividades y formatos para lograr brindar
a los profesionistas de software de nuestro
país un congreso de clase mundial. La re-
troalimentación de los asistentes nos indica
que esta misión se ha cumplido, y que SG
Conferencia y Expo es el mejor congreso de
software de Latinoamérica. Sin embargo,
lo que no hemos logrado es ofrecer tarifas
accesibles para la mayoría de los profesio-
nistas de nuestra región. Esta situación se
complica aun más en el contexto de la gran
cantidad de eventos gratuitos que se reali-
zan en la Ciudad de México.
Es así que actualmente estamos estudiando
alternativas para poder seguir ofreciendo
este congreso con un alto nivel de calidad,
pero en un precio y formato accesible. En
cuanto tengamos noticias al respecto, se
las haremos llegar. Mientras tanto, agra-
decemos a Secretaría de Economía por su
apoyo mediante PROSOFT, así como a todos
los patrocinadores, conferencistas, volunta-
rios y asistentes que han hecho posible este
congreso durante tres años.
AGO-OCT 2008 17
 // ENTREVISTA

Christian Lemaître y León nació en la ciudad de México, cursó la licenciatura en Física en la

Universidad Nacional Autónoma de México y el doctorado en Informática de la Universidad
de Paris VI. Ha realizado labores de docencia, investigación, desarrollo de innovaciones
tecnológicas y consultoría. Fundador de varias organizaciones científicas de compu-
tación  de México y del extranjero entre las que destacan la Sociedad Mexicana de
Inteligencia Artificial (SMIA), la Sociedad Mexicana de Ciencia de la Computación
(SMCC), La Organización Iberoamericana de Inteligencia Artificial, (IBERAMIA)
y la International Foundation for Multiagent Systems (IFMAS). Fue igualmen-
te miembro fundador del Laboratorio Nacional de Informática Avanzada
(LANIA A.C.), y Director Académico del mismo de 1997 a 2002.

Desde octubre 2005 se desempeña como Jefe del Departamento

de Tecnologías de la Información de la División de Ciencias de la
Comunicación y Diseño de la UAM-Cuajimalpa

ee o
îîttrr
xic
Mé
maa
en
ión
eem
tac
pu
om
nn LL
aC
el
sd
ttiiaa
cia
en
Ci
rriiss
as
el
rd
do
CChh
da
fun
ru
Gu

18 AGO-OCT 2008 www.sg.com.mx

Existen entre 50 y 70 mil
egresados sin empleo,
¿a qué se debe esto?
Creo que uno de los problemas es la facilidad
para crear carreras y maestrías. Tengo enten-
dido que alrededor del 12% de la matrícula
universitaria son estudiantes de carreras re-
lacionada con TI. Eso es muchísima gente,
mucho más de la que podemos sustentar con
un alto nivel de calidad.
Sé que la ANIEI está trabajando para mejorar
esto, pero es un reto significativo y están lu-
chando contra corriente.
¿Qué opinas sobre las
certificaciones?
Yo entiendo el énfasis que se le está dan-
do en la industria a las certificaciones. Si
estamos generando a nivel nacional tanto
egresado que tiene un título pero cuyas
competencias no cubren los requerimientos
básicos, o están en duda, entonces desgra-
ciadamente sí tenemos que recurrir a los
proveedores o empresas terceras para que
validen esto. Sin embargo, esto no es muy
eficiente a nivel nacional, ya que estamos
multiplicando las acreditaciones y quitán-
dole peso al trabajo de las universidades.
Por dar un ejemplo, yo creo que un ingeniero
recién egresado que tiene buenos fundamen-
tos de base de datos, y tiene experiencia con
una base de datos que puede ser de software
libre, entonces el día de mañana que en su
trabajo necesite aprender Oracle, va a tener
las bases para hacerlo. Y si la empresa donde
está necesita acelerar ese proceso y hacerlo
un experto, entonces va a tener que capaci-
tarlo y certificarlo. Eso es válido y compren-
sible, especialmente en un campo que evolu-
ciona tanto como el nuestro.
¿Hay que generar gente
pensante o certificada?
Creo que este es un falso dilema. Quienes
pretenden tener a jóvenes que al salir de la
escuela estén certificados en tecnologías y
versiones específicas, no están planteando
bien el problema. La universidad no tiene
porque estar haciendo eso, y más en un área
con el ritmo de cambio de la computación.
Sí estoy de acuerdo en que debemos ense-
ñar a los jóvenes a utilizar las herramientas
del momento, pero no creo que debamos
orientarnos hacia las certificaciones ni basar
cursos en el temario de una certificación. La
www.sg.com.mx
responsabilidad social de la universidad es
sacar muchachos con una preparación sóli-
da en los fundamentos, y capaces de seguir
la evolución de la computación. Es decir, de-
bemos generar gente que luego va a crecer.
El problema es que en muchos casos esa
no es la visión del empleador. A él lo que
le interesa es contar con alguien que le re-
suelva un problema en específico, y le tiene
sin cuidado el crecimiento de la persona.
Esto es un error, porque si las empresas
quieren crecer entonces necesitan gente
capaz de crecer.
¿Qué otros elementos, además
de los técnicos, deben ofrecer
las universidades para atraer a
los alumnos en este tipo de
carreras?
El gran problema que tiene la computación,
principalmente aquí en México es su éxito
comercial, porque lo primero que se ve es
la parte física de la computadora, las nove-
dades, las últimas aplicaciones que pueden
ejecutarse en ella, opacando la parte de
atrás, el esfuerzo que se hace para sacar
esas novedades y lo que vendrá durante los
siguientes años.
Hoy en día, los alumnos pueden hacer toda
la carrera de computación con su computao-
ra casera sin ningún problema. Esto es bue-
no, ya que en todo caso lo centra en lo que
realmente debe aprender. Es así que temas
como los algoritmos o las estructuras de
datostoman mayor importancia que el sim-
ple uso de la máquina.
¿En la universidad ya es muy
tarde para revertir la mentalidad
de consumo y fomentar la
creación e investigación?
El problema es de base y muy serio; nues-
tro nivel educativo tiene mucho que ver en
este aspecto.  Nos cansamos de escuchar
los resultados que tienen los alumnos en
los examenes reflejando un problema se-
rio. No se les está inculcando “el gusani-
to” de buscar las cosas. Pese a eso, siem-
pre existirán los jóvenes que tienen esa
curiosidad por ver más allá del caparazón
a una computadora.
Debido al dinamismo del área siempre exis-
tirán nuevas oportunidades, pero es des-
gastante ver cómo pasan los trenes.
¿Cómo es tu perspectiva de la
industria del cómputo
actualmente en México?
Creo que se están comenzando a hacer co-
sas interesantes, como por ejemplo en Gua-
dalajara, que desde años atrás fue un punto
de concentración en las áreas de la electró-
nica. Con altas y bajas, ha habido una cierta
continuidad en esta zona, y esto es algo que
hace falta en el país; darle seguimiento a
todo lo que se realiza para que poco a poco
se consoliden cosas y los proyectos.
¿En qué nicho(s) del mercado
interncional de TI debería
enfocarse México?
No estoy seguro, creo que eso deberá ser
el resultado de algo previo. Creo que pri-
mero debemos enfocarnos en resolver pro-
blemas locales. Sentarnos a resolver lo que
tenemos cerca. La India estuvo 15 años ge-
nerando capacidad, y luego se abrió.
Los problemas nacionales requieren de
muchísimo esfuerzo, y yo creo que eso
será un detonador importantísimo. Por
ejemplo, si requerimos sistemas para me-
jorar la producción en los campos agríco-
las, este puede ser un terreno interesante
y con potencial para las empresas locales,
que posteriormente pueden ofrecer esto a
nivel internacional.
¿Qué tendencias de TI conside-
ras de mayor relevancia hacia los
próximos años?
La interacción es una palabra clave, el cóm-
puto obicuo, las redes inalámbricas. Se
están multiplicando las posibilidades de in-
teracción entre los sistemas y las personas,
Descubriéndose las posibilidades de la red
en términos abstractos. Tanto a nivel social
(conectividad social) como individual (con
un aparato); la interactividad es una de las
grandes áreas que involucran una evolución
de servicios, las comunicaciones apenas es-
tán comenzando a ver su triple play :)
Algunas palabras para nuestros
lectores
En particular la computación, sigue siendo
una área absolutamente fascinante y que
vale la pena meterse de lleno, infinitamente
maleable. No necesita una infraestructura
de plantas sofisticadas para poder experi-
mentar con ella. Puede ser muy divertida y
al mismo tiempo múy útil.
AGO-OCT 2008 19
 é x i c o
iccoo
nM M
M é é x x i
d ee
e T
TTIIIeeenn cía
i a
a
uuussstttrrriia d
d u is F c o. Gar
a IInndd
d
L

e
e ttooss dddeeelllaa In
RR etos s e están
R anos
qu e
e Bas
e
l o s Mexic conomía d
n
u i d a do co a c í a una E
¡C n do H
n i z a
Orga
n o l ó gica!
Tec

20 AGO-OCT 2008 www.sg.com.mx


Lo cierto es que si en México tenemos la oportuni-
dad de encontrar una fuente de ingresos robusta en
la industria de servicios TIC’s, esto requiere que nos
organicemos antes de que ésta ventana se cierre
frente a nuestros ojos.
En este artículo quiero hablarle del siguiente esca-
lón que necesitamos construir para llevar la oferta
mexicana hacia un nivel favorable ante los merca-
dos globales. Se trata de ir más allá de la práctica y
de incorporar a nuestras organizaciones habilidades
competitivas que tienen que ver con aspectos de ne-
gocio, de comunicación organizacional y comercial.
» Una vista al panorama actual y retos
identificados
Ya hemos visto que la oferta mexicana en cuanto a
tecnología y sus atributos es suficientemente com-
petitiva como para encontrar un lugar entre las me-
jores propuestas del mundo. Esta oferta de calidad y
conocimientos especializados debe complementar-
se con habilidades de negocio y de comunicación
organizacional, los resultados a su vez sembrarán
crecimiento continúo y sostenido.
Estos resultados pueden ser por ejemplo, el lograr
que alguna empresa mexicana sea considerada por
primera vez como un proveedor para contratos ma-
yores a los mil millones de dólares, tal como los más
de 20 que han firmado en los últimos 3 años empresas
como: Cognizant, HCL Technologies, Infosys, Patni,
Satyam, Tata Consultancy Services (TCS), Wipro,
CPM, EPAM, Luxoft, y por supuesto las empresas de
costumbre como son IBM, EDS, Perot Systems, CSC
y Accenture entre otras. Un contrato de ese tamaño
es capaz de dar trabajo a 2,000 personas durante
cinco años, por ello lo estratégico de los mismos.
Un paso será saltear los retos que se enfrentan en
nuestra industria, que han impedido que las em-
presas mexicanas crezcan más allá de los 5,000 em-
pleados, ya sea por dificultad de localizar suficiente
talento o por la curva de aprendizaje ante de pro-
moción y capitalización de las oportunidades en los
mercados globales. Una característica de nuestro
país es también la disparidad de demanda y oferta
entre las regiones y estados, esto hablando del mer-
cado interno que es la principal fuente de ingresos
de nuestro sector.
Por ejemplo, ante demanda estadounidense, una
de las estrategias que han seguido empresas mexi-
canas es la de proveer a través de sub-contratación.
Una estrategia razonable dados nuestros niveles de
penetración a los mercados globales y de competi-
tividad en aspectos no-tecnológicos.
www.sg.com.mx
“Las áreas de mejora
pueden incluir las habilidades personales
de comunicación”
Y sabemos que a largo plazo una sola estrategia no
es suficiente, ya que México es un país grande y so-
fisticado que es capaz de crear los diversos caminos
que requiere, por ejemplo el crear los mecanismos
para lograr la incursión directa en el mercado, la bús-
queda de los contratos mayores y la proveeduría ha-
cia proyectos públicos (Gobierno).
» Construyendo los bloques
competitivos por pasos
Los “bloques básicos para el triunfo” son los elemen-
tos que forman una empresa, por ejemplo: adminis-
tración, ventas, calidad, producción, etcétera. Las em-
presas, durante su evolución, los adoptan por etapas y
siguen hasta que llegan a la cima, una empresa como
Cemex cuenta con todos los bloques básicos para el
triunfo y es líder mundial en diversas prácticas, Neoris,
sigue sus pasos de cerca, por otro lado una nueva em-
presa contará con menos bloques de triunfo.
Ahora en términos de industria, veamos que en nues-
tro país hay avances destacados en materia de calidad
–definitivamente un bloque básico para el triunfo- y
recientemente en materia de especialización que ha
impulsado México con programas como MoProsoft
y ahora Mexico First, ambos parte de la heróica Se-
cretaría de Economía.
Ahora bien, además del fondo Prosoft y las diferentes
estrategias que ha lanzado, existen apoyos menos
promocionados, también en Secretará de Economía
existen los fondos PyMes, recursos que quisieran mu-
chos países del mundo ya que los famosos grants o
prestamos a fondo perdido son una cosa del pasado.
Después tendríamos que preguntarnos si la tarea
esta hecha en cuanto a los medios para llegar hacia
los mercados globales, para estos también están las
bases sentadas, existen programas de promoción de
la imagen, como MexicoIT, que claramente debe me-
jorar y cumplir las expectativas que se tienen del mis-
mo y programas de aceleración hacia Estados Unidos
como TechBa.
Vale la pena mencionar las acciones orquestadas du-
rante ya más de 4 años por la Secretaría de Economía,
en particular por el Prosoft, donde se distingue el es-
fuerzo contínuo de Rocío Ruíz, Sergio Carrera, Ivette
García y muchas otras personas que han dejado su
huella en los esfuerzos de ese grupo como Jesús Orta
y muchas otras personas en la República Mexicana.
AGO-OCT 2008 21

No será una escalera de mármol o un ele-
vador capaz de hacer la tarea por nosotros,
pero ahí están las bases. En pocas palabras
en México si no aprovechamos los recursos
y posibilidades que hoy existen estaremos
desperdiciando una ventada de oportuni-
dad única, ya que en temas de calidad, fon-
deo, promoción y aceleración, los profesio-
nales mexicanos si tienen opciones.
Si pensamos que esta necesidad de mejorar
surge exclusivamente de la oportunidad, de-
bemos recordar que el entorno global tam-
bién esta en nuestra casa, en nuestro país
cuando llegan las empresas mundiales a es-
tablecerse con nosotros y a obligarnos a ser
mejores y más. Entonces no solo debemos
mejorar para exportar sino para competir con
las empresas de clase mundial que ya están
tocando las puertas de nuestros clientes.
De esta forma las empresas y los profesiona-
les mexicanos estamos obligados a entablar
esta carrera de mejora continua, que como
vemos ahora nos llevará fuera de la fronteras
de nuestra tarea diaria, seremos tecnólogos,
humanistas, estrategas, vendedores y si,
mercadólogos.
» ¿Cuál es entonces el siguiente
escalón para capitalizar la
oportunidad de México?
Sin duda son los de adoptar prácticas y aprove-
char oportunidades de negocio así como con-
tinuar con la promoción y cambio de imagen.

.BZPS
.nYJDP
)BDJB
PSHBOJ[BDJPOFT
5*
EF
DMBTF
NVOEJBM /FDFTJEBE » Los pasos para integrar las
capacidades de clase mundial

1SgDUJDBT
Z $POPDFS
FM "QSPWFDIBS $BQJUBMJ[BS
El primer paso es realizar un diagnóstico de
PQPSUVOJEBEFT NFSDBEP
FMFHJS WFOUBKBT 'VODJPOBS
FO
FM SFDVSTPT
Z su empresa que le permita medir sus com-
FOUPSOP
EF
OFHPDJP FM
DBNJOP EJTQPOJCMFT PQPSUVOJEBEFT petencias a nivel persona, departamento
ÇSFBT
EF
FOGPRVF
EF
.nYJDP

y organización. Este diagnóstico le deberá


1SPNPDJwO
Z &OUSFOBNJFOUP &KFDVDJwO
EF 1SgDUJDBT mostrar las áreas de trabajo específicas, por
DBNCJP
EF FO NFOTBKFT DPNFSDJBMFT
Z ejemplo tal vez su empresa sea muy afortu-
JNBHFO DPNVOJDBDJwO FNQSFTBSJBMFT EF
TFSWJDJP nada y cuente con personal altamente capaz
en comunicación en varios idiomas, tan bási-

.FEJPT
Z
co como es, tal vez no sea este el caso.
SFDVSTPT
QBSB 1SPTPGU 5FDICB
FYQPSUBS Siguiendo con la idea de “escalones básicos
para el triunfo” cada empresa y cada persona

1SPEVDUP
Z $PSF
CVTJOFTT
seguirán un plan distinto, propio a sus creen-
4FSWJDJP
EF 5FDOPMPHrBT
EF cias, deseos y situación actual.
DBMJEBE *OGPSNBDJwO
Después de realizar un diagnóstico, las áreas
$PNQFUJWF
-BUJO
"NFSJDB .BZPS de mejora pueden incluir las habilidades per-
"WBODF
sonales de comunicación. Pocas cosas son
tan decepcionantes y vergonzosas como ver
a un ejecutivo mexicano realizar una pobre

28
22 AGO-OCT 2008 www.sg.com.mx
presentación ante ejecutivos de alto nivel y Esto en cuanto a las capacidades de co-
echar todo por la borda, más allá de la ima- municación y usos y costumbres del mer-
gen de su empresa también la de la industria cado meta, las capacidades estratégicas Conclusión orno global para
nacional, por ello debemos creer en el entre- de una empresa incluyen el saber elegir La oportunidad en el ent
s continúa presen-
namiento, la preparación y la práctica, y no los mercados de oportunidad, por ejem- las empresas mexicana
bargo difícilmente
lo hacemos. plo, abrir una oficina en Houston, en lugar te, y es enorme, sin em
s, el mu ndo se esta trans-
nos esperará má
de Silicon Valley o el precio en el que debe as de base tecno-
formando hacia economí
Nuestros ejecutivos deben aprender, y prac- colocar sus servicios. Más de una empresa ún ico país compi-
ticar sus habilidades mediáticas, desde las mexicana realiza sus primeros esfuerzos lógica y México no es el
r su pe rfil.
formas de presentarse en una reunión, hasta sin conocer cuales son los mayores merca- tiendo por cambia
la ejecución de presentaciones ejecutivas. En dos para su oferta comercial, solo porque, logías de informa-
Las empresas de tecno
estos tres años en promoción de la industria tal y como el inmigrante ilegal, conocemos de sus líderes, tal vez
ción son un reflejo
mexicana, solamente he visto cuatro presen- a alguien en tal o cual ciudad. dad es y for mación orienta-
por las capaci
tadores aptos de más de 30 presentaciones ctas, no importa,
das hacia las ciencias exa
y por otro lado he presenciado ejecutivos Un error común de la empresa mexicana es qu e la receta para
lo que es relevante
mexicanos echar por la borda esfuerzos de que incursiona hacia mercados globales es mpos no es sufi-
triunfar en los viejos tie
meses para ponerlos a ellos ante un foro de el ignorar los diferentes recursos que existen y el futuro.
ciente para el presente
clase mundial. Lo más lamentable es que tanto en México como en el caso de Estados
esto es fácil de arreglar. Unidos especialmente diseñados para ayu- egar capacidades
Los retos requieren el agr
darles a triunfar y vender más. Igual de co- ras empresas, habi-
que completarán a nuest
A continuación vienen áreas de usos y cos- mún y grave es la carencia de presupuestos y rategia de merca-
lidades de planeación, est
tumbres durante la promoción de servicios, el compromiso de permanencia necesario. organizac iones y ejecuti-
dos, comunicación
tumbres, estamos
son actitudes sencillas para los mexicanos con va, y dominio de usos y cos
evos bloques bási-
nuestra cercanía cultural y nuestra distinguida Pocas empresas diseñan un plan de entra- obligados a incorporar nu
aptitud de calidad humana pronto podemos da al mercado estadounidense coordinado, nuest ras empresas.
cos para el triunfo en
adoptarlas y dominarlas. Por ejemplo manejo fondeando, sustentado y que conozca y ca-
las empresas glo-
del tiempo durante las reuniones, tiempos de pitalice los apoyos ya mencionados. Pocas El premio, es sumarse a
wt h tigers” por ello
respuesta para regresar con una propuesta, empresas siguen los pasos para establecerse bales llamadas “fast gro
documentación de las propuestas. En lo posi- como entidades legales en el mercado meta y al - ¿Cu ál es el nivel de fie-
una pregunta fin
organización?
tivo nuestra manera de formar lazos persona- mucho menos aprovechar las bondades pro- reza competitiva de su
les y de calidez son ventajas refrescantes para pias para las nuevas empresas.
la cultura de negocios Estadounidense.

Luis García, es Director de Competive Latinoamérica. Trabajó para empresas como IDC y Softtek, y ha dirigido proyectos de estrategia a nivel nacional, ha
sido orador en eventos en México, Colombia, Brasil y en United Nations Plaza, presentando el caso de México como Nación. Exprtador de Tecnologías de
Información. Puede contactarlo en lgarcia@competive.com

www.sg.com.mx AGO-OCT 2008 29

23
 r rol llo
l o
lo
D e
e a
esssaarrr oo
dd
sss dee
e D
D
i ccaaan nn a aa a Herr
era

s aass M
M
M eeexxxiic Ale ja n d r
e s s
ppprrreesa a M eeedddiid a
iddaa
LLaasssEEEm
mm aarree aaa lall a MM
Lea tww re
ddeeSSSooffttwa
o f
t i v idad
d p
ome t i
e l o d eC
od
Un M

30
24 AGO-OCT 2008 www.sg.com.mx
En las últimas décadas, la industria de desarrollo de software a la
medida en el mercado nacional y en el internacional, se ha movido
dentro de un esquema perverso de precios bajos en el que las em-
presas con menor poder de negociación tienden a ser las más casti-
gadas, hasta el grado de desaparecer.
Los retos que enfrentan los empresarios mexicanos en esta industria
son variados y atienden a diferentes factores, entre otros:
• El crecimiento de soluciones estandarizadas o empaquetadas cuyos
principales iconos son las empresas transnacionales.
• Los altos costos que implica el desarrollo de soluciones de software
para industrias o negocios en los que hay poca o nula experiencia.
• La escasez de recursos humanos especializados o con un perfil mul-
ticultural, para el caso de las empresas exportadoras.
Los criterios para el acceso a créditos tanto en la banca comercial como
en la banca de desarrollo, al no contar con activos tangibles que repre-
senten una garantía ya que su principal activo es capital intelectual
Por otro lado, según el Sector Competitiveness Analysis of the
Software and Computer Services Industry realizado por el Departa-
mento de Industria y Comercio de Gran Bretaña (2004), el 25.1% del
mercado mundial se encuentra repartido entre doce grandes firmas
estadounidenses que han extendido sus operaciones y oficinas en
diversos países de manera estratégica, en donde el capital humano
es abundante y de bajo costo, la infraestructura y normativa en el uso
de telecomunicaciones se adecúa a sus procesos de servicio, existe
un mercado en donde la demanda es atractiva o las políticas públicas
para la atracción de inversión extranjera son flexibles.
En la actualidad, Prosoft se ha ocupado de facilitar el camino para com-
petir a partir de la intensa participación del sector empresarial. Sin em-
bargo, entre las tareas pendientes se encontraba la identificación de
las fuentes de competitividad propias de las empresas mexicanas de
desarrollo de software a la medida que permitieran visualizar las bre-
chas que existen entre las empresas más exitosas y las que no lo son.
Estrategia de Negocios
· Tiene liderazgo empresarial, plan estratégico, visión e indicadores
de clase mundial.
· Crece a un ritmo mayor que el mercado.
· Toma riesgos controlados.
· Identifica y gana oportunidades de mercado.
· Tiene presencia en gremios profesionales.
· Da seguimiento a nuevas estrategias.
· Busca la excelencia.
· Es permanentemente insatisfecha.
· Quiere ser la mejor en un nicho.
· Aporta recursos para lograr ser la mejor.
· Incrementa la meta.
· Especializada.
· Se actualiza en temas de mercado.
www.sg.com.mx
Es por ello que como parte del Programa de Doctorado en Ciencias
de la Administración de la Facultad de Contaduría de la UNAM, se
realizó el proyecto de investigación “Las fuentes de competitividad
de las empresas mexicanas de desarrollo de software a la medida”,
con el objetivo de encontrar todos aquellos elementos que pueden
incrementar la competitividad de estas empresas con las capacida-
des propias del entorno mexicano.
Así, para estructurar el modelo de calidad, reunimos a más de 25
expertos, entre empresarios, consultores de empresa, académicos,
representantes del sector gobierno y clientes. La estrategia de inves-
tigación se conformó de técnicas de entrevistas, aplicación de cues-
tionarios y grupos de discusión. Además, los resultados obtenidos se
presentaron en distintos foros nacionales e internacionales en donde
fueron evaluados por expertos de diversos países.
Después de obtener el modelo final y como resultado de todo el
proceso de investigación, fue posible diseñar una herramienta de
diagnóstico y un índice de competitividad que permitiría visualizar
el nivel de apego de las empresas al modelo mismo. La herramienta
de diagnóstico fue probada a nivel exploratorio con cinco empresas
mexicanas: una de las más exitosas del país y otras cuatro con menor
nivel de desarrollo.
» Empresa competidora vs. empresa competitiva
Durante el proceso de investigación identificamos que era necesario defi-
nir lo que significa una empresa competitiva y los elementos que la hacen
diferente de una empresa competidora, ya que ambos conceptos son bá-
sicos para entender la competitividad de las empresas del estudio.
Entonces, después de recopilar información de otras investigaciones y
artículos y contando con la colaboración del grupo de expertos que par-
ticiparon en este proyecto, obtuvimos los siguientes elementos que de-
finen a una empresa mexicana de desarrollo de software competitiva:
Orientación al Cliente
· Ofrece valor agregado y efectivo a sus clientes.
· Excede las expectativas del cliente.
· Orienta la tecnología al negocio de sus clientes.
· Seriedad.
· Puntualidad.
· Cumple compromisos y acuerdos.
· Altamente enfocada al cliente.
· Una ética de trabajo muy fuerte.
· Sus clientes están muy satisfechos con sus servicios.
· Es socio tecnológico de sus clientes a largo plazo.
AGO-OCT 2008 25
31
 Financiera
· Es rentable.
· Solidez financiera, debe demostrar que
no desaparecerá de un día a otro.
· Precios atractivos.
Producción
Recursos Humanos
· Proceso estable de control operativo.
· Tiene personal experimentado. · Mantiene estándares para todos sus
· Equipo humano estratégico, directivo y procesos.
gerencial de muy buen nivel. · Calidad en sus procesos.
· Personal bilingüe. · Sus productos y servicios son de muy alta
· Tiene recursos humano motivados y calidad.
capacitados.
Gestión Tecnológica
· Busca la innovación de productos y servicios.
Por otra parte, una empresa mexicana de desarrollo de software · Desarrollo a distancia.
competidora tiene diferencias significativas en comparación con una
· Certificaciones en las tecnologías y
competitiva ya que su objetivo principal se centra en el uso de estra-
tegias de sobrevivencia y tiene las siguientes características: plataformas que utiliza.

· No maneja la diferenciación
· Basa su oferta en costos y precios bajos · Es incapaz de identificar áreas de oportunidad y corregirlas
· No cuenta con las características enunciadas para una · Establece su éxito solo con el número de contratos ganados
empresa competitiva
· Compite y no crece Una vez definidos estos conceptos, entonces nos enfocamos en iden-
· Es una empresa más tificar todos los elementos que componen la competitividad de este
· No tiene plan de negocio tipo de empresas hasta llegar a conformar el modelo que presenta-
· No tiene estrategia de calidad mos a continuación.
· No tiene estrategia de crecimiento
· Su único interés es vender » El modelo
· Quizá no permanezca mucho tiempo en el mercado El modelo de competitividad se presenta en la figura 1, el cual que-
· No tiene calidad dó integrado por el sector externo que está conformado por grupos
· Sobre vende, esto es que realiza ventas de servicios que exceden de influencia en la toma de decisiones de las empresas y el sector
su capacidad instalada interno, representado por todas las fuentes de competitividad que
· Sus clientes no están satisfechos con sus servicios puede desarrollar la empresa con sus propios recursos. Los grupos
· No tiene control de sus operaciones o su administración con un de influencia tienen relación directa con la definición de la estrategia
pobre seguimiento de resultados corporativa y colaboran en el diseño de estrategias, políticas públicas

32
26 AGO-OCT 2008 www.sg.com.mx
 $MJFOUFT 1SPWFFEPSFT
4FDUPS
FYUFSOP
(PCJFSOP $PNQFUJEPSFT

&TUSBUFHJB
$PSQPSBUJWB 1SPEVDDJwO
EF
4PGUXBSF
.FSDBEPUFDOJB
7FOUBT
Z
4FSWJDJP
B
$MJFOUFT
"ENJOJTUSBDJwO
Z
0SHBOJ[BDJwO
$PSQPSBUJWB

1SPZFDUPT
*%
*OHFOJFSrB
Z
%JTFvP
&TUSBUFHJB
EF
/FHPDJPT

(FTUJwO
5FDOPMwHJDB
3FDVSTPT
)VNBOPT

"ERVJTJDJPOFT

'JOBO[BT

'PSUBMF[BT
$BMJEBE
FO
FM $PNQFUJUJWBT
TFSWJDJP

$BMJEBE
EF
MPT
QSPEVDUPT
Con base en el perfil de los clientes locales
*OGSBFTUSVDUVSB y extranjeros se diseña el portafolio de ser-
4JTUFNBT
JOUFSOPT
BVUPNBUJ[BEPT
Z
BENwO
EF
MB
JOGPSNBDJwO vicios y los niveles de exigencia para su ne-
gociación; la satisfacción de estos clientes
'VFOUFT
EF
$PNQFUJUJWJEBE
representa el reto permanente de cada una
3FMBDJwO
EF
*OGMVFODJB $PNQPOFOUFT
EFM
.PEFMP de las áreas operativas de la organización.
Los competidores estimulan el ritmo de creci-
Figura 1. Modelo de competitividad miento de la empresa y la renovación de nue-
vas formas de trabajo, nuevos productos y
y la conformación de la visión empresarial, lo servicios y nuevas estrategias para sobresalir
que se explica de la siguiente manera: en la competencia nacional e internacional.
El gobierno participa en el desarrollo de las Los proveedores por su parte, abren oportu-
empresas a través de lineamientos de polí- nidades de financiamiento y de alianzas para
tica industrial, fiscal, económica, comercial, complementar competencias e infraestructura;
etcétera, que determinan esquemas de apo- en este grupo participan las instituciones de
yo en las diferentes etapas de madurez de educación superior, la industria de la electrónica,
las organizaciones o bien, si son ineficientes, telecomunicaciones, consumibles, entre otras.
implican un esfuerzo mayor de la empresa
por mantenerse en la competencia. Incluso El sector interno quedó estructurado en un
los gobiernos extranjeros juegan un papel primer nivel por la estrategia corporativa, la in-
importante en la definición de barreras para fraestructura con la que cuenta para la admi-
la entrada a sus mercados o bien, en la de- nistración de su información y lo relacionado
finición de esquemas para el intercambio directamente con la producción de software;
tecnológico o la búsqueda de bajos costos al siguiente nivel le denominamos subestrate-
provenientes de otras naciones. gias y al tercero, fuentes de competitividad
La estrategia corporativa comprende la es-
trategia de negocios, lo relacionado con los
recursos humanos, la administración y la
organización corporativa, la estrategia de
mercadotecnia, ventas y servicio a clientes,
investigación y desarrollo, ingeniería y dise-
ño, además de la gestión tecnológica, adqui-
siciones y finanzas.
La infraestructura está definida por la arqui-
tectura tecnológica interna de las empresas
que permite la administración y el manejo de
la información operativa de manera automati-
zada y sistemática para la toma de decisiones.
La producción de software se conforma por
las funciones relacionadas con la ejecución
de proyectos y las acciones y elementos que
permiten evaluar la calidad del servicio y el
producto. La producción de software basa
su operación no solo en la elaboración de
programas para computadoras, sino que su
desempeño depende en gran medida de la
armonía de todos los elementos del sector
interno de la empresa.

Alejandra Herrara, es Maestra y Doctora en Administración por la Universidad Nacional Autónoma de México y cursó la Maestría en Economía Internacional por
el Instituto Politécnico Nacional. Es consultora e  investigadora en temas de gestión tecnológica y de negocios. Ha sido ponente en diversos foros nacionales
e internacionales relacionados con nuevas tecnologías. Se desempeña como académica en la Maestría en Negocios Internacionales de la misma Universidad
en el programa sobre competitividad e innovación tecnológica.

www.sg.com.mx AGO-OCT 2008 33

27

P
P P
///PPPSSSPP
nn ll
aaal T
TTS
SS P
N
N a
a cc
ciio
ioo n
ivvaa a
IInniicicciiaiaatttiiva N z
In adurela M
oa
El Camin
Es bien sabido que para desarrollar
software de calidad de manera consistente
se requiere contar con una alta madurez de
procesos. A nivel internacional, el modelo
de madurez de procesos más popular es el
modelo CMMI. Sin embargo, este modelo
es complejo para implementar en empresas
pequeñas. En México también tenemos la
Norma Mexicana basada en MoProsoft, pero
ésta se centra en los procesos de las empre-
sas, más no en los de las personas.
La estrategia para incrementar la madurez
de la industria de software en México, debe
de contemplar no solamente los procesos de
las empresas sino, incluir el mejoramiento del
elemento básico que da sustento a la indus-
tria: las personas. Precisamente en las perso-
nas se enfoca el Personal Software Process
(PSP) y Team Software Process (TSP), crea-
dos por el Dr. Watts Humphrey del Software
Engineering Institute (SEI).
Es así que la Secretaría de Economía ha dado
marcha a la Iniciativa Nacional TSP/PSP, la
cual se está trabajando directamente con
el SEI y el Dr. Humphrey. El objetivo de esta
iniciativa es crear en México la infraestruc-
tura humana que permita la introducción
y expansión acelerada del uso de TSP, para
que la industria de desarrollo de software en
México alcance un desempeño superior al
de su competencia internacional.
»¿Por qué TSP/PSP?
Los elementos que se conjuntan y que nos
hacen creer en esta oportunidad son los si-
guientes:
• La gran mayoría de las empresas que desa-
rrollan software en México son menores a 50
empleados.
• El modelo que utilizan nuestros competi-
dores (CMMI) es complejo y apropiado para
organizaciones grandes.
• El TSP/PSP, cuando se implementa correc-
tamente, ha probado ser más eficaz que el
CMMI Nivel 5.
28 AGO-OCT 2008
u ez
Beatriz
Velázq
competitivo que permita acelerar la incor-
poración del uso de TSP/PSP en México.
• Con el uso de TSP/PSP las empresas en Si bien, la Secretaría de Economía a través
México podrían tomar ventaja y adelantar- del Prosoft está fondeando el desarrollo de
se en la incorporación de estos procesos de la certificación para TSP organizacional en el
calidad en menor tiempo y obteniendo me- SEI, ésta tendrá un reconocimiento mundial.
jores resultados. Así al mantener el sello del SEI México, será el
primer jugador (first mover) en este esfuerzo,
México ya ocupa el primer lugar mundial de obteniendo ventajas sobre quienes le sigan.
personas certificadas en PSP, lo que nos da
ventaja sobre nuestros competidores. El SEI » Relación CMMI-TSP
busca impulsar significativamente TSP/PSP Por lo regular se necesita de 18 a 24 meses
y está en busca de un socio que le ayude a para lograr un nivel en CMMI, lo que se tra-
cumplir este objetivo. México, como país ha duce en seis años para alcanzar un nivel 4 y
demostrado ser un aliado que permitirá con- ocho años para alcanzar un nivel 5.
tinuar con la evolución de dichos modelos.
Sin embargo, incorporar TSP/PSP acelera el
» Visión cumplimiento de las prácticas de CMMI de
Con la implementación de este proyecto una forma más generalizada en la organiza-
México logrará: ción, y recorta significativamente el tiempo
• Posicionarse como el país con mejor cali- necesario para alcanzar cada nivel. Esto su-
dad y valor agregado de manera ágil, ade- cede porque los integrantes del equipo de
lantándonos a las capacidades de nuestros trabajo conocen y aplican PSP en sus proce-
competidores. sos personales, lo cual acelera la implemen-
• Contar con un método avalado por el SEI tación de prácticas organizacionales.
que permitirá demostrar ob-
jetivamente la calidad de los
proyectos desarrollados por las
empresas que usan el TSP.
• Que la calidad de los desarro-
Conclusión
llos con talento mexicano sean ar y rebasar a los
Si México quiere alcanz
mejores que aquellos con niveles arr ollo de software,
países líderes en des
de alta madurez de CMMI. Esto un mé tod o que de re-
se requiere de
permitirá hacer desarrollos en mejores que los
sultados inmediatos y
menor tiempo y mejor calidad, lo los competidores.
métodos que utilizan
que se transforma en una ventaja a es qu e TSP /PSP es ese
Nuestra apuest
momento donde
de costo. método. Estamos en un
los pioneros de
podemos convertirnos en
» Acciones inmediatas ove cha r la corta ven-
este método y apr
emos antes que
Las metas para alcanzar a corto tana de tiempo que ten
adopten. Si ha-
plazo con la Iniciativa Nacional nuestros competidores lo
o, se podrá cumplir
TSP/PSP son: cemos bien todo est
• La definición de la primera ver- S. Hu mp hre y dijo en junio
lo que Watts
ndo volteará a
sión del método de evaluación or- del 2006: “En 5 años el mu
le hic ieron?”
ganizacional del uso del TSP. México y dirá ¿Cómo
• La definición del método de
mejora acelerada a través del
TSP+CMMI.
• Los estudios de impacto del TSP, n sobre la iniciativa TSP
/PSP,
para ajustar su uso y prácticas. Para mayor informació triz Velázquez Soto
con tac tar a Bea
favor de
ia.gob.mx.
• Desarrollar una infraestructura de bvelazquez@econom
instructores y coaches a un costo
www.sg.com.mx
 Méx
M iccoF
éxic oF IR
IR ST
ST
ST
Andrés Simón Bujaidar

Méxi o F I R
no
Clasificando el talento mexica

Business Service
“Multiswitching”
Management
#10 *5

Concientes de la importancia del ta-

Automated “Distributed
Services Computing”

lento humano en el crecimiento de la Data-

industria de TI, la Secretaría de Economía
en conjunto con el Banco Mundial idea-
ron y fondearán la creación y operación
de MexicoFIRST (Federal Institute for
Remote Services and Technologies).
Esta acción pondrá a nuestro país al nivel

MJEFSB[HP

OFHPDJBDJwO

FUD
³
de los países líderes en materia de TI de
alto valor agregado, ya que el alcance de
esta iniciativa con carácter nacional, pro-
moverá y facilitará la capacitación y certi-
ficación de nuestro talento mexicano para
llevar a cabo actividades de TI y Business
Process Outsourcing (BPO). Asimismo,
facilitará y reducirá los costos de recluta-
miento de personal de las empresas.
A nivel mundial la industria de TI y BPO ha
presentado un aumento sostenido en los
últimos años, las proyecciones nos indican
que para 2013 la demanda conjunta en TI
y BPO rondará los 150 billones de dólares,
lo cual representa una enorme oportuni-
dad. Para insertarnos en dicho mercado, la
industria de TI en México deberá crecer a
tasas aceleradas para lo cual requerirá de
150 mil nuevos profesionales certificados
en competencias de reconocimiento inter-
nacional (50 mil en temas de TI y 100 mil
de BPO). Para hacer frente a este reto, la Se-
cretaría de Economía a través del PROSOFT
invertirá 40 MUSD en los próximos 5 años
para sumarlos a las inversiones estatales y
privadas y alcanzar así nuestra meta.
MexicoFIRST es una iniciativa de la in-
dustria nacional alineada a las mejores
prácticas mundiales teniendo como so-
cios fundadores a la ANIEI y CANIETI. Su
misión es proveer a nuestra industria de
las certificaciones necesarias para que
nuestro talento en las áreas de TI y BPO
sea reconocido globalmente, vinculando
las necesidades de la industria con el tra-
bajo de la academia.
mining BPML (4)
SOA (2)
TSP/PSP
“Personal
Medicine”
SOX (1)
XML (5) SAPF, SAPL
(Funcional) RFID (3)
WAP (6)
ORACLE · Conocimientos
SAP
ORACLE
BPML (4) C-
Semiconductores,
funcionales (admin.,
Diseño de finanzas, contabilidad)
.NET C, C++ MEMs
Maya, GPS
procesos SAP · Habilidades de ventas JAVA Multimedia
de negocio · “Soft Skills para BPO (7)” Flash
Dreamweaver
ProTools,
(Multimedia)
*OHMnT
1SPKFDU
.BOBHFNFOU
²4PGU
4LJMMT
)BCJMJEBEFT
JOUFSQFSTPOBMFT
DPNVOJDBDJwO
Figura 1
Para lograr cristalizar su visión se sustenta- la especialización y adquirir la capacidad de
rá en una misión que toca tres importantes atender a la creciente demanda internacional.
líneas de acción:
• Otorgar al sector de TI el direccionamiento Este modelo nos permitirá incrementar la
y las tendencias a nivel global, con el fin de especialización mediante la adición de nue-
prever y estar siempre a la vanguardia. vos niveles y competencias, los cuales se irán
• Promover la capacitación y certificación en construyendo con una mezcla de revisiones
competencias de TI y soft skills generales, así prospectivas y reactivas para seguir ofrecien-
mismo promover a todo este capital huma- do recursos certificados en las nuevas áreas
no ya certificado para ofrecer sus servicios tecnológicas de vanguardia pensando en
en este sector. ofrecer a la industria nacional y global los ser-
• Proporcionar el acceso a la capacitación y vicios y productos que satisfagan sus necesi-
certificación personal y empresarial a través dades de talento, conocimiento y servicio.
del establecimiento de alianzas y generación
de economías de escala. » Metas
La primera meta de MexicoFIRST es certificar
» Catálogo de Certificaciones a 6 mil personas al término de 2008. A partir
Los esfuerzos de MexicoFIRST están alineados del próximo año buscará certificar al menos
a cubrir los requerimientos tanto inmediatos a 12 mil personas de forma anual, lo cual re-
como futuros en materia de recursos huma- presentará una inversión conjunta de más de
nos, para lo que se ha generado un catálogo mil millones de pesos en los primeros cinco
de certificaciones progresivo. El objetivo será años de operación.
ir elevando el conocimiento en materia de TI y
BPO con el fin de buscar niveles superiores de El alcance nacional y la sinergia que generará
especialización. La figura 1 muestra la estruc- MexicoFIRST con el PROSOFT, los gobiernos
tura de este catálogo progresivo. estatales y la industria, aunado a una lista de
alianzas estratégicas con las firmas propieta-
El modelo de capacidades previsto para los rias de los modelos, estándares y lenguajes
primeros años de operación está sustentado le permitirá acceder a economías de escala
por el dominio del idioma inglés, la adminis- para brindar servicios de insuperable calidad
tración de proyectos y los “soft skills”. Los tres con una ventaja significativa en el costo.
niveles de especialización técnica represen-
tados por los semicírculos concéntricos, nos iniciativa
n sobre la
indican el camino que habrá de seguir la certi- a m ay or informació ta r a A ndrés Sim
ón
Par ac
IR S T, fa vor de cont om ia .g ob .mx.
ficación en el país para poder ir avanzando en MexicoF bujaidar@
econ
Bujaidar as

www.sg.com.mx AGO-OCT 2008 29

 l mmme
een
nntteee???
t
ooss RR
Reeeaaall
e mm
uuueeerrreemo s
uuéé Q
Q
¿¿QQ Q
¿Qué
e un País
cimi ento d
El Cre
México es un país muy complicado. No nos
tenemos confianza entre nosotros mismos y
nuestras ideologías y preferencias partidistas
van por encima del bien nacional; preferimos
que algo no se haga a que lo haga el contrario,
aún si sabemos que es bueno, útil o necesario.
Esto nos ha llevado a una inacción de propor-
ciones alarmantes y a una costumbre muy dañi-
na, que es planear ad infinitum para posponer,
o de plano no tomar, decisiones. Y así vamos
por la vida, anclados a un pasado glorioso que
nos dicta nuestro quehacer, mientras otros sim-
plemente ven hacia el futuro y progresan.
El problema en estos tiempos es que todos los
países nos están rebasando y nosotros segui-
mos metidos en nuestro profundo laberinto
de ideologías, en lugar de enfocarnos a lo que
es bastante evidente que puede sacarnos del
atascadero, que es crear una base de industria
mexicana globalmente competitiva.
Tal vez la excepción hoy sea el programa Prosoft
de la Secretaría de Economía, que fue desarro-
llado en conjunto por la propia industria, el Go-
bierno y la Academia. Afortunadamente ningún
partido político ha visto al software con malos
ojos, tal vez por que ninguno de nuestros pró-
ceres tuvo nada que decir sobre él. Es más, nos
tocó ser testigos de que al construirse el edificio
para empresas de software en Vallejo a finales
del sexenio pasado, tanto en las ceremonias de
la primera piedra, —en plena campaña presi-
dencial—como en la inauguración, —con Refor-
ma tomado—se dieron un cordial abrazo el Jefe
de Gobierno y el Secretario de Economía, ambos
apostando por la industria de software mexicana
sobre los problemas políticos partidistas.
Rafael Bernal,  se dedica desde 1997 a promover una industria mexicana de software competitiva. Su experiencia de 35 años en software incluye CIO en
Procter & Gamble México, fundador de Heurística en 1982, entrepreneur en Silicon Valley  y actualmente Presidente de Prosoftware, A. C., desarrolladora
del clúster de empresas de software del Distrito Federal. Rafael considera que la riqueza de un país está en su gente.
30 AGO-OCT 2008
Rafael
Bernal
Sin embargo, aunque el horizonte parece lleno
de esperanza, vamos demasiado lento, o todos
los demás van muy rápido. Y es que sin impor-
tar la ideología política de cada país, ellos ven
primero por lo que les conviene y se dedican a
tomar medidas pragmáticas para lograrlo. Un
día Deng Xiaoping dijo que era glorioso ser rico,
y todo China se volcó a lograrlo. Gran idea, es-
pecialmente comparada con la idea que pare-
cemos tener sobre proteger la pobreza en lugar
de fomentar la riqueza; parece que es más fácil
ayudar al pobre a seguirlo siendo, que crear las
condiciones que generen riqueza.
» La excelencia en el estudio
Como ejemplo de esta situación que sufrimos,
hago un pequeño comentario sobre la educa-
ción. Un día me dijo una maestra de primaria que
no era posible exigir la tarea a un niño que no
desayunó; le respondí que con esa filosofía pro-
bablemente este niño no iba a desayunar toda
su vida. Nuestros gobiernos se han dedicado a
cubrir con sus alas protectoras a la ciudadanía,
especialmente si son pobres, dejándolos en su
ignorancia, en lugar de demandar la excelencia
en el estudio y luego en la vida. Para cualquier
país inteligente que cree realmente en la educa-
ción de calidad, ésta es la única actividad don-
de el elitismo es totalmente aceptado: al niño o
niña que tiene el cerebro se le dan todas las fa-
cilidades para que obtenga la mejor educación
posible, viéndolo/la realmente como el futuro
del país. Al que no, se le da solamente el me-
jor nivel de educación que pueda absorber. En
cambio, en México alegamos que la educación
universitaria debe ser para todos, y así tenemos
que la mejor institución educativa del país debe
aceptar muchachos que escasamente saben
leer porque “recibir una educación universita-
ria es su derecho como mexicanos”, cuando el
principio debería de ser “recibir una educación
al límite de su capacidad es su derecho como
mexicanos”. En el primer mundo, China, Cuba,
www.sg.com.mx
los países asiáticos y los de Europa Oriental,
la educación masiva sin requisitos no existe;
los que estudian son los que se lo ganan y lo
saben desde la primaria, y por eso nos reba-
san con mucho. A ellos se les exige mucho y
se les trata como adultos, a nosotros se nos
da poco y se nos trata como niños.
Pero regresando a nuestra industria de soft-
ware, aunque aún vamos increíblemente
lentos –recuerdo que hace 11 años, cuando
todo este movimiento empezó, consideré
que en unos dos o tres años estaríamos en
camino a ser un país de software, ya que
era tan obvio el negocio-país para México—
parece que avanzamos y estamos empezan-
do a ver un punto de inflexión ascendente
en la curva de la industria, que debería ser
exponencial, como lo ha sido en India o Ir-
landa. Analizando hoy lo que ha pasado en
esos 11 años y el estado de nuestra indus-
tria, considero que lo que hace falta ahora
es la infraestructura para fomentar el creci-
miento, la que se encuentra en los parques
de software. La razón es que la gran mayoría
de nuestras empresas, que de hecho son
muchas, son demasiado pequeñas para po-
der competir, no importa qué tanta calidad
logren tener. En un mercado de servicios, el
tamaño es crucial.
Hoy un parque de software es algo que in-
teresa a muchas entidades. Se han experi-
mentado varias formas de financiamiento,
pero considero que la ideal es la ya proba-
da en varias partes del mundo: el gobierno
interesado dona el terreno, una empresa
que tenga los conocimientos apropiados
construye y promueve, y las empresas de
tecnología que se instalan ahí tienen las
ventajas de un precio menor al del mercado
(a cambio del terreno que donó el gobier-
no), un ambiente adecuado para la sinergia
y las asociaciones, así como para la ense-
ñanza accesible de conocimientos para las
mismas empresas y sus empleados, y un
lugar donde la gente pueda crecer profesio-
nal, intelectual y hasta personalmente.
» Logrando entes productivos
Si realmente queremos desarrollar esta in-
dustria, los gobiernos tienen que estar con-
vencidos, no sólo de dientes para afuera,
sino con su bolsillo y sus propios proyec-
tos, hasta ahora internos, de desarrollo de
software. La entidad que realmente quiera
será ganadora indudablemente. La que
entre tibiamente, se quedará
en el camino. Una
buena pla-
neación a mediano y largo plazo y una vi-
sión verdaderamente de estado harán mi-
lagros por la economía de aquellos estados
que de veras quieran. Ya estamos viendo
que existen estados importadores y esta-
dos exportadores de talento, y esto sólo se
debe a que algunos tienen ideas y modelos
mejores que otros. Nosotros en Prosoft-
ware, una asociación creada para construir
el primer clúster de software en el DF, pro-
movemos que las empresas que se sumen
a nuestra asociación lo hagan para crecer y
ser mejores; los que no tengan estas metas,
no podrán ser asociados. Queremos cam-
biar el esquema de dádivas improductivas
por el de ayuda para lograr entes producti-
vos para la sociedad. Queremos demostrar
que habemos muchos que sí queremos y
que podemos sacudirnos el paternalismo
tradicional y usar la reciente libertad de
que gozamos para construir una indus-
tria productiva para el país.

» Parques tecnológicos
Los parques tecnológicos, en particular los
de software, pueden permitir que varias em-
presas pequeñas se conozcan y promover
el que existan motivadores para que logren
juntarse en una empresa mayor que tenga
la capacidad de atraer clientes e inversionis-
tas. Una empresa de veinte personas apenas
podrá llevar alguna metodología de calidad
y no logrará tomar clientes interesantes ni
mantener al día a su gente o contratar a la
gente más capaz a causa su tamaño. Pero
si se juntan varias empresas, logrando unos
200 – 250 empleados, esta nueva empresa
ya estará en capacidad de buscar mercados
más interesantes, de tener capacidad para
dar el entrenamiento continuo indispensa-
ble a todos sus empleados y de crecer. Todo
esto además la puede hacer interesante a los
ojos de inversionistas que puedan aportar el
capital necesario para un crecimiento mucho
más rápido. Recordemos que la demanda
por servicios de software es tal que toda la
industria India sigue creciendo a más del
20% anual y su tasa promedio anual durante
los últimos 20 años es cercana al 30%.

www.sg.com.mx AGO-OCT 2008 31

 mm
maa
ann o
noo
iitita H
aalll H
Huu
u Pedro
Galván
l C
C a
a p
pp t
ll R
R e
e ttooodddeeell Ca
EE Ret
El
a nza do
ha a l c
tino nos
E l d e s

C ualquiera que participe en la industria de software en México estará de

acuerdo en que el reto más grande que enfrentamos es el del capital humano.
Hay una gran cantidad de proyectos que están detenidos o se están enviando
a otros países porque no contamos con la gente necesaria.

» Algunas cifras a considerar

De acuerdo a las estimaciones de SG, en México existen cerca de 60 mil profe-
sionistas de software activos –con esto me refiero a personas cuya principal ac-
tividad laboral es desarrollar o mantener software. Por otro lado, la cifra no oficial
que se maneja en la industria de TI es que hay un déficit de 50 mil profesionistas
de TI, de los cuales alrededor de 20 mil son específicamente de software. La cifra
es alta, pero no se me hace descabellada, ya que tan solo en el último mes platiqué
con tres empresas diferentes que necesitaban a mil ingenieros de software cada
una. Entonces, si tenemos 60 mil profesionistas de software y nos hacen falta otros
20 mil, estamos hablando de un reto considerable.

Ante esto, lo primero que nos preguntamos es cuántos egresados estamos generan-
do. De acuerdo con datos del Anuario Prosoft 2007, anualmente se gradúan 60 mil
profesionistas de carreras relacionadas a TI. Esa es una cantidad alentadora, el proble-
ma está en que el porcentaje de graduados que cuenta con los conocimientos necesa-
rios para desempeñarse profesionalmente como desarrollador de software es de entre
un 10% y 15%. Eso significa que en el mejor de los casos estamos generando 10 mil
profesionistas de software al año, lo cual no es suficiente.

» Hemos generado demanda pero …

PROSOFT ha potenciado significativamente a la industria, pero no hemos logrado satisfacer
la demanda de gente que hemos generado (ya tengo espacio en el parque tecnológico, tengo
infraestructura, conseguí clientes, ¿y ahora donde está la gente para hacer los proyectos?).

Un factor que agudiza el problema es que la mayoría de las empresas de nuestra indus-
tria son pequeñas y no tienen capacidad para desarrollar personal, ellos necesitan gente
que pueda rendir inmediatamente. Y por otro lado, aquellas que tienen capacidad para
desarrollar a la gente no están muy dispuestas a hacerlo por el alto porcentaje de
rotación de personal (pirateo).

» El riesgo de las certificaciones

Los actores de la industria están muy conscientes del reto de capital humano que
enfrentamos, y es por ello que la iniciativa fuerte de este año es la de Mexico-
FIRST. Creo que este programa reúne buenas prácticas que van a mejorar el fun-
cionamiento de la capacitación y certificación en México. Ayuda a dar enfoque,
generar economías de escala, y simplificar los procesos para las organizacio-
nes que contratan servicios para capacitación y certificación. Sin embargo,
no debemos perder de vista que las certificaciones solo son el betún del
pastel. Previo a lograr una certificación debemos cumplir con los conoci-
mientos fundamentales que requiere un ingeniero de software.

32 AGO-OCT 2008 www.sg.com.mx

 “Primero debemos asegurarnos de establecer los fundamentos
y posteriormente enfocarnos en herramientas específicas ”
Las certificaciones facilitan significativamente la venta de servicios
de “staffing” para el extranjero. Sin embargo, todos estamos de acuer-
do en que ese es un mercado de bajo valor donde solo se compite
por tarifa, y esa es una guerra que no nos interesa. Así que si la estra-
tegia es proveer servicios de alto valor agregado, deberíamos pre-
ocuparnos primero por generar gente capaz de entender problemas
y resolverlos de forma innovadora.
Esto no significa que estoy en contra de las certificaciones. Creo que
son un elemento importante y hay que impulsarlas, especialmente
porque son algo medible. Pero tampoco debemos caer en la ilusión
de que son una varita mágica que de pronto va a convertir en “em-
pleable” a alguien que no tiene las bases adecuadas (el mono vestido
de seda mono se queda).
» Énfasis en fundamentos
Parecer ser que estamos dando por hecho que nuestros estudiantes
y profesionistas de software ya cuentan con los fundamentos de esta
disciplina, y solo es cosa de capacitarlos/certificarlos en inglés y mé-
todos/tecnologías específicas. Sin embargo, la retroalimentación que
continuamente recibo de los consultores que hacen implantaciones
de modelos de calidad de software en nuestro país es que la mayoría
del tiempo/esfuerzo de una implantación se va en la capacitación de
fundamentos. Es decir, cosas como qué es un requerimiento y qué
elementos tiene, qué significa diseñar un sistema de software y qué
tipo de decisiones involucra, qué es la gestión de la configuración y
por qué es importante.
Ante esto, creo que primero debemos asegurarnos de establecer
esos fundamentos, y posteriormente enfocarnos en herramientas y
tecnologías específicas. De no ser así, solo le estamos poniendo be-
tún a miles de pasteles que no están bien horneados.
» El rol de las instituciones educativas
Las instituciones educativas están conscientes de este problema y es-
tán en la mejor disposición de realizar los ajustes necesarios para re-
solverlo. La ANIEI (Asociación Nacional de Instituciones de Educación
en Tecnologías de la Información) generó el modelo paracurricular,
que es su propuesta para dotar a los estudiantes con los conocimien-
tos y competencias que requiere la industria. El reto que enfrentan
actualmente es el de implementar dicho modelo de forma rápida.
Digamos que es difícil transformar a 600 instituciones educativas
cuando sólo se cuenta con los ratos libres entre clases. La nota positi-
va es que el BID recientemente aprobó una cantidad significativa de
dinero para fondear el proyecto de implantación de este modelo.
www.sg.com.mx
» Generando experiencia
Otro gran problema que enfrentamos es el ciclo vicioso de la experiencia.
Las empresas no contratan recién graduados porque no tienen experien-
cia y estos nunca generan experiencia porque no los contratan, pasan los
años y terminan poniendo un Internet café o dedicándose a otra cosa.
Aquí no hay una solución única, sino la suma de muchos pequeños
esfuerzos. Una de las herramientas con las que contamos y debemos
aprovechar mejor son los periodos de prácticas profesionales que se
dan en la mayoría de las universidades hacia el final de la carrera. Hay
que armar y gestionar bien estos programas para que brinden expe-
riencia realmente útil a los participantes.
Por otro lado, las empresas deben apostarle más a estos recién gradua-
dos. Ciertamente ayudaría contar con mayores incentivos para quienes
emplean gente por primera vez, además de mayor protección contra
el pirateo de gente, pero aun así las empresas también deben poner su
parte y pensar en que al entrenar a un ingeniero de software, aunque
este se vaya a otra empresa, le está haciendo bien a la industria en ge-
neral y ese beneficio le va a regresar a la empresa de una u otra forma.
» Nada sirve sin la participación de las personas
A pesar de todo esto, no debemos pasar por alto que aunque defi-
namos los mejores modelos de competencias y consigamos todos
los recursos para implementarlos, si los estudiantes y profesionistas
no le entran a este esfuerzo, todo va a ser inútil. Desde mi punto de
vista, la gran mayoría de los estudiantes y profesionistas de nuestra
industria se encuentran en su área de confort. Hay miles de personas
que trabajan en el área de sistemas de su empresa y que consideran
que con saber más o menos como funciona el ERP en su empresa
(o cómo está estructurado su warehouse), ya con eso la hacen. Hay
otros miles de estudiantes que piensan que con graduarse ya tienen
trabajo seguro. Ellos piensan que simplemente por tener un título de
Ing. en Sistemas ya merecen ser gerentes de sistemas en un banco, y
si no entonces es culpa de la universidad o del gobierno.
Es triste ver que países como Argentina o Colombia, que tienen mu-
chísimo menos habitantes que México, tienen más participantes que
nosotros en programas de certificación gratuitos, como el de desa-
rrollador cinco estrellas de Microsoft (tan solo por dar un ejemplo).
Le hemos entrado a una competencia global. El gobierno tiene esto
muy claro, las empresas también, pero al parecer las personas toda-
vía no. Y mientras no logremos cambiar esta actitud, ningun progra-
ma de formación va a servir.
AGO-OCT 2008 33
 // COLUMNA invitada
Lecciones Aprendidas de la Quiebra
de Air-Go Technologies
Cuando el ego nos alcanza
Por Héctor Obregón
D e 1996 a 2002 tuve la oportunidad de
participar como fundador y Director General
de una empresa de servicios de desarrollo
de software en México. Esta empresa inicial-
mente se llamó InterSoftware y más adelan-
te Air-Go en su último año y medio de vida.
En ella perseguimos el sueño de crear la
mejor empresa de su tipo en México. Duran-
te varios años creímos que lo lograríamos y
después, en un periodo de tiempo muy cor-
to, fallamos por completo resultando final-
mente en la desaparición del negocio.
InterSoftware/Air-Go pasó de 5 colaborado-
res en 1996 a más de 300 en el año 2001.
Para el 2002 había desaparecido como en-
tidad funcional. Nuestra empresa fue de las
primeras en México en el desarrollo de apli-
caciones para dispositivos móviles (1998),
búsqueda formal de certificación CMM
(1998), implementación de un modelo de
fábricas de software de bajo costo (1999),
obtención de fondeo institucional de capital
de riesgo (1999), exportación de servicios
de desarrollo de software a Estados Unidos
(2000), y crecimiento mediante la consoli-
dación con competidores (2001). Aunque
nuestra visión puede haber sido la correcta
en varios aspectos, quizá se adelantó un
poco a su tiempo y, mucho más importante,
nuestra ejecución fue incompetente.
En este artículo comparto mis experiencias
personales a través del proceso del fracaso
de esta empresa así como las que considero
son las principales lecciones que espero ha-
ber aprendido durante el proceso.
Las causas del fracaso
Tuvimos mucho éxito en un periodo corto
de tiempo y con relativa facilidad. Desafor-
tunadamente, en mi caso personal eso me
condujo a una actitud de soberbia que me
cegó a la posibilidad de visualizar los pro-
blemas que se avecinaban con el tiempo
suficiente para actuar y prevenirlos. Varios
de mis colaboradores y socios se acercaron
34 AGO-OCT 2008
conmigo para alertarme sobre esto pero
esta soberbia me impidió escucharlos. Una
tremenda frase que jamás olvidaré refleja
la actitud que tenía en 1999. Poco después
de haber acordado la primera ronda de fi-
nanciamiento institucional para la empresa
por un monto de un millón de dólares, le co-
menté a mi socio co-fundador de la empre-
sa: “Ya no es posible que fallemos después
de esto.”. Varios años después, inmerso en
la crisis del negocio, otro de mis socios, un
empresario exitoso radicado en Estados
Unidos me comentaría que mantiene en su
oficina un enorme poster de PanAm Airlines
(ahora desaparecida) para nunca olvidar
que, sin importar el tamaño o el éxito alcan-
zados, la posibilidad de perderlo todo siem-
pre estará vigente.
El éxito aparente también nos había colo-
cado a mí y a algunos de mis colaboradores
dentro de nuestra zona de confort. Nues-
tros ingresos personales eran más que
suficientes para llevar una vida cómoda y
estaban totalmente desconectados de la
rentabilidad y la generación de valor de
la empresa. Aún cuando como socios de-
beríamos haber estado más preocupados
por el desempeño financiero del negocio,
la realidad de nuestro día a día era dema-
siado cómoda.
Sin duda otra de nuestras fallas fue el in-
tentar hacer demasiadas cosas al mismo
tiempo. En un periodo muy reducido de
tiempo expandimos nuestras operaciones
a Guanajuato, Monterrey y, mucho más di-
fícil, Estados Unidos. Todo esto sin tener
experiencia previa sobre las implicaciones
de administrar un crecimiento acelerado.
Alcanzamos a nuestro nivel de incompeten-
cia rápidamente. Acabamos haciendo mu-
chas cosas mal en lugar de pocas bien. Lo
más grave fue que estas operaciones dis-
trajeron la atención de la dirección del ne-
gocio principal que probablemente hubiera
podido salir adelante con más atención.
Mi ego en ese momento influyó también en
algunos conflictos con mis socios. Llegue a
estar más preocupado por mi posición in-
terna y externa como Director General que
por la salud del negocio. Fue fácil distraerme
con juegos de poder donde ya no se trataba
de lo mejor para el negocio sino de lo más
placentero para el propio orgullo. En parti-
cular este problema se hizo manifiesto en
nuestro intento fallido de fusión con otra
de las empresas líderes del mercado en ese
momento: Kiven. Mi conflicto con su Direc-
tor General, fue el factor determinante para
el fracaso de esta operación que probable-
mente, bien ejecutada, hubiera resultado de
gran beneficio para ambas empresas.
Tomamos riesgos extremos en la operación
financiera de la empresa. La supervivencia y
el muy acelerado crecimiento durante 4 años
no nos sensibilizaron al nivel de riesgo que
adquirimos. Adicionalmente en el periodo
1996-2000 era muy fácil para una empresa
innovadora en el sector de IT obtener fondos
y financiamiento debido al entusiasmo ge-
neral en los mercados sobre las posibilida-
des de este tipo de empresas. Este entorno
reforzó la precepción que teníamos de ser
prácticamente infalibles.
La experiencia del fracaso
La postura personal de orgullo que condujo
a mi empresa a fracasar se enfrentó con la
dura realidad en aún menos tiempo del que
había tomado el “éxito”. Cuando disminuyó
el ritmo de crecimiento de la compañía ha-
cia fines del año 2000 debido a la combina-
ción de una desaceleración de la economía
y del tamaño que habíamos alcanzado ya,
en cuestión de un trimestre se hicieron sen-
tir en el flujo de efectivo los problemas de
rentabilidad sistémicos que el negocio te-
nía. Durante años la acelerada tasa de cre-
cimiento en ventas (de alrededor de 100%
anual) permitía financiar la operación de la
empresa aun cuando su rentabilidad real
fuera entre mediocre e inexistente.
www.sg.com.mx

Pocas cosas son más difíciles que enfrentar-
se a dificultades de flujo de efectivo de corto
plazo en la operación del negocio. Rápida-
mente nuestras líneas de financiamiento
estaban saturadas y nos enfrentamos a pro-
blemas para solventar los costos de opera-
ción más indispensables como la nómina de
nuestro personal. Simultáneamente la “luna
de miel” con los inversionistas instituciona-
les terminaba y nos enfrascamos en discu-
siones sobre cómo solucionar el problema
sin llegar a acuerdos a la velocidad que la
situación demandaba. Los clientes se per-
cataron de nuestros problemas y, natural-
mente, perdieron la confianza en nosotros
como proveedores lo que aceleró nuestra
caída. Provocando que los inversionistas
institucionales perdieran la posibilidad de
creer en mí y se negaran a proporcionar
fondos adicionales para “darle la vuelta” al
problema. Aún cuando nuestros colabora-
dores hicieron un importante esfuerzo por
seguir operando, aun ante la falta de pago,
naturalmente esto nos llevó a un desgaste
finalmente insalvable.
Para fines del 2001, la única opción que me
quedaba para evitar el cierre inmediato de
la empresa era aceptar mi remoción como
Director General para tomar las funciones de
ventas. Fue muy poco y demasiado tarde.
Consideraba, y sigo considerando, a mis
principales colaboradores como mis amigos.
El afecto hacia y desde ellos dificultó enor-
memente contar con la claridad suficiente
para tomar las decisiones adecuadas.
En cuestión de meses pasé de una posición
de orgullo desmedido al otro extremo emo-
cional. Me sentí la persona más incompeten-
te y estúpida del mundo. Las malas noticias
adicionales, por pequeñas que fueran, me
provocaban crisis de pánico. Resultaba casi
imposible levantarse a trabajar todos los días
y la magnitud del problema me sobrepasó
tanto personal como profesionalmente.
www.sg.com.mx
“Debemos respetar a cualquier socio
potencial de tal manera que sus aportaciones
sean genuinamente efectivas, para el
desarrollo del negocio”.
Superar el vacío
Ahora, varios años después, no puedo más
que sentirme afortunado de haber superado
ese momento extraordinariamente doloroso
y difícil. Hay una serie de elementos que
fueron clave para poder salir adelante.
Sin duda lo más importante fue el que, aún
durante el punto más álgido, conté con el
apoyo de varias personas que siguieron
creyendo en mí. Esta confianza fue el sal-
vavidas que en ese momento me permitió
no ahogarme. Puedo mencionar a Mauricio
Mingramm, mi actual socio en emlink, a
Marcos Achar, Director General de Comex
(que continúa siendo nuestro cliente) , a mi
tío Raúl Obregón, y a un compacto equipo
de colaboradores que continuaron creyendo
en mí a pesar de todos los errores que co-
metí. A todos ellos les estaré agradecido el
resto de mi vida por su apoyo y confianza.
Durante este trance descubrí el significado
de la fe. No soy un hombre religioso. Sin em-
bargo, jamás había estado en una situación
donde tuviera que simplemente creer que
iba a salir adelante sin tener la más remota
idea de cómo lo lograría ni ningún funda-
mento lógico para creer que fuera posible.
Creer genuinamente en algo sin ningún fun-
damento racional es para mí el significado
más claro de la fe.
Fue necesario procesar emocionalmente el
fracaso y asumirlo. Esto no me fue posible
hacerlo rápidamente. Se requiere un espa-
cio de tiempo para poder procesar el duelo.
Sin temor a exagerar, me parece que el dolor
de ese momento haya sido similar al de la
pérdida de un ser querido. No es posible sa-
lir adelante de un dolor de este tipo sin darle
oportunidad de seguir su curso.
Necesité aprender a mirar siempre hacia el
futuro y rápidamente dar vuelta a las pági-
nas del fracaso. La tentación del enojo y de
aferrarse al éxito anteriormente logrado era
fuerte y creo que me hubiera hecho perder
más tiempo y dedicarle energía a persecu-
ciones sin sentido.
En la medida de lo posible, busque enfren-
tar la situación con la máxima franqueza
posible con los distintos afectados por el
cierre de la empresa. Había que darle malas
noticias a muchas personas. A los colabo-
radores, socios, acreedores, clientes y pro-
veedores. Todos se vieron afectados negati-
vamente por los errores que cometimos. En
la gran mayoría de los casos, el trato franco
con ellos evitó problemas muchos mayores.
Los casos donde no me fue posible hacerlo
o no dediqué el tiempo necesario fueron los
que se complicaron después convirtiéndo-
se, por ejemplo, en serios dolores de cabeza
legales. Sin embargo, creo que no es posi-
ble satisfacer a todos los afectados. Hay que
entender esto y prepararse para asumir las
consecuencias.
10 lecciones aprendidas
Las siguientes lecciones de aprendizaje per-
sonal no pretenden ser una receta general
para quien se encuentre en una situación
similar. No son resultado de un amplio es-
tudio de casos. Simplemente son un breve
resumen de lo más significativo de lo vivido
personalmente a lo largo de la experiencia
relatada y de la posterior búsqueda de cons-
truir una nueva empresa, emLink.
1. La gente vale la pena
Mencioné que el afecto con y desde mis cola-
boradores dificultó la toma de algunas deci-
siones importantes. Sin embargo, no me ima-
gino ni me interesa la construcción de una
relación de trabajo sin afecto. Estoy absolu-
tamente convencido de que la construcción
de un afecto es indispensable para lograr una
motivación de conjunto y un liderazgo efecti-
vo. Así que, en lugar de renunciar a este me
parece que lo mejor es incorporarlo dentro de
una ética de trabajo y claridad en la defini-
ción y evaluación de objetivos profesionales.
AGO-OCT 2008 35
 // COLUMNA invitada

“Los clientes se percataron de nuestros

problemas y, naturalmente, perdieron la
confianza en nosotros como proveedores, lo
que aceleró nuestra caída”.

Esto permite a las dos partes involucradas en
una relación de trabajo contar con un marco
de evaluación objetivo sobre los resultados
del trabajo conjunto.
2.Ten un sueño
Después del fracaso vivido, pasé una tem-
porada abandonando mis sueños, enfocado
exclusivamente a la rentabilidad de corto
plazo y la estabilidad del nuevo negocio
para evitar a toda costa una repetición de la
experiencia anterior. Ahora me parece que
sin un sueño no es posible construir una mi-
sión efectiva, atraer y retener a los colabo-
radores talentosos que cualquier empresa
que desee ser exitosa requiere.
3. Busca socios que compartan tus valores
Los conflictos que con mayor facilidad pue-
den destruir a una empresa, son entre los
socios de esta. Entrar en una sociedad de
negocios implica evaluar claramente nues-
tro entendimiento. Vale la pena incorporar
desde un inicio la posibilidad de la sepa-
ración. Como en un matrimonio dónde la
posibilidad real del divorcio nos motiva a
construir la relación todos los días. Un socio
debe compartir valores e idealmente com-
plementarnos en habilidades, capacidades
y puntos de vista. Debemos respetar a cual-
quier potencial socio de tal manera que sus
aportaciones sean genuinamente efectivas
para el desarrollo del negocio.
4. Se un Nazi con tu disciplina financiera
Para las empresas generar utilidades es
equivalente a comer para el ser humano. Si
un negocio no es rentable tendremos asegu-
rada la imposibilidad de alcanzar los sueños
y la visión que hemos trazado para este. Por
lo tanto, vale la pena ejercer una férrea dis-
ciplina en este aspecto. Es necesaria para
el bien de todas las entidades relacionadas
con una empresa: socios, colaboradores,
clientes, proveedores y acreedores. Una em-
presa que no es rentable acaba fallando con
la comunidad con que se relaciona.
5. Que mantener el foco sea la doctrina
Siempre que emprendamos una nueva ini-
ciativa hay que evaluar con honestidad si
realmente tendremos la capacidad de ejecu-
tarla y llevarla a término. Es fácil caer en la
tentación de hacer más de lo que realmente
tenemos capacidad de ejecutar. Una cosa a
la vez. O, cuando mucho, tantas como poda-
mos ejecutar efectivamente.
6. Ten paciencia
La velocidad de ejecución siempre es menor
a la velocidad de la imaginación. Es nece-
sario tener paciencia para ver que aquello
que imaginamos se convierta en realidad.
Hay que ser enconadamente persistentes y
entender que cualquier proceso de cambio
que involucre la participación de un equipo
de trabajo llevará tiempo. Los sueños si son
alcanzables, más no sin esfuerzo, tenacidad
y paciencia.
7. Sin riesgo no hay (casi) crecimiento
Toda empresa implica un riesgo. Sin impor-
tar cuantas lecciones creamos haber apren-
dido, si queremos crecer y alcanzar nuestro
sueño como organización, habremos de
asumir riesgos que nos pueden llevar al
fracaso. Es inevitable esta relación. Sin em-
bargo, podemos buscar calcular el riesgo de
tal forma que nos podamos permitir siempre
la posibilidad de fallar en alguna iniciativa
individual sin que esto conduzca al fracaso
total de la empresa.
8. 1% inspiración, 99% ejecución
El mundo está lleno de grandes ideas.
¿Cuánta gente no conocemos que celebra
que “se le ocurrió primero” o “ya lo veía
venir”? La diferencia entre un espectador y
un protagonista en mi opinión, no son las
ideas, es la capacidad de ejecutar sobre sus
ideas y llevarlas al resultado final deseado.
Los planes en nuestra mente siempre serán
posibles. La realidad es otra cosa.
9. Para emprender hay que ser un poco
bipolar
Es necesario mantener un optimismo (casi)
irracional sobre el futuro. Mantener el entu-
siasmo y la convicción de que el sueño que
hemos trazado como objetivo es en verdad
alcanzable en todo momento. Transmitir ese
entusiasmo a todo nuestro entorno. Al mis-
mo tiempo, se necesita un pesimismo (un
tanto) irracional para la toma de decisiones
financieras. ¿Realmente es necesario este
gasto?, ¿podríamos vivir sin él?, ¿podemos
ejecutar esta inversión? Planea para el me-
jor escenario, ejecuta previendo siempre el
peor escenario. Recuerda que siempre se
puede poner peor.
10. No se te olvide por qué estás aquí
Más allá de cualquier consejo práctico de
negocios, evalúa contantemente por qué
haces lo que haces. ¿Contribuye el ser em-
presario a tu felicidad? Es fácil perderse en
el día a día y un día darse cuenta de que el
sueño se ha ido o de que la rutina nos ha
absorbido. De vez en cuando vale la pena
hacer una pausa en el camino para evaluar
por qué somos empresarios. Cada uno ten-
drá que encontrar su propia respuesta.

Héctor Obregón (http://msdnfan.blogspot.com) es Director General de emLink desde 2002 (www.emlink.com.mx), Microsoft MSDN Regional Director y
Microsoft MVP para Windows Embedded. De 1996 a 2002 fue Director General de Air-Go Technologies (antes InterSoftware).

36 AGO-OCT 2008 www.sg.com.mx

www.sg.com.mx AGO-OCT 2008
 // PRÁCTICAS /*ASEGURAMIENTO DE CALIDAD*/
Revisiones entre Colegas
Una Práctica de las Mejores
Por Edith Martínez
Las revisiones entre colegas (peer reviews) están descritas dentro
del proceso de verificación de CMMI, y tienen como objetivo ase-
gurar que los productos de trabajo seleccionados cumplan con los
requerimientos especificados. Estas revisiones son un mecanismo
de verificación eficaz para prevenir y eliminar defectos, además de
identificar oportunidades de mejora.
Estas revisiones típicamente son aplicadas por compañeros de traba-
jo, muchas veces integrantes del proyecto que tienen un interés en el
artefacto bajo revisión. Los revisores son conocidos como colegas, ya
que tienen roles o actividades similares a los del autor del producto.
 
La aplicación de las revisiones entre colegas tiene diversos beneficios:
• Promueve la generación de productos completos y correctos.
• Ayuda a establecer un estándar de excelencia.
• Promueve el seguimiento del estilo y reglas de construcción en los
proyectos.
• Provee múltiples vistas en las revisiones.
• Permite obtener mediciones para mejorar el proceso y administrar
la calidad de los productos.
 
Algunas definiciones
Formalmente, una revisión es una técnica para encontrar y eliminar
defectos de productos de trabajo, tan temprano como sea posible y
de manera efectiva.
 
Un defecto es:
• Cualquier ocurrencia en un producto de trabajo que determine que
esté incompleto, incorrecto o con faltantes.
• Cuando no se satisface un requerimiento.
• Una inconsistencia o violación a estándares.
Se recomienda el uso de listas de verificación, o checklists, que fun-
gen como base para la revisión de artefactos.
 
Un checklist es:
• Una lista de elementos en forma de preguntas y/o características.
• Resume los problemas técnicos potenciales para una revisión.
• Son utilizados durante la etapa de preparación y de ejecución de
revisiones.
 
Hay diferentes tipos de checklists o bien se pueden revisar diferen-
tes características como: que el producto esté correcto o completo,
que siga reglas de estilo, construcción, etcétera.
Edith Alhelí Martínez Mata es Consultor especializado en Aseguramiento de la Calidad, en Avantare Consultores. Sus áreas de especialidad son las Inspecciones
de Software y Procesos de Soporte basados en CMMI y SW-CMM. Edith es Licenciada en Informática por el Instituto Tecnológico de Aguascalientes (ITA), y ha
participado como consultora en varios proyectos para la implementación de CMMI así como en evaluaciones SCAMPI.
38 AGO-OCT 2008
Roles participantes
Estos son los roles que típicamente participan en la revisión:
• Moderador. Es quien se asegura que se envíen los productos a los
involucrados, que la revisión se conduzca correctamente, se revise
al producto y no a la persona, se compartan las observaciones y se
hagan las modificaciones pertinentes.
• Autor. Elabora o desarrolla el producto que se revisará. Durante
las revisiones provee las explicaciones necesarias sobre el producto
en revisión.
• Revisores. Son los expertos o colegas que se preparan para la revisión,
encuentran defectos y retroalimentan acerca de las observaciones.
• Tomador de notas. Es quien completa las formas con los hallazgos
encontrados, observaciones realizadas, registra los tiempos y clasi-
fica los hallazgos.
• Lector. Participa realizando lecturas relacionadas al producto revi-
sado, en caso de ser requerido.
 
Es importante hacer notar que no es requerida una persona para
ejecutar cada rol, por el contrario una persona puede realizar dos
o más roles de acuerdo a las necesidades, cuidando que nadie sea
juez y parte para asegurar la objetividad.
 
Durante la revisión es importante enfocar las observaciones solo ha-
cia el producto y no al autor, así como asegurarse que se levanten
defectos y no soluciones, pues las últimas pueden tomar más tiem-
po del esperado y afectar en el lapso de las revisiones.
 
Tipos de revisiones
Existe variedad en los tipos de revisiones, cada uno con característi-
cas diferentes y con diferentes propósitos. Algunos de estos tipos se
describen a continuación:
Inspecciones de software
• Es la forma de revisión más estricta.
• Revisiones a profundidad.
• Criterio de salida para cada fase.
• Dirigida por el líder revisor y asistida por participantes.
• Se obtienen métricas (Producto y proceso).
 
Walkthroughs
• Medio para llegar a consenso.
• Útiles para aprendizaje informal.
• Dirigidas por el autor.
• No hay métricas.
www.sg.com.mx
Revisiones técnicas Entre los principales beneficios que proveen las revisiones entre co-
• Busca consenso. legas están:
• Útiles como capacitación. • Acortamiento de tiempos.
• Se expone el producto y se busca aprobación. • Reducción de costos.
• Útiles para productos complejos o de nueva tecnología. • Mejora en capacidad de predicción.
• Se requiere experiencia técnica. • Mayor satisfacción del cliente.
• Métricas no son obligatorias • Mayor entusiasmo en el personal.
  • Retorno de inversión atractivo.
Revisiones cruzadas  
• Determinan el estatus del producto. De forma cuantitativa, las expectativas de ahorro pueden esperarse en:
• Carga extra requerida es mínima. • 60% al 80% de los defectos eliminados antes de la ejecución de
• Revisiones en pares. las pruebas
• Facilita el intercambio de información. • Reducciones en la escala del tiempo de hasta el 25%
• Típicamente utilizadas para diseño y codificación. • Reducción hasta en 5 veces de los costos de pruebas
• Se recolectan algunas métricas.  
  La revisión entre colegas es una práctica que por sí sola genera un
Fases de la inspección de software retorno de inversión visible, ya que ayuda a incrementar la calidad
La realización de una inspección de software requiere de varias fa- y reducir costos.
ses que se detallan a continuación:  
  Preguntas  comunes
Planeación. ¿Quién decide qué debe ser revisado?
• Planear inspección en el calendario del proyecto. El líder técnico o de proyectos.
• Identificar qué productos revisar y los tipos de productos.  
• Asignar responsables (autor y moderadores). ¿Qué revisar?
  Productos de alto impacto, productos asociados a riesgos, y produc-
Preparación tos asociados a objetivos de calidad.
• Validar que el producto esté listo.  
• Asignar revisores, y resto de los roles. ¿Cuándo planear las revisiones?
• Verificar checklists listos y distribuir el material para revisión. De acuerdo al tipo de revisión, en el plan y al inicio del proyecto o
  fases.
Sesión de inspección  
• Revisar el producto. Recomendaciones
• Registrar y clasificar hallazgos. Algunos principios importantes de las inspecciones de software:
• Clasificar defectos. • Limitar las inspecciones a periodos de alta concentración (2 horas).
• Clarificar dudas puntualmente. • Revisar productos, no personas.
  • Identificar defectos, no soluciones.
Reporteo  
• Dar a conocer los resultados, hallazgos y métricas. Algunos riesgos comunes que pueden dificultar la implantación de
  la práctica o limitar los beneficios de ésta, y que por lo tanto deben
Seguimiento tenerse en cuenta para manejarlos adecuadamente:
• Asegurarse que se llevan a cabo las correcciones. • Los participantes no entienden el proceso de revisión.
• Registrar el cierre de los defectos. • Los revisores critican al autor y no al producto.
• Levantar métricas. • Falta de planeación de las revisiones.
  • Las juntas se enfocan a la solución de problemas de estilo.
Costo y beneficios • Falta de preparación y/o los revisores no son los adecuados.
El costo de implementar esta práctica en realidad no es muy alto, ya • Proceso no compatible con las características de la organización.
que es una actividad que se ejecuta naturalmente por los equipos
de trabajo. La ejecución de una revisión se lleva un máximo de 4 Y entonces ¿qué esperamos para llevar a cabo prácticas de
horas, considerando los tiempos de preparación y ejecución, y nos revisiones entre colegas?
da resultados cualitativos y cuantitativos al momento.

www.sg.com.mx AGO-OCT 2008 39

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

Aprendiendo Ruby y Rails

Parte 4. El Framework Rails
Por Carlos Ortega

El presente artículo es el cuarto y último de la serie que tiene la in-
tensión de introducir al lector los principales elementos del lenguaje
de programación Ruby y del framework Ruby on Rails. En esta oca-
sión se tratarán los temas del controlador y las vistas.
El Controlador
Contrario a lo que podría indicar el nombre del patrón: MVC, en Rails
se aconseja desarrollar primero el controlador antes que la vista.
Para lograr esto, Rails echa mano de una clase especial llamada
ApplicationController, a través de los siguientes pasos:
Ahora bien, los constructores de Rails han diseñado el framework de
tal manera que los métodos que se definan dentro de esta clase coin-
cidan con las acciones que se generen en las vistas, es decir, si se de-
sea que se realice un evento específico dentro de las vistas, el código
que representa ese evento podrá estar contenido dentro del nombre
del método o función que definamos dentro del controlador.
Por ejemplo, supongamos que dentro la vista new.rhtml invocamos al
evento agregrar un nuevo Usuario esto, mediante la liga
<%= link_to “Agregar un nuevo Usuario”, {:action => ‘new’}%>

a) generar una clase derivada de ApplicationController y Entonces si deseáramos que al activar esta liga se ejecute un código
b) manipular con esta clase, a nuestra clase que representa el mode- determinado X, tendremos que definirlo dentro un método o función
lo para lograr el acceso a la base de datos. del controlador cuyo nombre coincida con el nombre de la acción, en
este caso new.
Manteniendo la misma filosofía de generación automática de capas,
el comado generate permite uitlizar el parametro controller para acce- El siguiente diagrama intenta ilustrar mejor este mecanismo.
der a la clase ApplicationController, para invocarlo abriremos una sesión
class UsuarioController < ApplicationController
en linea de comandos, nos posicionaremos en el directorio railsass e <h1> Agregar un Nuevo Usuario </h1>
def metodo1
...
introduciremos: </br>
....
end

..... def metodo2

<%a= link_to ”Agregar un Nuevo Usuario”, {action=>’new’}%> ...
path/trabajo/railsass>ruby script/generate controller Usuario ..... end
.....
def new
# CODIGO QUE
# DESEAMOS QUE SE EJECUTE
end
...
end

new.rhtml usuario_controller.rb

Una vez entendido este concepto podemos proceder a incorporar la

parte que manejará al modelo actualizando al controlador:

class UsuarioController < ApplicationController

#---Mostrar la lista de Todos los Usuarios---#

def list
@usuarios = Usuario.find( :all )
Además de haber creado automáticamente el archivo con el nombre end
usuario_controller.rb destinado a contener la clase controladora, tam-
#--- Crear un nuevo Usuario en Memoria ---#
bién se habrá creado un directorio usuario debajo del directorio views def new
que contendrá los archivos RHTML que manejarán las vistas, un @usuario = Usuario.new
archivo usuario_controller_test.rb para realizar pruebas funcionales y ar- end
chivo usuario_helper.rb dentro del directorio helper que podrá utilizarse
#---Creamos Un Nuevo Usuario ---#
para albergar clases adicionales de soporte que puedan requerirse.
def create
@usuario = Usuario.new( params[:usuario] )
Al abrir el archivo usuario_controller.rb que se encuentra dentro del if @usuario.save
directorio app/controllers ,podemos observar que en este se encuentra redirect_to :action => ‘list’
la clase UsuarioController la cual es derivada de ApplicationController: else
class UsuarioController < ApplicationController render :action => ‘new’
end end
end

40 AGO-OCT 2008 www.sg.com.mx

 “En Rails se aconseja desarrollar primero el
controlador antes que la vista”.

#---Mostrar el detalle de Un Usuario---#

def show
@usuarios = Usuario.find( params[:id] )
end
end
Como se puede apreciar a excepción del método show que muestra la
lista de todos los Usuarios, hemos creado varios métodos que corres-
ponderían a la funciones CRUD de un objeto de negocio Usuario.
Por otra parte es interesante observar como es que a su vez estos
métodos manipulan al Usuario, es decir, dentro de ellos se invocan
las diferentes funciones de ActiveRecord, de ahí que el método find
de Usuario acepte como parámetro un objeto específico, como una
variable de entorno  (params[:id)  o un símbolo (:all) que representa la
condición para regresar todos los objetos Usuario.
Por otra parte, la invocación de método redirect_to resulta en la una nue-
va llamada a la acción y el refrescado de la página web correpondiente.
Para simplificar nuestra revisión en este momento nos concentra-
remos solo en un objeto, no tocaremos las relaciones (behaviours)
entre otros tipos de objetos de negocio.
La siguiente étapa es la construcción de las vistas.
La(s) Vista(s)
Como se explicó en la sección anterior, el controlador atiende pe-
ticiones de las vistas a través de sus métodos. El nombre de estos
métodos coinciden con las acciones a invocarse en las vistas.
Ahora bien, de la misma manera que acontece en otras partes del
framework, la convención que los diseñadores de Rails han emplea-
do para definir las vistas, es hacer coincidir el nombre de los archivos
que contengan a las vistas, con el nombre de los métodos que repre-
sentarán a las acciones a invocarse dentro de los controladores.
Por ejemplo, en nuestro caso UsuarioController tiene los métodos
list, new y show, por ende generaremos los archivos list.rhtml, new.rhtml,
show.rhtml que serán los que invocaran a estos métodos y se definen
dentro del directorio app/views/usuario, sin embargo a diferencia de lo
que sucede con el controlador y el modelo, el comando generate no tie-
ne un parámetro específico para generar los archivos .rhtml que con-
tendrán a las vistas, por esta razón es necesario crearlos a mano.
El siguiente diagrama trata de ilustrar este mecanismo.

<h1> Usuarios del Sistema </h1>

</br>
....
.....
<%a= link_to ”Listar Usuario”, {action=>’list’}%>
.....
.....
class UsuarioController < ApplicationController
list.rhtml
<h1> Agregar un Nuevo Usuario </h1> def list
</br> # CODIGO PARA MOSTRAR TODOS LOS USUARIOS
.... end
.....
<%a= link_to ”Agregar un Nuevo Usuario”, {action=>’new’}%> def new
..... # CODIGO PARA CREAR UN NUEVO USUARIO
.....
end
new.html
def show
<h1> Detalle de un Usuario </h1>
# CODIGO PARA MOSTRAR EL DETALLE DE UN USUARIO
</br>
.... end
.....
<%a= link_to ”Mostrar Usuario”, {action=>’show’}%> def delete
..... # CODIGO PARA BORRAR UN USUARIO EXISTENTE
..... end
show.rhtml
...
<h1> Borrar un Usuario </h1> end
</br>
....
.....
<%a= link_to ”Borrar un Usuario”, {action=>’delete’}%> usuario_controller.rb
.....
.....
delete.rhtml

www.sg.com.mx AGO-OCT 2008 41

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

Un comentario al margen es que existe un mecanismo llamado Finalmente reinicializaremos nuestro webserver WEBRick (si es que
scaffolding que permite la generación automática de todas las vistas y este se encuentra apagado).
un formato homogéneo de las mismas. Sin embargo en esta ocasión
no explicaremos este mecanismo con el fin de que el lector conozca ruby script/server webrick
y maneje los elementos básicos para manipular vistas. Y arrancaremos el web browser de nuestra preferencia apuntándolo
a la siguiente dirección:
A continuación se muestra un ejemplo del código de las vistas, en
este caso sería de la vista list.rhtml. http://localhost:3000/usuario/list

<html> La 1ra. vez deberá aparecer una página parecida a la siguiente:

<head>
<h3>
Historia 15 - USUARIOS - Nuevo
</h3>
</head>
<body>
<h1>Agregar un Nuevo Usuario</h1>
<%= start_form_tag :action => ‘create’ %>
<p><label for=”usuario_nombre”>Nombre</label><br/>
<%= text_field ‘usuario’, ‘nombre’ %></p>
<p><label for=”usuario_apellido”>Apellido</label><br/>
<%= text_field ‘usuario’, ‘apellido’ %></p>
<p><label for=”usuario_tipo”>Tipo</label><br/>
<%= text_field ‘usuario’, ‘tipo’ %></p>
<p><label for=”usuario_permisos”>Permisos</label><br/> Al darle click a la liga “Agregar Nuevo Usuario”  se desplegará en
<%= text_field ‘usuario’, ‘permisos’ %></p> pantalla una forma.   Introduzcamos un par de usuarios de ejemplo:
<%= submit_tag “Create” %>
<%= end_form_tag %>
Nombre: Liliana
<%= link_to ‘Back’, {:action => ‘list’} %> Apellido: Allen
Tipo: 1
</html> Permisos: rwx rwx rwx

Formatos de los archivos de vistas Nombre: Sebastian

Al analizar el código RHTML observamos que en estos estan pre- Apellido: Coe
sentes instrucciones HTML y lo que aparenta ser codigo Ruby; en Tipo: 2
efecto lo es. Permisos: rrr rxx rwx

Recordemos la arquitectura de Rails: La parte de las vistas esta con-
tenida en archivos .rhtml que son interpetados por el programa ERb,
el cual a su vez intepreta, ejecuta y substituye las instrucciones de
Ruby y convierte su salida en HTML la cual es entregada al webserver
que finalmente devuelve al browser para su interpretación.
Observemos también que en la vistas, se puede llamar directamente
a los objetos de negocio que representan el modelo, esto, sin nece-
sidad de incluir ninguna librería, mas importante aún es recordar
que el controlador el responsable de crear este tipo de objetos. Para
nuestro caso: @usuario.
Otro punto interesante es el código inmerso dentro de las etiquetas
<%= start_form_tag %> … <%= end_form_tag%>, este es una instrucción pre-
construida en Ruby que es interpretada por ERb la cual permite el de-
sarrollo de formas complejas en HTML de una forma rápida y sencilla.
Y demos click en el boton “Create” al final de la introducción de los
datos de cada usuario
Podemos percatarnos que una vez que finalizamos la introducción
de cada usuario mediante el botón “Create” la aplicación nos regre-
sa a la página donde se enlistan todos los usuarios. Esto se debe
justamente al código que incrustamos dentro del controlador:
if @usuario.save
redirect_to :action => ‘list’
El cual le indica a Rails que en caso de haber guardado exitosamente
al usuario, el control se redireccione a la acción list.
Probemos ahora la liga “Back”; la página desplegada deberá ser si-
milar a la siguiente:

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

42 AGO-OCT 2008 www.sg.com.mx

 “Las construcciones de Rails han diseñado
el framework de tal manera que los métodos
que se definan dentro de esta clase coincidan
con las acciones que se generan en las vistas”.
Por último, demos click a alguna de las ligas
que presenta el nombre de los usuarios, la
página web desplegará el detalle de los da-
tos que introducimos anteriormente:
La versión básica de nuestra aplicación ¡ya
corre!
Un punto adicional que vale la pena comen-
tar es que a pesar de que el código RHTML
hace sencilla la construcción de vistas, es
muy posible que en futuras versiones de
Rails este deje de utilizarse debido a que en
últimas fechas se han creado nuevos meca-
nismos que simplifican la manipulación de
vistas de manera dramática.
Conclusión
A través de estos 4 artículos tuvimos
la oportunidad de revisar el lenguaje
Ruby y el framework Rails.
www.sg.com.mx
Pudimos comprobar diferentes capa-
cidades que los hacen ser uno de los
lenguajes y frameworks más pode-
rosos para desarrollar aplicaciones
web de forma extremadamente rápi-
da. Adicionalmente el hecho de ser
abiertos, libres y correr en múltiples
plataformas los distingue como una
de las tecnologías más atrayente de la
actualidad.
Esta última entrega finalizó nuestra re-
visión básica incluyendo el desarrollo
de los controladores y las vistas.
Existen temas más avanzados que
complementan los mecanismos ne-
cesarios para generar una aplicación
Rails a nivel empresarial. Temas como
el manejo de relaciones entre diferen-
tes objetos de negocio, routers, Ajax,
andamios, seguridad y distribución,
quedan para una revisión posterior.
Sin embargo los elementos hasta aquí
presentados permitirán al lector tener
las bases mínimas para comenzar a
desarrollar y adentrarse en esta nove-
dosa tecnología.
Referencias
[ Thomas David, Fowler Chad, Hunt Andy.
“Programming Ruby”. 2nd Edition. The
Pragmatic Bookshelf. 2005 ]
[ Thomas David, Heinemeier Hanson Da-
vid, et al. “Agile Web Development with
Rails”. 2nd Edition. The Pragmatic Books-
helf. 2006 ]
[ Black, David A. “Ruby for Rails”. Manning
Publications Co. 2006 ]
[ ruby-lang.org/en ]
[ rubyonrails.org ]
[ mysql.com]
[ haml.hamptoncatlin.com ]
AGO-OCT 2008 39
 // PRÁCTICAS /*ARQUITECTURA*/

Más Allá del Manual de Usuario

Parte 2. Documentando la Arquitectura de Software
Por Omar Gómez

En el número anterior vimos la propuesta de SEI que define tres cate- Si se desea que la documentación de la arquitectura cumpla con el
gorías denomidas tipos de vista. Para concluir con esta propuesta en la estándar, se deben seguir las siguientes prácticas:
figura 1 se muestran los principales conceptos de este enfoque.
• Identificación e información general. En esta práctica se lleva lo
1FSTPOB 5JQP
EF
WJTUB 4JTUFNB
4PGUXBSF
relacionado al control de versiones del documento, fecha, histórico
*OWPMVDSBEB
FO de revisiones, estado, contexto del sistema, declaración del alcance,
FM
1SPZFDUP
entre otros más.
1..x 1 1
satisface los tiene tiene • Identificación del personal involucrado y sus intereses. Se descri-
intereses
1.. x
1.. x
1 ben los diversos tipos de personas involucradas en el proyecto. Ta-
7JTUB "SRVJUFDUVSB
&TUJMP les como, administradores, diseñadores, desarrolladores, usuarios,
"SRVJUFDUwOJDP cumple
1..x 1 patrocinadores. A su vez, se incluye la diversidad de intereses que la
arquitectura debe satisfacer.
1 1 1
se obtiene es descrita
1
1..x
1..x
• Puntos de vista. Cada de uno de estos debe contener un nombre,
1BRVFUF
EF
7JTUB
(VrB
EF
&TUJMPT %PDVNFOUP
EF personal involucrado, intereses que satisface, lenguaje o técnicas de
1..x 1 MB
"SRVJUFDUVSB modelado utilizados durante la construcción de la vista, algún método
4FDDJwO
1..x 1
analítico para analizar de manera cualitativa o cuantitativa los atribu-
tos de calidad que satisface el punto de vista, y su justificación.

Figura 1. Relación de conceptos de la propuesta “vistas y más allá de éstas” del SEI.
Por su parte, el IEEE Software propone el estándar IEEE 1471 que
define un conjunto de recomendaciones centradas básicamente
en 2 ideas, un marco conceptual para describir arquitecturas, y un
conjunto de prácticas a seguir. La descripción de la arquitectura se
organiza en un conjunto de vistas, cada vista modela una parte del
sistema y satisface uno o más intereses de las personas involucra-
das. Los distintos intereses se deben considerar durante la cons-
trucción del sistema; si alguno de ellos  no es considerado en al
menos una de las vistas se dice que la descripción de la arquitectu-
ra está incompleta.
Cada vista se documenta de acuerdo a un punto de vista (elemento
que pude ser reutilizado) determinado, definiendo las notaciones,
técnicas y reglas para construir e interpretarla, a su vez, este deter-
mina cómo el contenido de una vista satisface uno o más intereses
de las personas involucradas. En este marco conceptual, una vista
es la instancia de un punto de vista dado. Un conjunto (biblioteca)
de puntos de vista es análogo a la guía de estilos que propone el
SEI. En la figura 2 se muestra un extracto del marco conceptual del
estándar IEEE 1471.
• Vistas. Cada vista debe tener un identificador, una breve introduc-
ción y la representación del sistema con respecto a un punto de vista
en particular.
• Consistencia entre vistas. Registra las inconsistencias entre las
vistas, así como algún tipo de procedimiento que indique la consis-
tencia entre ellas.
• Justificación. Se debe incluir la justificación del tipo de arquitectu-
ra seleccionada, y de los puntos de vista utilizados.
Actualmente, el IEEE e ISO están revisando en conjunto este están-
dar con el objetivo de tener una versión actualizada en el siguiente
año para someterla a votación.
Estos dos últimos enfoques tienen varias similitudes entre sí. Por
ejemplo, ambos se centran en las personas involucradas y en sus di-
versos intereses, ninguno de estos prescribe un número fijo de vistas,
los dos enfoques hacen uso de la reutilización de artefactos; uno atra-
vés de la guía de estilos y el otro por medio de una biblioteca de pun-
tos de vista, en ambos la arquitectura debe estar justificada y los dos
enfoques recomiendan el uso de análisis cualitativos o cuantitativos.

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

44 AGO-OCT 2008 www.sg.com.mx

 4JTUFNB
EF
4PGUXBSF
tiene
1..x
1FSTPOB
JOWPMVDSBEB
FO
FM
QSPZFDUP
1..x es
importante
para es considerado 1..x
5FNB
EF
*OUFSnT
usado para
satisfacer
1..x
Figura 2. Extracto del marco conceptual del estándar IEEE 1471.
Una de las diferencias entre los dos enfoques es la siguiente. En el
enfoque del SEI primero se selecciona un conjunto posible de vistas
con respecto a las estructuras que están presentes en el sistema a
construir, después se validan de acuerdo a un consenso de intereses
por parte del personal involucrado, posteriormente se documentan.
Por otra parte, el IEEE primero determina los intereses del personal
involucrado, después en base a estos se selecciona un conjunto de
puntos de vista que los satisfaga, por último se documenta cada una
de las vistas basándose en los puntos de vista seleccionados.
Conclusión
Uno de los principales beneficios de realizar esta práctica,
es el poder efectuar evaluaciones sobre la arquitectura do-
cumentada, con el fin de determinar si se están cumpliendo
o no los intereses del personal involucrado. Para finalizar, al-
gunos de los puntos que se deben considerar al momento de
documentar un arquitectura son:
• Documentar la arquitectura tomando en cuenta las necesida-
des e intereses de cada persona que forma parte del proyecto.
• Acompañar la documentación de las vistas con un modelo
analítico que ayude a predecir el comportamiento de los atri-
butos de calidad.
• UML no es el único lenguaje para documentar la arquitectu-
ra. Existen diferentes notaciones y lenguajes para este pro-
pósito, por ejemplo, lenguajes para descripción de arquitec-
turas (ADLs) que describen aspectos particulares de esta.
• Mantener una relación consistente entre las vistas.
• Elaborar plantillas de estilos para promover la reutilización
de artefactos dentro de la organización.
www.sg.com.mx
"SRVJUFDUVSB
tiene 1
descrita por
1
%FTDSJQDJwO
EF
MB
"SRVJUFDUVSB
identifica 1..x
está
organizada por
1..x selecciona 1..x
1VOUP
EF
WJTUB 7JTUB
conforma
puede tener
0..1
#JCMJPUFDB
EF
1VOUPT
EF
7JTUB
• Mantener actualizada la matriz de trazabilidad entre los
requisitos y los elementos de la arquitectura.
• Tener bajo una línea base el documento de la arquitectura.
Referencias
[ Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE
Software., Los Alamitos, CA, USA, Volume 12, Number 6, págs. 42-50.
IEEE Computer Society Press, 1995 ]
[ Dilip Soni; Robert L. Nord & Christine Hofmeister. “Software archi-
tecture in industrial applications”. ICSE ‘95: Proceedings of the 17th
international conference on Software Engineering, New York, NY, USA.
págs. 196-207, ACM, 1995 ]
[ Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers;
Reed Little; Robert Nord & Judith Stafford. “Documenting Software
Architectures: Views and Beyond”. Addison Wesley Professional. 2002 ]
[ IEEE Architecture Working Group. “IEEE Standard 1471-2000,
Recommended practice for Architectural Description of Software-
Intensive Systems”. págs 1-23. IEEE, 2000 ]
[ Mary Shaw & David Garlan. “Software Architecture: Perspectives on
an Emerging Discipline”. Abril. Prentice Hall. 1996 ]
[ Mark Klein; Rick Kazman & Robert Nord. “Attribute-Based
Architectural Styles”.Software Engineering Institute. Technical Report
CMU/SEI-99-TR-22. Carnegie Mellon University. 1999 ]
[ Software Engineering Institute, SEI. “Views and Beyond Architecture
Documentation Template” ]
[ sei.cmu.edu/architecture/arch_doc.html ]
[ Rich Hilliard. “ISO/IEC 42010/IEEE 1471: Architectural Description” ]
[ sei.cmu.edu/architecture/IEEE_1471.html ]
[ Omar Gómez. “Evaluando la Arquitectura de Software, métodos de
evaluación”. Revista Software Gurú. Año 03 No. 02. 2007 ]
AGO-OCT 2008 45
 // PRÁCTICAS
Aplicaciones Web Seguras. ¿Mito o
Realidad?
El mito de la seguridad en aplicaciones Web
Por Germán Domínguez
La seguridad en las aplicaciones Web de las
organizaciones es, hoy en día, una priori-
dad importante. Y es que éstas aplicaciones
contienen y manejan información invaluable
para la operación y el comercio de las em-
presas, por lo mismo, la seguridad se vuel-
ve imprescindible, ya que muchas de estas
aplicaciones manejan números de tarjetas
de crédito, listas de clientes de las empre-
sas, inventarios físicos, documentos de pro-
piedad intelectual, etcétera; bienes por los
que un hacker estaría dispuesto a hacer lo
posible para obtenerlos.
La mayor parte de los presupuestos de se-
guridad en las compañías están dedicados
a la infraestructura de la red y de acuerdo
con estudios realizados, más del 60% de los
ataques en seguridad de la información no
están dirigidos ahí, sino a la capa de apli-
caciones Web; otro estudio demuestra que
más del 70% de estas aplicaciones, son
vulnerables a ataques informáticos y para
el 2010 el 80% de las organizaciones experi-
mentará un incidente de seguridad.
A pesar de esto y de las inversiones en ma-
teria de seguridad, seguimos leyendo no-
ticias que sitios de empresas, medios de
comunicación, entidades gubernamenta-
les, organizaciones políticas y civiles, entre
otras, son presas de ataques a la seguridad
de sus sitios web.
Las organizaciones invierten recursos, prin-
cipalmente, en la seguridad informática, en
seguridad perimetral con la instalación de
Firewalls, en Sistemas de Detección de In-
trusos (IDP), Sistemas de Prevención de In-
trusiones (IPS) y Firewalls de Aplicaciones,
todo apoyado en Sistemas de Administra-
ción de Eventos e Incidentes (SIEM). Todos
estos controles de seguridad bloquean ata-
ques muy bien identificados, sin embargo,
Germán Domínguez es Licenciado en Informática Administrativa de UNITEC con más de 13 años de experiencia en el desarrollo de aplicaciones de ne-
gocio y aplicaciones Web. Ahora pertenece al equipo de IT de IBM de México, especialista para la marca de software Rational, y puede ser contactado en
germand@mx1.ibm.com
46 AGO-OCT 2008
/*SEGURIDAD*/
todos ellos descuidan la seguridad en las
aplicaciones y la información que en ella se
contienen, de tal manera que la seguridad se
deja única y exclusivamente a la programa-
ción realizada. Sin embargo aquellas fallas
de seguridad no contempladas o conocidas,
quedan vulnerables a usuarios malintencio-
nados, empleados enojados o en el peor de
los casos, a un hacker.
Los ataques a las aplicaciones no siempre
son malintencionados, un usuario por error
puede lograr tener acceso a información a
segmentos del aplicativo que no estaban
destinados para su perfil de usuario. Adi-
cional a esto, ha habido un incremento de
sitios que proporcionan herramientas para
la exploración y explotación de vulnerabi-
lidades en sitios Web, lo que ha permitido
el crecimiento de la población de usuarios
malintencionados. Una de las mejores prác-
ticas para mantener seguras las aplicacio-
nes es “nunca asumir que la información in-
gresada por el usuario será confiable”, esto
evita que la aplicación acepte información
o datos que no están permitidos y que po-
drían convertirse en datos potencialmente
peligrosos para la seguridad de la misma.
La realidad de la seguridad
Tipos de vulnerabilidades
Según la organización Web Application
Security Consortium (WASC), las aplica-
ciones son vulnerables a diferentes tipos
y categorías de ataques y los clasifica en 6
grandes rubros:
• Autenticación, el objetivo de estos ata-
ques es la validación de la identidad de los
usuarios con la intención de engañar al pro-
ceso de autenticación del sitio web.
• Autorización, este tipo de ataques buscan
obtener acceso a recursos o información a
los que el usuario no tiene derecho o permi-
so de utilización.
• Ataques en la parte cliente, resultan de la
relación de confianza que existe por parte
del usuario final en el sitio Web, en esta re-
lación el usuario confía que la información
proporcionada por el sitio Web será verda-
dera y espera no recibir ningún tipo de ata-
que por parte de la aplicación.
• Ejecución de comandos, en esta catego-
ría caen las vulnerabilidades que permiten al
usuario ejecutar comandos remotos en el sitio.
• Revelación de información como objetivo
obtener información específica del sitio, ta-
les como el sistema operativo del servidor,
la marca y versión del servidor de aplicacio-
nes web, etcétera. Y con esta información
poder utilizar o explotar vulnerabilidades
conocidas de dichos productos.
• Ataques lógicos, son aquellos que burlan
la lógica programada de las aplicaciones y
perjudican la aplicación, los usuarios o la
información contenida.
Estas grandes categorías nos permiten tener
una idea del universo de posibilidades para
un ataque a un sitio Web. En este artículo
nos enfocaremos en los que se ubican como
los primeros lugares, según la clasificación
hecha por el Open Web Application Security
Project (OWASP), una de las organizaciones
independientes más importantes en Seguri-
dad de la Información:
1. Cross Site Scripting se refiere a aquellos
ataques que permiten al hacker obtener in-
formación confidencial del usuario (como
cuentas y contraseñas), llevar a cabo ata-
ques de phishing y hasta llegar a tomar el
control del navegador del usuario final. Está
es la vulnerabilidad más común y agresiva
de las aplicaciones web; en las clasificacio-
nes antes mencionadas pertenece a ataques
en la parte del cliente y autenticación.
Esta vulnerabilidad es exitosa mediante la
inserción de código HMTL o JavaScript en el
navegador del usuario, usualmente estos
www.sg.com.mx
ataques son encontrados en comunidades
virtuales, foros de discusión, salas de chat y
hasta en el mismo sitio web que se pretende
afectar. Todas las plataformas son suscepti-
bles a estos ataques. Lamentablemente, es-
tas agresiones son dirigidas directamente al
usuario final, por lo que la inserción de códi-
go en el navegador no puede ser controlada
por nuestros sistemas de seguridad.
2. Inyección defectuosa, este tipo de vulne-
rabilidades tienen lugar cuando un usuario
malicioso ejecuta comandos no previstos
en la aplicación Web mediante el envío de
datos especialmente diseñados para tal fin
utilizando como interprete de estos coman-
dos al sitio, estas instrucciones permiten al
atacante leer, crear o borrar información.
Algunos tipos de instrucciones que se inyec-
tan en las aplicaciones son tipo SQL, LDAP,
XML o comandos de sistema operativo.
En casos extremos, este tipo de ataques
permiten al intruso tomar el control total del
sistema, incluidas aplicaciones, datos, siste-
ma operativo y hasta intrusión en los demás
equipos en la red de la organización.
Todas las plataformas son susceptibles a
cualquiera de estos tipos de ataque, ya sea
C#, .Net, PHP, C, Perl, Ruby on Rails y hasta
aplicaciones Java y lo peor de todo es que no
importa que tan segura sea la configuración
de red, si la aplicación no es segura, la infor-
mación que contiene está en riesgo.
Tomar cartas en el asunto
Las aplicaciones deben ser protegidas con-
tra cualquier problema de seguridad, es de-
cir, los ataques a las mismas se deben de de-
tectar y evitar desde su concepción, para ir
delante de los hackers existen dos caminos:
el fortalecimiento de los estándares de pro-
gramación y las pruebas sobre aplicaciones.
Robustecer los estándares de seguridad pro-
gramados en las aplicaciones permite evitar
la recodificación, reduce los costos de man-
tenimiento y las situaciones críticas cuando
algún evento de seguridad se presenta. En
algunos casos la utilización de frameworks,
permiten reducir la posibilidad de un ataque
Cross-Scripting y para evitar situaciones de
inyección de código SQL, es posible median-
te la utilización de sentencias preparadas
www.sg.com.mx
en aplicaciones que ayudan a mitigar este
riesgo. Este tipo de acciones reduce la posi-
bilidad de algún ataque a la aplicación, pero
siempre una buena práctica de seguridad
es la realización de pruebas para verificar y
comprobar nuestras mejoras en el diseño y
programación.
En la etapa de pruebas, de igual manera
existen dos maneras de ser realizadas, ma-
nualmente o mediante una herramienta que
automatice estas pruebas. La primera signi-
fica dedicar tiempo en la creación de los ca-
sos de prueba, instrucción y documentación
del equipo de pruebas para conocer las vul-
nerabilidades existentes. Actualmente, con
la mayor adopción de aplicaciones Web 2.0,
las variables en la ecuación de seguridad de
aplicaciones crece aún más.
La automatización de las pruebas reduce
tiempos de realización de las pruebas y sim-
plifica los casos, adicionalmente es impor-
tante contar con una herramienta que emu-
le el comportamiento malicioso del hacker
y contenga una base de datos actualizada
con las fallas comunes que se conocen en
el mundo de la Seguridad de la Información.
La herramienta en el mercado que facilita
estas actividades es Rational AppScan que,
adicionalmente a las características antes
mencionadas, contiene una base de conoci-
mientos que permite sugerir correcciones y
mejores prácticas a los errores y omisiones
que se hayan encontrado al momento de la
ejecución del proceso de revisión del sitio.
La prioridad es la seguridad
La seguridad y garantía de la información
que reside en las aplicaciones Web no es un
tema que se deje a la ligera, requiere de toda
la atención ya que existe todo un ejército de
personas que están dispuestas a tomarse
el tiempo de encontrar en las fallas al sitio
que escojan y de esa forma poner en riesgo
a las empresas, independientemente de su
tamaño. Tomar las medidas precautorias es
garantía de que ni las organizaciones ni los
usuarios sufrirán de algún tipo de pérdida
económica, robo de identidad o despresti-
gio frente a clientes e inversionistas.
Referencias
[ webappsec.org/projects/threat/ ]
[ owasp.org/index.php/Top_10_2007 ]
AGO-OCT 2008
 // UML
RECONOCIENDO LOS DIAGRAMAS
Buen Comportamiento con Diagramas de Secuencia
Por Miguel Ángel Armas Alemán
Una de las principales preguntas al anali-
zar y diseñar software con UML es ¿cómo
se hace o reconoce un buen diagrama?
Conocer la notación es apenas el inicio del
camino, la mejor analogía la encontramos
en la literatura, saber leer y escribir no ga-
rantiza que podamos escribir obras como
Shakespeare o Quevedo, de la misma forma
el conocer UML no garantiza que tengamos
la capacidad de hacer un buen análisis o di-
seño. En otros artículos se han mostrado las
reglas básicas para elaborar un diagrama de
secuencia, en esta ocasión nos ocuparemos
de los principios mínimos para hacer el di-
seño de un caso de uso en un diagrama de
secuencia de UML.
Intención del diagrama de
secuencia
El diagrama de secuencia nos permite dise-
ñar el comportamiento del software. Sirve,
entre otras cosas, para diseñar casos de
uso, generalmente se hace al menos uno
por cada caso de uso, se diseña tomando en
cuenta los resultados del análisis, por lo que
los artefactos que se necesitan para elabo-
rarlo son los mostrados en la figura 1.
&TQFDJGJDBDJwO

B

EFUBMMF
EFM
$6
%JBHSBNB
EF
TFDVFODJBT
1SPUPUJQP
EF
%JTFvBS
VO
$6
JOUFSGB[
HSgGJDB
%JBHSBNB
EF
DMBTFT
.PEFMP
DPODFQUVBM
Figura 1. Entradas y salidas del diseño de un caso
de uso.
El diagrama de secuencia es un diagrama
de comportamiento y modela lo que suce-
de internamente en el software cuando, por
ejemplo, los usuarios aprietan botones y
teclas, ahí debemos definir con qué objetos
de frontera (GUI, servicios web, etcétera) in-
48 AGO-OCT 2008
teractúa el actor y qué objetos de negocio
se ven involucrados para atender los even-
tos generados, todo esto apegado al guión
especificado en el texto del análisis.
Este tipo de diagrama puede verse como
una traducción del texto del análisis en tér-
minos de objetos y métodos con todas las
consideraciones técnicas de la arquitectura.
Hacer un buen diseño no es cuestión de com-
plejidad, es decir, el mejor diagrama de secuen-
cia no es el que tenga más objetos y mensajes,
pero hay tres principios básicos que debe cum-
plir un buen diagrama de secuencia:
1. Identificar a los objetos involucrados
2. Definir la responsabilidad de cada objeto
3. Mostrar el ciclo de vida de cada objeto
El diagrama de secuencia modela el compor-
tamiento de un caso de uso desde la perspec-
tiva del diseño, por lo que el comportamiento
de una aplicación de escritorio para 25 usua-
rios es distinto al de una aplicación web para
700 usuarios, esta particular interacción en-
tre los objetos de la aplicación debe quedar
plasmada en el diagrama aplicando los prin-
cipios mencionados.
Identificar a los objetos
involucrados
La primera parte de traducir el texto del aná-
lisis a objetos y métodos consiste en identifi-
car qué objetos están involucrados, el texto
del análisis menciona normalmente sólo a
los objetos de negocio; mismos que posible-
mente tengamos ya incluidos en el modelo
conceptual. Es responsabilidad del diseña-
dor identificar e incluir el resto de los objetos
que participan en el caso de uso y que no son
de negocio, como ventanas, formas, servicios
web, persistencia, seguridad, etcétera.
Tampoco se trata de modelar todos y cada
uno de los objetos, solo los más importantes
para la ejecución del caso de uso, no tiene
sentido modelar una y otra vez en cada caso
de uso cuáles son los objetos involucrados
en las tareas repetitivas como esta, pueden
omitirse por un sentido práctico.
Una parte importante de la identificación de
los objetos consiste en nombrarlos y asig-
narlos a la clase a la que pertenecen, esto
evita que los programadores dupliquen ob-
jetos y clases que ya existen.
La identificación de los objetos involucrados
usualmente se hace en paralelo con la asig-
nación de responsabilidades de cada obje-
to, el cual es el siguiente punto.
Definir la responsabilidad de
cada objeto
Este es el aspecto más importante de un
diagrama de secuencia, la mejor forma de
asignarle responsabilidad a un objeto es
usando los Patrones de Diseño y los Patro-
nes Generales de Asignación de Responsa-
bilidades (GRASP por sus siglas en inglés).
Pero, otro aspecto importante que no abar-
can los sistemas de patrones anteriores,
es lo que tiene que ver con el negocio del
sistema que se diseña. En el caso de uso
Prestar Libro, ¿qué objetos de negocio están
involucrados?, ¿cuántas ventanas se necesi-
tan?, ¿cuáles son los objetos de persistencia
necesarios?, ¿qué objeto lleva el control del
CU? Estas preguntas se deben resolver al di-
señar cada caso de uso.
Una de las técnicas más utilizadas para de-
finir las responsabilidades de los objetos es
clasificar cada objeto de acuerdo al patrón
Modelo-Vista-Control (MVC) como frontera,
control o entidad.
Los objetos de frontera son los que interac-
túan con el actor, mostrando información o
recibiendo peticiones. Estos objetos repre-
sentan ventanas, páginas web y servicios
web entre otros.
www.sg.com.mx
Los objetos de control son los que reciben
mensajes de los objetos frontera y deci-
den qué curso de acciones tomar, enviando
mensaje a todos los objetos involucrados en
atender la petición del usuario. En una de las
variantes del patrón MVC se modela un obje-
CPPM
to de control para cada caso de uso, el cual
CPPM
tiene los pasos necesarios para ejecutarlo.

CPPM refactoring sobre el código de ambos casos
Los objetos entidad son los que ya se han
identificado como clases en el modelo con-
ceptual, aunque se podrían identificar nue-
vos conceptos de negocio en el diseño. Tam-
bién se pueden modelar los objetos de una
capa de persistencia como objetos entidad.
'SPOUFSB $POUSPM &OUJEBE
Figura 2. Estereotipos de los objetos en el patrón MVC.
En los objetos de negocio es donde el dise-
ñador debe aplicar su pericia para definir la
responsabilidad de cada objeto, por ejem-
plo, si hay que validar que una credencial
esté vigente, no es responsabilidad del ob-
jeto ventana, si no de un objeto credencial,
verificar que el lector no tenga más de tres
préstamos vigentes y ninguna multa sin
pagar, lo debe hacer el objeto lector y no la
CPPM
ventana de préstamos. Estas responsabili-
CPPM
dades las podemos ver en la figura 3.
Para definir las responsabilidades en un
diagrama de secuencia se deben identificar

CPPM de uso y cuáles existían previamente.
que objetos de frontera intercambian men-
sajes con el actor y que objetos de control
solicitan a los objetos de entidad ejecutar
las operaciones de negocio necesarias para
realizar el caso de uso.
Mostrar el ciclo de vida de cada
objeto
Saber qué objetos ya existen y cuáles son
los que deben crearse durante la ejecución
de un caso de uso es importante para evitar
que en cada caso de uso se reserve memoria
a diestra y siniestra y se dupliquen objetos
haciendo viajes innecesarios a la Base de
Mike Armas es consultor e instructor senior certificado por la OMG en Milestone Consulting.
www.sg.com.mx
lar y no cuando estamos programando, por
ejemplo, si únicamente diseñamos con un
#JCMJPUFDBSJP GSN3FH1SFTUBNP DUSM$63FHJTUSBS1SFTUBNP DSFEFODJBM MFDUPS
diagrama de clases, corremos el riesgo de

WBMJEBS-FDUPS OVN$SFE
que cuando estemos programando el caso

WBMJEBS-FDUPS OVN$SFE
de uso Pagar Multa y nos demos cuenta de que

OVN$SFE7BMJEPWBMJEBS OVN$SFE
el objeto credencial se comporta similar en el

DSFE7JHFOUF
WJHFOUF
caso de uso Prestar Libro, tengamos que hacer

MFDUPS&MFHJCMF1SFTUBNP
FMFHJCMF1SFTUBNP OVN$SFE

HFU%BUPT
de uso, y definitivamente es más rápido y ba-

NPTUSBS MFDUPS
rato modificar diagramas que código.
Otra ventaja está en la posibilidad de de-
Figura 3. Responsabilidad de los objetos. sarrollar una arquitectura consistente para
todo el sistema. Si sólo diseñamos utilizan-
Datos. En un diagrama de secuencia debe do diagramas de clases, cada programador
modelarse con mensajes de creación (- - - >) puede codificar sus casos de uso con un
en qué momento se necesita crear un objeto, estilo muy particular y distinto al de los de-
al encontrar una X en la línea de vida de un más, que dependerá más de la calidad de la
objeto, sabemos que es elegible para reco- especificación del caso de uso y la habilidad
lección de basura. de cada programador.
Los objetos que no reciben un mensaje de Pero, como le solemos explicar a nuestros
creación se asume que ya existen antes de co- alumnos en nuestros cursos, la proporción
menzar el caso de uso y el símbolo del objeto de casos de uso a los cuales conviene dise-
está hasta arriba en el diagrama de secuen- ñarles sus diagramas de secuencia depende
cias, como puede observarse en la figura 4. de la situación del proyecto y sus tiempos.
Debido a que en la mayoría de los casos
no contamos con tantos recursos ni tiempo
#JCMJPUFDBSJP GSN3FH1SFTUBNP DUSM$63FHJTUSBS1SFTUBNP
como para poder desarrollarlos todos.

WBMJEBS-FDUPS OVN$SFE

WBMJEBS-FDUPS OVN$SFE

OFX
$SFEFODJBM Conclusión
DSFEFODJBM Un buen diagrama de secuencia debe

OVN$SFE7BMJEPWBMJEBS OVN$SFE
dejar claro cuáles son los objetos in-

DSFE7JHFOUF
WJHFOUF
volucrados, cómo colaboran dichos
objetos para realizar el caso de uso, y

OFX
-FDUPS
qué objetos se crean durante el caso
MFDUPS

MFDUPS&MFHJCMF1SFTUBNP
FMFHJCMF1SFTUBNP OVN$SFE

NPTUSBS MFDUPS

HFU%BUPT
No es necesario indicar el algoritmo
para validar el número de una creden-
cial o la sintaxis de una dirección de
email, eso le corresponde al progra-
Figura 4. Símbolo del objeto. mador, pero si es imprescindible indi-
car qué objeto es el responsable de va-
Ventajas de diseñar con un lidar y además a qué clase pertenece.
diagrama de secuencia No olvides que, siempre que te sea
Elaborar un diagrama de secuencia para cada posible, es sano apoyarte en gente
caso de uso representa un esfuerzo impor- con mayor experiencia en las buenas
tante dentro del proyecto, pero nos permite prácticas. Al final tu usuario te lo agra-
detectar comportamiento común en varios decerá al beneficiarse con la calidad
casos de uso, identificando tempranamente de tus sistemas.
a los objetos y clases reutilizables al mode-
AGO-OCT 2008 49
 // PM CORNER
MEJORES ESTIMACIONES PARA EL
DESARROLLO DE SOFTWARE
El Poker de la Planeación
Por Marco Dorantes
En la actualidad la teoría y la práctica del
diseño de software es todavía una mezcla
sui géneris entre arte-artesanía y ciencia-
ingeniería donde la precisión matemática es
tan relevante como el atractivo emocional.
El lado técnico del diseño de software se asi-
mila mejor familiarizándose con el proceso
creativo de obras que provienen exclusiva-
mente de la lógica y cuyas propiedades por
ende no están definidas en el campo de la
física (con excepción quizá de la medida del
desorden observado en las dependencias
en, desde y hacia dicho software).
El diseñador de software desarrolla y ejerce
su talento desde su fuero interno en don-
de encuentra la materia prima del software
mismo sujeto de diseño: la lógica, como
los principios de la inferencia lícita y los
criterios de la demostración válida que in-
vestigan y clasifican la estructura de las de-
claraciones y de los argumentos. Las propie-
dades de la materia prima de un producto
cualquiera moldean las posibilidades de lo
que puede llegar a convertirse y la manera
en que alcanza su función. Por lo tanto, el
conocimiento detallado de las propiedades
de la materia prima y de los bloques prefa-
bricados es esencial para un buen diseño;
donde los bloques prefabricados aquí son
el software previamente escrito y disponible
para ser reutilizado.
Siendo la lógica —la lógica simbólica en par-
ticular— parte de la materia prima en diseño
de software entonces para un empleo ade-
cuado de la misma es ineludible el dominio
del lenguaje, sea este natural como el espa-
ñol o el inglés o sea artificial como Microsoft
Visual C#, para lograr consistencia, validez y
completitud en el software diseñado. No es
sorpresa entonces que la actividad de dise-
Marco Dorantes es consultor en el diseño y formulación de software desde 1987. Ha realizado diversas contribuciones públicas en la comunidad mundial de pro-
gramación, tanto en foros técnicos como en software disponibles en www.xprogramming.com Publica un diario electrónico en blogs.msdn.com/marcod
50 AGO-OCT 2008
ño de software ofrezca mejores resultados
cuando se realiza en un ambiente cooperati-
vo donde los diseñadores emplean todo tipo
de lenguaje y sus formas de expresión habla-
da o escrita para crear software de calidad.
La importancia de la comunicación efectiva
es imponente en diseño de software tan sólo
seguida de la importancia de inventiva. Sin
embargo, es paradójico descubrir que existe
una imposibilidad intrínseca en la comunica-
ción humana que nos libera de intentar una
comunicación perfecta. Así, el desarrollo de
software se convierte en un juego cooperati-
vo de comunicación e invención con el cual
cada proyecto no intentará lograr comuni-
cación perfecta sino administrar la falta de
completez en nuestra comunicación.
Calculando un proyecto de
desarrollo de software
La responsabilidad del cálculo de las varia-
bles económicas típicas de un esfuerzo se-
rio para llevar a cabo X está en función del
conocimiento y experiencia de quienes ha-
cen dicho cálculo. Ese conocimiento incluye
no solamente las expectativas sobre X sino
también sus propiedades intrínsecas, es de-
cir su naturaleza.
Tom DeMarco y Timothy Lister nos explican
cómo la actividad del desarrollo de software
es inherentemente diferente a la actividad
de producción o manufactura. Ellos men-
cionan algunos efectos fatales que causa
la mentalidad de producción o manufactura
cuando se aplica al desarrollo de software
y, sin embargo, cuán frecuente es el caso
de grupos gerenciales que permiten mol-
dear su pensamiento por una filosofía de
administración enteramente derivada de
los ambientes de producción o manufactu-
ra. Por brevedad, aquí presentaré —desde
la perspectiva del cálculo de proyectos de
desarrollo— sólo dos de las conclusiones
de DeMarco y Lister: El planteamiento en
producción o manufactura tiende a evitar
que los individuos se pongan a pensar en el
trabajo, a su vez, se inclina por empujar el
esfuerzo hacia un enfoque ciento por ciento
dedicado a la ejecución y a la conclusión de
tareas bajo la excusa de que hay poco tiem-
po, como si hubiese alguna vez trabajo por
hacer sin la presión del tiempo.
Un planteamiento que considera la natura-
leza del desarrollo de software incluye tiem-
po suficiente para pensar en, por ejemplo,
¿debiéramos siquiera realizar esta tarea? y
pensarlo en repetidas ocasiones. Un proyec-
to o un ambiente donde la reflexión —acer-
ca del contexto y rumbo del esfuerzo— es
alentada tienen mayor oportunidad de ofre-
cer predicciones más confiables. Después
de todo ¿qué es un estimado?. Desde un
punto de vista formal un estimado es una
predicción basada en una valoración pro-
babilística siempre sujeta a ser ajustada. El
proyecto de alta prioridad que debe ofrecer
los mejores beneficios económicos a todas
las partes es precisamente el proyecto que
no puede darse el lujo de privarse de dicho
ambiente donde los individuos son estimu-
lados a realizar reflexiones frecuentes.
El trabajo intelectual es diferente al trabajo
mecánico y los errores provisionales —no
permanentes— son una parte natural y sana
de este tipo de trabajo. Los errores de esta
clase proveen más oportunidades para el
aprendizaje y mantener un ambiente donde
no se permiten dichos errores sólo provoca
que la gente adopte una actitud defensiva
y de no intentar nada nuevo que tenga una
ligera probabilidad de resultar mal. Dicho
www.sg.com.mx
ambiente se provoca cuando se pretende
automatizar el proceso intelectual tal como
se automatiza un proceso mecánico —al
estar este completamente entendido— o
cuando se imponen metodologías rígidas
que impiden a los individuos tomar cual-
quiera de las decisiones estratégicas por
miedo a que se equivoquen. Por otro lado,
un planteamiento más cercano a la realidad
del desarrollo de software estimularía a los
individuos a cometer este tipo de errores y
ser felicitados cuando los cometan pues es,
en parte, por lo que reciben su sueldo. Des-
de esta perspectiva introduzco a continua-
ción una estrategia que puede ser llamada
estimación iterativa.
Estimación iterativa
La idea básica es que cualquiera que publi-
que un estimado es susceptible de mejorar
dicha habilidad y así publicar estimados
cada vez más útiles. Dicho con otras pala-
bras, se sabe que algunos estimados son
intrínsecamente propensos a estar del todo
equivocados y tienen que ser rechazados,
no ajustados, pues la actividad de estima-
ción incluye tales callejones sin salida y el
esfuerzo perdido puede mantenerse peque-
ño y ser considerado un error provisional.
La estimación iterativa puede ser percibida
por algunos como una complicación política
pues les parece difícil justificar el re-trabajo
y prefieren creer que les irá mejor usando
el estimado equivocado aún cuando podría
costar mucho más al final de cuentas. La
estimación iterativa es una técnica heurís-
tica, es decir, una técnica de indagación y
descubrimiento; una manera de buscar la
solución a un problema mediante métodos
no rigurosos, por tanteo ó reglas empíricas.
La estimación iterativa considera al menos
cinco causas por las que las estimaciones
son deficientes:
1. Escasez de destreza para estimar
2. Predisposición o imparcialidad no consi-
derada en la estimación
3. Poco entendimiento del significado de un
estimado
4. Uso inadecuado de políticas que obstacu-
lizan una buena estimación
5. Escasez de métricas de estimación para
referencia
No debiera suceder una sola vez al inicio de
un proyecto pues su mayor valor se obtiene
al repetirla por cada agrupación de alcance
funcional detallado en que haya sido dividi-
www.sg.com.mx
do el proyecto. Una técnica para ejecutar la
estimación iterativa se llama poker de pla-
neación. La granularidad del alcance funcio-
nal determina dos niveles de planeación: de
grano grueso, y de grano fino. El nivel de pla-
neación de grano grueso abarca funciones
generales de alto nivel y representa ciclos
usualmente en la escala de meses. El nivel de
grano fino abarca funciones detalladas que
son implementables en ciclos típicamente en
la escala de semanas. Los ciclos de desarro-
llo de grano fino inician con la ejecución del
poker de planeación y terminan con una ver-
sión interina de la solución en desarrollo que
incluye la implementación de las funciones
estimadas en el poker de planeación inicial.
Los ciclos de desarrollo de grano grueso sim-
plemente son agrupadores de ciclos de grano
fino y terminan con la liberación de una ver-
sión pública de la solución en desarrollo.
¿Cómo mejorar tus
estimaciones?
La variedad de técnicas existentes para desa-
rrollar una estimación pueden ser de ayuda
siempre y cuando se decida analizar su utili-
dad en el debido contexto, depende de usted
estimado lector. A continuación resumo breve-
mente la técnica de poker de planeación para
su consideración cuando le pregunten ¿cuán-
do... ó cuánto...?, y que también le pueden
servir para valorar la calidad de la respuesta
cuando sea usted quien hace la pregunta.
La técnica puede tener aplicación gene-
ral, pero en realidad están orientados para
proyectos de desarrollo de soluciones de
software, además se asume que los puntos
esenciales para mejorar el ¿qué desarrollar?
ya han sido debidamente considerados en
forma de una especificación funcional. El
poker de planeación incluye como partici-
pantes a todo el personal técnico posible
del grupo de proyecto incluyendo desarro-
lladores, arquitectos, testers, DBAs, etcé-
tera. Al inicio del poker de planeación se le
ofrece a cada estimador un mazo de cartas
donde cada carta tiene escrito un valor es-
timado válido: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
16, 20, y 40. Los números deberán ser su-
ficientemente grandes para verse desde el
otro extremo de una mesa. Los números re-
presentan el tamaño funcional relativo de lo
que se va a estimar y lo importante es que
se mantenga consistencia entre los tamaños
relativos, es decir, una función con tamaño 2
debe representar el doble de funcionalidad
de una función con tamaño 1.
Los roles son el moderador, el dueño del
producto y los estimadores. El dueño del
producto es similar al rol gerente de produc-
to en MSF. Por cada función, caso de uso o
característica a ser estimada el moderador
lee en voz alta la descripción. El dueño del
producto contesta cualquier pregunta que
tengan al respecto los estimadores. Después
de ser contestadas todas las preguntas para
esa función, cada estimador selecciona una
carta en forma privada y que represente su
tamaño funcional estimado.
Las cartas permanecen privadas hasta que
todos los estimadores hayan hecho su elec-
ción. Entonces, todas las cartas son mostra-
das simultáneamente de tal forma que todos
los participantes pueden verlas. Es muy pro-
bable que en este punto los estimados va-
ríen significativamente y esto, de hecho, son
buenas noticias. Si estos difieren, los estima-
dores con las evaluaciones más bajos y más
altos proceden a explicar su estimado. Nóte-
se que no se trata de criticar o atacar a estos
estimadores en este punto, sino de escuchar
y entender cuáles fueron sus criterios.
El grupo puede discutir la función bajo es-
timación por algunos minutos, durante los
cuales se pueden tomar notas de puntos
importantes para el momento de estar im-
plementando dicha función. Después de la
discusión, cada estimador revalora y reali-
za nuevamente un estimado seleccionando
la carta correspondiente de manera priva-
da. Las cartas permanecen privadas hasta
que todos hayan evaluado y entonces to-
das las cartas son mostradas simultánea-
mente. Para la segunda vuelta es probable
que los estimados hayan convergido, pero
sino, será necesario repetir el proceso. El
objetivo es que estos converjan en un solo
estimado para la función en cuestión. No es
absolutamente necesario que todos coinci-
dan en un solo número, lo importante es
que exista consenso.
Referencias
[ Agile Software Development. The
Cooperative Game by Alistair Cockburn ]
[ Peopleware. Productive Projects and
Teams by Tom DeMarco y Timothy Lister ]
[ Controlling Software Projects.
Management, Measurement and
Estimation by Tom DeMarco ]
[ Agile Estimating and Planning by Mike
Cohn ]
AGO-OCT 2008 51
 // fundamentos
Un, Dos, Threads!
Una Introducción Simple a los Threads y sus Conceptos Básicos
Por Erick Frausto
Quizás están esperando leer algo sobre
threads al comenzar a revisar este artículo,
pero les propongo que recorran esta lectura
de una forma diferente, qué les parece si co-
menzamos hablando sobre las casetas tele-
fónicas. Se preguntarán ¿cuál es la relación
de los threads con estas?, descubramos mas
adelante la analogía.
En la ciudad de México no me ha tocado ver
en las esquinas de las calles casetas telefóni-
cas con cabina, pero creo que todos hemos
visto una en las películas, como aquellas
donde Superman entraba a cambiarse para
ponerse su disfraz. Ahora que menciono esto,
Superman tendría que asegurarse de que
nadie mas utilizará la caseta telefónica don-
de se cambiaba para que nadie descubriera
quién era realmente, y debido a que las case-
tas telefónicas que ocupaba eran públicas y
por lo tanto accesible para cualquier usuario,
Superman tendría que tener cuidado.
Sabemos que estas casetas al tratarse de
un recurso compartido, su uso está sincro-
nizado para atender a un usuario a la vez,
así que por este lado Superman podría estar
tranquilo, y los usuarios que desean hacer
una llamada también lo estarán ya que na-
die mas interrumpirá su conversación mien-
tras usa la caseta telefónica. De lo contrario,
¡imagínense lo que pasaría si el uso de la ca-
seta telefónica no estuviera sincronizado!.
Cualquier persona entraría a la caseta mien-
tras alguien más la está utilizando, colgaría
su llamada y marcaría el nuevo número para
comunicarse con alguien más, además de
que la cabina se saturaría después de unos
cuantos usuarios, seguro que habría bas-
tantes problemas entre los usuarios además
de que todos sabrían quién es Superman y
se enterarían de todo lo que dice la persona
que esté hablando.
También deberíamos considerar que la case-
ta telefónica podría sufrir descomposturas o
Erick Frausto es egresado de la carrera de Ing. en Informática en UPIICSA-IPN. Además de desempeñarse como Arquitecto JEE, organiza cursos sobre tecno-
logía Java. Lo puedes contactar al siguiente e-mail: erick_frausto10@yahoo.com.mx. Erick dedica este artículo a su hermosa novia Irma.
52 AGO-OCT 2008
requerir mantenimiento, y por lo tanto, de-
bería un técnico estar al tanto de las repara-
ciones y mantenimiento de ésta, momento
en el cual el siguiente usuario de la caseta
deberá esperar fuera de esta si llegara algu-
no en el momento de una reparación o hacer
fila si algún usuario ya se encontrara espe-
rando para entrar (¡incluido Superman!) y
con esto permitir el trabajo del técnico quien
también tuvo que esperar a que terminara la
llamada de algún usuario si es que alguno
se encontrara usando la caseta en el mo-
mento de su arribo. Una vez que el técnico
termine con el mantenimiento y/o repara-
ciones, dará el aviso a los usuarios para que
continúen con el uso de la caseta.
Llegando a este punto, seguro que las perso-
nas que planificaron la forma en como funcio-
narían las casetas telefónicas de uso público
consideraron las siguientes situaciones:
• Las casetas telefónicas serán de uso com-
partido
• Los usuarios podrán llegar de forma con-
currente a la caseta, por lo que el uso de la
misma deberá sincronizarse
• Un técnico se encargará de forma periódica
de visitar la caseta telefónica para realizar el
mantenimiento y/o hacer las reparaciones
correspondientes si estas fueran necesa-
rias. En este momento, la caseta no podría
ser utilizada por ningún otro usuario
Bien, ahora será momento de hacer la ana-
logía de la caseta telefónica con los threads
y de plasmarla en código para poder echar a
andar nuestro ejemplo de manera práctica.
Para esto, primero pensemos en el diseño
de nuestra caseta  y las diferentes formas
en que podrá ser utilizada por sus usuarios,
la primera sería su uso para realizar una lla-
mada y dirigida a cualquier tipo de usuario;  Como podemos darnos cuenta, tanto el mé-
otra sería darle mantenimiento, enfocada
a los técnicos encargados de que la caseta
funcione correctamente. Es un hecho que
solo un usuario a la vez podría estar hacien-
do uso de la caseta telefónica y también es
un hecho que diversos usuarios a la vez po-
drían necesitar hacer uso de ella, por lo que
para resolver este problema necesitaremos
sincronizar el uso de la caseta y de esta for-
ma asegurarnos que solo un usuario a la vez
la utiliza, por otra parte, el técnico encarga-
do del mantenimiento también deberá ser el
único que podría estar dentro de la caseta ya
que mientras el mantenimiento se realiza, la
caseta estaría temporalmente fuera de servi-
cio y no podría ser usada ni por otro técnico
ni por cualquier otro tipo de usuario. Con
esto, nuestra clase que representa la caseta
telefónica quedaría de la siguiente manera:
package undosthreads;
public class CasetaTelefonica {
private String numeroMarcado;
private boolean enUso;
private boolean enMantenimiento;
public synchronized void usarCaseta(String numeroTel) throws
Exception {
if(enMantenimiento) {
wait(); // El usuario esperara a que el mantenimiento se
termine
}
       
enUso = true;
numeroMarcado = numeroTel;       
if(!numeroMarcado.equals(“”)) {
System.out.println(“Se esta haciendo una llamada al
numero: “ + numeroMarcado);
}
else {
System.out.println(“El usuario no específico un número
para hacer la llamada.”);
System.out.println(“Tal vez entro superman para cambiar-
se y salir al rescate...”);
}
       
long duracionLlamada = Math.round(Math.random() *
10000);
Thread.sleep(duracionLlamada);  // Llamando...
System.out.println(“Duración de la llamada: “ + duracionLla-
mada/1000 + “seg.”);
numeroMarcado = null; // El usuario colgo el telefono
enUso = false;
}
public synchronized void darMantenimiento() throws Excep-
tion {
enMantenimiento = true;
while(enUso) { }
System.out.println(“Caseta Telefónica en mantenimiento...”);
long duracionMantenimiento = Math.round(Math.random()
* 10000);
Thread.sleep(duracionMantenimiento);  // En mantenimiento...
        System.out.println(“Duración del mantenimiento: “ + dura-
cionMantenimiento/1000 + “seg.”);   
        enMantenimiento = false;
        notifyAll(); // El tecnico avisa a los usuarios que pueden
continuar con el uso de la caseta
}
}
todo usarCaseta() y el método darMantenimiento()
se encuentran sincronizados (synchronized),
con esto aseguramos que los usuarios se-
www.sg.com.mx
rán representados como threads podrán
acceder uno a la vez a un método en par-
ticular, de esta manera tenemos que solo
un thread entrará al método usarCaseta()
y un solo thread entrará al método
darMantenimiento(). Pero lo anterior no resuel-
ve del todo nuestro problema de concurren-
cia, ya que la implementación que tenemos
hasta ahora permite que un usuario normal
y un técnico puedan hacer uso de la caseta
telefónica al mismo tiempo, por lo que de-
beremos establecer una comunicación en-
tre los usuarios normales y el técnico, esto
lo logramos mediante los métodos wait() y
notifyAll(), el método wait() le dice al thread
que se este ejecutando que deberá suspen-
der momentáneamente su ejecución has-
ta que otro thread le notifique que puede
continuar, el método wait() será llamado por
el thread que representa a un usuario normal
cuando detecte que la caseta telefónica se
encuentra en mantenimiento, y el método
notifyAll() será llamado por el thread que repre-
senta al técnico, este método lo que hace es
avisar a los threads que están en espera que
pueden continuar con su ejecución, es decir,
le dirá a los usuarios que la caseta telefónica
esta lista para ser usada nuevamente.
Una vez lista nuestra caseta telefónica, pa-
semos a la creación de nuestros usuarios.
Como mencionamos antes, tanto la imple-
mentación de los usuarios normales como la
implementación del técnico, deberán estar
basados en threads. Existen dos formas en
Java mediante las cuales indicamos que una
clase será un thread, esto es extendiendo de
la clase Thread o implementando la interfaz
Runneable, en ambos casos debemos de
implementar el método run() cuyo conteni-
do será la actividad que el thread llevará a
cabo. Veamos ambos casos:
package undosthreads;
public class Usuario1 extends Thread {
private CasetaTelefonica ct;
    private String numTelefono;
  public Usuario1(CasetaTelefonica ct, String numTelefono)
{ tintos usuarios. Después tenemos la creación
this.ct = ct;
this.numTelefono = numTelefono;
    } usuarios, lo interesante a mencionar en esta
public void run() {
        try {
ct.usarCaseta(numTelefono);
} thread cuya clase que representa su función
catch(Exception e) {
System.out.println(e);
}
    }
} necesario crear el objeto de la clase que here-
www.sg.com.mx
package undosthreads; da de Thread y llamaremos al método start(),
public class Usuario2 implements Runnable {
    el cual iniciará la ejecución del thread (la JVM
private CasetaTelefonica ct;
    private String numTelefono; se encargará de llamar al método run() que
public Usuario2(CasetaTelefonica ct, String numTelefono) implementamos para este Thread), para el
{
this.ct = ct; segundo caso después de crear el objeto de
this.numTelefono = numTelefono;
    } la clase que implementa Runneable, creare-
public void run(){ mos una instancia de Thread y le pasaremos
try {
ct.usarCaseta(numTelefono); a través de su constructor el objeto creado
}
catch(Exception e) { un paso antes, posteriormente llamaremos
System.out.println(e);
} al método start() que tendrá la misma función
}
    que en el primer caso.
}
Con la ejecución de la clase de prueba, po-
En el caso del técnico, la implementación
quedará de la siguiente manera: dremos ver algo como esto:
package undosthreads; Se esta haciendo una llamada al numero: 98776655
public
    class Tecnico extends Thread { Duración de la llamada: 2seg.
Se esta haciendo una llamada al numero: 99887654
private CasetaTelefonica ct;
public Tecnico(CasetaTelefonica ct) { Duración de la llamada: 3seg.
this.ct = ct; Caseta Telefónica en mantenimiento...
    } Duración del mantenimiento: 4seg.
public void run() { El usuario no específico un número para hacer la llamada.
try {
ct.darMantenimiento();
Tal vez entro superman para cambiarse y salir al rescate...
Duración de la llamada: 9seg.
} Se esta haciendo una llamada al numero: 81909090
catch(Exception e) { Duración de la llamada: 1seg.
System.out.println(e);
}
    }
}
Conclusión
Finalmente nos queda crear una clase de prue- Es claro que lo que vimos fue una in-
ba donde echaremos a volar nuestra pequeña troducción al tema de threads y a sus
aplicación, esta luce de la siguiente manera: conceptos básicos, estos dan lugar a
tantas opciones dentro de la creación
package undosthreads; de aplicaciones en Java, desde las que
public
    class Test { solo requieran levantar un thread en
public static void main(String[] args) throws Exception {
CasetaTelefonica ct = new CasetaTelefonica();
paralelo al thread principal para que
Usuario1 a = new Usuario1(ct, “98776655”); borre archivos temporales hasta apli-
        a.start(); caciones complejas que requieran toda
Usuario2 b = new Usuario2(ct, “99887654”);
Thread hilo = new Thread(b); una administración de threads, como
        hilo.start(); una aplicación de scheduling donde
Tecnico tecnico = new Tecnico(ct);
        tecnico.start(); se podrían tener diversos threads
Usuario1 superman = new Usuario1(ct, “”);
ejecutándose en paralelo y accedien-
        superman.start();
Usuario1 c = new Usuario1(ct, “81909090”); do a recursos compartidos, donde la
c.start();
} implementación de una aplicación de
}
    este tipo requerirá de toda la dedica-
ción y atención posibles tanto en su
diseño como en su desarrollo.
Aquí tenemos la creación del objeto caseta
telefónica que será compartido entre los dis- El desarrollo de aplicaciones basa-
das en threads es un tema complejo
de diversos objetos que representan a los y para el cual existen libros completos
tratando el tema, sin embargo, espero
parte es la diferencia cuando creamos un que esta pequeña introducción sea un
primer buen paso para los que se ini-
hereda de la clase Thread o implementa la cian en el tema de threads y sus con-
interfaz Runnable, en el primer caso solo es ceptos básicos.
AGO-OCT 2008 53
 // COLUMNA
La Calidad del Software Mexicano
Resultados del 2º Concurso e-Quallity
Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es co-
fundador. Fue profesor-investigador en el ITESO durante varios años, que incluyeron una estancia de posgrado en prueba de software en
Alemania, en la que abordó aspectos formales de dicha disciplina. Es autor de varias publicaciones nacionales e internacionales. Fue co-
fundador del Capítulo Jalisco de la AMCIS.
R ecientemente el proceso de prueba de
software, de la empresa en la que laboro, fue
certificado con un nivel muy alto tanto en el
modelo estadounidense Testing Maturity
Model (TMM) como en el europeo Test
Process Improvement (TPI).
Aprovechando esta experiencia el año pa-
sado lanzamos el Concurso e-Quallity 2007,
en el que convocamos a la comunidad desa-
rrolladora nacional de software a enviarnos
productos pequeños terminados, para en-
contrar los productos con menor densidad
de defectos (cantidad de defectos entre ta-
maño). Hicimos la premiación en el congreso
SG’07 Conferencia y Expo, publicamos los re-
sultados en la columna Prueba de Software
del número 20 de esta revista.
Este año llevamos a cabo el Concurso
e-Quallity 2008, del cual hicimos la premia-
ción en el pasado congreso SG’08 Conferen-
cia y Expo. Aquí mostraremos los resultados
que se obtuvieron. Nuestro objetivo no es
realizar un estudio estadístico riguroso, sino
poner nuestro grano de arena en la genera-
ción de datos para cubrir el enorme hueco
de información que tenemos respecto a mé-
tricas de calidad de los productos mexica-
nos, y su repercusión en la industria.
El Impacto de probar
inadecuadamente el Software
En la publicación de esa columna, mencio-
nábamos que en 2003 la industria de los
Estados Unidos perdió cerca del 1% de su
PIB por pruebas de software inadecuadas o
inexistentes, equivalente a casi 60 mil millo-
nes de dólares.
Comentamos que en México no existe una
cuantificación semejante, pero que pode-
mos pensar que en nuestro país el efecto es
más nocivo, pues mientras que la industria
54 AGO-OCT 2008
/*PRUEBA DE SOFTWARE*/
5JFNQP
%FTBSSPMMP
EFM
QSPEVDUP
7FOUBT
Figura-1: Impacto económico de las pruebas
del software estadounidense es mucho más
grande y madura, la nuestra está apenas
despegando, lo que dificulta ganar inercia
positiva, y crea un nocivo circulo vicioso.
En The Impact of Software Testing in small
Settings, publicamos datos del impacto eco-
nómico de las de pruebas en dos proyectos
reales en los que participamos. Puesto grá-
ficamente tendríamos lo que se observa en
la Figura 1.
Aquí la curva negra muestra el consumo de
los recursos al desarrollar un nuevo produc-
to de software, considerando datos de A
Guide to the Project Management Body of
Knowledge; la verde los ingresos por ventas
del producto; la azul los costos de mante-
nimiento cuando el software es probado
adecuadamente antes de ser liberado y se
elimina la mayoría de los defectos; y la roja
los costos de mantenimiento cuando no se
prueba o se prueba inadecuadamente el
software. Cuando no se prueba adecuada-
mente el software, los costos de manteni-
miento suelen mermar significativamente
las utilidades (ventas – mantenimiento,
grosso modo), dificultando la inversión en
mercadotecnia e innovación en el producto,
haciendo difícil el crecimiento de esa unidad
de negocio.
.BOUFOJNJFOUP
DPO
1SVFCBT
.BOUFOJNJFOUP
TJO
1SVFCBT
El proceso y la muestra
La evaluación de servicios la realizamos en
tres fases:
1. Un Diagnóstico del software: un tester ex-
perimentado realiza pruebas exploratorias y
detecta una primera capa de defectos. Uti-
lizando esa información y nuestro Modelo
Predictivo, se genera una estimación de los
defectos que aún se encuentran en el pro-
ducto, el costo de detectarlos, y la compara-
ción del producto contra la media de calidad
de los productos que hemos probado.
2. Con esos datos del diagnóstico, el intere-
sado puede optar por contratar las Pruebas
Profundas para detectar esos defectos: si
el producto está muy mal, sólo se justifica
invertir en pruebas lo suficiente como para
detectar una pequeña segunda capa de
defectos críticos (por ejemplo, probar sólo
alguna(s) sección(es)); si está muy bien,
recomendamos no invertir en pruebas pues
resultará muy caro detectar los defectos; si
el producto tiene un estado intermedio, las
pruebas profundas sí pueden ayudar a me-
jorar significativamente el producto.
3. Si después de estas pruebas profundas y
las correspondientes pruebas regresivas, el
software muestra un buen comportamiento
www.sg.com.mx
 “Mientras que la industria del software
estadounidense es mucho más grande y
madura, la nuestra está apenas despegando”.
al aplicar nuestro Modelo de Calidad de Pro-
ducto, otorgamos nuestro Sello de Calidad
e-Quality Approved, mismo que fue validado
con apoyo del Consejo Nacional de Ciencia y
Tecnología (CONACyT).
Para la ejecución del Concurso aplicamos un
proceso que representa un downsizing del
Diagnóstico mencionado arriba (fase 1).
Este año redujimos el número máximo de
concursantes a 20. Una cantidad considera-
ble de productos fueron rechazados, ya fuera
porque se excedían en el tamaño, o porque
no estaban completamente terminados.
La muestra final constó de 15 productos,
provenientes de varios dominios de aplica-
ción. Su tamaño (entre 20 y 30 meses hom-
bre) se midió utilizando una métrica interna
semejante a los puntos de función.
Resultados y Análisis
En la tabla que se muestra a continuación
presenta datos sobre la calidad de los pro-
ductos concursantes (KLOC = miles de lí-
neas de código).
En un primer acercamiento, si comparamos
directamente la segunda columna contra los
resultados del Concurso pasado, podríamos
pensar que estos productos son más esta-
bles que aquellos. Sin embargo, estos fue-
ron más pequeños, y como dijera un autor
“Size matters”: un producto de 100 KLOC
con 300 defectos en realidad tiene constitu-
yentes más confiables que un producto de
10 KLOC con 30 defectos… siempre y cuando
tengan complejidad estructural semejante.

1SPEVDUP
%FGFDUPT$BTPT
EF





NgT
NBEVSP


QSPNFEJP


NFOPT
NBEVSP

Tabla-1: Densidad de Defectos en Productos mexicanos pequeños
www.sg.com.mx
(Esto es un tema en sí mismo, que buscare-
mos abordar en otro número.) Por tanto, la
hipótesis no es concluyente.
Por otra parte, este año recabamos la mé-
trica de los Defectos por KLOC (D/KLOC).
En el marco del Encuentro Prosoft llevado a
cabo recientemente, se anunció el impulso
que se le brindará en nuestro país al mode-
lo Team Software Process (TSP); ahí mismo
Watts Humphrey (autor de ese modelo y
de CMMI) declaró que con TSP se pueden
alcanzar densidades de defectos de hasta
0.06 D/KLOC, contra los 7.50 para el Nivel 1
de CMMI-1, los 6.24 para el 2, los 4.73 para
el 3, los 2.28 para el 4, y los 1.50 para el 5.
Los resultados obtenidos en este Concurso
muestran que el 1º, 2º y 3er lugar tendrían
densidades de defectos correspondientes
al Nivel 4, 4 y 5 de CMMI respectivamente…
lo curioso es que esas empresas no tienen
tales acreditaciones.
Aquí también hay que considerar la salve-
dad del tamaño (size matters).
Conclusión
Un asunto pendiente que abordaremos
en otro número es cómo los ganadores
de los primeros lugares en el concurso
lograron esos niveles de calidad.
Referencias
Por otro lado: se asevera que con TSP
se puede obtener densidades de de-
fectos de hasta 0.06 D/KLOC; sin em-
bargo, hemos encontrado empresas
%FGFDUPT,-0$
1SVFCB






en nuestro país que reportan lograr
densidades semejantes… lo curioso
es que son los mismos programado-
res los que realizan las pruebas, no un
equipo de testers (interno o externo)
debidamente entrenado, al que se le
pague por detectar defectos (a los de-
sarrolladores no se les entrena para
eso, ni se les paga por ello).
Para poder demostrar que con TSP
verdaderamente se pueden alcanzar
esas densidades de defectos, sería
interesante ver resultados de pruebas
realizadas por un tercero, no por los
mismos desarrolladores de la empresa.
Habrá que esperar además, más pre-
cisión de TSP, pues no es lo mismo ha-
blar de esas densidades de defectos
para productos de 100 KLOC, que para
productos de 1,000 KLOC.
Surge también la duda: ¿cuántas KLOC
suelen tener los compiladores comer-
ciales?, ¿con qué densidad de defec-
tos? Si fuera superior a 0.06 D/KLOC,
entonces los productos generados por
ellos tendrían dificultad para alcanzar
ese número.
[ León-Carrillo, L.: Columna “Prueba de
Software”, Software Gurú, Feb-Abr 2008 ]
[ León-Carrillo, L.: The Impact of Software
Testing in small Settings, en Oktaba, H.
and Piatini, M. et.al. Software Processes in
small Enterprises. IGI Global. 2008 ]
[ The Project Management Institute: A
Guide to the Project Management Body of
Knowledge. USA, 2000 ]
[ e-quallity.net/definiciones.php ]
[ e-quallity.net ]
» Luis Vinicio León Carrillo
AGO-OCT 2008 55
 // COLUMNA
Nuevos Patrones de Software para el
Consumidor Digital
El Concepto Mesh
Luis Daniel Soto es director regional de desarrolladores y difusión de plataforma en Microsoft para América Latina. Es miembro de la
orden nacional al mérito de México (ministro de educación). Luis Daniel obtuvo el primer lugar en el Concurso Nacional para Software de
Exportación en 1989. blogs.msdn.com/luisdans
Presente
S e han consolidado los medios sociales,
complementando a los medios tradicionales de
comunicación. Este conjunto de tecnologías del
Web 2.0 junto con otras (por ejemplo, experien-
cia de usuario) evolucionan a Enterprise 2.0.
El desarrollador de software vive una gran
confusión entendiendo las tecnologías. Por
ejemplo, si he de construir una experiencia
Rich Internet Application (RIA) o una Rich
Local Application, se tiene que entender a
fondo las diferencias y ventajas para selec-
cionar entre Silverlight, WPF, Ajax, HTML,
FLASH, AIR, JavaFX y otras.
Las opciones que permiten crear aplicacio-
nes Web, para dispositivos, para el escrito-
rio y para el servidor con las mismas herra-
mientas y lenguajes son muy pocas.
Nuevas realidades:
cómputo en la nube
El panorama se complicará, se demandará
la creación de nuevos patrones de creación
de soluciones de software. Por una parte el
cómputo en la nube (trataremos ese tema
en una columna futura), por otra el desa-
rrollo de cómputo empresarial (tampoco lo
trataremos a fondo ahora). Estamos por ver
una evolución de las herramientas de desa-
rrollo de software a creación de mashups
que combinen sistemas internos y externos,
y se continuará soportando mayor funciona-
lidad ALM en sistemas cliente-servidor. Hoy
nos enfocaremos en los consumidores fina-
les de tecnologías.
Un modelo para aplicaciones
del consumidor digital
Ni el desarrollo monolítico, ni el de múlti-
ples capas, tampoco el modelo de software
entregado como servicio resuelve las nece-
sidades de los nativos digitales y del consu-
midor en la era digital:
56 AGO-OCT 2008
/*tendencias en SOFTWARE*/
-BQUPQ
8PSL
• Los dispositivos no tienen nociones de
pertenencia entre ellos. El usuario no tiene
una vista de todos sus dispositivos. Aunque a
nivel empresarial está resuelta la distribución
de software, un usuario que tiene varias com-
putadoras tiene que pelear por mantener la
configuración e instalar en forma independiente.
• Los datos están atrapados. Apesar de vivir
en la época de facilidad de intercambio de
información, esto no es cierto. Un usuario
con varias computadoras tiene que enviarse
correos a sí mismo a veces para sincronizar
sus sistemas. El paradigma actual de sincro-
nización 1:1 es frágil y tedioso.
• Las aplicaciones no son capaces de vivir en
múltiples dispositivos: si fueron hechas para
Internet su capacidad de operar fuera de lí-
nea es muy pobre. Carecen de capacidades
básicas de explotar las redes sociales a nues-
tro alrededor: de la misma forma que hoy el
menú “editar, copiar” existe, debería permitir
“etiquetar (tag), calificar (rate)”, etcétera.
Es decir, el individuo que hoy vive en la era
digital no tiene acceso entre sus dispositi-
vos, aplicaciones, datos y redes sociales con
las que interactúa.
Solución
El Web es el centro de intercambio de infor-
mación: imaginemos que de alguna forma en
)PNF
%FTLUPQ
"EE
%FWJDF
-JWF
%FTLUPQ
Internet un usuario almacena una lista de sus
dispositivos para que estos tengan noción
el uno del otro, para que posteriormente el
usuario pueda definir la ubicación de archivos
en cualquier dispositivo o en un almacena-
miento en la nube. Además existe un software
que es capaz de replicar los datos entre los
dispositivos utilizando normas de Internet y
traspasando cualquier configuración de red.
Por ejemplo, Juan crea un listado que incluye
la computadora de oficina, el sistema de tea-
tro en casa, una Apple mac de uso personal y
un teléfono celular inteligente. Después de-
fine que la carpeta “imágenes personales”
va a residir en la computadora que corres-
ponde a la sala de TV pero que se mantendrá
sincronizada en todos los dispositivos. Ese
usuario también desea que su esposa pueda
acceder la carpeta por lo que de forma natu-
ral permite la colaboración grupal.
Esas computadoras, podrán sincronizarse y
comunicarse de dispositivo a dispositivo de
forma segura: no se requiere Internet. Por
último, la actualización será automática y
transparente, los datos auténticamente se
hacen disponibles en el momento necesario
y en cualquier dispositivo.
En el modelo más avanzado, es posible
ahora crear una aplicación, por ejemplo de
administración de proyectos, que puede tra-
www.sg.com.mx

bajar indistintamente en la nube, en una red
o localmente. Y cuando lo hace localmente
eventualmente se sincronizará. El usuario
tendrá la vista de que dispositivos han sido
sincronizados.
Sin duda, esto representa un innovador pa-
trón que complementa los existentes hoy en
día. Una implementación de este modelo es
parte de lo que se ha denominado Live Mesh.
Se compone de una plataforma que define
modelos, servicios en la nube, software en
el cliente y una experiencia de plataforma
que expone dispositivos, archivos, aplica-
ciones, notificaciones y redes sociales.
No hay que confundir las primeras aplicacio-
nes con el concepto, la implementación de
carpetas virtuales o acceso remoto son solo
www.sg.com.mx
“El individuo que hoy vive en la era digital
no tiene acceso entre sus dispositivos,
aplicaciones, datos y redes sociales con las
que interactúa”.
las aplicaciones más triviales que se cons- •Manténgase informado. Es posible des-
truyen bajo el nuevo esquema. cubrir los cambios y actividades que a cada
quién interesan.
Resultado
Los beneficios son: •Nuevas experiencias. Se hace posible que
• Los dispositivos trabajan de forma inte- los sitios de Internet se extiendan en partes
grada. Se comunican por canales encripta- portátiles que hace sentido llevar y operar
dos, cada dispositivo puede tener poder de fuera de línea. Combine esto con tecnolo-
cómputo y almacenamientos muy variables, gías para crear interfaces cinemáticas en
conforme lo demande la aplicación. pantallas muti-tácto y los consumidores es-
tarán complacidos.
• Acceso universal. Por primera vez, el mesh
está disponible en cualquier dispositivo que La era de la innovación en software más ser-
puede ser accedido desde cualquier cliente vicios apenas ha iniciado…
o arbitrariamente en cualquier explorador
de Internet. Rerefencias
[ mesh.com ]
• Simple de compartir. Es fácil invitar a más [ is.gd/tgj ]
personas a colaborar los unos con los otros. » Luis Daniel Soto
AGO-OCT 2008
 // TECNOLOGÍA
¿Repetir el Proceso?
10 recomendaciones para una migración P2V exitosa
Traducido por Martín Álvarez
Cuando se trata de migrar servidores físicos
a máquinas virtuales, muchos profesionales
de TI han descubierto que llegar ahí no es
la mitad de la diversión. Muy a menudo, el
proceso de conversión es más frustrante,
confuso y tardado de lo que necesita ser. El
tiempo y recursos requeridos para la con-
versión son variables importantes en el va-
lor global y el costo total de propiedad que
le brindarán sus sistemas virtualizados. Es
fundamental seleccionar el enfoque correc-
to en la migración de servidores físicos a
virtuales (P2V) para minimizar riesgos, man-
tener su proyecto dentro del presupuesto y
en continuidad, y sus datos intactos.
Presentamos las siguientes recomendacio-
nes para el manejo del proceso y la selec-
ción de la solución que mejor satisfaga sus
necesidades.
1. Evalúe las necesidades
inmediatas y futuras
La conversión P2V se ha llevado a cabo de
muchas maneras, pero sólo unos cuantos
enfoques han funcionado bien en las migra-
ciones a gran escala. La escalabilidad y la
velocidad son dos de los mayores diferen-
ciadores entre las soluciones de conversión;
de modo que es importante que entienda
sus necesidades actuales y futuras.
Considere no sólo cuántos servidores se
necesitan convertir en el proyecto en curso,
sino también si se pueden convertir otros
servidores de forma periódica o en masa
(como volver otro departamento virtual
después de que se completen los proyectos
actuales). También es importante tomar en
cuenta si todos los servidores físicos serán
convertidos a la misma plataforma virtual
o si se pudieran utilizar múltiples entornos
virtuales. Algunas soluciones de conversión
sólo admiten un entorno virtual.
2. Establezca escalas de tiempo,
fechas límite y presupuestos
A menudo el mejor enfoque depende del
tiempo disponible para completar la conver-
58 AGO-OCT 2008
/*INFRAESTRUCTURA*/
sión. La mayoría de las organizaciones tie-
nen una fecha límite para su conversión de
físico a virtual y tienen tiempo extra limitado
para completarlo. Por lo tanto, el tiempo de
conversión total y la capacidad de conver-
sión simultánea de cada enfoque son con-
sideraciones importantes. Decida si puede
desconectar servidores para realizar la con-
versión durante o después de horas de tra-
bajo y determine de cuánto tiempo con los
servidores desconectados dispone en total
antes de la fecha límite del proyecto. A con-
tinuación, divida el tiempo disponible entre
el número de servidores que virtualizará a
fin de determinar su requisito de tiempo de
conversión total del que puede disponer por
servidor. Aquí el presupuesto es también un
factor (¿se necesitará tiempo extra o perso-
nal adicional para completar el proyecto?).
3. Evalúe sus facultades
Las preguntas acerca del personal y del pre-
supuesto no se pueden responder hasta que
determine si su personal tiene las facultades
y el tiempo para llevar a cabo la conversión.
Evalúe sus conocimientos de TI internas y su
disponibilidad para determinar qué opcio-
nes tiene a disposición su organización.
4. Fije una meta de nivel de éxito
Las fallas en la conversión de servidores P2V
no son raras. Pueden ocurrir fallas con má-
quinas virtuales de mayor tamaño por arri-
ba del rango de los 50 gigabytes, y también
cuando las herramientas P2V no cuentan
con el soporte para ciertos entornos, con-
troladores o servicios implícitos. Utilizando
el tiempo y el personal disponibles como
guías, determine cuántas conversiones falli-
das puede soportar, fije una meta de nivel
de éxito y úsela para ayudarse en la evalua-
ción de opciones. Debe poder encontrar una
solución que le proporcione un nivel de éxi-
to de al menos 95%.
5. Conozca las opciones (y sus
limitaciones)
Si sigue las primeras cuatro recomendacio-
nes tendrá un buen entendimiento de sus
necesidades. Ahora es tiempo de empa-
tarlas a las soluciones disponibles. Existen
cuatro enfoques básicos de la conversión
P2V. Cada uno de ellos es efectivo en casos
de uso específicos y cada uno tiene sus li-
mitaciones. Primero elija el enfoque general
y luego comience por evaluar opciones de
una solución específica. Éstas son cápsulas
resumidas de enfoques de conversión P2V:
• CDs de arranque más utilidades genera-
les de clonación y copia. Las organizaciones
a menudo utilizan software de clonación he-
redado y lo complementan con una utilidad
de conversión de máquina virtual y CDs de
arranque para capturar, convertir y transferir
archivos. Éste es el enfoque de conversión
original y puede ser difícil de usar, en espe-
cial si se le compara con alternativas más
recientes. Es el mejor para proyectos de
conversión pequeños o únicos.
• Herramientas de conversión gratuitas
de proveedores de plataformas de virtua-
lización. Para los usuarios con un entorno
virtual homogéneo, las herramientas gratui-
tas que ofrecen los fabricantes representan
un paso adelante del enfoque de copiar e
iniciar. Como las herramientas gratuitas se
centran en el aspecto de la conversión y no
intentan automatizar mucho del proceso
global, el tiempo total que se requiere para
preparar, convertir y solucionar problemas
de los servidores puede ser muy largo, en
especial en el caso de servidores grandes.
Conclusión: son buenas para conversiones
únicas y ocasionales.
• Herramientas y soluciones de conversión
comerciales. Las soluciones comerciales au-
tomatizan muchas tareas relacionadas con la
preparación, conversión y procesamiento pos-
terior, y a menudo proporcionan una interfaz
de usuario única para estas etapas. Ofrecen el
tiempo total de migración más corto y pueden
incluir programación de actividades y funcio-
nes avanzadas de conversión simultáneas;
de modo que a menudo son más adecuadas
para proyectos de mediana y gran escala.
www.sg.com.mx
• La subcontratación de servicios con un
proveedor de soluciones es siempre una op-
ción y puede que sea la única opción prác-
tica para organizaciones con necesidades
únicas que no satisfacen las aplicaciones de
conversión comerciales. Es más apropiada
para organizaciones con restricciones seve-
ras de tiempo y personal.
6. Calcule el tiempo total que
emplearía cada método
Tras un análisis inicial, uno o dos enfoques
de conversión podrían parecer apropiados
para su proyecto. Uno de los errores más
comunes (y costosos) que se comete en los
proyectos de conversión P2V es subestimar
el tiempo total requerido. Asegúrese de
considerar la preparación de los servidores
físicos, la programación de los tiempos para
los propietarios de los servidores, los pasos
precisos requeridos para llevar a cabo la con-
versión y los requisitos de procesamiento
posteriores a la conversión cuando evalúe el
tiempo total requerido.
Estas recomendaciones deben ayudarle a
identificar el enfoque y la solución que me-
jor se adapte a sus necesidades. Las reco-
mendaciones siguientes se aplican a la eje-
cución de la conversión misma.
7. Prepare los servidores para
optimizar el proceso de
conversión
Los tiempos de conversión pueden dismi-
nuir y los niveles de éxito aumentar cuando
los servidores físicos son preparados de
manera efectiva con antelación. Los pasos
a seguir en esta etapa incluyen calcular el
inventario de sus parámetros de configura-
ción, detalles de la licencia y direcciones IP,
instalar parches de software, desfragmentar
unidades de disco, limpiar directorios, des-
comprimir archivos y realizar otras tareas de
mantenimiento. También debe verificar que
Martín Álvarez realizó la traducción del documento original que pueden consultar en: http://www.vizioncore.com/articles/positiondoc/p2v.pdf
www.sg.com.mx
la red disponga del ancho de banda para
transferir la imagen virtualizada, y que la
máquina virtual destino tenga la memoria
para poder aceptarla. Trabaje con el propie-
tario del servidor y programe la conversión
y la prueba subsecuente del entorno vir-
tualizado. Por último, fije fechas límite para
solicitudes de cambios y programe la reali-
zación de la conversión real.
8. Automatice la ejecución
hasta donde sea posible
La realización del paso de conversión pue-
de tomar de unos 30 minutos a 20 horas. El
tiempo requerido tiene un impacto impor-
tante en el costo del proyecto y en la posibi-
lidad de cumplir con la fecha límite. Se sus-
citan muchos procesos entre el momento en
que se instala el software de conversión y
se inicia el servidor virtual recientemente
migrado. Se deben seleccionar, configurar
y asignar nombres a destinos y anfitriones;
es posible que se requiera alguna partición;
que se necesite configuración adicional para
la CPU y la memoria; se deben monitorear
las redes y las condiciones de error; se debe
asignar un nombre e iniciar la nueva máqui-
na virtual; y se debe repetir el proceso con el
siguiente servidor. Cuantas menos de estas
tareas tenga que realizar el administrador
manualmente, más rápido se realizará la
conversión. Las velocidades de conversión
reales varían considerablemente entre las
herramientas y soluciones P2V, asegúrese
de considerar la velocidad cuando manipule
todas las variables.
9. Verifique y haga pruebas
La complejidad de la preparación y la conver-
sión misma crean oportunidades de error;
de modo que las máquinas virtuales recien-
temente convertidas deben ser probadas
para asegurarse de que la conversión haya
sido exitosa. Incluso cuando resultó libre
de errores, existen varias tareas posteriores
que se deben llevar a cabo. Entre estas se
cuentan: revisar registros, reactivar servicios
y agentes, actualizar controladores, reali-
zar pruebas de control de calidad, ejecutar
scripts generados por el usuario, activar y
sincronizar la nueva máquina virtual, crear
documentación y quitar el software de con-
versión. Estas actividades se deben contem-
plar al calcular los requisitos de tiempo total
de conversión, que frecuentemente se pasan
por alto. Una vez más, el tiempo requerido
para completarlas depende de lo completa
que sea la solución de conversión.
10. Repita el proceso las veces
que sea necesario
Para realizar conversiones de medio y alto
volumen, el método debe ser repetible para
ser efectivo. Las soluciones desarrolladas
para estos escenarios de uso tienen caracte-
rísticas para eliminar mucha de la redundan-
cia en la conversión de decenas o cientos de
servidores físicos.
Existen muchos enfoques para convertir un
servidor físico en un entorno virtual, pero las
opciones prácticas se reducen abruptamen-
te cuando aumenta el tamaño del proyecto.
En el caso de migraciones de servidores a
gran escala, el tiempo del personal es a me-
nudo el elemento más costoso del proyecto
de virtualización.
Las soluciones que ahorran tiempo ahorran
dinero. Los conocimientos y la disponibi-
lidad son también restricciones comunes.
Las organizaciones deben considerar el
tiempo de conversión total al evaluar dife-
rentes enfoques y deben determinar qué
tareas necesitan que manipule su solución
de conversión. Considerando y manejando
estas variables, las organizaciones pueden
seleccionar la solución más eficiente para
sus necesidades y por último minimizar el
riesgo, el tiempo y el costo total.
AGO-OCT 2008 59
 // TECNOLOGÍA /*gadgets*/

Connect-A-Desk
¿Cuántas veces has caminado con la lap-top encendida y escribiendo con una sola
mano? Suena extraño, pero ¡es cierto!. En ocasiones, tenemos la necesidad de estar con
la computadora portátil funcionando al mismo tiempo que caminamos o estamos para-
dos, es un poco incómodo no solamente teclear con una sola mano, sino estar cargando
con la otra la máquina con el riesgo de sufrir algún incidente (por ejemplo tirarla... bueno,
tal vez este ejemplo sea un poco exagerado). Para evitar cualquier tipo de percance y para
evitarnos la incomodidad de cargar con una mano y escribir con la otra, llega para complacer
a todo tipo de usuario el  Connect-A-Desk, un soporte para cargar la computadora portátil.

Fácil de transportar, de utilizar, de ponerse y quitarse; además es un artículo en pro de la ecología

al estar fabricado con plástico 100% reciclado, ergonómicamente diseñado, ajustable a cualquier
estatura de persona, puede utilizarse con cualquier tamaño de laptop, notebook o tablet; no impor-
ta en dónde te encuentres o si estás caminando o sentado en la sala de espera.

Compuesto por una base y un par de soportes que van al hombro, este producto llega para
alivianar la carga de una herramienta de trabajo, que se ha vuelto popular en este tiempo:
la laptop.

Sony VAIO

Mouse Talk

SE2 Labs
ITC One
Para los amantes de la tecnología, ha lle-
gado la navaja suiza de los gadgets. Así
es, SE2 Labs ha hecho posible el sueño
Los diseñadores industriales e ingenieros muestran su talento a través electrónico de muchos y saca el ITC One,
de este diseño compacto de mouse óptico de doble funcionalidad, es que ensambla lo más solicitado en el
además un teléfono vía Internet. Como mouse, ofrece una resolución de mercado del consumidor de tecnología.
800 dpi y con un peso de 67 gramos,  además de ser un teléfono para
VOIP que puede ser utilizado con Skype; tiene un led indicador que se Con un procesador de sonido THX y 125
enciende, a manera de alerta, cuando entra una llamada. Con tan sólo watts, un controlador Netlinx todo puede
presionar un botón, el mouse se abre para ponerlo en modo teléfono. ejecutarse sin dificultades desde un con-
trol remoto. Bajo el concepto de Hi-Def,
Es ideal para laptop y ahorra espacio en la oficina, el hogar o mientras se está elaborado con DVR y una pantalla
está en los ahora restaurantes y cafeterías con servicio de WiFi. ¡Ah! y tam- touchscreen en el frente. ¿Complicado?, no,
bién está disponible en color blanco. incluye un Apple iPod y un Xbox 360 (con
sus respectivos puertos de control) que lo
hace estándar, si eso no es suficiente se
puede escoger opcionalmente un player
Blu-ray, una AppleTV o un Nintendo Wii.
60 AGO-OCT 2008 www.sg.com.mx
 INDEX

DIRECTORIO Anunciante Páginas Sitio

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

Avantare 43 www.avantare.com
CIAPEM 15 www.guerrero.gob.mx/ciapem2008
Compusoluciones 63 www.compusoluciones.com
Cutter 3F www.cutter.com.mx/summit2008
e-Quallity 13 www.e-quallity.net
Gartner 37 www.gartner.com/mx/econit
IDC 61 www.idc-eventos.com
IT Institute 57 www.it-institute.org
Manpower 47 www.manpowerprofessional.com.mx
Milestone Consulting 4F www.milestone.com.mx
Prodata 11 www.prodataconsult.com.mx
Safe Net 7 www.safenet-inc.com
SIE Center 9 ciisa.gda.itesm.mx

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

www.sg.com.mx AGO-OCT 2008 61

 // cOMUNIDADES

¿Cómo se Organiza la Comunidad?

Coordinación de Esfuerzos en Grupos de Desarrollo e Integración de Software Libre
Por Gunnar Wolf

Acercarse a comprender el funcionamiento y la organización de las
tareas dentro de las comunidades de desarrollo de software libre
es una tarea bastante complicada ante quien se acerca con curiosi-
dad, proveniente del mundo del software propietario, desarrollado
e integrado centralmente y dentro de compañías que operan como
“cajas negras”. Sin exponer sus procesos, sin ofrecer a los clientes
una ventana a cada uno de los momentos de su proceso de desarro-
llo. Comprender cómo funcionan las comunidades de Software Libre
es una gran oportunidad para entender las distintas metodologías
de ingeniería de procesos, en entornos donde todas las metodolo-
gías formales simplemente no tienen cómo ser aplicadas.
El ejemplo que aquí se muestra se centra en el trabajo que realizo en
el grupo de empaquetamiento de módulos de Perl (pkg-perl) para la
distribución Debian GNU/Linux.  en aparecer, ante la iniciativa de Joachim Breitner, fue pkg-perl. El eje
Retomando el concepto de que Perl  es un lenguaje de programación
muy popular, especialmente para las tareas de administración de
sistemas y de desarrollo de sitios Web, y uno de sus más importan-
tes recursos es el CPAN (Comprehensive Perl Archive Network), una
enorme biblioteca de módulos nacida en octubre de 1996, y que a fe-
brero del 2008 cuenta con más de 13,000 módulos independientes.
CPAN ofrece a sus usuarios, además, herramientas para el desarro-
llo y seguimiento colaborativo, un sistema de seguimiento de fallos
y un sistema de organización, búsqueda y consulta de la documen-
tación de dichos módulos.
El proyecto Debian, por su parte, es la distribución de software libre,
hoy por hoy, más grande del mundo, con más de 15,000 paquetes
fuente independientes. Su propósito es presentar una colección co-
herente, consistente y con un elevado nivel de control de calidad.
El reto del grupo pkg-perl es empaquetar (de una manera consisten-
te con las políticas de Debian) y dar seguimiento a los fallos que va-
yan apareciendo en dichos paquetes. Debian ofrece a sus usuarios
un sistema de seguimiento de fallos centralizado a través del cual
pueden comunicarse directamente con los “mantenedores” de cada
uno de los programas. Son ellos los responsables de determinar,
para cada fallo, si cae en el ámbito de la consistencia del sistema
Debian (y por tanto debe ser corregido directamente por ellos) o si
es relativo a la lógica de uno de los paquetes (en cuyo caso debe ser
corregido en coordinación con el autor de dicho programa, para que
la corrección “fluya” hacia las otras distribuciones que lo integran y,
en general, hacia todos sus usuarios).
Hasta hace unos cuatro años, la norma en Debian era que cada mante-
nedor fuera responsable exclusivo de los paquetes que le interesaran.
En 2003 nació el sistema Alioth, basado en GForge, y ofreciendo de
una manera centralizada las herramientas necesarias para un ver-
dadero desarrollo colaborativo, se comenzaron a configurar grupos
amplios de mantenimiento de infraestructura. Uno de los primeros
fundamental en torno al cual gira el trabajo del grupo es el depósito
Subversion, donde mantenemos sobre un esquema de manejo de ver-
siones todos nuestros paquetes, programas y documentos, así como
los cambios independientes que vamos realizando sobre de ellos.
Los módulos del CPAN ofrecen varias ventajas para su mantenimiento
masivo colaborativo. A diferencia de lo que ocurre en muchos lengua-
jes, casi la totalidad de los módulos están basados en una estruc-
tura de compilación ampliamente conocida (ExtUtils::MakeMaker o
Module::Build). Esto permitió la creación de dh-make-perl, un script
bastante genérico cuyo objetivo original era simplificar la creación de
paquetes Debian directamente a partir del CPAN para ser instalados
localmente por los administradores, pero que fue extendido por el
grupo pkg-perl para automatizar la creación de paquetes.
Si bien formalmente el grupo pkg-perl cuenta con 70 miembros, en
todo momento hay aproximadamente 15 miembros activos. Actual-
mente, el grupo es responsable por 660 paquetes en las siguientes
actividades:
• Responsable el dar seguimiento a los fallos reportados
• Mantenerlos al día (tanto respecto a nuevas versiones producidas
por sus autores como respecto a las políticas en Debian, que van
cambiando poco a poco reflejando la evolución del proyecto)

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

62 AGO-OCT 2008 www.sg.com.mx

 “Comprender cómo funcionan las
Comunidades de Software Libre es una gran
oportunidad para entender las distintas
metodologías de ingeniería de procesos”.

• Realizar operaciones transversales de control de calidad a través de todos los paquetes,

y demás

Para simplificar la coordinación de todas estas tareas, los integrantes del grupo (especialmen-
te Martín Ferrari, de Argentina, Gregor Hermann, de Austria, y Damyan Ivanov, de Bulgaria)
hemos creado un script que tiene las siguientes funciones:

• Comparar el estado de los módulos en CPAN Comparar los paquetes en el depósito

• Subversion
• Comparar los reportes en el sistema de seguimiento de Debian, y los paquetes publicados
en la distribución misma de Debian

Hoy en día, este script es nuestra principal herramienta, brindándonos un reporte de estado
condensado y adecuado específicamente a nuestro flujo de trabajo. Y tan útil resulta este
resumen que actualmente estamos adecuando este script para que lo utilicen también otros
grupos con un enfoque similar; probablemente  para cuando este artículo esté impreso, lo
están utilizando ya los grupos de empaquetamiento de Python y Java, habiendo varios más
en el horizonte.

Conclusión
El ejemplo que aquí se presenta es sólo uno de tantos, pero es ilustrativo. Bajo el mo-
delo del software libre, las barreras entre desarrollo e integración se desvanecen, y el
contacto directo entre usuario final y los desarrolladores deja de ser una rara ocurren-
cia, y se vuelve la norma, algo que damos por supuesto en todo momento de nuestros
desarrollos.

Referencias
[ debian.org ]
[ perl.com ]
[ cpan.org ]
[ rt.cpan.org ]
[ search.cpan.org ]
[ pkg-perl.alioth.debian.org ]
[ bugs.debian.org ]
[ alioth.debian.org ]
[ svn.debian.org/wsvn/pkg-perl ]
[ pkg-perl.alioth.debian.org/cgi-bin/qareport.cgi ]

www.sg.com.mx AGO-OCT 2008 51

 // BIBLIOTECA

Ajax on Rails
Scott Raymond
O’Reilly, 2007

01
Las nuevas tendencias del desarrollo para web nos invitan Es importante mencionar que el
al aprendizaje de herramientas de vanguardia, pero cuan- autor no olvidó hablar de pun-
do un par de estas se combinan para trabajar, entonces se tos importantes para el desa-
crea la mancuerna perfecta. Como ejemplo tenemos este libro. rrollo de una aplicación como
son las pruebas, detección de
El lector aprenderá a construir aplicaciones web dinámicas utilizan- errores, seguridad y tiempo
do dos de las herramientas más importantes de desarrollo actual: de ejecución. Dedicando por
Ajax y Ruby on Rails. A través de sus páginas, conocerá cómo combi- separado un espacio para
nar ambas tecnologías para construir rápidamente aplicaciones con cada uno de ellos, el autor
alto tiempo de procesamiento y escalabilidad. habla sobre los principios
de seguridad de las apli-
Los capítulos del libro no solamente incluyen una introducción a los caciones web, así como
conceptos de Ajax y Rails, además incluye la explicación y uso de las estrategias de estudio
Prototype, framework de JavaScript que permite el fácil desarrollo del “performance”.
de aplicaciones web dinámicas.
En la sección de tiempo de ejecución incluye temas como: optimi-
Para hacer una mejor mancuerna con Prototype, incluye un capítulo zación de sesiones, tiempo de respuesta en las peticiones a Rails,
dedicado a uno de los add-on’s de este framework: script.aculo.us, reducción en la comunicación entre JavaScript, CSS y Ajax y la utili-
en el que se enseña el uso de las características de la biblioteca que zación de Ajax para mostrar el progreso de una tarea del usuario.
corresponden a la plataforma Rails.

Inside Windows Communication

Foundation
Justin Smith
Microsoft Press, 2007

02
Para los interesados en WCF con conoci- A través de sus 10 capítulos
mientos previos en el mismo, llega este el lector puede apreciar el
libro para profundizar más en el tema. Con por qué y el cómo de WCF,
la finalidad de dejarle los mejores conceptos al lector, ya que el libro muestra el
el autor trata en la primera parte una introducción para balance entre la cobertura
enseñar el por qué del concepto además de mostrar las del modelo y los concep-
metas del mismo. tos que deben ser con-
siderados dentro de las
En la segunda parte del libro,  podemos encontrar con- aplicaciones de WCF.
ceptos más propios de Windows Communication Founda-
tion como los mensajes, los canales y los administrado- Este libro brinda al lector, un vistazo dentro de Windows
res de canales para terminar con una tercera parte que Communication Foundation para facilitar el diseño, construcción,
trata sobre la capa del ServiceModel. pruebas y mantenimiento de las aplicaciones.

64 AGO-OCT 2008 www.sg.com.mx

No. 21 www.sg.com.mx SG SOFTWARE GURU - CONOCIMIENTO EN PRÁCTICA Agosto-Octubre 2008