SOFTWARE GURU CONOCIMIENTO EN PRÁCTICA

Web Services y SOA

Casos de Uso
Usabilidad

EN SUS
MARCAS
México y su posición en la competencia
por la industria de Software

ProSoft
El programa a seguir
A Fondo

> Caso de Estudio

Eclipse 3.0
Ultrasist pg. 12
primera PyME mexicana SW-CMM4

Además: Noticias, Biblioteca, Gadgets, Fundamentos, Desarrollo Profesional

 DIRECTORIO
A› Edición Ejecutiva
Pedro Galván

Coordinación Editorial
Mara Ruvalcaba

Producción
Edgardo Domínguez

Arte y Diseño
GUGU Diseño
www.gugu.com.mx
EDITORIAL
Consejo Editorial
Para lograr un resultado de valor, se requiere de un proceso, y todo buen proceso debe ser capaz Francisco Camargo, Guillermo Rodríguez y
de responder cuatro preguntas: ¿Qué hay que hacer? ¿Quién lo debe hacer? ¿Cuándo se debe Raul Trejo, ITESM Campus Estado de
hacer? y ¿Cómo se debe hacer? Al fundar Software Guru, nos hemos planteado estas preguntas y México; Hanna Oktaba, UNAM-AMCIS;
hemos llegado a las siguientes respuestas: Luis Cuellar, Softtek.

¿Qué? Hacer de México una potencial mundial de la industria de software. Colaboradores

¿Quién? Todos los partícipes de la industria. Jorge Palacios, Francisco López Lira, Paulina
¿Cuándo? Ahora. Olivares, Rafael Bernal, Mauricio Durán,
¿Cómo? Esa es la información que buscaremos proveer en cada número de Software Guru. Fernando Gutiérrez, Roberto Silva, Dámaso
Canales, Sergio Cedillo, Ernesto Elizalde,
El propósito de esta publicación es compartir experiencias que fomenten el desarrollo de softwa- Ivette García, Ma. Julia Orozco, Claudia
re con calidad. SG es un medio para comunicar la experiencia, métodos y visión de todos aque- Alquicira, Ariel García, Omar Ruvalcaba.
llos que participan de manera activa en la industria de software.
Ventas y Relaciones Públicas
En este número nos hemos enfocado en dar a conocer la situación actual de la industria de soft- David González
ware nacional y qué es lo que se está haciendo para desarrollarla. Hemos incluido información
sobre estudios de capacidad, programas de gobierno y el caso de estudio de una PyME. El obje- Marketing
tivo de compartir esta información es buscar que todos aprovechemos y nos sumemos a estos Natalia Sánchez
esfuerzos. Solamente así lograremos el objetivo planteado de ser una potencia mundial de la
industria de software. Webmaster
Arturo Méndez
Software Guru no es una ni varias personas. Es una comunidad formada por todos los profesionistas
de esta industria. Los invitamos a que participen a través de los foros disponibles en Agradecimientos
www.softwareguru.com.mx o contactándonos directamente en editorial@softwareguru.com.mx René Bravo, Carlos Villaseñor, Hilda López,
Secretaría de Economía, AMCIS, AMITI, Luis
Bienvenidos, esto es Software Guru. Daniel Soto, Sergio Vega, Martha Kondo y
todos los que confiaron en Software Guru.

Contacto
info@softwareguru.com.mx
Tel: (55) 5239-5502

Software Guru es una publicación editada por Brainworx, S.A. de

C.V., Parque de la Malinche No. 6, Col. El Parque, Naucalpan,
Estado de México. Ejemplar de cortesía. Derechos reservados por
Brainworx, S.A. de C.V. Certificado de licitud de Derechos de Autor
en trámite. Certificado de licitud de título e ISSN en trámite.
Certificado de licitud de contenido en trámite. Prohibida la repro-
ducción total o parcial sin previa autorización escrita de los edito-
res. Se terminó de imprimir en el mes de septiembre del 2004 en
Supergráfica S.A de C.V. Todos los artículos son responsabilidad
absoluta de sus propios autores y no necesariamente reflejan el
punto de vista de esta editorial.
 CONTENIDO

EN PORTADA
22 Industria de Software:
México vs.
Resto del Mundo
La industria de software mundial se
encuentra en un momento clave. En
este artículo analizamos diferentes
factores para que México pueda
competir con los líderes mundiales.
16
ProSoft
PRODUCTOS Programa para el Desarrollo de la
Industria del Software.
Lo que viene 10
Plataformas de desarrollo de software para el 2005.

A Fondo 12
Eclipse 3.0.

Herramientas 14
Herramientas para pruebas automatizadas.

PRÁCTICAS
20
Arquitectura 34
Entendiendo Web Services y SOA Entrevista
Los web services y las arquitecturas orientadas a servicios están revolucionando Jesús Orta, Director de Economía
la manera como construimos sistemas de software. Mauricio Durán y Fernando Digital en la Secretaría de Economía.
Gutiérrez explican los conceptos básicos de esta tecnología y sus principales
beneficios.

Requerimientos 38
Casos de Uso
Los casos de uso son uno de los elementos más importantes y menos entendi-
dos de UML. En este artículo, Roberto Silva revisa algunos errores comunes en
su aplicación y sugiere cómo evitarlos.

40
Usabilidad
Cuestión de Percepción, Efectos y Frustración 30
La usabilidad se encarga de estudiar la relación entre las herramientas y sus
usuarios. Dámaso Canales aborda los diferentes factores en los cuales se basa
el Diseño Centrado en el Usuario (DCU). 38 Caso de Estudio
Ultrasist, primera PyME
100% mexicana SW-CMM 4.
COLUMNAS
Tejiendo Nuestra Red por Hanna Oktaba 6
EN CADA NÚMERO
Moviendo la Industria por Rafael Bernal 8 Noticias y Eventos 4
Gadgets 43
Cátedra y Más por Guillermo Rodríguez 42 Biblioteca 44
Fundamentos 46
Desarrollo profesional 48
 EVENTOS
INFO

INFO
5-6 Octubre 2004
NOTICIAS Congreso AMITI 2004
Centro Banamex
Cd. de México
Info: www.amiti.org.mx
Tel: +52 (55) 5207 0212
MoProSoft Email: karla@amiti.org.mx
es aceptado para ser norma mexicana
MoProSoft y su método de evaluación EvalProSoft, 27-29 Octubre 2004
MoProSoft propuesta de Secretaría de Economía para la PyME de TI Américas & Prosoft
desarrollo de software, han sido entregados en junio Grand Hotel Tijuana – Institute of the Americas
2004 al NYCE, organismo responsable de la normali- Tijuana, B.C.– San Diego, CA.
zación y certificación en México. El objetivo de esta Info: www.tiamericas.com
norma es proveer acceso a las prácticas de ingeniería Tel: +52 (664) 622-9221
de software de clase mundial y contar con un método Email: tiamericas@canieti.org
de evaluación propio. La propuesta fue incluida en el
Programa Nacional de Normalización, bajo el nombre: 1-3 Noviembre 2004
“Tecnología de la Información-Software-Modelo de XpoLinux Monterrey 2004
procesos y método de evaluación para desarrollo y Cintermex
mantenimiento de software: Monterrey, N.L.
Parte 01: Definición de conceptos y productos. Info: www.expolinux.org
Parte 02: Requisitos de procesos (MoProSoft). Tel: +52 (81) 8388 8805
Parte 03: Guía de implantación de procesos. Email: dgranados@expolinux.org
Parte 04: Método de evaluación (EvalProSoft).”
Se espera que NYCE haga los trámites correspondien- 4 y 18 Noviembre 2004
tes para que la norma se publique en diciembre del Seminario Optimización de TI
2004. MoProSoft y EvalProSoft fueron desarrollados Itera Cd. de México – Itera Monterrey
por los expertos de la AMCIS (Asociación Mexicana 4 Noviembre, Cd. de México
para la Calidad en Ingeniería de Software), bajo los 18 Noviembre, Monterrey N.L.
convenios entre la SE y la UNAM. Para obtener mayor Info: www.itera.com.mx
información ingresa a www.amcis.org.mx, o bien, al Tel: México +52 (55) 5281 7660
sitio oficial de la industria de software Tel: Monterrey +52 (81) 8368 2409
www.software.net.mx Email: info@itera.com.mx

8-10 Noviembre 2004

SEPG LA 2004
Solaris Hotel Hilton
a código abierto Guadalajara, México
Sun Microsystems confirmó su intención para que su Info: www.esi.es/SEPGLA
sistema operativo Solaris esté disponible como códi- Tel: +52 (33) 3818-6777
go abierto a finales de este año. Sun indicó que se Email: sepgla@esi.es
abrirá todo el sistema operativo, y no solamente el
kernel, como algunos esperaban. 9 Noviembre 2004
BEA Dev2Dev Days 2004
Hotel Marquis Reforma
Cd. de México
HP Info: mx.bea.com
apoyando a los desarrolladores Tel: +52 (55) 5202 6070
Como parte de su estrategia para atender al mercado Registro:
de la PyME, denominada Smart Office, HP lanzó el www.dev2dev.com/dev2devdays/mexico_city.jsp
programa Click on HP, dirigido a las empresas desa-
rrolladoras de software y consultoría. Con el objetivo 15-19 Noviembre 2004
de complementar la oferta de las desarrolladoras de STAR WEST 2004
software, el programa Click on HP ofrece la asesoría y Software Testing, Analysis and Review
capacitación necesarias, infraestructura, así como The Disneyland Hotel
incentivos de mercadotecnia y esquemas crediticios. Anaheim, CA
Todas las empresas desarrolladoras de software pue- Info: www.sqe.com/starwest
den participar en el programa, sólo requieren regis- Tel: +1 (904) 278 0524
trarse en: www.hp.com.mx/clickonhp Email: sqeinfo@sqe.com

04 > OCT-DIC 2004 > www.softwareguru.com.mx

COLUMNA Tejiendo Nuestra Red
10 Minutos de Locura
Factores y Tendencias en Investigación de Procesos
La Dra. Hanna Oktaba
es profesora en la Facultad
de Ciencias de la UNAM. Es
fundadora y vicepresidenta
de la Asociación Mexicana
para la Calidad en la
Ingeniería de Software.
Actualmente dirige el pro-
yecto para la creación de
una norma mexicana para
la industria de software.
Miembros del International
Process Research Consortium
06 > OCT-DIC 2004 > www.softwareguru.com.mx
E n esta columna quiero compartir con ustedes mis
vivencias y reflexiones relacionadas con los proyectos
y eventos en los que participo, así como comentarios
sobre lo que sucede referente a la Ingeniería de Software,
en México y en el mundo.
El primer relato lo dedicaré a la creación del International
Process Research Consortium (IPRC) cuyo objetivo es defi-
nir el mapa y la ruta (roadmap) de la investigación en el
área de procesos de software para los próximos 5-10 años.
Al inicio de 2004 me llamó Caroline Greatinger del Software
Engineering Institute (SEI) invitándome a participar en el
IPRC. La “culpable” de que me invitaran fue Suz García,
también miembro del SEI, quien en diciembre pasado par-
ticipó en el Seminario de Calidad de Software de la AMCIS
y asistió a mi ponencia sobre el proyecto de MoProSoft.
Gloria Quintanilla le hizo la traducción “en línea” al oído y
le obsequiamos una copia, con dedicatoria del documento
de MoProSoft v 1.1 en español. Con este antecedente, no
me quedó de otra sino aceptar la invitación. Por un lado,
porque fue un reconocimiento al trabajo que hicimos, y por
el otro, porque me comentaron que iba a ser la única repre-
sentante de Latinoamérica en el consorcio.
El trabajo de IPRC se llevará a cabo a través de seis talle-
res, entre agosto 2004 y agosto 2006, de los cuales los
dos primeros se dedicarán a generar el máximo número de
ideas para las líneas de investigación y su justificación
correspondiente. Los dos posteriores se dedicarán a la
revisión de las propuestas, su clasificación y la selección
de las que se consideren más relevantes. Finalmente, a
través de los dos últimos talleres, se generará el docu-
mento del mapa y ruta para la investigación en procesos
de software para los próximos 10 años.
El 12 y 13 de agosto de 2004 tuvo lugar el primer taller en
una playa cercana a Los Angeles. Los principales partici-
pantes fueron los 14 miembros académicos del consorcio
(dos de Estados Unidos, dos australianos y otros ocho
provenientes de Canadá, España, Italia, Inglaterra,
Alemania, Suecia, Irlanda, Corea del Sur y México).
Además, asistieron pagando una módica cuota de
$150.000 USD, siete personas representando a grandes
consorcios y seis personas por parte del SEI, quienes fue-
ron responsables por el desarrollo del evento. Los detalles
del taller se pueden consultar en www.sei.cmu.edu/iprc
Durante el taller nos pidieron preparar una presentación
de diez minutos llamada Ten Minute Madness on Trends
and Topics. Esta sesión fue muy interesante porque pudi-
mos conocer uno por uno a los participantes y escuchar de
su boca cuáles son sus preocupaciones e ideas alrededor
del tema que nos reunió. Les puedo contar brevemente
cuáles fueron los puntos centrales de mi presentación.
Desde el principio mencioné que el contexto de mi propues-
ta es la realidad mexicana, que probablemente se puede
generalizar a otros países en desarrollo. La dividí en tres pun-
tos, tratando de dar respuesta a las siguientes preguntas:
1. ¿Cuáles son los factores y
las tendencias para los próximos 5-10 años?
En este punto mencioné la posibilidad de la creciente
demanda de sistemas de software en tres sectores: indus-
tria y servicios, gobierno y educación. En la industria y ser-
vicios para mejorar la competitividad de las micro y
pequeñas empresas; en el gobierno para ofrecer los servi-
cios eficientes y transparentes a los ciudadanos; y, en la
educación, para proveer del contenido estandarizado y de
mejor calidad a los jóvenes en todos los rincones del país.
2. ¿Cuáles son los obstáculos
para atender estas tendencias?
Mencioné dos problemas, que yo considero cruciales: el
tamaño de la industria y su nivel de madurez, así como la
baja cultura general de Tecnología de Información (TI).
Sabemos que tenemos pocas empresas de desarrollo de
software en México, que en su mayoría son micro y peque-
ñas (menos de 20 personas), y que el uso de las prácticas
recomendadas de procesos de software es muy escaso por
falta de recursos e insuficiencia en la educación. Por otro
lado, el acceso a la TI y su uso todavía no están generali-
zados y, por lo tanto, no se reconoce su valor estratégico
para el desarrollo y la competitividad del país.
3. ¿Cómo puede responder la investigación
en procesos de software a estos problemas?
En este punto mencioné varias ideas: la necesidad de
tener procesos estandarizados y, tal vez, especializados,
listos para usarse (prêt-à-porter software processes); la
necesidad de integrar las actividades de verificación, vali-
dación, pruebas, mediciones, y control de productos con
las prácticas de requerimientos, análisis, diseño y cons-
trucción -tal como lo propusimos en MoProSoft-, la defini-
ción de procesos dirigida a humanos (role-driven software
processes); y, finalmente, la revisión de los conceptos de
madurez y capacidad de procesos, que a mi juicio no son
lo suficientemente claros.
En la próxima ocasión les platicaré sobre los temas de inte-
rés general que surgieron del primer taller. Para que “no se
pierdan el siguiente capítulo”, les adelanto que CMMI no es
el final del camino y que en el SEI también están preocupa-
dos por tener procesos para la pequeña y mediana indus-
tria, cuyo tamaño, para ellos, es hasta 100 personas.
Hanna Oktaba
COLUMNA Moviendo la Industria

Ya No Discutamos…

Actuemos
panic control

espués de varios años de reclamar en cortito sobre
D la incapacidad de México para darse cuenta de sus
oportunidades y crear nichos propios de competitivi-
dad, me di cuenta de que no basta con refunfuñar todo
el día sobre cómo deberían hacerse las cosas, hay que
hacerlas. Puedo decir que me volví un activista pro
industria de software, y afortunadamente hubo sufi-
ciente gente de gobierno, academia e iniciativa privada
que colaboró para que, siete años después, tuviéramos
un programa de fomento a la industria, el ProSoft de la
Secretaría de Economía (SE).
En esta ocasión quisiera llamar la atención de ustedes
hacia el porqué tener este programa y tratar de ser un
país de software. México necesita desarrollar áreas de
oportunidad donde pueda crear industria propia y
lograr de vez en cuando un “milagrito económico”
como los de otros países que tanto admiramos. El que
este primer nicho haya resultado ser el de desarrollo de
software se debe a que la industria ha logrado conven-
cer al país sobre sus bondades: el software beneficia
horizontalmente a toda la economía; crea empleos
masivos, pero de calidad; tiene gran potencial exporta-
dor; tiene una demanda creciente y prácticamente infi-
nita; y podemos hacerlo nosotros sin requerir grandes
inversiones de capital.
Para todos los que estamos en esta industria, es
importante conocer el ProSoft y otros estudios y
documentos de él derivados. Los más importantes
los pueden encontrar en www.software.net.mx sitio
patrocinado por la SE y la AMITI. Como resumen, la
meta más importante de ProSoft es lograr un merca-
do de desarrollo de software de 5,000 mdd en 10
años. Para lograr esta meta, estamos viendo pro-
puestas de políticas de crecimiento, con metas par-
ciales y métricas que nos permitan ir fondeando y
modificando los programas de ProSoft según las
necesidades de la industria.
Pero este programa no pasará de ser sólo buenos deseos sin la
participación activa de todos los que estamos en la industria de
desarrollo de software. No podemos mejorar empresas que ni
siquiera sabemos que existen. No podemos crear nuevas
empresas si nosotros mismos no nos volvemos empresarios.
¿Cuántos de ustedes conocen el fenómeno de integración de
empresas pequeñas de desarrollo que está sucediendo por
todo México? ¿Las razones por las que ocurre esto? ¿Las ayu-
das para promover esta integración? Para lograr ser un país de
software, hay que querer serlo. La AMITI es hoy la asociación
más representativa de la industria de software, pero sólo alcan-
za a una pequeña parte de las empresas; cada vez que quere-
mos tener estadísticas para elaborar programas, nadie se toma
la molestia de contestarlas. Sabemos bien a dónde queremos
llegar, pero no sabemos de dónde estamos partiendo.
Yo quiero conminarlos a que nos dejemos ver. A que nos plati-
quemos cuántos somos y qué buscamos. A que salgan los
empresarios comprometidos a crecer. Ya existen iniciativas en
varios estados para promover la industria, ayudados por
ProSoft, y en el DF estamos tratando de cuantificar la demanda
para definir cómo manejaremos el programa. Necesitamos que
nos contacten. Todo el que tenga un concepto de empresa de
desarrollo de software puede enviarme un correo a rafael.ber-
nal@heuristica.com.mx, contactar a la AMITI directamente o
contactar a la Secretaría de Desarrollo Económico de su estado
para averiguar cómo aprovechar este programa. Si hoy no res-
pondemos como industria, no nos quejemos mañana cuando no
la tengamos.
Quiero aprovechar lo que me queda de espacio para desear la
mejor de las suertes a Mara y Pedro. Publicar una revista
como ésta es ayudar activamente a que se una nuestra comu-
nidad y nos conozcamos mejor. Es una tarea de héroes, cono-
ciendo la tasa de mortandad de las publicaciones. De
nosotros dependerá si sobrevive, y de nuestra retroalimenta-
ción dependerá el que nos enriquezca como comunidad.
Rafael Bernal Arce

Rafael Bernal es ingeniero químico de carrera, y desarrollador de

software de profesión y alma. Rafael fue el primer CIO mexicano
en Procter & Gamble de México. En 1982 fundó Heurística, una
compañía de desarrollo de software a la medida, que fue la prime-
ra en implantar SAP en México. Actualmente Heurística se dedica
a dar consultoría para el desarrollo de la industria de software en
México y promover el outsourcing de Estados Unidos hacia el
país. Rafael Bernal es miembro activo de la AMITI, donde ha sido
Vicepresidente de Software dos veces, y Comisionado para el
Desarrollo de Software desde 2000.

08 > OCT-DIC 2004 > www.softwareguru.com.mx

 PRODUCTOS
LO QUE VIENE
LO QUE VIENE
Nuevas Capacidades
en Plataforma IBM-Rational
IBM anunció las capacidades que incluirá la nueva versión de su
plataforma de productos para desarrollo de software, que estará
disponible a finales de este año. Durante Rational Software
Development User Conference 2004, Mike Devlin, Director General
de IBM Rational, explicó y demostró las nuevas capacidades. “Al
utilizar la plataforma de desarrollo de software de IBM para alinear
en forma transparente al negocio con los equipos de desarrollo y
operación, nuestros clientes pueden optimizar el valor del negocio,
acelerar el desarrollo de software e integrarse mejor con las plata-
formas de ejecución y middleware IBM”, dijo Devlin.
INTEGRACIÓN PROFUNDA Y MÁS RICA
La nueva plataforma está basada sobre la tecnología Eclipse, dise-
ñada para proveer un ambiente común donde convivan diversos
artefactos como requerimientos, modelos, código, casos de prueba
y defectos. Eclipse permite integrar productos de diferentes vende-
dores y provee interfaces basadas en roles, permitiendo al equipo
trabajar en un ambiente adaptado a sus necesidades individuales.
DISEÑO Y CONSTRUCCIÓN SIMPLIFICADA
Las nuevas soluciones para diseño y construcción simplifican y ace-
leran el desarrollo de aplicaciones. Algunos de los nuevos elemen-
tos soportados son:
• Java Server Faces (JSF)
• Service Data Objects (SDO)
• Modelado UML 2.0
• Despliegue a Websphere en tiempo real
• Refactorización visual
• Desarrollo de aplicaciones en C/C++
NUEVAS SOLUCIONES DE CALIDAD PARA EL SOFTWARE
Basadas en Hyades —un ambiente integrado para pruebas, rastreo y
monitoreo—, las nuevas soluciones para calidad de software permiten
generar productos integrados de análisis, diseño, pruebas y monitoreo
para analistas, arquitectos, desarrolladores, ing. de pruebas y gerentes.
Los desarrolladores y arquitectos pueden beneficiarse de las nue-
vas capacidades para generación de componentes de prueba, aná-
lisis arquitectónico y análisis en tiempo de ejecución. Los
ingenieros de pruebas también se benefician de las nuevas capaci-
dades para pruebas de carga, así como la integración con Tivoli para
analizar el desempeño de aplicaciones instaladas.
DESARROLLO DISTRIBUIDO MEJORADO
El soporte a equipos de trabajo distribuidos —personas en diferentes
localidades colaborando en un mismo proyecto— mejora sustancial-
mente con el nuevo soporte a clientes de red de área ancha (WAN),
en conjunto con las capacidades extendidas para administración de
versiones y configuración del software. Esto permite capturar, contro-
lar y administrar de forma segura y eficiente los cambios al software
provenientes de diferentes localidades.
Para mayor información:
www.ibm.com/software/sdp
10 > OCT-DIC 2004 > www.softwareguru.com.mx
Microsoft
Visual Studio Team System
Microsoft comenzará un nuevo capítulo en su estrategia para herra-
mientas de desarrollo de software con el próximo lanzamiento de
Visual Studio 2005 Team System, también conocido por el nombre
clave “Burton”. Con este lanzamiento, la empresa norteamericana
entrará en competencia directa con la división Rational de IBM, así
como con Borland Software.
Burton proveerá herramientas para soportar al equipo completo de
desarrollo de software. Estas son algunas de las capacidades dis-
ponibles para los diferentes roles:
• Arquitectos.- La edición Team Architect contiene herramientas
integradas para modelar sistemas distribuidos basados en arqui-
tecturas orientadas a servicios.
• Desarrolladores.- La edición Team Developer habilita a los pro-
gramadores con herramientas para análisis estático, análisis de eje-
cución, análisis de cobertura, y pruebas unitarias.
• Ing. de Pruebas.- La edición para pruebas incluye las capacidades
para desarrolladores y agrega herramientas para ejecutar y admi-
nistrar una amplia gama de pruebas, incluyendo pruebas funciona-
les, unitarias, de carga y de velocidad.
• Administradores de Proyecto.- La edición Team Foundation pro-
vee diversas herramientas para administración basadas en aplica-
ciones conocidas como Microsoft Excel, Microsoft Project y
Windows SharePoint, que se integran de manera natural con el
resto de los productos de esta suite. También existe la capacidad
para generar un sitio web del proyecto que incluye una consola o
“dashboard” para que los diferentes partícipes puedan monitorear
el estatus en cualquier momento y generar reportes con métricas
generadas durante la ejecución de las tareas diarias del equipo.
Adicionalmente, todos los productos incluyen capacidades para tra-
bajo en equipo, como control de versiones avanzado y un sistema
para administrar ordenes de trabajo. Aunque el gran atractivo no
son las herramientas individuales, sino la estrecha integración
entre éstas.
Aún así, las herramientas por sí solas no son suficientes para desa-
rrollar sistemas empresariales de alta calidad y en un tiempo razo-
nable, también se requiere un proceso de desarrollo adecuado. Es
por esto que Burton incorpora un proceso configurable para desa-
rrollo de software basado en mejores prácticas.
Se espera que la versión de producción del Visual Studio 2005 Team
System esté disponible en la primavera del año próximo. Sin embar-
go, los suscriptores de Microsoft Developer Network (MSDN) pue-
den obtener el Visual Studio 2005 Beta 1, que incluye una versión
previa de Burton.
Para mayor información:
lab.msdn.microsoft.com/vs2005/teamsystem/
PRODUCTOS A FONDO

Eclipse 3.0
Mucho más que un IDE

Eclipse es una plataforma para aplicaciones cuya popularidad ha crecido enormemen-

te en los últimos años. Se originó como un proyecto de IBM para desarrollar una pla-
taforma universal de integración de herramientas. Posteriormente IBM liberó la
tecnología y se convirtió en un proyecto de código abierto administrado por la
Fundación Eclipse. Recientemente fue presentada la versión 3.0 de Eclipse, la cual
incluye muchas capacidades nuevas y seguramente mantendrá en ascenso la popula-
ridad de este producto.

UN PEQUEÑO REPASO MÁS CAPACIDADES

Antes de explorar las nuevas características, vale la pena revisar la estructura base de
Eclipse. La Figura 1 muestra una vista simplificada de los principales elementos.
PARA DESARROLLADORES
La popularidad de Eclipse se generó principalmente por
Fig. 1 Plug-ins JDT PDE Otras herramientas
(CDT, UML2, etc)
ser un IDE para Java disponible de manera gratuita. De
hecho, la mayoría de sus usuarios actuales lo ven sola-
Otros componentes mente como un IDE para Java. Aunque en la versión 3.0 se
(Búsqueda, Ayuda, etc) busca demostrar que Eclipse es mucho más que un IDE, no
Componentes Workbench se puede descartar que éste es el principal uso que se le
Estándar (UI) da. Es por esto que las herramientas para desarrollo en
Plataforma Workspace Java se continúan mejorando. Una de las características
JFace
Eclipse (recursos) más atractivas es la capacidad de refactorización. Esto es
que, al modificar un elemento como una clase o un méto-
SWT do, todas las referencias que haya desde otros elementos
hacia éste, sean actualizadas automáticamente de acuer-
Ambiente de Ejecución do a los cambios realizados. Esta no es una capacidad
nueva, pero anteriormente sólo se actualizaban archivos
El ambiente de ejecución (runtime) es la plataforma base de código Java. Ahora se ha ampliado para incluir otros
para cargar y administrar componentes. elementos, como JSPs o archivos XML. Otras característi-
cas importantes son el soporte mejorado para Ant, forma-
El Standard Widget Toolkit (SWT) y JFace proveen librerías teo avanzado de código fuente, búsqueda y reemplazo
base para interfaz gráfica. utilizando expresiones regulares, y nuevas opciones para
generación de código.
El Workbench es el ambiente de trabajo compuesto por
ventanas, menús, barras de herramientas y editores.
La principal diferencia de
El Workspace se encarga de administrar los recursos, Eclipse respecto a otros IDEs
especialmente el acceso a los archivos.
como NetBeans o Visual Studio,
Por último, existen otros componentes de soporte, como es la diversidad de lenguajes
la ayuda y la búsqueda, que proveen capacidades que
pueden ser utilizadas por cualquier herramienta o plug-in
que soporta.
que se ejecuta sobre Eclipse.
Aunque Eclipse está programado en Java, y el JDT es uno
Todos estos elementos en su conjunto son lo que se cono- de sus proyectos más populares, también se ha preocupa-
ce como la Plataforma Eclipse. Sobre esta plataforma se do por ser una opción atractiva para otros lenguajes.
puede agregar una variedad de herramientas. Por ejemplo, Desde la versión 2.0 se hizo una reestructuración de la
el JDT provee un IDE para Java. El Plug-in Development plataforma para facilitar el soporte de otros lenguajes de
Environment (PDE) es un IDE especializado para desarro- programación, y se crearon subproyectos para IDEs de
llar plug-ins de Eclipse. Otras herramientas disponibles C++, Perl y Cobol, entre otros. Hoy en día, uno de los prin-
incluyen plug-ins para desarrollo en C/C++, modelado en cipales diferenciadores de Eclipse respecto a otros IDEs
UML, control de versiones, administración de servidores y como NetBeans o Visual Studio, es la diversidad de len-
muchas otras tareas. guajes que soporta.

12 > OCT-DIC 2004 > www.softwareguru.com.mx

 SG
Fig. 2
Eclipse 3.0
Las opciones para formateo The Eclipse Foundation
de código fuente se pueden www.eclipse.org
importar y exportar para Calificación:
que todo el equipo utilice
los mismos estándares. 4 de 5

Precio y Disponibilidad
Código abierto disponible bajo licen-
cia CPL. El Eclipse SDK, que incluye
binarios, documentación y código
fuente se puede obtener en
www.eclipse.org/
downloads/index.php

Requerimientos
de Sistema*
JRE o JDK 1.4.1 o superior
256 MB de RAM mínimo, 512 MB
recomendados.
PLATAFORMA PARA APLICACIONES Procesador Pentium III o superior,
Para la versión 3.0 se reestructuró la plataforma Eclipse una vez más; sin embargo, en esta ocasión la meta dependiendo de la plataforma.
fue ampliar su alcance de una plataforma para herramientas, a una plataforma para aplicaciones. Con esto *La documentación de Eclipse no indica requeri-
mientos mínimos de sistema más allá de la versión
nos referimos a que Eclipse sea el ambiente dentro del cual se ejecuten aplicaciones de propósito gene- de JRE. Los requerimientos de memoria y procesa-
ral. Para lograrlo, se agrupó la funcionalidad específica para IDEs en plug-ins opcionales, limpiando el dor son los recomendados por Software Guru.
Workbench y dejándolo como una interfaz de usuario genérica. De esta forma, las aplicaciones que no son
IDEs pueden utilizar una versión más simple y compacta de Eclipse, conocida como el Rich Client Platform Veredicto
(RCP). Aunque el RCP es mucho más ligero, también se puede beneficiar del sinfín de capacidades de La nueva versión de Eclipse es un
Eclipse, así como de plug-ins opcionales. gran avance. Tal vez para quienes lo
usan como IDE de programación no
Diversos proveedores de aplicaciones ya han expresado su interés en el RCP. Como era de esperarse, uno haya nada realmente novedoso, pero
de los principales entusiastas es IBM, cuya nueva suite de herramientas de productividad llamada Lotus las mejoras introducidas pueden
Workplace está construida sobre el RCP. mejorar bastante su productividad. Y
para quienes buscan una plataforma
RCP tiene un gran potencial para convertirse en la plataforma estándar para clientes Java o aplicaciones de sobre la cual montar sus aplicacio-
escritorio. El RCP cae en un lugar intermedio entre lo que es el ambiente de ejecución de java (JRE) y un nes, el RCP es una opción que bien
sistema operativo. El valor del RCP es que provee un gran conjunto de funcionalidad para interfaces gráfi- vale la pena considerar.
cas que no incluye el JRE y para la cual no hay ninguna otra solución multiplataforma con un amplio grado
de adopción. RCP deberá madurar bastante para cumplir su cometido, ya que tiene en frente un trecho Pros:
largo y lleno de obstáculos. 1. Disponibilidad gratuita
por ser código abierto.
> La vista de Javadoc permite 2. Gran extensibilidad,
visualizar la documentación el cielo es el límite.
al mismo tiempo que el 3. Al ser construido 100% en Java,
código fuente. funciona en una amplia gama de
sistemas operativos, entre ellos
Windows, Linux, Solaris y Mac OS X.

Contras:
1. Al igual que la mayoría de los
productos de código abierto, el
soporte se reduce a foros y
INTERFAZ DE USUARIO CON MEJOR RESPUESTA listas de correo.
Una de las prioridades para esta versión fue mejorar la respuesta de la interfaz de usuario. En versiones 2. Su complejidad lo hace difícil de
anteriores, era muy común tener que esperar a que el sistema terminara de procesar las peticiones para aprender y acostumbrarse. Aunque
continuar haciendo algo. Esto afecta la productividad de los usuarios, y es por eso que para esta versión mejoró bastante para la versión
muchas operaciones se ejecutan en segundo plano. Esto permite que un programador escriba código y éste 3.0, la usabilidad sigue siendo uno
se compile automáticamente sin tener que esperar. Lo mismo sucede con otras operaciones continuas como de los puntos débiles.
la sincronización con un repositorio de versiones. 3. Por el momento sólo está disponi-
ble en inglés. El paquete
> El editor resalta los cambios para lenguaje español estará
que realizados entre la versión disponible próximamente.
anterior y la actual.

www.softwareguru.com.mx > OCT-DIC 2004 > 13

PRODUCTOS HERRAMIENTAS

Mitos y Realidades sobre la

AUTOMATIZACIÓN DE PRUEBAS
por Sergio Cedillo

eis años de trabajar en proyectos de pruebas con empresas de diferentes tama-
S ños, estilos y tipos, me han llevado a escuchar comentarios como los siguientes:
“Ahora que ya compramos herramientas de pruebas automatizadas
podremos bajar costos al reducir el número de probadores.”
“Ya con estas herramientas vamos a ser mejores probadores.”
“Ahora podremos automatizar 100% del esfuerzo de pruebas.”
“Vamos a reducir los tiempos dedicados a las pruebas.”
entenderse de esto que las herramientas no sirven; al con-
trario, sirven y son bastante útiles, pero no como sustituto
del proceso de pruebas, que implica principalmente una
labor intelectual, analítica, de razonamiento, deducción,
inducción, conclusión y priorización que necesariamente -a
menos que el futuro se encargue de desmentirme- tendrán
que ser hechas o, al menos, conducidas por la mente huma-
na. Las herramientas pueden ser muy útiles en las tareas
repetitivas y tediosas, que involucran procesamiento de
combinaciones en donde el humano siempre le ha cedido su
lugar a las máquinas, pero no más allá.

“Ahora la vida en pruebas será más fácil.”
“Oye, con tus herramientas maravillosas necesito que le hagas la prueba
al sistema en dos semanas.”
“Nosotros ya utilizamos herramientas de pruebas en el pasado y no nos
sirvieron, seguimos con problemas en producción.”
Tampoco se debería buscar automatizar 100% de los
casos de pruebas, sino más bien hacerlo donde resulte
más efectivo, y para ello hay una serie de técnicas que
merecen un artículo completo. Lo importante es entender
que al aplicarlas efectivamente podremos reducir tiempos
conforme sea necesario reejecutar pruebas, habilitando al
equipo a extender la cobertura de la prueba.

He escuchado muchos más comentarios, aunque la mayoría son similares, por eso
es importante entender realmente qué podemos esperar y qué beneficios trae real-
mente la automatización de pruebas.
Sergio Cedillo se desempeña
como Ingeniero de Procesos
de Software en Itera, empresa
dedicada a proveer productos y
servicios para ingeniería de
software. Sergio tiene amplia
experiencia en la disciplina de
pruebas de software, ha
impartido cursos y participado
en proyectos para clientes como
PEMEX, Banco de México,
Bursatec y Bancomer, entre
otros. Próximamente se unirá al
equipo de IBM como IT
Specialist en la línea de
productos Rational.
POSIBILIDADES REALES
Antes que nada, explico en breve la automatización de
pruebas. Significa hacer la prueba manualmente una vez,
registrarla en un script tipo macro de excel con lenguaje
programático, y poder ejecutarla múltiples veces, tantas
como sea necesario para verificar que un cambio hecho a
la aplicación, ya sea por aumentar o cambiar funcionali-
dad, como por supuesto, por corregir un defecto, no haya
afectado las funciones previamente probadas y certifica-
das. Si se alcanza a ver, la automatización es útil durante
un proyecto, pero resulta una gran ventaja o prácticamen-
te indispensable para un sistema en producción.
Lo primero que debo decir de la automatización de prue-
bas con herramientas es que no sustituye al proceso de
Planeación, Análisis, Diseño e Implantación de las prue-
bas, sino que lo complementa. Las herramientas tampoco
sustituyen a las personas, son sólo herramientas, y deben
estar en su lugar, en una caja de herramientas. Nunca he
escuchado a un arquitecto decir: “ahora sí, con estas
palas y picos que compramos esperamos reducir el núme-
ro de albañiles en la obra”, o a un líder de proyecto comen-
tar: “con estos debuggers y analizadores de código vamos
a poder tener menos programadores”.
Tal vez en diez años me tenga que retractar, pero por ahora
con seguridad puedo decir que no ha habido sustituto del
análisis humano para la identificación y aplicación de técni-
cas de verificación de los productos de software. No debería
Es cierto que las herramientas pueden hacer mejores tes-
ters, pero porque les permita ser más efectivos, no porque
el hecho de tenerlas y usarlas lo garantice en sí mismo.
Esto depende de la manera como se apliquen. Se pueden
usar y aún así fracasar en una prueba, justo como se pue-
den usar los mejores compiladores o ambientes de desa-
rrollo y construir aplicaciones desastrosas.
Si hablamos de costos y beneficios, el costo está en crear la
prueba manualmente la primera vez, en hacer los cambios
programáticos necesarios a los scripts y en darles manteni-
miento cada vez que se requiera por modificaciones a la
aplicación. El beneficio está en la ganancia en tiempo de
ejecutar una prueba de regresión mucho más rápido cuan-
do ocurren cambios que hay que liberar en breve, y en las
posibilidades de ejecutar múltiples combinatorias de accio-
nes de usuario y de datos de entrada a la prueba.
Como corolario final, diré que con el uso efectivo de las
herramientas de automatización de pruebas se pueden
hacer más y mejores pruebas al sistema, y no tanto redu-
cir los tiempos completos de la prueba. Actualmente exis-
te una gran oferta de herramientas de automatización de
pruebas. Entre las compañías más importantes están:
Mercury Interactive
www.mercury.com/us/
IBM Rational Software
www-306.ibm.com/software/rational
Compuware
www.compuware.com
Segue
www.segue.com

14 > OCT-DIC 2004 > www.softwareguru.com.mx

Seguramente la industria del software es de
gran importancia para usted. Sin embargo, es
bueno saber que el Gobierno Federal también
la considera estratégica y tiene en marcha un
programa para apoyarla.

ANTECEDENTES
• México tiene un nivel de gasto
en tecnologías de información
y comunicaciones (TIC) de
3.2% del PIB, que lo ubica en
el lugar 50 a nivel mundial
• Específicamente en software
este rezago es aún mayor,
donde el gasto en México es 6
veces inferior al promedio
mundial
• Países como India, Irlanda y
Singapur han utilizado la
industria del software como
uno de los principales motores
de su crecimiento económico.
• La cercanía geográfica y
cultural de México con el
mercado más grande del
mundo en esta industria (EUA),
le da una gran oportunidad
para desarrollar esta industria.
ProSoft
Programa para el Desarrollo de la Industria del Software
por Ivette García

Es por esto que la Secretaría de

Economía, en conjunto con orga-
nismos y empresas del sector,
ha puesto en curso el Programa
para el Desarrollo de la Industria
del Software (ProSoft).
Revisemos en qué consiste este
programa, qué avances se han
logrado y cuales son los planes
hacia futuro.
E l Programa para el Desarrollo de la Industria del
Software (ProSoft) se lanzó el 9 de Octubre del 2002
por la Secretaría de Economía, con el objetivo de crear las
condiciones necesarias para que México cuente con una
industria de software competitiva internacionalmente y
asegurar su crecimiento en el largo plazo
¿A DÓNDE QUEREMOS LLEGAR?
El ProSoft establece metas de largo plazo, con miras a que
en el año 2013 el país:
• Logre una producción anual de software de $5,000.00
millones de dólares.
• Alcance el promedio mundial de gasto en tecnologías de
información.
• Se convierta en el líder latinoamericano de desarrollo de
software y contenidos digitales en español.
Para alcanzar estas metas, la Secretaría de Economía con-
vocó a organismos e instituciones gubernamentales fede-
rales, estatales y municipales, así como a las propias
industrias del software y el sector académico del país. El
resultado fue un programa consensuado constituido por 7
estrategias:
1. Promover las exportaciones y la atracción
de inversiones.
2. Educar y formar personal competente en el desarrollo
de software, en cantidad y calidad convenientes.
3. Contar con un marco legal promotor de la industria.
4. Desarrollar el mercado interno.
5. Fortalecer a la industria local.
6. Alcanzar niveles internacionales en
capacidad de procesos.
7. Promover la construcción de infraestructura física
y de telecomunicaciones (agrupamientos
empresariales).
El ProSoft sigue contando con el apoyo de la iniciativa pri-
vada en el desarrollo de sus proyectos, algunos de los cua-
les han culminado con reformas legales adoptadas por el
H. Congreso de la Unión.

16 > OCT-DIC 2004 > www.softwareguru.com.mx

 ProSoft

¿HACIA DÓNDE VAMOS?

El ProSoft tiene una visión a largo plazo junto con metas de corto y mediano plazo.

En el bienio de 2003 y 2004, estamos trabajando en los elementos indispensables para el desa-
rrollo de una industria de calidad, que tenga a su alcance apoyos en materia de desarrollo de
capital humano, financiamiento y un marco normativo adecuado para la adopción de tecnologí-
as de información en las empresas en general. Así mismo, iniciaremos la promoción y estrategias
de despliegue en el mercado internacional.

Lanzamiento Plataforma Masa Jugador de

PROSOFT de despegue Crítica Clase Mundial

2002 2004 2006 2008 2010 2012

Factores Consolidación Innovación y

estructurales de la cadena productiva desarrollo tecnológico

Hacia el bienio 2005-2006 podremos ver una creciente participación de la industria en el merca-
do interno, como un proveedor confiable del gobierno y de los grandes consumidores de servi-
cios de la industria, como un proveedor consciente de las necesidades de tecnificación de las
pequeñas empresas y con una participación creciente en las exportaciones.

De 2007 a 2009 se tiene contemplado un importante crecimiento en el número de empresas y en

la diversificación de sus campos de actividad, siendo cada vez más importante su participación
en la investigación y desarrollo para la creación de soluciones que potencien las aplicaciones del
conocimiento derivado en la ciencia en ramas diversas.

En el 2013 visualizamos a la industria de software mexicana como un reconocido jugador de

clase mundial.

¿QUÉ SE HA LOGRADO?
Algunos de los avances de este programa son:
• Se elaboró un estudio sobre el perfil de la
Industria Mexicana de Software para identificar
los nichos de mercado internacional donde
México tenga ventaja competitiva, para así iden-
tificar las oportunidades en distintos países, en
distintos sectores, así como las recomendacio-
nes y estrategia necesaria para participar acti-
vamente en esos mercados.
• Se lanzó el Portal de la Industria Mexicana de
Software www.software.net.mx, para poner al
alcance de la industria un medio de difusión de
sus capacidades en los mercados externos, así
como facilitar la generación de negocios entre
oferentes y demandantes de la industria.
• Se implementó el proyecto de adecuación de
los planes de estudio en los niveles 5 y 6 del
Sistema Educativo Nacional, que permitirá
reducir la brecha que existe entre el recién egre-
sado y el personal productivo.
• Se han identificado cursos paracurriculares
para reforzar la formación de ingenieros desa-
rrolladores de software en las universidades,
para ello se está en proceso de elaborar los con-
tenidos que sustenten dichos cursos bajo la
modalidad de e-Aprendizaje.
• Con el fin de promover un marco normativo que
favorezca el desarrollo de la economía digital, el
Gobierno Federal publicó en el Diario Oficial de la
Federación, la Norma Oficial Mexicana NOM-151-
SCFI-2002- Prácticas comerciales-Requisitos que
deben observarse para la conservación de men-
sajes de datos. Se aprobaron la iniciativa de
reformas al Código de Comercio para el reconoci-
miento jurídico de la Firma Digital por el H.
Congreso de la Unión y las reformas en el Código
Fiscal para el reconocimiento de los comprobantes
fiscales electrónicos.
• Se creó la Fundación México Digital, organismo pri-
vado, cuyo fin será desarrollar el mercado interno de
tecnologías de información a través de la adopción
de tecnología en cadenas productivas específicas.
• Se realizó un estudio para identificar el nivel de
adopción de TI en sectores económicos en el país y
detectar aquellos en donde se pueda acelerar su
adopción; como resultado del estudio se identifi-
caron los nichos de transporte de carga, talleres
mecánicos, ferreterías, refaccionarias, farmacias y
misceláneas.
• Se diseñó una metodología para la incubación de
empresas de software, que será implantada con-
juntamente con las entidades federativas, y permi-
tirá aumentar las capacidades tanto de nuevas
empresas de software como las ya existentes.

www.softwareguru.com.mx > OCT-DIC 2004 > 17

 ProSoft
• Se ha promovido la apertura para compras gubernamen-
tales de TI a la industria nacional haciendo uso de las
reservas nacionales previstas en los tratados comerciales.
Como resultado de estas gestiones, el IMSS y e-México
han ocupado estas reservas en sus licitaciones de desa-
rrollo de software y servicios de TI.
• Se desarrolló un estudio para medir el nivel de madurez
y capacidad de procesos de la industria de TI. Se ocupará
la metodología planteada para obtener los indicadores
que permitan realizar el monitoreo, seguimiento y formu-
lar líneas de acción dirigidas a fortalecer las capacidades
de la industria de software y servicios relacionados.
• Se estableció el Fondo ProSoft, cuyo objetivo general es
promover el desarrollo económico nacional a través del
otorgamiento de apoyos de carácter temporal a progra-
mas y proyectos que fomenten la creación, desarrollo,
consolidación, viabilidad, productividad, competitividad y
sustentabilidad de las empresas del sector de tecnologías
de información.
• Se está trabajando en la creación de la Norma Mexicana
para el desarrollo y mantenimiento de Software, que esta-
rá basada en el Modelo de Procesos para el Desarrollo de
Software (MoProSoft) y su Método de Evaluación
(EvalProSoft), ambos creados por la UNAM y un grupo de
expertos de la industria a petición de la Secretaría de
Economía. El objetivo es elevar la competitividad de las
micro y pequeñas empresas de desarrollo en México.
• Se ha fomentado la formación de empresas integradoras
y clusters de TI alineados al ProSoft, en conjunto con dis-
tintas entidades federativas como: Aguascalientes, Baja
California, Coahuila, Guanajuato, Jalisco, Morelos, Nuevo
León, Puebla, Sinaloa, Sonora, Tabasco y Yucatán.
• Se realizó un estudio de potencialidades de las entida-
des federativas para desarrollar núcleos de economía digi-
tal, el cual establece una metodología para identificar el
potencial de las entidades, ya sea sobre la media nacional
(alto potencial) y bajo la media (bajo potencial). Los tres
primeros lugares son: Distrito Federal, Nuevo León y
Estado de México.
Inversiones y
Exportación
Capital
Integración Humano
y Clusters
de TI
ProSoft Marco
Legal
Capacidad
de Procesos
Mercado
Industria Interno
Local
18 > OCT-DIC 2004 > www.softwareguru.com.mx
"Se ha promovido la
apertura para compras
gubernamentales
de TI a la industria
nacional."
AGENDA PENDIENTE
Se han logrado avances sustanciales en la implementación
del ProSoft, sin embargo, aún hay acciones pendientes:
• Es necesario promover misiones comerciales para
consolidar la imagen del país en este sector a nivel
mundial y a su vez promover las capacidades de la
industria mexicana de TI;
• Es necesario incrementar las habilidades de la
industria y apoyar proyectos productivos de alto
impacto económico y laboral.
• Debido a la necesidad de incrementar las capacidades
de las empresas de desarrollo y mantenimiento de
software, es crucial promover el uso de modelos de
procesos que les apoyen a alcanzar tales objetivos.
• La industria requiere también de un
mayor financiamiento.
• Se deben establecer los lineamientos en materia
de compras gubernamentales de TI, promoviendo las
licitaciones nacionales.
PARTICIPACIÓN EN EL PROSOFT
Los avances antes citados son hoy una realidad gracias a
los grupos de trabajo del ProSoft. En estos, representan-
tes de empresas, instituciones educativas, organismos
empresariales, gobiernos estatales y gobierno federal
colaboran para definir los proyectos y acciones que permi-
tan alcanzar los objetivos del Programa. A la fecha, más de
120 representantes de estos organismos y empresas han
invertido más de 4,500 horas hombre para trabajar en los
subcomités del programa y alinear los esfuerzos entorno
al ProSoft.
Datos de contacto:
prosoft@economia.gob.mx
El documento completo del Programa, presentaciones, estudios y
avances del mismo se puede consultar en: www.software.net.mx
Ivette García es Subdirectora de la Industria
de Software para la Secretaría de Economía,
coordinando operativamente el Programa
para el Desarrollo de la Industria de Software.
Previamente laboró en el Centro de Desarrollo
de Motorola México en el área de calidad y
procesos. Ivette estudió ingeniería en sistemas
computacionales en la Universidad de
las Américas.
ENTREVISTA

JESÚS ORTA
Director de Economía Digital de la Secretaría de Economía
por Jorge Palacios

n este número entrevistamos a Jesús Orta,

E Director de Economía Digital en la Secretaría de
Economía. Jesús y su equipo de trabajo son respon-
sables de promover el desarrollo de la industria de
Tecnología de Información en México, fomentar su
adopción dentro del sector público para automatizar
los procesos, y colaborar en la definición de aspec-
tos regulatorios de la economía digital.

20 > OCT-DIC 2004 > www.softwareguru.com.mx


Software Guru.- ¿Cuál es tu rol en esta área?
Jesús Orta.- Nuestro ámbito es la tecnología de informa-
ción. Por ejemplo, todo lo que tenga que ver con firma
electrónica, privacidad en el uso de la información y regu-
lación de Internet. También laboramos en la administra-
ción del la NOM 151. En fin, todo lo que tenga que ver con
la regulación de la economía digital y el fortalecimiento
del mercado interno.
SG.- ¿Cuál es el estado actual
de la Industria de Software en México?
JO.- De acuerdo a nuestra economía, hay dos bloques, un
grupo de empresas que tienen posibilidades de competir
y muchas otras pequeñas que no, porque requieren de
financiamiento. Por eso, una parte de nuestros fondos
los estamos juntando con Nacional Financiera para crear
instrumentos listos para ser usados. Existen agrupacio-
nes como Empeira, la comunidad de software libre, y los
clusters, que nos exponen sus necesidades, y en base a
éstas establecemos las estrategias en ProSoft para aten-
derlas y aprovechar todo su potencial.
SG.- ¿Qué ventajas competitivas tiene hoy la industria y cuáles se amplían?
JO.- Las podemos dividir en dos: las ventajas naturales y las creadas. Las naturales son
la geografía, por la cercanía que tenemos a los Estados Unidos, y el mercado de alto
crecimiento de contenidos en español. Esto es algo que España está aprovechando
enormemente; nosotros tenemos que hacer lo mismo en América Latina. En la parte de
las ventajas creadas, nosotros tenemos que desarrollar capacidades humanas. Si inver-
timos en esta capacitación, automáticamente un mexicano con el mismo nivel de prepa-
ración de un chino o un indio, tiene una ventaja competitiva por las ventajas naturales
que ellos no poseen. La principal desventaja es el precio, somos más caros en ciertas
partes de la cadena de valor como puede ser escribir código; sin embargo, podemos
competir en consultoría, que implica conocer proceso, viajar constantemente, interac-
tuar con el cliente, para lo cual es necesario una cultura mas afín, cultura occidental.
Además, la proximidad te reduce costos, haciendo competitivo el costo total del proyec-
to en oposición a costo por hora del programador oriental.
SG.- A nivel de visión, ¿cómo ves a la industria mexicana al mediano y largo plazo?
JO.- Yo diría que la industria mexicana en general carece de una visión. Para despegar
es necesario atender todos los factores críticos para poder ser una empresa de clase
mundial. ProSoft tiene una responsabilidad en ese sentido, cada vez veo a más gente
decir: En diez años vamos a producir 5 mil millones de dólares, que es uno de nuestros
objetivos, crear una visión en común.
SG.- ¿Cuáles son los principales retos actuales de la industria?
JO.- La de satisfacer las necesidades de capital humano, la de trabajar con el sector edu-
cativo en la parte donde se forman las competencias. Por eso, ProSoft asegura ambas
cosas, cantidad y calidad. La otra es la certificación, si no la tienes, estás fuera. Lo mismo
pasa en el mercado gubernamental, el gobierno es el mayor comprador del país; si PEMEX
o el IMSS te están pidiendo niveles de certificación que las empresas mexicanas no
cubren, ¿quién se está llevando los contratos? las empresas extranjeras. Si queremos
crear una industria local con ingresos importantes debemos elevar la capacidad de proce-
sos de las empresas nacionales para que tengan acceso a los mercados de alto valor. Así
que otro reto es elevar la capacidad de procesos de la industria en general.
Software Guru
SG.- En varios países está vigente la práctica de
consumir sólo software hecho en ese país,
¿el gobierno ha pensado en adoptar una práctica
similar? ¿Cuál sería la estrategia para consumir
únicamente software hecho en México?
JO.- México, como país insertado en la economía global,
tiene un compromiso con el comercio internacional y sus
políticas y no puede simplemente decir que el gobierno
sólo va a consumir software nacional. Sin embargo hay
otro tipo de herramientas que se están utilizando, como
es el caso de una “reserva nacional para compras guber-
namentales”, la cual nos da aproximadamente 110 millo-
nes de dólares anuales para licitaciones nacionales. En
ProSoft estamos haciendo dos cosas para aprovecharla,
una promover su uso y la otra establecer mecanismos
para su aprovechamiento.
“La reserva nacional nos da
aproximadamente 110 millones
de dólares anuales para
licitaciones nacionales.”
SG.- ¿Cómo se están institucionalizando
todos estos esfuerzos para que vayan
más allá de un esfuerzo sexenal?
JO.- Es una preocupación que tenemos desde hace unos
dos años. Tomaría como ejemplo el cómo se consiguieron
los recursos para ProSoft, donde hubo un diálogo con el
congreso y las comisiones de economía, quienes aproba-
ron el recurso; eso es importante porque el congreso le
da una especie de prueba para que en el cambio de
administración se sepan las prioridades. Con ello tene-
mos una ruta trazada que, como punto culminante, nos
llevará a la creación de una ley de fomento al desarrollo
de este sector.
SG.- ¿Cuál es la perspectiva inmediata
y mediata de las integradoras regionales?
JO.- Realmente creo que esto va a ser una avalancha. Las
integradoras van a jugar un papel muy relevante en la
producción nacional de software al largo plazo. Para que
éstas tengan un papel significativo, requieren multiplicar
varias veces su capacidad actual y esto les va a tomar
algunos años. Sin embargo, hay quienes al cabo de uno o
dos años podrían estar teniendo éxito. Los casos de éxito
van a ser muy importantes para atraer a los otros jugado-
res, y esto es otro reto importante. Estamos muy atentos
de la formación de estas integradoras y por supuesto
tiene prioridad.
SG.- ¿Qué mensaje dejarías
a la comunidad que lee Software Guru?
JO.- A la comunidad de SG y a la comunidad de software
en general, que sigan alineados, que compartamos todos
una misma visión e idea sobre cómo llegar a desarrollar
esta industria. ProSoft busca ser el elemento de cohesión,
por ello está abierto a la participación de todos ustedes.
www.softwareguru.com.mx > OCT-DIC 2004 > 21
EN PORTADA

INDUSTRIA
DE SOFTWARE
MÉXICO VS. RESTO DEL MUNDO

uede ser cierto que todos los caminos lleven

P a Roma. Sin embargo, para planear adecua-
damente el viaje es necesario saber desde dónde
partimos. Esto mismo sucede con el proyecto
para desarrollar la industria del software en
México. Necesitamos saber dónde estamos para-
dos, cuáles son nuestras capacidades actuales y
cómo nos comparamos contra los competidores.
 Software Guru

Para este análisis nos hemos basado en información provista en un estudio recientemen-
te presentado por la Secretaría de Economía (ver recuadro 1). Como marco de referencia
hemos utilizado el Modelo Oval de Carmel. Este modelo fue originalmente desarrollado
para describir los principales factores de éxito de las naciones líderes en la exportación
de software. Sin embargo, también es útil como marco de referencia para analizar y eva-
luar las capacidades de la industria de software en una nación en particular. Los ocho fac-
tores que considera el modelo son:
1. Visión y política del gobierno.
2. Capital humano.
3. Salarios.
4. Calidad de vida / Atracción de talento.
5. Características de la industria.
6. Infraestructura tecnológica.
7. Acceso a capital de inversión.
8. Vinculación.

La siguiente figura ilustra este modelo. En el diagrama se sugiere que algunos de los fac-
tores pueden traslaparse (óvalos encimados), mientras que otros están relacionados
entre sí (óvalos conectados por flechas).

Frontera Nacional Modelo Oval de Carmel

VISIÓN Y POLÍTICA DEL GOBIERNO

Salarios El gobierno ha jugado un papel clave en la mayoría de los
países con una industria de software exitosa. El apoyo típi-
Capital camente se da en forma de programas para destinar recur-
Humano sos, otorgar facilidades y promover los productos/servicios
Vínculos en el exterior. Algunos ejemplos recientes de apoyo a esta
Calidad
Visión y de Vida industria por parte del gobierno son:
Industria
Políticas
del Gobierno Mercado
Externo China. Elaboración de un programa para fomentar la
Exportaciones de Software industria y creación de zonas económicas especiales
Capital para el software (2000).
Rumania. Eliminación del impuesto sobre la renta a
los empleados de esta industria (2001).
Infra- Costa Rica. Creación de visión nacional para la
estructura Oportunidad Digital. Incentivos fiscales a las empresas
de tecnología que se establezcan en sus zonas francas.
Negociación con Intel para la apertura de una planta
en San José (2001).
Recuadro 1:
En el caso de México, el estudio Global Information
La Secretaría de Economía solicitó la realización del “Estudio del Perfil de la Technology Report 2004 del Foro Económico Mundial, lo
Industria Mexicana de Software para Definir los Nichos de Mercado Internacional posiciona en el lugar número 59 en el rubro de ambiente
Acordes al Perfil y Competitividad de la Industria”, el cual fue presentado en agos- político y regulatorio para Tecnología de Información y
to de 2004. El estudio está compuesto por los siguientes seis criterios: Comunicación (TIC). Esperamos que esta posición mejore
conforme las estrategias de ProSoft vayan generando
• Criterio 1.- Análisis de las características de oferta y demanda en los nichos de resultados. Sin embargo, un punto importante que sigue
mercado mundial de software y servicios relacionados. sin resolverse es el de los incentivos fiscales para las
empresas de este sector.
• Criterio 2.- Perfil de la industria mexicana de software y servicios relacionados.
Ambiente Político y Regulatorio para TIC
6.00
• Criterio 3.- Análisis de brecha de la industria mexicana de software y servicios
relacionados respecto a las principales industrias oferentes a nivel mundial. 5.00

• Criterio 4.- Determinación del mercado objetivo y potencial para la industria mexi-
4.00
cana de software y servicios relacionados.
3.00
• Criterio 5.- Estrategia de despliegue de la oferta nacional de software y servicios
(77) Argentina
(24) Irlanda

(29) India

(43) Brasil

(57) C. Rica

(59) México
(15) Israel

(18) Chile

(60) Colombia
(1) Finlandia

(53) Uruguay

(63) Filipinas

en los nichos de mercado identificados.

• Criterio 6.- Ruta crítica del despliegue de la oferta nacional de software y servi-
cios relacionados en los nichos de mercado mundial identificados. Fuente: Global Information Technology Report 2003-2004

www.softwareguru.com.mx > OCT-DIC 2004 > 23

CAPITAL HUMANO Número de empleados en el sector de software (miles de personas)
Este factor considera las características y habilidades colectivas de los profesionistas en
EE.UU. 1,800
esta industria. Esto incluye cantidad, orientación y tradiciones nacionales; composición, India
manejo de otros idiomas y habilidades administrativas. China
Filipinas
Brazil
La fortaleza del capital humano de un país es consecuencia de una tradición de varias México
Chile
generaciones hacia la educación en ciencias e ingeniería. Países como India, Irlanda e Irlanda
Israel se han beneficiado de un énfasis nacional en educación técnica avanzada que data Argentina
C. Rica
de más de dos generaciones atrás. De los diferentes factores del modelo, el capital huma- Uruguay
no es el que requiere el mayor tiempo de inversión, ya que no es posible desarrollarlo en 0 100 200 300 400 500 600 700 800
unos cuantos años.
Número de egresados anuales en carreras de sistemas computacionales
La cantidad de capital humano disponible es vital para acumular una masa crítica que ener- India
gice la industria. China anualmente genera 50,000 graduados de carreras de computación, EE.UU.
China
y 465,000 de otras ciencias e ingenierías (varios de los cuales terminan en la industria de Filipinas
software). En Filipinas el número de graduados anuales en computación es de 30,000. En México
Brasil
México esta cifra se aproxima a los 20,000. Chile
Irlanda
Argentina
El capital humano no es homogéneo, así que su composición también es un factor rele- C. Rica
vante. Por un lado existen individuos altamente capaces, a quienes se considera como Uruguay

“talento”, y por otro lado están aquellos simplemente considerados por sus “habilida- 0 20,000 40,000 60,000 80,000 100,000 120,000

des”. La diferencia entre estos dos términos es sencilla: una habilidad es algo que se
Calidad de los programas educativos y de capacitación en T.I.
puede adquirir a través de estudio y práctica (como ser un programador certificado en 7
algún lenguaje), mientras que el talento es la capacidad para resolver problemas com- 6
plejos. Haciendo una analogía, cualquiera puede tocar un instrumento musical, pero sólo 5
4
algunos pueden crear música.
3
2
El manejo del idioma inglés es otro criterio importante para medir la capacidad en este 1
sector. Aunque en México el manejo del inglés es común en ciertos sectores, no es la 0
segunda lengua, como en el caso de la India o Filipinas. Generalmente el personal

Rusia
C. Rica

Chile

Filipinas

Brazil

Argentina
India

Irlanda

México
EE.UU.

Uruguay

China
directivo tiene un nivel fluido en inglés oral y escrito, sin embargo, este no es el caso
del personal técnico. Sólo un pequeño porcentaje de los programadores es capaz de
comunicarse claramente en inglés, lo cual es sin duda una desventaja tomando en
cuenta que la mayoría de los clientes extranjeros hablan ese idioma.
La cantidad de
Por último, las habilidades administrativas son otro aspecto a tener en cuenta. Éstas nor-
malmente se aprenden en escuelas de negocios, así que se requiere profesionalizar a la capa capital humano
administrativa de este sector para que pueda destacar. disponible es vital
Aunque el capital humano doméstico es vital, vale la pena recalcar que algunas naciones para acumular una
están desarrollando su industria de software en base a capital humano importado. Tal es masa crítica que
el caso de Panamá, que recientemente creó un parque tecnológico cuyo modelo conside-
ra la importación de cientos de profesionistas de software. Aún es muy temprano para energice la industria.
decidir si este modelo es eficaz y sostenible, pero no hay que perderlo de vista.

CALIDAD DE VIDA
¿Por qué las empresas de software establecen sus centros de
investigación y desarrollo en ciertos países? Estas empresas bus-
can capital humano innovador o “talento”, como lo llamamos ante-
riormente. Este talento no está distribuido de manera aleatoria,
sino que se concentra en clusters caracterizados por un alto nivel
de calidad de vida. Esto es, los profesionistas talentosos tienden a
concentrarse en lugares que cuenten con belleza natural, centros
de entretenimiento, un mercado laboral atractivo y otras condicio-
nes que provean un alto nivel de calidad de vida. Tal es el caso de
Miami, San Francisco y otros centros científicos del mundo como
Estocolmo, Tel-Aviv, Moscú. Aún en India, la ciudad de Bangalore
ha logrado atraer talento por esta razón.

En México no existen tales centros para atracción de talento. El

mercado laboral de esta industria se concentra principalmente en
el Distrito Federal, el cual tiene un alto costo de vida, así como pro-
blemas de sobrepoblación, contaminación e inseguridad. Esto
causa que una buena parte del talento emigre hacia el extranjero.

24 > OCT-DIC 2004 > www.softwareguru.com.mx

 Software Guru
SALARIOS
En contraste con el factor de la calidad de vida, está el de
los salarios. Los directivos que adquieren servicios de out-
sourcing buscan al proveedor de más bajo costo, y el prin-
cipal componente del costo son los salarios de los
desarrolladores y gerentes.

El salario promedio para un programador mexicano con

dos o tres años de experiencia en la Ciudad de México es
de $18,000.00 dólares al año. En las ciudades de Pretender ser el país
Guadalajara y Monterrey el salario es de 10 a 15% menor. con los salarios más
Aunque este nivel de salario es significativamente infe-
rior al que se presenta en Estados Unidos, Europa, bajos es una carrera
Australia y Japón, sigue siendo relativamente alto si se
sin sentido...
compara con otros países asiáticos como India, Filipinas
o China. Aún en América Latina, México es el país más
caro en mano de obra.

Pretender ser el país con los salarios más bajos es una

carrera sin sentido. Hay poco que los países puedan hacer
para competir en este ciclo en el que la inversión y los inte-
reses rápidamente se mueven hacia los países con sala-
rios más bajos. Esta dinámica no es exclusiva de la
industria de software. Ya la vivimos en el periodo posterior
a la Segunda Guerra Mundial, cuando la manufactura se
mudó a Japón, que posteriormente encareció su mano de
obra, obligando a la industria a migrar hacia Corea y
Taiwán, que vivieron el mismo ciclo, para finalmente recu-
rrir a China. En el caso de la industria de software, India
fue la opción más barata durante muchos años, pero sus
salarios han subido, además de que surgieron países con
menores salarios.

Salario anual promedio de profesionistas de software en dólares (2002)

EE.UU.
Japón
Singapur
Irlanda
México
Tailandia
Malasia
Chile
China
Argentina
Filipinas
Rusia
Brasil
India
0 10,000 20,000 30,000 40,000 50,000 60,000 70,000

INDUSTRIA
El perfil y características de la industria son determinantes para su éxito en el mercado
global. Las principales características que inciden en el éxito del sector son: efectos de
cluster, número de empresas, tamaño, asociaciones y estándares a los que aspiran.

Un cluster representa una masa crítica de empresas con proximidad geográfica. El cluster
de tecnología más conocido a nivel mundial es Silicon Valley. Los efectos de cluster son muy
importantes ya que proveen un ambiente de competencia y cooperación entre empresas. La
competencia se traduce en innovación y la cooperación en crecimiento. Los efectos de clus-
ter también se generan como resultado de las redes de profesionistas que comparten su
conocimiento y experiencia. En México las empresas de software tradicionalmente han esta-
do diseminadas en las grandes áreas metropolitanas. Existen esfuerzos recientes para
generar clusters en diferentes zonas del país, pero están en etapas tempranas.

Una industria de software exitosa requiere una masa crítica de empresas con algunas de
tamaño significativo. Las empresas grandes (más de cien empleados) funcionan como núcleo
alrededor del cual se desarrollan empresas pequeñas. En México existen cerca de 1,500
empresas en la industria de software, y 83% de ellas cuenta con menos de 50 empleados. A
nivel mundial, el promedio de empleados por empresa en esta industria es de 250.

www.softwareguru.com.mx > OCT-DIC 2004 > 25

 EN PORTADA

Otro elemento a considerar es la habilidad de las empresas para agruparse

en asociaciones que promuevan la industria nacional a la vez que proveen
de servicios a sus miembros. Este es el ejemplo de NASSCOM en la India,
que ha ayudado a desarrollar la “marca” del software hindú alrededor del
mundo. Adicionalmente, las empresas se pueden agrupar para mercadear
sus productos y servicios en el exterior. Este es el caso de Fort Ross en San
Petersburgo, SibIT en Novosibirsk y Bulsoft en Bulgaria. En México hay algu-
nos consorcios como Empeiria y Aportia.

La especialización también juega un papel importante en la competitividad y cre-

dibilidad. Para tener éxito como industria, las empresas deben especializarse en
un mismo nicho de productos o servicios específicos. Esta especialización favore-
ce los efectos de cluster y facilita el branding a nivel internacional. Por ejemplo,
Japón se especializa en videojuegos, India en servicios profesionales y desarrollo
offshore, Irlanda en localización y desarrollo de productos comerciales, e Israel
provee tecnología de capas inferiores para ser incluida en productos de terceros.
En el caso de México, la falta de enfoque y especialización es uno de los principa-
les puntos débiles. Esto dificulta fuertemente una estrategia nacional de posicio-
namiento hacia el mundo.

En cuanto a estándares de calidad se refiere, sabemos que el modelo de referen-

cia más utilizado en esta industria es el Capability Maturity Model (CMM). India
es el país con mayor número de empresas certificadas en nivel 5, el máximo de
este modelo. Esto le da un gran renombre a nivel internacional, y provee tranqui-
lidad a sus clientes sobre la calidad de los productos que va a obtener, mitigan-
do el riesgo del desarrollo de software a distancia. En el caso de la industria
mexicana, el nivel de madurez medido en términos del número de empresas con
acreditación CMM, es el segundo en América Latina después de Brasil; aunque
este último no tiene ninguna acreditación nivel 5, mientras que México tiene una.
Como parte del esfuerzo para mejorar la capacidad de procesos de la industria
mexicana, se creó el Modelo de Procesos para la Industria de Software —para
más información, ver columna adjunta (MoProSoft pg. 28).
Tamaño de la Industria de T.I. (ventas anuales en millones de dólares)
EE.UU. $282,644
China
Irlanda
India
Brasil
México
Argentina
Filipinas
Uruguay
Chile
C. Rica
$0 $2,000 $4,000 $6,000 $8,000 $10,000 $12,000 $14,000

Número de empresas en sector de software

EE.UU. 76,524
Brasil
China
Filipinas
India
Chile
Uruguay
México
Irlanda
C. Rica
0 1,000 2,000 3,000 4,000 5,000 6,000

Número de empresas con acreditación CMM

EE.UU. 1,838
India
China
Brasil
México
Chile
Uruguay
Irlanda
Filipinas
C. Rica
Argentina
0 50 100 150 200 250 300 350

26 > OCT-DIC 2004 > www.softwareguru.com.mx

 Software Guru

CAPITAL
La industria del software, como cualquier otra, requiere
acceso a capital para crecer y desarrollarse. Existen diver-
sas fuentes de capital, tanto internas como externas. Entre
las internas está la oferta de acciones de la empresa, fon-
dos de gobierno y fondos de capital de riesgo, mientras
que en las externas destaca la inversión extranjera directa
y la ayuda de organismos internacionales. El caso de
Irlanda es notable, donde su Agencia de Desarrollo
Industrial ha logrado atraer una gran cantidad de inversión
INFRAESTRUCTURA extranjera directa. En Israel, su Secretaría de Industria y
Las empresas de software requieren una infraestructura Comercio ha apoyado a las empresas de tecnología con
de telecomunicaciones abundante y barata. De igual créditos bastante blandos.
importancia es la provisión continua de energía eléctrica
que muchas veces se toma por dada pero que en algunos El Global Information Technology Report 2003-2004 pone
países continúa siendo un problema. a México en el lugar número 76 en este rubro. Sin duda,
este es uno de los factores en los que más adolece la
En países donde la infraestructura disponible es insufi- industria de software mexicana. Las empresas han tenido
ciente se han utilizado diferentes soluciones. Por ejemplo, que financiarse internamente, lo cual ha limitado sus
en India en la década de los 80 las empresas optaron por capacidades de crecimiento. Los créditos bancarios no son
utilizar redes satelitales para comunicarse con sus clien- una opción atractiva, ya que además de su alto costo, no
tes en el extranjero, y en el 2002 se inauguró un cable sub- se cuenta con colaterales de garantía, ya que los principa-
marino de 3,200km que conecta la ciudad de Chennai con les activos de las empresas de software son intangibles.
Singapur. En otros lugares se ha generado infraestructura Esta es una de las principales razones por las que no ha
dedicada para clusters tecnológicos, como es el caso de prosperado la industria local de software empaquetado.
Filipinas, donde existen parques tecnológicos con capaci-
Disponibilidad de capital de riesgo
dades de conectividad muy por encima de las provistas en
el resto del país. 6.00
5.00
Las estadísticas disponibles en este rubro son engañosas, 4.00
ya que evalúan la infraestructura a nivel país, no por zonas 3.00
o clusters. México ocupa el lugar 42 a nivel mundial, aun- 2.00
que sus principales ciudades (México, Guadalajara y 1.00
Monterrey) cuenten con servicios de telecomunicación

(98) Argentina
(12) Singapur

(15) Hong Kong

(28) India

(58) Vietnam

(68) C. Rica
(4) Israel

(9) Irlanda

(71) Filipinas
(3) EE.UU.

(54) Brasil

(76) México
comparables a los disponibles en Estados Unidos.

Sin embargo, el punto débil para México en cuanto a infra-

estructura no es su disponibilidad ni calidad, sino su
costo, ya que éste se encuentra notoriamente por arriba Fuente: Global Information Technology Report 2003-2004
del de sus principales competidores.

Infraestructura de TIC a nivel nacional

5.00

4.00

3.00

2.00
(72) China
(32) Irlanda

(34) Brasil

(36) Chile

(41) Uruguay

(42) México
(16) Hong Kong

(22) Israel

(49) C. Rica
(5) Singapur

(38) Argentina

(67) India

Costo promedio de 20 horas de acceso a Internet

25
20
15
10
5
0
México
Brazil

Rusia

Filipinas

Irlanda

EE.UU.
India

Uruguay

C. Rica
China

Chile

Argentina

Fuente: Global Information Technology Report 2003-2004

www.softwareguru.com.mx > OCT-DIC 2004 > 27

 EN PORTADA OPINIÓN AMCIS

VÍNCULACIÓN
La vinculación se refiere a la relación que surge entre indi-
viduos, empresas o naciones debido a sus conexiones
Hacia una
culturales, geográficas, lingüísticas o étnicas. La vincula-
ción es esencial para realizar negocios, debido a que los
industria
directivos buscan relaciones que minimicen el riesgo y el
costo de hacer negocios.
de software
Este es tal vez el factor donde México goza de mayores
competitiva
ventajas, ya que tiene una fuerte vinculación con Estados
Unidos, Canadá, América Latina y España. Su ubicación
con MoProSoft
geográfica le da un huso horario similar al de estos países, Por Francisco López Lira
así como un menor tiempo de traslado. Además, la cultura
social y de negocios con estos países es más cercana que
la de la India u otras naciones asiáticas. México también “Hombres haga quien quiera
debe aprovechar la diáspora de profesionistas que tiene hacer pueblos.”
en el extranjero y que pueden influenciar para enviar opor- —José Martí
tunidades en esta industria hacia este país.

Según Porter, para que una empresa

CONCLUSIONES obtenga una ventaja competitiva sosteni-
La brecha de la industria mexicana de software y servicios relacionados es muy significativa cuan- da depende de:
do se le compara con los principales países oferentes de software como Estados Unidos, la India o
Irlanda. En América Latina, México ocupa el segundo lugar después de Brasil en la mayoría de los a) La estructura de la industria.
criterios analizados, como tamaño de la industria, número de empresas y empleo. Sin embargo, los b) La estrategia, puede estar basada en:
costos en México son altos comparados con los de sus competidores en esta región. • Ofertar productos/servicios con
mayor valor y/o
El siguiente cuadro muestra un análisis FODA que resume la información provista en este estudio. • Reducir costos
(eficiencia operacional).
FORTALEZAS DEBILIDADES
El Modelo de Procesos para la Industria
• Estabilidad política • Imagen y reputación —México no de Software (MoProSoft) es parte de los
• Huso horario similar a EEUU es reconocido como productor de software trabajos en curso para impulsar la indus-
• Afinidad cultural con países de América • Oferta limitada de mano de tria mexicana de software. El modelo fue
• Proximidad y traslado rápido con obra capacitada desarrollado ante la necesidad de contar
países de América • Escaso manejo del inglés con una norma que ayudara a elevar el
• Buena infraestructura • Baja madurez de procesos nivel de calidad de la industria y fuera
• Tratados comerciales • Acceso limitado a capital accesible para las empresas (y áreas inter-
nas de desarrollo) pequeñas y medianas.
MoProSoft incluye un conjunto de herra-
mientas que pueden coadyuvar con la
OPORTUNIDADES AMENAZAS competitividad de las empresas, como: la
planeación estratégica, el enfoque de pro-
• Amplio espacio para apoyo efectivo • Alta competencia de naciones emergentes: cesos, esquemas de verificación y valida-
del gobierno Brasil, Rusia, Costa Rica, China y Filipinas ción interconstruidos, un enfoque
• Capitalizar el apetito nearshore (EEUU) • Incrementos en costo de mano de obra sistémico, la inclusión de los tres niveles
• Asociación con jugadores globales • Fluctuaciones en tipo de cambio de la organización, la administración de
de la industria • Constante invasión tecnológica proyectos y las mejores prácticas de
• Servicios de localización para Desarrollo de Software.
mercado latino
Parafraseando a Martí, si queremos hacer
una industria competitiva, tenemos que
hacer empresas competitivas. MoProSoft
Los invitamos a que revisen el estudio completo de nichos de mer- puede convertirse en una palanca de
cado para la industria mexicana de software, el cual se encuentra apoyo para alcanzar este propósito.
disponible en www.software.net.mx. Todas las estadísticas y gráficas
presentadas en este artículo fueron obtenidas de ahí, a menos que Invitamos a las empresas y organizaciones
se especifique otra fuente. de software a que consulten MoProSoft y
su estatus actual en www.software.net.mx
Otras referencias: ••
Dutta, Soumitra, et al. Global Information Technology Report 2003-2004. Oxford El autor es fundador y actual presidente
University Press, 2004. de la Asociación Mexicana para la
Calidad en Ingeniería de Software
Carmel, Erran. “The New Software Exporting Nations: Success Factors”. Electronic flopezlira@amcis.org.mx
Journal of Information Systems in Developing Countries, vol. 13, Mayo 2003.

28 > OCT-DIC 2004 > www.softwareguru.com.mx

CASO DE ESTUDIO
ULTRASIST
PRIMER PYME 100% MEXICANA CON NIVEL 4 SW-CMM®
Por María Julia Orozco M. y Claudia Alquicira
Una empresa con diez años de existencia,
es la primer PYME 100% mexicana en
obtener el nivel 4 del modelo SW-CMM®,
mediante una evaluación formal CBA-IPI
(CMM® Based Appraisal for Internal
Process Improvement). Maria Julia Orozco
y Claudia Alquicira narran el proceso que
siguieron para alcanzar este logro.
30 > OCT-DIC 2004 > www.softwareguru.com.mx
a tecnología de información se ha convertido en un impulsor clave en el mundo actual.
L Debido a ello, construir sistemas que cubran las necesidades del cliente en el tiempo
y costo esperados es fundamental para el éxito de las empresas de desarrollo de softwa-
re. Para lograr esa meta, hay que mantener el compromiso de definir y mejorar continua-
mente los procesos de trabajo.
Si bien se ha escrito mucho sobre las experiencias de la aplicación de un proceso de soft-
ware en las grandes organizaciones, poco conocemos acerca de las experiencias en las
pequeñas empresas. En muchos países, entre ellos México, las pequeñas empresas repre-
sentan un gran porcentaje de la industria. De acuerdo con información del INEGI, en nues-
tro país las pequeñas y medianas empresas (PyMEs) representan más de 90% del total.
En este artículo se resume la experiencia en la implantación de los niveles 2, 3 y 4 de SW-
CMM® en Ultrasist, S.A. de C.V., empresa mexicana de desarrollo de software a la medida.
Ultrasist ha realizado, desde su creación, un esfuerzo de mejora iterativo e incremental,
mediante la adopción de mejores prácticas de diferentes modelos internacionales. La pri-
mera versión del sistema de calidad se definió e implantó en el año de 1994. A partir de
entonces, la empresa ha realizado revisiones y actualizaciones del sistema.

PROCESO DE
DESARROLLO DE SOFTWARE
En el proceso de desarrollo de software es necesario consi-
derar un conjunto de actividades que garanticen una venta-
ja competitiva sostenible, proyectando una serie de
estándares y guías para la construcción de aplicaciones,
capacitación del personal, adquisición e implantación de
herramientas de apoyo.
La ausencia de estos elementos en las tareas diarias deriva
en que gran parte del tiempo se invierta en dar respuestas
rápidas a problemas urgentes, con soluciones que no siem-
pre son duraderas y correctas, ya que no son planeadas.
Esto trae como resultado que las tareas urgentes tengan
mayor prioridad que las importantes y que una misma acti-
vidad se realice más de una vez. Esto implica a las empre-
sas una pérdida de tiempo, de recursos financieros y
humanos, aumentando sus costos de operación y disminu-
yendo sus utilidades.
Para tener un proceso de desarrollo eficiente y efectivo, hay
que planear cada una de las actividades que se realizan,
monitorearlas y controlarlas; asegurarse de que cada uno
de los miembros cuenta con los conocimientos necesarios
para desempeñar correctamente las tareas que le son asig-
nadas; fomentar buenos hábitos de desempeño como la
disciplina y el trabajo en equipo; compartir el conocimiento
y utilizar tecnología que apoye a realizar eficientemente las
labores. Es necesario proveer de manera eficiente los recur-
sos y prevenir los defectos; evitar la duplicidad de tareas no
sólo en los proyectos, sino a nivel organización.
Ultrasist, consciente de esto, desde sus inicios decidió defi-
nir un proceso que precisara las prácticas que deben llevar-
se a cabo para construir las soluciones que la organización
ofrece. A ese proceso hoy en día lo denominamos SQAE.
La característica general tanto del proceso creado como de
los resultados que produce, es un enfoque minimalista que
reduce la curva de aprendizaje de los elementos de la orga-
nización. Se buscó que fuera un proceso ligero con un esque-
ma de múltiples roles, pues de lo contrario el costo para
llevarlo a cabo podía ser prohibitivo para la organización.
Software Guru
PROCESO SQAE
El SQAE está basado en la ingeniería de procesos, enten-
diendo como un proceso al conjunto de prácticas que defi-
nen el qué, cuándo, cómo y quién debe hacer las tareas
diarias para lograr una meta. Todo trabajo que se lleva a
cabo en Ultrasist es visto como un proceso, el cuál es defi-
nido, ejecutado y evaluado para poder ser mejorado.
El SQAE está integrado por tres macro procesos básicos:
Planeación, Construcción y Evaluación.
• El proceso de Planeación contempla el conjunto de acti-
vidades para definir y mantener una metodología de tra-
bajo que nos permita construir adecuadamente las
soluciones que ofrece la organización; definir cómo con-
formar un equipo de trabajo que lleve a cabo las tareas
como se han planeado, perfeccionar la metodología esta-
blecida con base en las mejores prácticas tanto de la
industria como del proceso mismo. Considera el conjunto
de actividades que debe realizar la organización para man-
tenerse actualizada en cuanto a las nuevas opciones de
tecnología de información y cómo se pueden aprovechar
para los productos de negocio actuales y futuros, así como
proponer nuevos productos de negocio basados en inno-
vaciones tecnológicas; investigar, ver su factibilidad y
tomar la decisión oportuna para su integración.
• El proceso de Construcción tiene como fin construir y
mantener sistemas que produzcan resultados correctos,
con un código eficiente y que cumplan con los requeri-
mientos de negocio del cliente en el tiempo y costo espe-
rados aplicando la metodología definida a las soluciones
que ofrece la organización. Este proceso busca encontrar
un término medio entre los métodos rigurosos que asegu-
ran generar sistemas mantenibles, reutilizables y confia-
bles pero con la desventaja que los resultados pueden ser
muy lentos, contra los métodos de desarrollo rápido de
aplicaciones que difícilmente pueden ser mantenibles y
reutilizables.
• El proceso de Evaluación establece un mecanismo que
nos permite evaluar la eficacia y eficiencia de los proce-
sos, así como medir la calidad de los productos obtenidos,
con el fin de poder optimizarlos. Encontrar las diferencias
entre lo documentado y lo real. Este proceso también se
encarga de reforzar las nuevas normas, valores y procesos
establecidos para que permanezcan en la organización
hasta que tenga lugar un cambio.
La definición, implantación y mejora del proceso ha sido un
esfuerzo continuo en la organización y se ha logrado a tra-
vés de una metodología iterativa e incremental. Iterativa en
el sentido que se consideran los éxitos obtenidos, los cua-
les se integran para refinar constantemente el proceso.
Incremental en el sentido que gradualmente se incluyen
nuevos elementos mediante progresos demostrables.
Nos hemos apoyado en varios modelos y estándares de la
industria, entre los cuales podemos mencionar
Perspective, TSP (Team Software Process), SW-CMM®
(Capability Maturity Model), ISO15504, PMBoK (Project
Management Body of Knowledge), TMM (Test Maturity
Model) y actualmente MoProSoft (Modelo de Procesos
para la Industria Mexicana de Software).
www.softwareguru.com.mx > OCT-DIC 2004 > 31
CASO DE ESTUDIO
A D M I N I S T R A D O S
•Refinar aplicando las mejores prácticas
Planeación Construcción Evaluación
Evalúa Productos
y Procesos
Procesos Mejores Prácticas
Producto
Metodología Métricas
Herramientas
Base de
Conocimiento
Siempre hemos buscado que el SQAE sea un proceso ágil, sencillo, robusto y evolutivo.
Ágil.- Que sea una guía, mas que un conjunto de reglas rígidas, que defina lo que
hay que hacer sin generar cuellos de botella, complejidad o burocracia en el traba-
jo y que nos permita alinearnos dinámicamente a las necesidades de los proyectos.
Que pueda adecuarse para manejar los diversos proyectos. Algunas actividades
pueden incluirse o excluirse dependiendo de la complejidad del proyecto. Que sea
lo más general posible pero sin dejar lugar a ambigüedades.
Sencillo.- Fácil de aprender y de aplicarse. Que dé resultados factibles y prácticos
y que para ello no requiera una estructura compleja en la organización.
Robusto.- Que permita crear sistemas correctos de una forma adecuada a la velocidad
que las organizaciones demandan. Entendiendo como sistema correcto aquel que
soporta de la mejor manera no sólo las necesidades del usuario, sino del negocio.
Evolutivo.- Que defina una estrategia de mejora continua, que mediante una tácti-
ca para recolectar y evaluar datos, permita medir y mejorar el proceso y los pro-
ductos. Que permita aprender de las fortalezas y debilidades.
MÉTRICAS
El SQAE establece las actividades necesarias para la definición, recolección y análisis de
métricas. Ultrasist cuenta con un grupo que es responsable por definir y actualizar las
métricas de los procesos y de los productos, considerando que éstas sean cuantitativas
y que proporcionen información de la eficacia y eficiencia del proceso, así como de la cali-
dad del producto.
Los responsables del proyecto o proceso recolectan las métricas de acuerdo con una
periodicidad establecida, apoyándose en una herramienta desarrollada por la organiza-
ción, denominada SQAT. Esta herramienta ha sido robustecida a la par de la actualización
del SQAE, por lo que además de la recolección de métricas satisface las necesidades defi-
nidas por los procesos, por lo que la hace una herramienta ad-hoc para la implantación
del mismo.
El análisis de las métricas se realiza tanto a nivel proyecto como a nivel organizacional.
Cada proyecto es responsable de analizar las métricas, generadas por el mismo en cada
cierre de fase, y comparar los resultados con las metas de calidad del proyecto. En caso
que exista una desviación, se toman acciones correctivas y, si es necesario, se escala al
siguiente nivel. Este análisis se realiza de manera formal en cada cierre de fase, pero los
administradores de proyecto lo realizan durante la fase, lo que permite tomar acciones
anticipadamente y así poder hacerlo de manera oportuna.
32 > OCT-DIC 2004 > www.softwareguru.com.mx
El grupo de métricas realiza el análisis del comportamien-
to de la organización por medio del consolidado de las
métricas definidas en el SQAE para dar seguimiento a las
metas de calidad organizacionales. Con base en éstas se
establecen las metas de los proyectos, las cuales se ajus-
tan de acuerdo a la tecnología y al tipo de proyecto.
Ultrasist cuenta con datos de métricas desde el año 1999,
hecho que nos ha permitido tomar decisiones basadas en
el resultado del análisis de las mismas.
ESTÁNDARES ORGANIZACIONALES
Un elemento importante del SQAE, que facilita la comuni-
cación entre los equipos de trabajo de manera ágil y lleva
a cabo los procesos de manera efectiva, es la definición de
estándares organizacionales, ya que es una buena prácti-
ca, sobre todo cuando intervienen varias personas en el
desarrollo de un trabajo. En la organización se tienen defi-
nidos estándares para nombrar desde los elementos de un
programa hasta los elementos de la red, estándares de
documentación, tanto de proyectos como de procesos,
entre otros.
HERRAMIENTAS
Para hacer eficiente el trabajo hemos integrado herra-
mientas que facilitan la documentación de los procesos
de la organización, el modelado de los sistemas, la sin-
cronización de los modelos con los lenguajes de progra-
mación y las bases de datos, generación automática de
la documentación de los sistemas y la administración y
publicación de los componentes a reusar.
Los criterios principales para elegir las herramientas es
que cumplan con los estándares de vanguardia de la
industria y, sobre todo, que estén al alcance de nuestro
presupuesto.
Bajo esta premisa, adquirimos “Select Component
Factory”, conjunto de herramientas enfocadas al modela-
do que permite a las organizaciones apoyarse en un

desarrollo basado en componentes y entregar sistemas
que cumplen con la evolución de las necesidades del
negocio. La herramienta permite el desarrollo rápido
de aplicaciones de negocio flexibles y escalables a cos-
tos bajos y reduciendo los riesgos.
Con base en nuestra experiencia, podemos decir que
un proceso difícilmente puede llevarse a cabo eficien-
temente sin herramientas, pero su puesta en marcha
debe ser después de haber definido el proceso.
“Se tienen definidos
estándares para nombrar
todos los elementos usados.”
BASE DE CONOCIMIENTO
La organización tiene mecanismos definidos que per-
miten que la experiencia adquirida en los proyectos y
procesos se resguarde en una base de conocimiento, la
cual es accesible y clara para todos. Contar con una
base, adicionalmente nos permite tener de manera
organizada y controlada el conocimiento generado.
La base de conocimiento contiene la información de una
forma consistente y con integridad, adicionalmente es
accesible a todos los miembros de la organización de una
forma rápida e inmediata. Contempla las experiencias
adquiridas, permitiendo clasificarlas de acuerdo a los
intereses de los diferentes grupos, la información de los
proyectos, lo que ha fallado y lo que ha tenido éxito;
información de tecnología, incluyendo los riesgos que
han surgido por utilizar cierta herramienta, lenguaje o
plataforma; información de los modelos construidos y
aciertos en la conformación de equipos de trabajo; pro-
yectos que han estado fuera de presupuesto y por qué;
defectos técnicos más frecuentes y cómo se han solucio-
nado. De esta forma, el conocimiento adquirido no se
queda en los individuos, es un valor de la organización.
Software Guru
HACIA SW-CMM®
En el año de 2003, Ultrasist tomó la decisión de evaluarse bajo el modelo SW-CMM®. Una
vez tomada esta decisión, se efectuó un análisis de brecha de las prácticas establecidas en
la organización con respecto al modelo. Con base en el análisis realizado, y tomando en
cuenta la madurez de los procesos ya implantados, se priorizaron los objetivos con la Alta
Dirección y se elaboró el Plan de Calidad. Se acordó contar durante el proyecto con el apoyo
de Avantare, empresa experta en programas de mejora que cuenta con consultores con
conocimientos y experiencia en SW-CMM® para asegurar el apego al modelo.
Avantare proporcionó un servicio integral, brindando asesoría para la revisión documental
del proceso y la verificación de la implantación.
La estrategia que se utilizó en la organización fue realizar una sesión de trabajo semanal entre
el grupo de procesos y el consultor. Durante la revisión documental del proceso, esta estrate-
gia fue apropiada y ágil porque permitió tener una interacción personal entre ambas partes, en
la que se aclaraban dudas tanto del modelo como del proceso, se acordaban puntos que eran
inmediatos y se dejaban tareas para ser realizadas durante la semana.
La implantación de las mejoras a los procesos se realizó con la misma metodología iterativa e
incremental, es decir, una vez que el proceso se terminaba de revisar contra un área clave del
modelo, la organización iniciaba la implantación del mismo. La verificación de la implantación
se inició una vez actualizado el proceso de aseguramiento de calidad, por lo que esta área fue
una de las primeras en planearse. Para la verificación se asignó un consultor experto en ase-
guramiento de calidad, con el objetivo de verificar el proceso y de capacitar en la práctica a los
responsables de aseguramiento de la calidad. Como uno de los resultados de estas activida-
des, se determinó que la organización estaba preparada para la evaluación formal CBA-IPI
(CMM® Based Appraisal for Internal Process Improvement).
ELEMENTOS INDISPENSABLES
PARA LA PUESTA EN MARCHA
En Ultrasist la puesta en marcha de un ciclo de mejora implicó involucrar a todos los niveles
de la organización. Un elemento indispensable fue el compromiso de la Alta Dirección. Este
compromiso facilitó la implantación y capacitación en el proceso y en las técnicas necesa-
rias, así como la constante asesoría y supervisión. El poder involucrar a toda la organización
se convirtió en el motor para motivar sobre los beneficios que nos brinda el proceso, fomen-
tar el trabajo en equipo, obtener la retroalimentación en las fallas y fortalezas del proceso,
e imponer la disciplina en los grupos de trabajo.
PRÓXIMOS PASOS
Vamos por la I.- En el 2005, Ultrasist hará la transición para alcanzar un buen nivel de
CMMI® (Capability Maturity Model Integrated), para lo cual está trabajando conjuntamente
con Avantare para realizar el análisis de brecha.
Ma. Julia Orozco ocupa la Dirección Técnica
en la empresa Ultrasist. Es Matemática con
estudios de Maestría en Ciencias de la
Computación. Ha impartido cursos en univer-
sidades, gobierno e iniciativa privada y ha sido
ponente en diversos foros internacionales.
Claudia Alquicira trabaja en Avantare
Consultores como consultor en programas de
mejora en organizaciones de desarrollo de soft-
ware. Claudia cuenta con Maestría en Ciencias
de la Computación y sus areas de interés son la
ingeniería de software, calidad y tecnología ori-
entada a objetos.
www.softwareguru.com.mx > OCT-DIC 2004 > 33
 Arquitectura

Entendiendo
PRÁCTICAS

WEB SERVICES y SOA

Por Mauricio Durán y Fernando Gutiérrez

os web services y las arquitecturas orientadas a servicios —SOA por sus siglas
L en inglés— están revolucionando la forma de construir sistemas de software.
Gartner prevé que para el 2006 más de 60% de las empresas basarán sus arqui-
tecturas empresariales sobre estas tecnologías. Sin embargo, muchas organizacio-
nes aún no las entienden bien y están confundidas respecto a sus beneficios y
riesgos. En este artículo revisamos algunos de sus aspectos fundamentales con el
objetivo de entenderlas e identificar sus implicaciones.
SERVICIOS
Estrictamente hablando, un servicio es un trabajo que se
desempeña a favor de un tercero. En nuestras actividades
cotidianas estamos acostumbrados a utilizar todo tipo de
servicios, por ejemplo, el de una cafetería, donde selec-
cionamos una opción del menú, comunicamos nuestra
elección al mesero y pagamos la cuenta.

¿No deberían ser igual de sencillas las cosas en el mundo

La orientación a servicios consiste en
agregar una capa de abstracción que
permita que los objetos se comuniquen
de manera organizada y desacoplada.
del software? ¿Qué pasaría si nuestras aplicaciones actua-
ran como el ejemplo de la cafetería? En este caso habría
un programa proveedor que describiría en un menú sus
servicios disponibles, así como la lista de requisitos para
disponer de ellos. Otros programas cliente serían capaces
de interpretar esta información, invocar el servicio y lograr
así una comunicación exitosa. Un aspecto relevante en
este ejemplo es que el cliente no necesita saber qué accio-
nes va a realizar el proveedor para satisfacer su petición.
En la cafetería los límites son muy claros, todo lo que suce-
de detrás del mostrador es responsabilidad exclusivamen-
te de la cafetería. Usted no va a brincar el mostrador e
irrumpir en estas tareas, ¿cierto? Esta analogía también
aplica a los sistemas, ya que no es recomendable que un
programa invada el dominio de otro. Esta autonomía es un
concepto vital en una arquitectura orientada a servicios.
Los límites deben estar claramente definidos, de tal forma
que los clientes no requieran saber cómo es que un pro-
veedor realiza cierto servicio, sino que solamente se inte-
resen en el resultado.

Estos escenarios son altamente deseables y requieren que

la industria evolucione de un modelo de orientación a
objetos hacia un modelo de orientación a servicios. Esto
no significa que vayamos a desechar el modelo de orien-
tación a objetos. La orientación a servicios simplemente
consiste en agregar una capa de abstracción, la cual per-
mita que los objetos se comuniquen de manera organiza-
da y desacoplada, logrando así que estos objetos sean
más entendibles, flexibles y útiles para el negocio.

34 > OCT-DIC 2004 > www.softwareguru.com.mx


WEB SERVICES
Tradicionalmente hemos utilizado diversas alternati-
vas para intercomunicar sistemas: sockets, acceso
directo a las bases de datos, o mecanismos como
RMI, CORBA o DCOM, con los cuales es posible lograr
la interoperabilidad deseada, pero a costa de un alto
acoplamiento. Otra desventaja de estas tecnologías
es que ninguna es considerada como un estándar en
la industria.
Esta situación llevó a las principales empresas de la
industria a trabajar en conjunto para definir un grupo
de estándares que permitiera homogeneizar la forma
en que los sistemas interactúan a través de servicios.
Este conjunto de especificaciones definen lo que
conocemos como web services, y son administradas
por organismos de estándares como el World Wide
Web Consortium (WC3), y OASIS. Los principales ele-
mentos de esta plataforma son los siguientes:
UDDI (Universal Description, Discovery and
Integration).- Es un mecanismo para encontrar web
services. Si tomamos en cuenta que cualquier persona
puede escribir un servicio y publicarlo, entonces nos
enfrentamos a la necesidad de contar con un directorio
que nos permita tanto publicar como buscar los servi-
cios que nos interesan. Por ejemplo, si queremos agre-
gar a nuestro sitio web un recuadro que indique las
condiciones de clima actuales, podemos ir a un direc-
torio de servicios como el provisto por Microsoft en
http://uddi.microsoft.com/search/ y buscar un servi-
cio utilizando la palabra “clima”. Este es un ejemplo de
un directorio público, pero también hay directorios pri-
vados para uso exclusivo de una organización.
WSDL (Web Service Definition Language).- Define las
reglas que deben de seguir los documentos que des-
criben un web service. Estos documentos contienen
información como tipos de datos, mensajes y proto-
colos soportados por el servicio. Continuando con el
ejemplo anterior del servicio del clima, sería en este
documento donde se especifiquen los diferentes
métodos para obtenerlo y la información que debe-
mos enviar como parámetro. Quizá uno de los méto-
dos nos pida un código postal, mientras otro solicite
la ciudad, estado y país.
SOAP (Simple Object Access Protocol).- Hasta ahora
hemos listado los estándares que rigen la búsqueda
y descripción de un web service. El siguiente paso es
acordar las reglas que deben seguir los mensajes, o
sea, el protocolo de comunicación. Esto es lo que
resuelve SOAP, que es un protocolo sencillo y no
abarca temas como seguridad o confiabilidad de
mensajes, ya que éstos son abarcados en otras espe-
cificaciones como WS-Security o WS-Addressing.
En resumen, un web service es una aplicación que
puede ser accesada usando los estándares descritos
anteriormente. Probablemente notaron que ninguna
de estas definiciones menciona plataformas ni len-
guajes de programación. Esto es debido a que la prin-
cipal idea detrás de un web service es que sea
independiente de las tecnologías utilizadas por el
proveedor y consumidor.
Software Guru
SOA
¿Por qué surge la necesidad de una arquitectura enfocada a servicios?
La principal meta de de los sistemas de información de una empresa es alinearse con la estra-
tegia de negocios de la misma. El éxito de un sistema es medido en términos de los beneficios
que genera al negocio mediante la automatización de procesos. En el mundo actual de nego-
cios, los procesos se encuentran en cambio constante, así que la capacidad para adaptarse a
estos cambios es un factor vital para el éxito. Es aquí donde surge la necesidad de crear arqui-
tecturas orientadas a servicios, que sean multiplataforma, basadas en estándares y, sobre
todo, que sean ágiles, o sea, que fácilmente puedan adaptarse a cambios.
¿Qué es SOA?
La Arquitectura Orientada a Servicios (SOA) es un patrón arquitectónico para diseñar sistemas
de tipo petición/respuesta. Consiste en lograr que las aplicaciones expongan su funcionalidad
como servicios, y que éstos interactúen de manera flexible y no intrusiva. Es aquí donde los
web services juegan un rol importante, debido a que proveen los mecanismos necesarios para
que esta arquitectura sea exitosa en ambientes heterogéneos. Una arquitectura orientada a
servicios no forzosamente debe ser implementada a través de web services, pero suele ser una
buena opción, ya que, después de todo, fueron diseñados con este propósito.
La Figura 1 muestra un modelo muy básico de una arquitectura orientada a servicios. En él
podemos identificar los roles de consumidor y proveedor, además de un tercer tipo de entidad
que representa el directorio de servicios.
El consumidor del servicio primero realiza una búsqueda en el UDDI Registry y obtiene la infor-
mación necesaria para llamar al proveedor de servicios B. A su vez, B busca y solicita un ser-
vicio a C para poder satisfacer la petición de A.
Aplicación A Aplicación B Aplicación C
Solicitud Solicitud
Consumidor/ Servicio
Consumidor
Servicio
Respuesta Respuesta
Búsqueda UDDI Búsqueda
Registry
Figura 1
Anatomía de una aplicación orientada a servicios
Cada una de estas aplicaciones deberá estar compuesta por diferentes capas, como lo mues-
tra la Figura 2. Un servicio puede tener clientes internos, por ejemplo, la capa de interfaz de
usuario de la aplicación, o también clientes externos, como una aplicación de otra empresa.
Ambos tipos de cliente pueden accesar la capa de servicios de igual forma, sin importar las
tecnologías con que fueron desarrollados. Además, pueden notar que la capa de UI de la apli-
cación también puede realizar llamadas directamente a los componentes de negocio, en caso
de ser necesario.
www.softwareguru.com.mx > OCT-DIC 2004 > 35
 Arquitectura

Aplicación Externa

Esta arquitectura permitirá que los sistemas “legacy” Consumidor del Web
sean envueltos en una arquitectura de servicios y pue- Service
dan ser aprovechados.

Aplicación

Capa de Interface Capa de Servicios

de Usuario

Objetos de Negocio
PRÁCTICAS

Repositorio Aplicación “Legacy”

Figura 2
de Datos

Retos de SOA
SOA implica nuevos retos y consideraciones para quienes
desarrollamos sistemas empresariales. Debemos apren-
der a diseñar e implementar servicios autónomos y con
bajo acoplamiento. Esto se refiere a que no podemos asu-
mir nada acerca de los consumidores de un servicio. La
esencia de un servicio está en su capacidad para ser reu-
tilizado en contextos desconocidos. Si no ponemos el bajo
acoplamiento como prioridad, generaremos aplicaciones
monolíticas y desaprovecharemos los beneficios potencia-
les de SOA.
El bajo acoplamiento habilita la reutilización pero aumen-
ta la complejidad. Un caso común es que en la aplicación
A el término “orden de compra” puede referirse a algo muy
diferente que en la aplicación B. Es por esto que es común
que el ensamble de servicios requiera elementos que fun-
cionen como adaptadores y provean un contexto común.
Otro elemento a tener en cuenta es la dificultad para pro-
bar estos sistemas. Al no tener control sobre el ambiente
ni clientes de un servicio, el diseño y ejecución de pruebas
debe ser muy completo y adquiere gran complejidad.
¿Por dónde empezar?
Los principales proveedores de software están convenci-
dos de que Web Services y SOA son el camino a seguir,
así que están fomentando el uso de estas tecnologías y
proveen muchos recursos para comenzar. Aunque uno de
los grandes objetivos de web services y SOA es la inte-
racción independiente de plataforma, a fin de cuentas es
necesario implementar los programas en algún lenguaje
de programación. En el caso de utilizar tecnología
Microsoft, su primera fuente de referencia debe ser el
Web Services Developer Center (http://msdn.micro-
soft.com/webservices), donde encontrará material de
referencia, tutoriales y las noticias más recientes.
También recomendamos ampliamente el libro de Jeffrey
Hasan, listado en las referencias.
Para implementación en J2EE, sugerimos los sitios para
desarrolladores de IBM (http://www.ibm.com/developer-
works/webservices) y Sun (http://java.sun.com/webser-
vices) donde podrá obtener kits de desarrollo, tutoriales y
ejemplos.
CONCLUSIONES
La mesa está puesta para que comencemos a explotar
estas tecnologías y construyamos mejores sistemas. En
este artículo platicamos algunos conceptos básicos y
esperamos haber despertado interés en este tema que
está revolucionando la industria y del cual seguramente
no querrá quedarse fuera.
Mauricio Durán es arquitecto de software espe-
cializado en tecnologías Microsoft con más de 6
años de experiencia en desarrollo de software a
la medida. Mauricio es fundador de Sieena
Software, empresa basada en Monterrey, N.L.,
dedicada a proveer servicios de tecnología a
empresas de México y Estados Unidos.
Fernando Gutiérrez es arquitecto de software y
co-fundador de Sieena Software. Fernando
tiene experiencia trabajando con un amplio
espectro de tecnologías, y conoce a profundidad
J2EE y el .NET Framework.
Referencias
Hasan, Jeffrey. Expert Service-Oriented
Architecture in C#. APress, 2004.
Natis, Yefim & Roy Schulte. Introduction to
Service-Oriented Architecture. Gartner, 2003.

36 > OCT-DIC 2004 > www.softwareguru.com.mx

PRÁCTICAS Requerimientos
CASOS DE USO
LO MÁS IMPORTANTE Y MENOS ENTENDIDO DE UML
por Roberto Silva
ace ya varios años, un consorcio internacional llamado Object Management Group
H (www.omg.org), publicó el Unified Modeling Languaje (UML), el estándar interna-
cional para el modelado de sistemas de software. El UML ha revolucionado a la indus-
tria en muchos aspectos. Sin embargo, uno de sus bloques de construcción más
importantes es, tal vez, el menos comprendido. Me refiero al Caso de Uso (CU).
Cuando los Casos de Uso son bien aplicados, las probabilidades de éxito de los pro-
yectos de ingeniería de software se incrementan de manera importante. Este artículo
está dividido en dos secciones. En la primera, trataré de convencerlos de la gran
importancia de la aplicación correcta de los Casos de Uso. En la segunda parte utili-
zaré antipatrones, aunque de manera informal, para ayudarles a identificar y evitar
los tres errores más graves, cometidos durante el análisis, modelado, y especificación
de requerimientos.
IMPORTANCIA
DE LOS CASOS DE USO
Expertos —Boehm y Papaccio— y analistas —Standish
Group— de la industria, coinciden acerca de una reali-
dad muy desafortunada: los errores más comunes y de
mayor impacto negativo en el resultado de los proyectos
de software son cometidos durante el desarrollo de
requerimientos.
Los Casos de Uso representan las condiciones y capaci-
dades que el sistema de software deberá cumplir y tener
respectivamente, desde el punto de vista funcional. El
modelo de Casos de Uso nos permite visualizar el alcan-
ce del sistema en términos de los servicios que ofrece a
sus usuarios, que en UML son llamados Actores.
Además, los Casos de Uso son las únicas piezas de infor-
mación utilizadas por todos los partícipes (stakeholders)
del sistema de software.
En promedio, 30% del total de lo que terminan costando
los proyectos de software es utilizado únicamente para
resolver problemas, que fueron generados desde etapas
tempranas del proyecto, durante el desarrollo de requeri-
mientos. Lo más grave es que todo este esfuerzo correcti-
vo no agrega valor al resultado final del proyecto, y tira a
la basura una gran cantidad de dinero.
38 > OCT-DIC 2004 > www.softwareguru.com.mx
ERRORES GRAVES
Y COMUNES DE LOS MODELOS
DE CASOS DE USO
Descomposición Funcional.- Es muy común caer en des-
composición funcional al momento de identificar Casos de
Uso. Cuando hay Casos de Uso que han sido definidos en
términos de las típicas funciones de un sistema de softwa-
re, es cuando hemos caído en la trampa de las analogías.
Un Caso de Uso es una abstracción de funcionalidad ofre-
cida por un software orientada a un Actor. Un Actor es una
persona, dispositivo u otro sistema que actúa sobre el sis-
tema de software, porque éste le permitirá o le facilitará el
logro de un objetivo específico. Los Actores interactúan
con el sistema para conseguir un resultado observable y
de valor. Es por esto que se llaman Casos de Uso; cada
uno de ellos representa una razón —el objetivo— para uti-
lizar el sistema de software.
Por ejemplo, si un sistema de software está determinado
por veinte Casos de Uso, significa que hay veinte objetivos
que podrán ser conseguidos interactuando con él, veinte
casos en donde tendrá sentido usarlo; no significa que
sólo es capaz de ejecutar veinte funciones.
Flujo de Datos.- Otra trampa de las analogías es interpre-
tar la relación entre un Caso de Uso y un Actor como un
flujo de datos, cuando su semántica es otra muy diferen-
te. De hecho, el diagrama que contiene estas relaciones es
un diagrama estático, que nos permite visualizar el alcan-
ce del sistema de software en términos de sus servicios y
sus consumidores correspondientes.
En muchas ocasiones este error de interpretación es cau-
sado cuando tenemos una asociación unidireccional —
una flecha—, ya que estamos acostumbrados a
interpretar las flechas como flujos de información o men-
sajes. Cuando nuestro objetivo sea modelar este tipo de
elementos dinámicos hay que utilizar otros diagramas de
UML más adecuados para dicho fin, tales como diagramas
de actividades, secuencia o de colaboración.
 Software Guru

La interpretación correcta de la asociación entre un Actor y un Caso de Uso es simplemente “comu-

nicación”; la relación de asociación representa el canal de comunicación que permite entablar un
diálogo entre el Actor y el Caso de Uso. La flecha hay que interpretarla simplemente como una res-
tricción en la comunicación en el sentido al que apunta. Por ejemplo, si la asociación va del Caso de
Uso hacia el Actor, significa que el Actor nunca inicia la comunicación, siempre lo hace el software.

Una manera mas sencilla de entender la relación entre un Caso de Uso y un Actor es la siguiente:
veamos al Caso de Uso como un contrato de servicio, al Actor como el cliente del servicio y a la aso-
ciación como el medio de entrega del servicio.

Sistema
Cliente
Retirar Efectivo Bancario

Cliente selecciona Retirar Efectivo

Sistema despliega cantidades disponibles Sistema transmite petición de retiro
Cliente Selecciona cantidad a retirar Sistema bancario acepta petición
Sistema depliega confirmación de operación
Sistema entrega efectivo

Mezclar el “Qué” con el “Cómo”.- Uno de los errores más graves es mezclar el “qué” y el “cómo”
del sistema. Si un Caso de Uso es un contrato de servicio, ¿quién es el responsable de realizar dicho
servicio cuando es requerido? En UML se le llama Realización de Caso de Uso, mejor conocida como
Colaboración.

Una Realización de Caso de Uso es un conjunto de objetos que colaboran entre sí para lograr un
resultado observable y de valor para el Actor. Es decir, la Colaboración nos muestra el “cómo” res-
ponderá el sistema al flujo de eventos generados durante el diálogo entre el Caso de Uso y el Actor.
Por consecuencia, el Caso de Uso es el “qué” del sistema; al definir lo que él deberá ser capaz de
realizar para permitir al Actor lograr un objetivo específico usando el sistema de software. Por eso
se llaman Casos de Uso y para eso se inventaron.

Los Casos de Uso obligan al analista de sistemas a separar el “qué” del “cómo”, ya que sólo el pri-
mero es su responsabilidad. El segundo es responsabilidad del arquitecto o diseñador de software.
El analista de sistemas opera en el espacio del problema; el arquitecto o diseñador en el espacio de
la solución.

Lo que hay que evitar es incluir en la Especificación de Caso de Uso elementos del interior del sis-
tema; sólo debemos incluir detalles relevantes y necesarios para entender el diálogo. Hay que ver
al sistema de software como caja negra, abstrayendo su interior mientras se define perfectamente
bien el objetivo y el medio de entrega del servicio correspondiente.

Si primero definimos los ingredientes del platillo que debemos preparar, seguramente no tendre-
mos éxito ofreciendo el servicio de lavado de coches. Primero hay que definir el problema correcto
y lograr un consenso entre todos los partícipes del sistema, después hay que especificar los reque-
rimientos de una solución adecuada —el “qué”—, para poder continuar con el diseño y construc-
ción de la solución —el “cómo”.

Roberto Silva es Fundador y Director de Desarrollo de Negocio

en Impulsare, empresa dedicada a la educación y consultoría en
BPM. Dedicó aproximadamente diez años a la integración y desa-
rrollo de sistemas de software empresariales. Entre sus intereses
actuales están la investigación y arquitectura de software comer-
cial. Estudió Actuaría en la UNAM y cuenta con certificaciones
internacionales otorgadas por IBM-Rational.

www.softwareguru.com.mx > OCT-DIC 2004 > 39

PRÁCTICAS Usabilidad
USABILIDAD
CUESTIÓN DE PERCEPCIÓN, EFECTOS Y FRUSTRACIÓN
por Dámaso Canales
a Usabilidad es una práctica que estudia la relación entre las herramientas y sus
L usuarios. Para que una herramienta sea efectiva, debe permitir a sus usuarios rea-
lizar las tareas de la mejor manera posible. En este artículo revisaremos tres concep-
tos relacionados con la Usabilidad: la percepción, el efecto y la frustración.
PERCEPCIÓN
Para los que nos encargamos de analizar, evaluar y definir guías, directrices y estándares de
Usabilidad y de DCU (Diseño Centrado en el Usuario) de productos de desarrollo, es impor-
tante garantizar por medio de metodologías y prácticas la satisfacción de los usuarios,
midiendo su percepción al usar los productos. El aplicar controles de Usabilidad en las dife-
rentes fases de desarrollo de un producto nos da la ventaja de lograr soluciones robustas
que cuenten entre otras cosas con: una mayor rapidez de adopción; una fácil transmisión
de conocimiento del sistema a la cultura diaria de trabajo; una eliminación de los riesgos de
percepción del producto; y un aumento de credibilidad sobre el valor del producto.
Las metodologías de Usabilidad y DCU que cubren el desa-
rrollo del producto van desde la concepción hasta la entre-
ga final y el uso del producto frente al usuario. Por lo
general éstas inician con el análisis de los objetivos de la
organización a través de tareas, y terminan evaluando la
satisfacción del usuario. Algunos ejemplos de técnicas
simples son las evaluaciones heurísticas y cuestionarios
como Computer System Usability Questionnaire o After
Scenario Questionnaire; otras más complejas incluyen los
estándares de iure o de facto, que intervienen mayormen-
te en la definición del producto o en la evaluación de los
Recorridos por Expertos de Usabilidad.
La percepción del
usuario garantiza la
permanencia de los
productos en las
organizaciones.
40 > OCT-DIC 2004 > www.softwareguru.com.mx
En México el nivel de madurez de los productos de software
en cuestión de diseño de Usabilidad y DCU es limitado, ya
que la mayoría de los productos no cuentan con un análisis
formal realizado por un experto. La mayoría de las veces esta
especialidad la cubren parcialmente los analistas, líderes de
proyecto, administradores, diseñadores o encargados del
marketing que aisladamente conciben la realización de pro-
ductos bajo la visión limitada de sus respectivas áreas, como
funcionalidad, efectos visuales, mensajes etc. y no a satis-
facción de la percepción del producto.
Actualmente en algunos productos se pueden ver deste-
llos iniciales de una preocupación por garantizar esta
satisfacción. Con esto quiero dividir la satisfacción funcio-
nal del producto con la satisfacción de percepción del
usuario. Podemos asegurar que la mayoría de los produc-
tos mexicanos cuentan para su realización con equipos
sofisticados para analizar, diseñar y evaluar funcionalidad,
pero esto sólo cubre la mitad del producto, la otra mitad,
y no por ello menos importante, es la percepción del usua-
rio. Esta mitad es la que garantiza la permanencia de los
productos en las organizaciones; de nada sirve tener un
sistema con todas las capacidades requeridas para la
organización si el producto es percibido como un produc-
to inconsistente, inestable o inútil debido a la percepción
y expectativas que se tengan de él.
Por lo general no se analiza la percepción del usuario
desde las fases iniciales del desarrollo de los productos y
comienzan los problemas cuando ya entregado el produc-
to empiezan a notarse las inconformidades que, muchas
veces, no se pueden detectar o son filtradas por el poco
interés ocasionado por la primera impresión del producto.
Algunos expertos de Usabilidad, como Loren Burke, se
concentran principalmente en el factor de la Primera
Impresión, ya que es determinante controlar La Ventana
de Juicio en la que se enfrenta el usuario al producto, por-
que así se asegura una primera reacción de satisfacción
favorable, que sucede en los primeros segundos, donde
se acepta o rechaza definitivamente un producto.
 Software Guru

efectos vs Efectos
Hablando de sistemas Web que fácilmente están accesibles a muchos y muy distintos perfiles de
usuario, podemos notar que en México tienden a los efectos y no a los Efectos. Por efectos debe-
mos entender los elementos inherentes al producto, como la funcionalidad, la complejidad visual,
Mensajes y Marketing. Por otro lado, los Efectos son reacciones y cambios ocasionados sobre el
usuario: expectativas, percepción, satisfacción, memoria y eficiencia.

Actualmente son pocos los sitios Web que alcanzan a satisfacer y a facilitar el uso de la información.
Se enfocan más en cumplir con los requerimientos funcionales, estéticos y de marketing que en faci-
litar el entendimiento de acceso y control que pueda tener el usuario sobre la navegación, valor y
servicios que ofrece el sitio Web.

FRUSTRACIÓN
Para los usuarios, que son quienes determinan el éxito o fracaso de un sistema, es importante sen-
tir la confianza y control. Cuando no se domina al sistema, el usuario comienza a sentir frustración
por no poder desplazarse en él o por no poder cumplir con las tareas, esto conlleva al malestar y al
rechazo de usarlo, o a suplirlo por otro que tengan a la mano. Cuando el uso del sistema es obliga-
torio y no hay métodos alternativos, termina desgastando además su productividad y reduce la efi-
ciencia y eficacia sobre los resultados de la organización.

A pesar de las ventajas que ofrece el análisis y diseño basado en Usabilidad, en México se siguen
desarrollando productos sin considerar, de manera profesional, este importante factor. La calidad
de un software de clase mundial se verifica en lo que los usuarios perciben de él, y esta percepción
radica en la forma de usar el sistema. Los usuarios son parte integral de un Sistema de Información.
Ya va siendo hora de que los involucremos en el desarrollo de los mismos, para que los sistemas
dejen de ser cuerpos extraños y pasen a formar parte integral de la vida organizacional desde el pri-
mer momento en que el usuario tiene contacto con él.

Referencia:
Krug, Steve & Roger Black. Don't Make Me Think: A Common
Sense Approach to Web Usability. New Riders, 2000.
Recursos en línea “Usability First”
www.usabilityfirst.com

Dámaso Canales es consultor especializado en identidad corporativa y

diseño centrado en el usuario. Ha participado en el desarrollo de aplica-
ciones para clientes como IBM, Sun, Banorte y PEMEX. Actualmente
es Director de Intuisystems, empresa dedicada al desarrollo de soluciones
tecnológicas centradas en la experiencia del usuario.

www.softwareguru.com.mx > OCT-DIC 2004 > 41

COLUMNA Cátedra y Más
Industria de Software en México…
¿PODRÁ PROSOFT?
l ambiente global de la actualidad trae consi-
E go grandes retos de competencia. Ésta no
sólo se da entre compañías, sino también entre
naciones y bloques de ellas. En el pasado, las
posibilidades de un país para desarrollar su eco-
nomía se basaban en factores como abundancia
de recursos, posición geográfica o mano de obra
barata, pero estas ventajas ya no resultan deter-
minantes. La abundancia de recursos pierde fuer-
za conforme las transacciones económicas de
servicios se imponen sobre la base de manufac-
tura; la baja en los costos de distribución minimi-
zan las ventajas geográficas; y la mano de obra
barata presenta una ventaja mínima para atraer
inversión extranjera de maquila. En medida que la
sociedad basa sus actividades en el conocimien-
to, el capital intelectual cobra una mayor impor-
tancia como ventaja competitiva nacional.
Esto nos lleva a la reflexión sobre la posición de
México ante el mundo y los retos que debe
enfrentar para buscar un desarrollo sustentable.
Tradicionalmente, este país ha dependido de su
abundancia de recursos, como el petróleo, para
posicionarse en el mercado global. Igualmente,
ha atraído de manera volátil a la industria
maquiladora al ofrecer la frágil ventaja de la
mano de obra barata, y su posición geográfica le
ha servido como puente entre América Latina y
Estados Unidos.
Sin embargo, nuestro país ha perdido vertigino-
samente su competitividad al no poder compa-
rarse en costo con otras economías emergentes,
como China; provocando que los productos
nacionales sean desplazados por aquellos pro-
ducidos en países con condiciones de menor
costo. ¿Qué rumbo debe entonces tomar nuestro
país? ¿Por qué no hemos podido consolidar
nuestra economía siendo que tenemos las venta-
jas antes citadas? Las respuestas pueden ser
muchas, pero es en estos momentos donde nos
conviene analizar casos de éxito en transforma-
ción de competitividad nacional por parte de paí-
ses que tenían condiciones inferiores de
competencia a las de nuestro país.
Un ejemplo es Singapur, país que hasta hace unas
décadas se caracterizaba por ser sólo una colonia
con un puerto. Su geografía no le representaba
ventaja alguna, al ser una isla pequeña y monta-
ñosa sin recursos naturales considerables. Su
demografía tampoco se podría considerar una
ventaja, ya que su población está compuesta por
tres etnias diferentes: india, malaya y china, que
42 > OCT-DIC 2004 > www.softwareguru.com.mx
hablan lenguajes distintos y profesan religiones para hacerlos más eficientes. Esto se acompañó
diferentes. Estas condiciones hacen pensar que
existían los elementos esenciales para un cóctel
de incentivos fiscales apropiados y alianzas con
miembros clave de la industria de Tecnología de
molotov, ya que se trataba de un país dividido y Información (TI).
joven, sin experiencia para gobernarse por sí
mismo. ¿Cómo entonces llegó esta nación a cons- El programa ProSoft tiene consideraciones en
tituirse en la potencia económica que es hoy? La cuanto a la formación del capital intelectual
respuesta radica en el establecimiento de una necesario. Igualmente, maneja provisiones para
estrategia nacional para lograr competitividad por incentivar la participación de miembros clave en
medio de tecnologías de información en su único la industria de TI. Sin embargo, sin una apropia-
recurso: el manejo portuario. da articulación y facilitación de los procesos, el
esfuerzo del programa puede perder todo su
También es digna de mencionar la transforma- momento y convertirse en un juego de suma
ción de Irlanda de una economía agraria a una cero, donde todos los participantes se queden
potencia de la industria de software. Igualmente con las manos vacías al intentar obtener benefi-
podemos observar el surgimiento de Finlandia cios máximos inmediatos, sin tener una visión a
como potencia en tecnologías móviles. Parece largo plazo.
ser que en México por fin nos “ha caído el vein-
te”. Ahora vemos que no podremos mantener las Organizaciones como la Asociación Nacional de
condiciones de vida de nuestra gente si conti- Instituciones de Educación en Informática (ANIEI),
nuamos con un pensamiento competitivo basado el Instituto Latinoamericano de la Comunicación
en factores tradicionales. Un esfuerzo loable en Educativa (ILCE) y la Asociación Mexicana de la
este rubro es el programa ProSoft, cuyo fin último Industria de las Tecnologías de Información
es desarrollar en México una nueva ventaja com- (AMITI), han presentado iniciativas ante la
petitiva, basada en capital intelectual de alta cali- Secretaría de Economía para impulsar la vincula-
dad, capaz de competir con las naciones líderes ción entre los sectores educativo, empresarial y
en esta industria. gubernamental. Dicha vinculación es un factor
clave para que las empresas de tecnología en
Pero, ¿será un paquete de buenas intenciones o México se conviertan en productores en vez de
realmente logrará su objetivo? Lo cierto es que no distribuidores. También ayudaría a disminuir el
es cuestión únicamente de generar un programa costo de capacitación, para generar mejores pro-
con buenas ideas, sino de crear el entorno que fesionistas. Pero lograr una relación efectiva entre
garantice su desempeño exitoso. En Singapur no los sectores requiere simplificación administrati-
sólo crearon un programa que automatizara los va, poner los intereses inmediatos a un lado sin
procesos del puerto marítimo; el éxito del sistema sacrificar los de largo plazo y aprender a vivir en
TradeNet© de Singapur es el resultado de una comunicación y coordinación. Nuestra corta his-
estrategia de años, donde se identificaron las toria democrática nos ha mostrado que aún no
condiciones necesarias y se apostó todo a gene- sabemos hacer eso, lo malo es que se nos está
rarlas. Así, el sistema educativo se transformó acabando el tiempo porque nuestros competido-
radicalmente; se declaró al inglés como el idioma res no nos tendrán tregua. ¿Aprenderemos? Yo
oficial comercial y se le enseñó a toda la pobla- espero que sí. ¿Y usted, estimado lector?
ción; se transformaron los procesos burocráticos Guillermo Rodríguez
El Dr. Guillermo Rodríguez es Director del Departamento de
Sistemas de Información en el Tecnológico de Monterrey, Campus
Estado de México, donde se especializa en temas como Sistemas
Estratégicos, Administración del Conocimiento y Transferencia de
Tecnología. Guillermo participa de manera continua en conferen-
cias internacionales, y en 1999 recibió el reconocimiento a la mejor
conferencia en el Americas Conference on Information Systems. Es
presidente fundador de la Asociación de Sistemas de Información
de América Latina y el Caribe y miembro activo de la Association
for Information Systems.
 Software Guru

HP

iPaq 4150
Ligera, elegante y accesible sería una definición ade-
cuada para la iPaq 4150 de HP. Su rendimiento ha sido
modificado por los ingenieros de Hewlett-Packard para
garantizar la productividad del usuario en cualquier
condición. El sistema Windows Mobile, puertos Wi-Fi y
Bluetooth garantizan su conectividad, y la ranura para

GADGETS
tarjetas Secure Digital, la hace escalable y permite res-
paldar la información.

Apple

iMac G5
El rediseño de la popular iMac va más allá de
lo estético. La innovadora arquitectura del
procesador G5 se incorpora a un diseño que
integra el CPU a un monitor LCD de pantalla
plana y formato 16:9 (widescreen). Los mode-
los disponibles por el momento cuentan con
procesadores a 1.6 ó 1.8GHz, 256MB en RAM,
discos duros de 80 y hasta 160GB, unidad
DVD-ROM/CD-RW o Superdrive (DVD-R/CD-
RW), tres puertos USB, dos Firewire y uno
mini-VGA. Con un precio inicial de $1,299.00
dólares, esta nueva iMac es ideal para disfru-
tar de toda la gama de programas de utilidad
y entretenimiento que ofrece Apple, además
es una excelente opción para desarrolladores.

Lexar
4 Gigabyte
Los medios de almacenamiento siguen rom-
piendo los cánones reduciendo su tamaño e
incrementando drásticamente su capacidad.
La nueva Compact Flash II con 4GB es ideal
para almacenar todo tipo de archivos, desde
las fotografías tomadas con una cámara digi-
tal hasta documentos generados en una
handheld. Un pequeño disco duro que cabe
en la palma de la mano y que permite trasla-
dar información de un dispositivo a otro sin
estorbosos cables ni complicaciones.
Canon
Digital Rebel
Imágenes nítidas, colores excelentes y un fácil
manejo es lo que busca toda persona que tenga por
hobby la fotografía. La Canon Digital Rebel brinda la
calidad que la empresa dio a sus modelos Rebel de
35 mm con todas las bondades de la tecnología
digital. Viene con un sensor óptico de 6.3 megapixe-
les, procesador de imagen DIGIC y la compatibilidad
con más de 50 lentes EF de Canon. Trae consigo
una unidad para tarjetas Compact Flash y varios sis-
temas de enfoque y exposición. Tan fácil de usar
que no habrá límites para la creatividad.

www.softwareguru.com.mx > OCT-DIC 2004 > 43

 * BTPM
BIBLIOTECA
enter
CC2
CODE COMPLETE 2
SEGUNDA EDICIÓN
Steve McConnell
Microsoft Press, Junio 2004
Steve McConnell es una de esas escasas personas capaces de poner en práctica conceptos
complejos y al mismo tiempo explicarlos de manera sencilla
para nosotros los mortales. En 1993 publicó Code Complete,
que es reconocido como una de las biblias en desarrollo de
software. Ahora, este clásico ha sido revisado y actualizado,
e incluye prácticas y tecnologías modernas. Es de esperarse
que esta nueva edición mantenga al libro como el estándar
en el campo.
Algunos de los temas que se abordan en Code Complete 2:
• Administración de requerimientos de software.
• Elementos comunes de la arquitectura de software.
• Retos comunes en el diseño de software y técnicas
para superarlos.
• Uso adecuado de la orientación a objetos.
• Mejores prácticas para programación.
• Técnicas para mejorar la calidad del software.
• Consideraciones para administrar proyectos de software.
• Herramientas para desarrollo de software.
El siguiente comentario de Richard Mateosian describe
adecuadamente este documento:
“Para quienes aspiran a ser programadores
profesionales, este libro puede ser la mejor inversión que
hagan. McConnell se propone reducir la brecha entre el
conocimiento de los gurús de la industria y las prácticas
diarias de la mayoría de los desarrolladores. Para
lograrlo, pretende explicar todas las cosas importantes
que estos gurús saben sobre construcción de software.
Y sorprendentemente… lo logra.”
En conclusión, Code Complete 2 debe ser una parte esen-
cial de tu biblioteca personal. Tanto si eres un novato que
comienza su carrera en el desarrollo de software, como si
eres un venerable anciano que asesora y enseña a otros.
En ambos casos, CC2 pone a tu disposición un sinfín de
mejores prácticas para desarrollo de software. Como decía
un compañero de la universidad: “¡aquí está la ciencia!”
44> OCT-DIC 2004> www.softwareguru.com.mx
BREAKTHROUGH TECHNOLOGY
PROJECT MANAGEMENT
Bennet P. Lientz y Kathryn P. Rea
Academic Press, Enero 2001
Tal vez les resulte sorprendente que reseñemos un
libro presentado al mercado hace tres años, lo cual
en nuestra industria acostumbra ser toda una eter-
nidad. Sin embargo, el contenido de Breakthrough
Technology Project Management permanece vigen-
te y es de gran utilidad.
Existen diversas referencias sobre administración de
proyectos, pero hay pocas específicas para proyectos
de sistemas. Además, la mayoría se quedan en la teo-
ría y sólo mencionan qué es lo que hay que hacer, pero
no brindan ayuda de cómo hacerlo. Este libro es la
excepción, ya que su gran valor reside en los tips, line-
amientos y lecciones aprendidas, enfocadas específi-
camente a proyectos de sistemas.
El libro está dividido en cuatro partes. La primera
explica diferentes estrategias para administrar proyec-
tos y cómo lidiar con la administración de varios pro-
yectos simultáneos. En la segunda parte los autores
explican cómo arrancar proyectos y abundan sobre
todo lo que esto conlleva, desde cómo hacer una pla-
neación efectiva hasta cómo conseguir al personal
adecuado. La tercera parte lidia con la ejecución de los
proyectos. Hay un capítulo para proyectos de desarro-
llo de aplicaciones nuevas, otro para la operación y
mantenimiento de aplicaciones existentes, y uno más
sobre implantación de paquetes configurables, como
es el caso de los ERPs. Por último, la cuarta parte es
una lista de problemas comunes en proyectos de sis-
temas, y recomendaciones para resolverlos. Por ejem-
plo, ¿qué hacer cuando el área de negocio cambia los
requerimientos frecuentemente? ¿Cómo lidiar con
personal que se resiste a aprender nuevas habilida-
des? ¿Qué hacer cuando el proyecto depende comple-
tamente de un proveedor externo?
El autor principal es Bennet Lientz, uno de los líderes
de proyecto del desarrollo de ARPANET, la base de lo
que hoy es el Internet, así que es alguien que real-
mente sabe de lo que habla.
Recomendamos ampliamente este libro a cualquiera
que administre proyectos de sistemas. Es de especial
ayuda para quienes ya cuentan con conocimientos
generales de administración de proyectos y quieren
aprender a administrar proyectos de tecnología.
 FUNDAMENTOS
Clasificando
los requerimientos de software
A l obtener y capturar los requerimientos de
un sistema es difícil saber si ya se tienen
contemplados todos los requerimientos nece-
sarios, así como poder agruparlos en categorías
que simplifiquen su administración. Un modelo
para categorizar los requerimientos nos permite
tener requerimientos más completos y mejor
organizados.
Típicamente se manejan dos grandes grupos de
requerimientos:
• Funcionales.- Especifican servicios que el sis-
tema debe proveer a sus usuarios.
• No funcionales.- Restricciones de ejecución u
otros atributos en el ambiente del sistema.
No obstante, esta categorización se queda bas-
tante corta y no es suficientemente útil. Es por
eso que hay otros modelos más completos. Tal
es el caso del modelo FURPS+, cuyo nombre es
un acrónimo en inglés de las diferentes catego-
rías (Functionality, Usability, Reliability,
Performance, Supportability). Este modelo fue
desarrollado por Robert B. Grady de Hewlett-
Packard hace más de diez años, y en la actuali-
dad es uno de los más utilizados.
Revisemos las distintas categorías:
• Funcionalidad.- Estos requerimientos repre-
sentan las características centrales del produc-
to. Describen qué es lo que un usuario debe ser
capaz de hacer a través del sistema de softwa-
re; por ejemplo, agregar un cliente nuevo o
registrar una orden de compra. En esta catego-
ría también se incluyen capacidades como
impresión, reporteo y seguridad.
• Usabilidad.- Es posible que cierto software
posea toda la funcionalidad requerida, pero si
es una pesadilla usarlo entonces no va a servir
de mucho. La facilidad de uso o “usabilidad”,
incluye todos aquellos atributos que facilitan la
interacción de un usuario con el sistema.
Ejemplos de requerimientos de usabilidad pue-
den ser la organización de los elementos visua-
les para facilitar su legibilidad, ventanas de
diálogo explicando los campos de las formas,
ayuda en línea, mapas de sitio, etc.
• Confiabilidad.- Esta categoría agrupa los
requerimientos que tienen que ver con la soli-
dez de un sistema durante su ejecución.
Algunos ejemplos son: frecuencia de fallas
46> OCT-DIC 2004> www.softwareguru.com.mx
aceptable, porcentaje de tiempo que el sistema
debe estar funcionando, capacidad de recupe-
ración de fallas.
• Rendimiento.- El rendimiento se refiere a la
velocidad del sistema y su eficiencia en utiliza-
ción de recursos. Estos típicamente se definen
en términos de tiempo de respuesta esperado y
carga de usuarios concurrentes que debe ser
soportada.
• Soporte.- Los requerimientos de soporte
incluyen requisitos de instalación y configura-
ción, así como facilidades para mantener y
administrar la operación del sistema.
Con esto abarcamos los FURPS, sin embargo el
modelo menciona un '+' que no hemos cubierto.
El signo '+' en FURPS+ se utiliza para identificar
requerimientos adicionales que típicamente se
refieren a restricciones como:
• Restricciones de diseño.- Limitan las posibili-
dades para diseñar un sistema. Por ejemplo,
puede ser necesario tener que usar una base de
datos relacional.
• Restricciones de implementación.- Estas se
refieren a reglas para la programación, como la
utilización de una versión específica de un len-
guaje, o apegarse a ciertos estándares.
• Restricciones de interfase.- Indican elementos
externos con los que el sistema debe interac-
tuar; pueden ser otros sistemas o dispositivos
como lectores de código de barras.
• Restricciones físicas.- Se refieren a indicacio-
nes para el hardware, por ejemplo que sea de
cierta forma, tamaño o peso.
Con esto cubrimos todas las categorías definidas
por el modelo FURPS+. Este modelo también se
puede utilizar para representar las categorías o
dimensiones de calidad de un sistema de softwa-
re. A fin de cuentas, la calidad de un sistema radi-
ca en el cumplimiento de sus requerimientos, así
que las categorías de requerimientos y calidad
deben estar estrechamente ligadas.
Les recomendamos que en su próximo proyecto
utilicen este modelo, ya que facilitará la labor
de administración de requerimientos.
 Anunciante Páginas url

Directorio AMCIS
AMITI
Avantare
Bea Systems
19
11
39
F3
www.amcis.org.mx
www.amiti.org.mx
www.avantare.com
mx.bea.com
Deintec 15 www.deintec.com
Global Book 45 www.globalbook.com.mx
Impulsare 29 www.impulsare.com
Intuisystems 7 www.intuisystems.com
Itera 9 www.itera.com.mx
Microsoft F2-1 www.microsoft.com/spanish/msdn
Oracle F4 www.oracle.com/global/mx
Sieena Software 46 www.sieena.com
TENEMOS UN ESPACIO RESERVADO PARA TI
INDEX

Software Guru 47 www.softwareguru.com.mx

Si deseas anunciarte contáctanos en el (55) 5239-5502
Tecnológico de Monterrey 37 www.itesm.mx
o en ventas@softwareguru.com.mx
TI Américas 5 www.tiamericas.com
Ultrasist 41 www.ultrasist.com.mx

www.softwareguru.com.mx > OCT-DIC 2004 > 47


DESARROLLO PROFESIONAL
Formando al líder
de proyecto ideal
ada la complejidad y escala de los proyectos
D actuales de TI, las compañías que basan su
estructura en el desarrollo vertical de sus emple-
ados se enfrentan constantemente con el reto de
encontrar y formar nuevos líderes de proyecto,
capaces de lidiar con todos los procesos involu-
crados en el desarrollo e integración de solucio-
nes tecnológicas.
El rol de líder de proyecto no depende exclusiva-
mente de un perfil, sino que requiere de un balan-
ce de habilidad, experiencia y personalidad. Un
buen líder de proyecto necesita contar con las
siguientes características:
1. Habilidad para resolver problemas. Sin duda,
el mayor atributo de un líder de proyecto es su
capacidad para identificar, replantear y dar solu-
ción a los problemas. Esta capacidad requiere de
conocimientos técnicos, administrativos y de per-
sonal, así como la experiencia adecuada para eva-
luar correctamente un problema.
El mayor atributo de un líder de proyecto es su capacidad
para identificar, replantear y dar solución a los problemas.
2. Capacidad de aprendizaje. Un líder de proyec-
to debe ser capaz de entender un sinfín de pro-
blemas tanto técnicos como de negocio. Así que
es imprescindible demostrar haber pasado por un
proceso de aprendizaje que compruebe sus avan-
ces en todos los ámbitos.
3. Supervisar el proyecto hasta su conclusión.
Aunque demuestre excelentes características
para consolidarse como un líder, uno de los pun-
tos trascendentales para este rol es contar con la
energía y enfoque necesarios para mantenerse
firme durante todo el proyecto, desde su lanza-
miento hasta el cierre.
4. Capacidad para trabajar con otros. Esto se
refiere a la habilidad para laborar y entenderse no
sólo con el equipo técnico, sino también con clien-
tes, usuarios y alta gerencia, manteniendo una
correcta línea de comunicación con los distintos
48 > OCT-DIC 2004 > www.softwareguru.com.mx
partícipes del proyecto, incluso con personal tra-
bajando en proyectos relacionados. Un líder de
proyecto requiere continuamente hacer presenta-
ciones de avance, y debe ser capaz de hacerlo de
una manera convincente.
5. Experiencia de negocios. Resulta de suma uti-
lidad para una organización moderna que un líder
de proyecto se pueda desempeñar en el dominio
del negocio. Los líderes de proyecto deben mane-
jar procesos de negocios, así como personal de
estas unidades.
6. Experiencia técnica. Esta característica no se
refiere específicamente a la capacidad para pro-
gramar, sino a la aplicación del conocimiento téc-
nico. El líder debe ser capaz de entender los
problemas relacionados con el equipo y el soft-
ware, además de lograr una integración con los
miembros responsables de esta área trabajando
con ellos, demostrando así sus conocimientos y
ganando el reconocimiento de sus subalternos.
7. Experiencia en proyectos. Esta experiencia no
necesita ser exclusivamente como líder. Al contra-
rio, contar con experiencia en distintos roles per-
mite lograr un mayor conocimiento de los
diferentes aspectos relacionados con el desarro-
llo de soluciones tecnológicas. Los puntos a resal-
tar en este renglón: los proyectos más largos y
cortos en los que se ha participado y las diferen-
cias entre éstos; cuál fue el proyecto más intere-
sante y el menos satisfactorio, y porqué; cuáles
fueron los retos más complejos que se enfrenta-
ron durante el proyecto.
8. Habilidades administrativas. Todo buen líder
debe contar con esta característica, que acompa-
ña el conocimiento del software y otras herra-
mientas; se trata de la habilidad para organizar,
planear y coordinar actividades. También aquí
entra la capacidad para preparar presupuestos, y
administrar los gastos del proyecto.
Software Guru
Conocer estos fundamentos pueden
darle ventaja competitiva al aplicar para
un puesto de líder de proyecto, o lo ayu-
darán para desarrollarse en este rol. He
aquí algunas recomendaciones para los
interesados en formarse como líderes de
proyecto:
• Es importante para quienes cuenten
con poca experiencia, que al trabajar en
un proyecto se ofrezcan como volunta-
rios para resolver problemas, esto prove-
erá la práctica necesaria.
• También resulta útil tomar notas y rea-
lizar el análisis del proyecto, su posterior
estudio dará la pauta para mejorar en
futuros trabajos.
• Desarrollar ideas para futuros proyectos,
o incluso plantear proyectos a un gerente
amigable, que haga notar los errores y
aciertos en estas presentaciones, resulta
un ejercicio benéfico para mejorar la capa-
cidad de trabajo entre áreas. Hay que
tomar en cuenta el riesgo de que la idea
pueda ser tomada por alguien más sin
brindar el crédito apropiado.
• Una característica que puede resultar
definitiva al solicitar el puesto de líder de
proyecto, es conocer el proceso de admi-
nistración de proyectos en su organiza-
ción. En la mayoría de las empresas este
proceso está basado en el Project
Management Body of Knowledge
(PMBOK) del Project Management
Institute (PMI), así que es vital estar
cuando menos familiarizado con éste.
• Aunque parezca irrelevante, es funda-
mental recolectar información relaciona-
da con los problemas que se presentan
durante un proyecto, así como sus res-
pectivas soluciones; esto puede resultar
muy valioso en futuros proyectos.
• Por último, un ejercicio definitivo: ela-
borar diferentes versiones de su currícu-
lum, divididos en línea gerencial y
asignaciones de proyecto. La diferencia
entre ambos radica en que el primero se
enfoca en el proceso de negocios y el
número de personas bajo su línea de
mando; el segundo se enfoca en los
beneficios, tamaño y problemas resueltos
durante el proyecto. Es más fácil para una
organización identificar a un futuro líder
de proyecto con este tipo de currículum.
No.0 www.software guru.com.mx > SOFTWARE GURU CONOCIMIENTO EN PRÁCTICA Octubre -Diciembre 2004