EN PORTADA

En un mundo de cambios constantes y GUÍA DEL

competencia global, las organizaciones
de desarrollo de software son presio-
nadas a alcanzar mayor eficiencia con
VIAJERO
Por Mara Ruvalcaba
menores costos. Para poder lograr este
objetivo, es necesario adoptar una for-
ma de trabajo que permita entender,
controlar, comunicar, mejorar, predecir
y certificar el trabajo realizado.
Actualmente existe una gran diversidad de
opciones relacionadas con procesos de de-
sarrollo. Constantemente se escuchan di- ¿Por qué contar con un proceso de software?
ferentes acrónimos como CMM, CMMI, Hasta hace poco tiempo, la producción de software era realizada con un
RUP, ISO, PSP, TSP, etc., que causan con- enfoque artístico, a diferencia de un enfoque industrial. Ante la constante presencia de
fusión, principalmente debido a la mala proyectos fallidos, y con el objetivo de mejorar la calidad de los productos, en los últi-
interpretación de los mismos. mos años las organizaciones introdujeron los métodos de ingeniería de software. (Ver
Fundamentos – Desarrollar software es mucho más que programar, pág. 42)
Revisemos entonces los principales pro-
cesos de desarrollo y modelos más utiliza- A partir de estos, se formalizó el enfoque de ingeniería de producto para desarrollar software.
dos al momento, así como los estándares Factores como la globalización han obligado a las organizaciones a contar con marcos de tra-
relacionados. bajo que las ayuden hacer las cosas de la manera más eficiente. Fue entonces que se incorporó
la ingeniería de procesos al desarrollo de software.

20 ENE-FEB 2005 www.softwareguru.com.mx

Proceso
Antes de definir lo que es un proceso de desarrollo de software, entendamos lo que Elementos Típicos del Proceso de Software
es un proceso. Una definición sencilla de proceso es “serie de acciones que condu- Actividad Definen las acciones que se llevan
cen a un final”. Esta definición parece coincidir con las ideas generales de la gente a cabo en un momento dado del
sobre procesos, pero deja muchas preguntas abiertas. ¿El proceso es la forma en desarrollo de software.
que la organización opera —desde mercadotecnia hasta recursos humanos— o es Flujo de Colección estructurada de
la forma en que un desarrollador diseña, produce código, o prueba el software? ¿El Trabajo actividades y elementos asociados
(artefactos y roles), que producen
proceso se refiere a administración, ingeniería, o ambas? ¿El proceso implica dema- un resultado de valor.
siada documentación y nos abstiene de desarrollar el producto objetivo?
Rol Son responsables por llevar a cabo
las actividades del proceso, pueden
La respuesta a éstas puede variar dependiendo de la perspectiva. Sin embargo, siem- ser personas o herramientas.
pre que para alcanzar algún fin deseado necesitemos ejecutar una serie de acciones,
y estas acciones tengan cierto orden, dependencias, roles responsables, resultados, Producto o Son las entradas y salidas de las
Artefacto actividades, pueden ser de diferen-
tiempos de ejecución y herramientas de apoyo, estaremos hablando de procesos, tes tipos, como documentos,
que pueden ser predefinidos y personalizados. modelos, componentes, planes,
reportes, etc.

Disciplina Conjunto integrado por actividades

Proceso de software relativas a una rama particular de
conocimiento. Ej. Análisis y diseño.
La meta de la ingeniería de software es construir productos de software, o mejorar los
existentes; en ingeniería de procesos, la meta es desarrollar o mejorar procesos.

Un proceso de desarrollo de software es un conjunto de personas, estructuras de or- Diversidad en Modelos

ganización, reglas, políticas, actividades y sus procedimientos, componentes de soft- Actualmente existe una gran variedad de modelos para pro-
ware, metodologías, y herramientas utilizadas o creadas específicamente para definir, cesos de software. Podemos entenderlos más fácilmente si los
desarrollar, ofrecer un servicio, innovar y extender un producto de software. clasificamos en dos tipos: genéricos y específicos.

Un proceso de software efectivo habilita a la organización a incrementar su pro-

ductividad al desarrollar software: Modelos Genéricos Modelos Específicos
• Permite estandarizar esfuerzos, promover reuso, repetición y consistencia Abarcan todos los Enfocados a la ingeniería de
entre proyectos. procesos relacionados con productos de software
el desarrollo de software
• Provee la oportunidad de introducir mejores prácticas de la industria.
• Permite entender que las herramientas deben ser utilizadas para soportar CMM – modelo de madurez UP – proceso de desarrollo
un proceso. de capacidades – estándar
de facto RUP – proceso de desarrollo
• Establece la base para una mayor consistencia y mejoras futuras.
CMMI – modelo integrado PSP – enfocado en indivi-
Un proceso de software mejora los esfuerzos de mantenimiento y soporte: duos
ISO 9001-2000 – sistema
• Define cómo manejar los cambios y liberaciones a sistemas de software existentes. para administración de la TSP – enfocado en equipos
• Define cómo lograr la transición del software a la operación, y cómo ejecutar calidad - estándar (incluye PSP)
los esfuerzos de operación y soporte. ISO/IEC 15504 – marco
para evaluación de proce-
Necesitamos un proceso de software cuya funcionalidad esté probada en la prácti- sos de software – en vías
de ser estándar, por ahora
ca, y personalizado para que cumpla con nuestras necesidades específicas. reporte técnico

MoProSoft – modelo de
procesos para la industria
de software en México – en
vías de ser norma mexicana

• Nos dicen qué • Nos dicen el cómo debe-

debemos hacer mos hacer las cosas
• Se deben usar como refe- • Se usan como guía para
rencia para definir procesos ejecutar proyectos
en una organización y para
autoevaluación.
• Medio para evaluar
que tan bien o mal esta
la organización.

Proceso de Software
Revisemos estos modelos para entender mejor su objetivo
y estructura.

¿Y las Metodologías Ágiles?

Las metodologías ágiles son otro ejemplo de prácticas específicas para desarrollar software. Uno de los métodos ágiles más conocidos es Extreme
Programming (XP), que se describe como una disciplina de desarrollo de software basada en valores de simplicidad, comunicación, retroalimentación, y
coraje. XP funciona al poner a todo el equipo en presencia de prácticas sencillas, con suficiente retroalimentación para habilitar al equipo para ver donde
están y afinar las prácticas para una situación única. No hemos listado XP como un modelo específico, ya que no se considera un proceso formal y
completo, sino que más bien es un conjunto de prácticas que se pueden aplicar dentro de los modelos mencionados.

ENE-FEB 2005 21
 Modelos Genéricos En el año 2000, el SW-CMM fue reemplazado por CMMI. El SEI ya no mantiene
el modelo SW-CMM, sus métodos de evaluación asociados, ni el material
de entrenamiento.
CMM (Capability Maturity Model) -
Modelo de Madurez de Capacidades

Marco que describe elementos clave de procesos efectivos de software. Creado por
el Software Engineering Institute (SEI) en conjunto con Carnegie Mellon Univer- CMMI (Capability Maturity Model
sity. La primera versión se publicó en 1994. Integration) - Modelo de Madurez de
Capacidades Integrado
CMM describe un camino evolutivo en 5 niveles de mejora de procesos para lograr
su madurez. Cubre prácticas de planeación, ingeniería y administración del desarro- El proyecto de CMMI fue concebido como una iniciativa
llo y mantenimiento de software. para reunir los diferentes CMMs en un conjunto de mo-
delos integrados, más consistentes entre ellos. Los modelos
fuente que sirvieron como bases incluyen: CMM Software,
Niveles de Madurez CMM Ingeniería de Sistemas, y CMM Desarrollo Integra-
Nivel Áreas clave del proceso do de Producto .
1 – Inicial Ninguna
Proceso caótico, impredecible. CMMI proporciona una guía para desarrollar procesos,
El éxito depende del esfuerzo heroico que además ayuda a evaluar la madurez de la organización
de individuos.
o capacidad de un área de procesos. CMMI incluye los
2 – Repetible • Administración de Requerimientos. procesos de ingeniería de software e ingeniería de sistemas.
Institucionalizar procesos efectivos • Planeación de Proyecto de Software.
de administración de proyectos de • Seguimiento y Control del Proyecto
software, que permiten a las organi- de Software. El modelo está representado de forma continua y es-
zaciones repetir prácticas exitosas • Administración de Subcontratos
desarrolladas en proyectos previos. de Software. calonada. Contiene 22 áreas de procesos. Cada área de
• Aseguramiento de Calidad de Software. proceso está formada por: Objetivos específicos, Prácticas
• Administración de Configuración.
de Software. específicas, Objetivos genéricos, y Prácticas genéricas.
3 – Definido • Enfoque en Procesos de
El proceso estándar para desarrollar y la Organización. CMMI Modelo Continuo
mantener software en la organización • Definición de Procesos de Esta formado por 5 niveles de capacidad del proceso:
esta documentado, incluyendo pro- la Organización.
cesos de administración e ingeniería • Programa de Capacitación. 0. Incompleto
de software, y estos procesos están • Administración Integral de Software. 1. Desempeñado
integrados. • Ingeniería de Productos de Software. 2. Administrado
• Coordinación Intergrupal.
• Revisiones entre Colegas. 3. Definido
4 – Administrado • Administración cuantitativa
4. Administrado cuantitativamente
Se establece un conjunto de metas de procesos. 5. Optimizado
cuantitativas para medir el nivel de • Administración de la calidad del Y por cuatro categorías de áreas de procesos: Administra-
calidad y desempeño de los proyec- producto de software.
tos y del proceso organizacional. ción de Procesos, Administración de Proyectos, Ingeniería,
Soporte. Estas categorías agrupan a las diferentes áreas de
5 - Optimizado • Prevención de defectos.
No es simplemente detectar y resolver • Administración de cambio proceso, dividiéndolos en procesos básicos y avanzados.
defectos, sino prevenirlos y evitarlos de tecnología.
al implementar actividades proactivas. • Administración de cambio
Mejora continua de procesos. de procesos. CMMI Modelo Escalonado
El modelo escalonado, al igual que CMM, describe un ca-
mino evolutivo en 5 niveles de madurez de procesos, ade-
ISO 9001-2000 más integra nuevas áreas de proceso.
ISO (International Standards Organization) en 1987 crea la norma ISO 9000, con-
junto de estándares que establecen los requerimientos para la gestión de los sistemas La selección entre el modelo escalonado y el continuo
de calidad. ISO 9000:2000 está formado por: depende del objetivo de la organización, además de tener
• ISO 9000 Fundamentos y Vocabulario. que considerar la situación (si ya se tiene CMM, cultura
• ISO 9001 Requisitos. en procesos, etc.). Por ejemplo, si el objetivo es llevar a la
• ISO 9004 Recomendaciones. organización a cierto nivel de capacidad, deberá seleccio-
narse la forma escalonada; en cambio si el objetivo es me-
La parte de Requisitos - ISO 9001:2000, está estructurado en 8 secciones: jorar cierto proceso, será mejor seguir la forma continua.
1. Alcance.
2. Normas para la Consulta. Algunos Beneficios de CMMI vs. CMM
3. Términos y Definiciones. Algunos de los beneficios que han experimentado las organi-
4. Sistema de Gestión de la Calidad. zaciones que pasan de CMM a CMMI son los siguientes:
5. Responsabilidad de la Dirección. • Mejor alineación a objetivos de negocio.
6. Gestión de los Recursos. • Mejor visibilidad hacia las actividades de ingeniería, con
7. Realización del Producto. el objetivo de asegurar que el producto o servicio cumple
8. Medida, Análisis y Mejora. las expectativas del cliente.
• Aprovechamiento de mejores prácticas adicionales (e.j., me-
Aunque ISO 9001:2000 no otorga un estándar específico para sistemas de desarrollo de dición, riesgo, administración, y manejo de proveedores).
software, es decir, no abarca todos los procesos relacionados con el desarrollo de software, • Acoplamiento más estrecho con estándares de ISO.
muchas organizaciones de software han optado por gestionar su sistema de calidad en base a
este estándar, y obtener una certificación reconocida de manera internacional.

22 ENE-FEB 2005 www.softwareguru.com.mx

 ISO/IEC 15504
Estándar internacional que ofrece un marco para la evaluación de procesos. Fue inicia-
do en 1991 como el proyecto SPICE (Software Process Improvement and Capability
dEtermination). La versión de Reporte Técnico fue aceptada y publicada en 1998, en-
focada únicamente en procesos de software.

En el transcurso de su desarrollo ha evolucionado, de ser un modelo de referencia de buenas

prácticas de software, para convertirse en un marco de trabajo para evaluación de múltiples mo-
delos (de software o no). Su dirección actual es poder aplicarse a múltiples disciplinas y permitir
a las diferentes comunidades definir sus propios procesos específicos, modelos de referencia o * Partes publicadas
buenas prácticas. ISO 15504 está en vías de convertirse en estándar internacional, y se espera
que esté completo para 2006. Esta versión esta compuesta de cinco documentos, a diferencia Gráfica 1 - Estructura de Documentos 15504
del reporte técnico que consta de nueve partes (Ver gráfica 1 - Estructura de documentos).
Niveles de Capacidad (Ver gráfica 2):
La parte 2 de este estándar es de especial interés, ya que es la que define como se realiza 0. Incompleto.- Falta de cumplimiento del proceso.
una evaluación. Establece requisitos tanto para modelos de procesos de referencia como 1. Realizado.- Genera los productos de trabajo esperados.
para los métodos de evaluación sin establecer alguno en particular. 2. Administrado.- Proceso y productos administrados
y controlados.
3. Establecido.- Proceso definido para la organización
y utilizado adecuadamente.
4. Predecible.- El proceso opera dentro de los límites
estadísticos establecidos.
5. Optimizado.- El proceso mejora continuamente.

Las organizaciones de software no tienen que seleccionar

entre 15504 y su modelo actual. El rol de 15504 es pro-
veer un marco de trabajo en el que los modelos y métodos
de evaluación puedan existir de una manera armónica. No
esta diseñado para ser utilizado solo. La selección radica
en decidir si el ajustarse a 15504 es importante para el ne-
gocio (¿El negocio compite en el mercado global?, ¿Pro-
vee software a algún cliente que requiera 15504?, ¿Existen
Gráfica 2 - Modelo de Capacidades 15504-2 varios modelos de evaluación en la organización?). De ser
así, deberán elegir modelos que se ajusten a 15504.

Compatibilidad entre Modelos

CMMI Modelo Escalonado
Nivel de Madurez
1 – Inicial
Madurez de un proceso caracterizada
por resultados impredecibles.
2 – Administrado
Madurez del proceso caracterizada
por el desempeño repetible del
proyecto. El foco clave del proceso
esta en actividades y prácticas a
nivel proyecto.
3 – Definido
Madurez del proceso caracterizada
por mejorar el desempeño del pro-
ceso dentro de una organización.
Áreas de proceso
Ninguna
• Administración de Requerimientos.
• Planeación de Proyectos.
• Monitoreo y Control de Proyectos.
• Administración del Acuerdo con el Proveedor.
• Administración de Configuración.
• Aseguramiento de Calidad de Proceso y Prod.
• Mediciones y Análisis.
• Desarrollo de Requerimientos.
• Solución Técnica.
• Integración de Producto.
• Verificación, Validación.
• Enfoque Organizacional en Proceso.
• Definición de Procesos de la Organización.
• Capacitación Organizacional.
• Administración Integral de Proyectos.
• Administración del Riesgo.
• Análisis de Decisión y Resolución.
ISO/IEC 15504
• Evaluación de procesos de software.
• En vías de ser estándar.
• Dirección amplia.
• Niveles de capacidad.
• Evaluación de capacidades por proceso individual.
• Guía para realizar la evaluación.
• Toma como referencia ISO 9001 y CMMI.
CMMI
• Modelo de madurez de procesos de software.
• Modelo – estándar de facto.
• Dirección detallada.
• Pasos progresivos (niveles) - Escalonada.
• Categorías de procesos - Continua.
• Guía para institucionalización e implementación.
• Modelo de evaluación será conforme al modelo de
evaluación de 15504.

4 – Administrado Cuantitativamente • Desempeño de Procesos Organizacionales.

Caracterizada por mejorar el
desempeño organizacional.
5 - Optimizado
Madurez del proceso caracterizada
por un desempeño organizacional
rápido y configurable, Mejora conti-
nua y cuantitativa de procesos.
• Administración Cuantitativa de Proyectos.
ISO 9001-2000
• Sistema de Gestión de la Calidad.
• Innovación y Despliegue Organizacional. • Estándar internacional.
• Análisis Causal y Resolución.
• Dirección amplia.
• Un conjunto de requerimientos a ser cubierto.
• No hay lineamientos para su implementación.
• Usado como referencia en actividades de gestión de
calidad por CMMI y 15504.

www.softwareguru.com.mx ENE-FEB 2005 23

 Modelos Específicos
PSP – Personal Software ProcessSM
Personal Software Process (PSP) es un proceso diseñado para ayudar a los
ingenieros de software a controlar, manejar y mejorar su trabajo. PSP está
basado en una motivación: La calidad de software depende del trabajo de
cada uno de los ingenieros de software. Debido a que los costos de perso-
nal constituyen 70% del costo del desarrollo de software, las capacidades y
hábitos de trabajo de los ingenieros determinan en gran manera los resul-
tados del desarrollo de software.
Basado en prácticas encontradas en CMM, el PSP puede ser usado por
ingenieros para estructurar y disciplinar el desarrollo de software. El inge-
niero de software podrá planear mejor el trabajo, conocer con precisión
el desempeño, medir la calidad de productos, y mejorar las técnicas.
PSP puede ser aplicado en:
• Desarrollo de programas.
• Definición de requerimientos.
• Documentación.
• Pruebas de sistemas.
• Mantenimiento de sistemas.
Evolución de PSP
TSP - Team Software ProcessSM
Team Software Process (TSP) es un marco para el desarrollo de software
que pone igual énfasis en el proceso, producto y trabajo en equipo. Al
igual que PSP, TSP fue propuesto por Watts Humphrey.
TSP se basa en PSP, y se fundamenta en que el software, en su mayoría,
es desarrollado por equipos, por lo que los ingenieros de software deben
primero saber controlar su trabajo, y después saber trabajar en equipo.
TSP le enseña a los ingenieros a construir equipos autodirigidos y des-
empeñarse como un miembro efectivo del equipo. También muestra a
los administradores como guiar y soportar estos equipos.
Estrategia de TSP
• Proveer un proceso sencillo basado en PSP
• Desarrollar productos en varios ciclos. Ciclo de TSP: Lanzamiento,
Estrategia, Plan, Requerimientos, Diseño, Implementación, Pruebas,
Postmortem
• Establecer medidas estándares para calidad y desempeño
• Proveer definiciones de roles, y evaluaciones de rol y de equipo
• Requiere disciplina de proceso
• Provee guía para manejo de problemas de trabajo en equipo
24 ENE-FEB 2005
RUP
El Rational Unified Process (RUP) es un proceso de software de-
sarrollado y comercializado por Rational Software (ahora parte de
IBM). RUP está diseñado alrededor de seis mejores prácticas para el
desarrollo de software:
• Desarrollar de manera iterativa.
• Administrar los requerimientos.
• Utilizar arquitecturas basadas en componentes.
• Modelar el software visualmente.
• Verificar la calidad de manera continua.
• Controlar los cambios.
En sí, RUP es una guía que define roles, actividades, flujos de trabajo
y lineamientos para ejecutar proyectos de software de acuerdo a estas
mejores prácticas.
RUP organiza los proyectos de software en dos dimensiones: la del
tiempo y la de las actividades. En base al tiempo, los proyectos se
dividen en cuatro fases secuenciales:
• Concepción – Definición de alcance, identificación de riesgos.
• Elaboración – Resolución de riesgos, establecimiento de arquitectura.
• Construcción – Generación del producto.
• Transición – Disponibilidad a la comunidad de usuarios finales.
Las actividades se organizan en nueve diferentes disciplinas que son eje-
cutadas durante las diferentes fases.
En realidad RUP es un framework (marco de trabajo) que preten-
de ser personalizado o configurado para organizaciones y proyectos
específicos. RUP no se puede aplicar de la misma forma en todos
los proyectos de una organización. Es por esto que pretender seguir
RUP a través de ir cumpliendo con la lista de artefactos que defi-
ne, es una estrategia poco efectiva. Lo que las organizaciones deben
hacer es entender la razón de ser de RUP – las prácticas citadas an-
teriormente – y en base a esto aplicar lo que decidan que es conve-
niente para cada área o proyecto específico.
RUP es una instancia particular del Proceso Unificado, definido por
Ivar Jacobson, Grady Booch y James Rumbaugh en el libro “The
Unified Software Development Process” de 1998. Adicionalmente
existen otras instancias de este proceso, tales como el Proceso Unifi-
cado Mejorado (Enhanced Unified Process), el cual agrega soporte
multiproyectos y fases y disciplinas para el mantenimiento y retiro
de sistemas de software.
Compatibilidad de PSP y TSP con CMMI
CMM y CMMI se enfocan en la mejora organizacional basada en modelos.
TSP contiene prácticas operativas para el desarrollo de equipos. PSP se
enfoca en la mejora a nivel individual.
www.softwareguru.com.mx
¿Qué hay para la Industria Mexicana?
México quiere y puede darse a conocer con una
fuerte industria de software. Las condiciones
básicas están dadas: se generan recursos huma-
nos capacitados, se tiene acceso a los equipos
y herramientas de desarrollo, el mercado local
tiene necesidades lejos de estar satisfechas, el
mercado externo de habla hispana no está sa-
turado y la cercanía con los E.U. trae oportuni-
dades de exportación potenciales.
MoProSoft, modelo de procesos para la in-
dustria de software mexicana, fue desarrolla-
do pensando en facilitar a las organizaciones
dedicadas al desarrollo y mantenimiento de
software la adopción de las mejores prácticas
reconocidas internacionalmente a través de
modelos como SW-CMM, CMMI, TSP, PSP,
ISO/IEC 15504, PMBOK y SWEBOK.
Características principales
1. Estructura adaptable - Los procesos están
organizados en 3 categorías, que corresponden
a la estructura de cualquier organización.
2. Número reducido de procesos - Sólo 6
procesos principales y 3 subprocesos.
3. Procesos integrados a través de roles y
productos.
4. Gestión de Negocio como proceso explícito.
5. Integración de la gestión de recursos huma-
nos, de infraestructura y conocimiento.
6. Verificaciones y validaciones explícitas.
7. Manejo de situaciones excepcionales.
8. Productos de trabajo con características
mínimas explícitas.
9. Indicadores y propuestas de mediciones
para evaluar el cumplimiento de los procesos.
10. Guías de ajuste para adecuar los procesos.
REFLEXIONES
El Desarrollo
de Software
¿ARTE O INGENIERÍA?
Por Francisco López Lira
“La virtud está en el medio.”
—Horacio
Existen en la industria dos visiones aparente-
mente encontradas sobre lo que debería ser el
desarrollo de software, aquella que lo conside-
ra una arte y la que plantea que es ingeniería.
La primera considera al desarrollador como
un artista, no sujeto a reglas ni métodos, en-
fatizando la creatividad como la principal vir-
tud. Rechaza los procesos considerando que
estos restringen la creatividad.
La segunda visualiza al desarrollador como
un ingeniero, que debe utilizar procesos,
métodos y técnicas probadas en un ambiente
disciplinado y hace énfasis en establecer pro-
cesos definidos y controlados.

Aunque ambos enfoques tienen algo de

verdad, debemos tener en cuenta algunas
consideraciones:

• Arte no equivale a Caos. La idea de Arte está

estrechamente relacionada con un sistema de
trabajo. Etimológicamente Arte deriva del latín
Arquitectura de Ars que, a su vez, deriva del griego Tecné y que
MoProSoft para Aristóteles era “el uso sistemático del cono-
cimiento para la acción humana inteligente”.

• El arte requiere disciplina. Por ejemplo, a

Miguel Angel le tomo cuatro años terminar la
Conclusión Capilla Sixtina. Se dice también que Leonardo
Da Vinci podía trabajar las 24 horas del día.
Las organizaciones de desarrollo de software, además de entender los principales modelos y pro-
cesos existentes, deben considerar varios factores para poder decidir que camino seguir, como: • Producción artística no es producción comer-
cial. Los grandes artistas del renacimiento tenían
tamaño de la organización, recursos, enfoque en mercado global o local, habilidades, etc. mecenas que les permitían vivir cómodamente
hasta que creaban su obra maestra. Por otro
Las empresas grandes con miras a la exportación, pueden considerar una certificación en CMMI, lado, el desarrollo de software en el entorno ac-
tual implica cumplir con tiempos establecidos, lo
principalmente niveles 2 y 3, con el objetivo de evaluarse y ganar ventaja competitiva. Las em- cual a su vez requiere de procesos predecibles.
presas pequeñas y medianas con miras a mejorar los procesos y ser competitivos, pueden adoptar
• La creatividad es muy importante, pero no es
ISO 9001, ya que es un modelo más barato y sencillo. Las PyMEs mexicanas tienen la opción de lo único. Un proyecto de desarrollo de software
seguir MoProsoft como camino inicial. Las áreas internas de sistemas pueden adoptar algún pro- requiere además: planear, controlar, organizar
ceso específico, además pueden requerir a sus proveedores algún nivel de madurez comparable personas, dirigir, comunicar, coordinar, nego-
ciar, interactuar, verificar y validar, por ejemplo.
con CMMI o ISO 15504, o bien, que adopten el mismo proceso específico. Todo esto requiere de un entorno organizado.

Es recomendable considerar otros modelos que apoyen y complementen la correcta implantación • Lo importante es la gente, lo secundario los
procesos. Sin embargo, hay que considerar
del proceso de software. Como ISO/IEC 9126:2001 enfocado en modelar la calidad de productos que la gente no puede funcionar adecuada-
de software, o bien, modelos para implementar procesos de mejora como IDEAL. Otros mode- mente en un sistema caótico. “El sistema
siempre ganará” dice Rummler . Por ello, es
los especializados, que pueden ser de gran utilidad son PMBOK (Project Management Body of necesario contar con los procesos adecuados
Knowledge) y SWEBOK (SW Engineering Body of Knowledge). que posibiliten un sistema estable.

• Un mal proceso es peor que ninguno. Los

Para muchas de las organizaciones a nivel mundial, los 90s fueron la década de mejora de pro- procesos que se utilicen deben ser diseñados a
cesos. Aunque muchas aprendieron cómo implementar exitosos programas de mejora, otras partir del conocimiento de los desarrolladores y
lucharon sin lograr mejoras duraderas. Estas últimas organizaciones pasarán la siguiente década de las condiciones de cada organización.
tratando de ponerse al día, mientras que los líderes emprenden nuevos retos. Las metas relacio- Quizá la virtud yazca en el medio. Podemos uti-
nadas con procesos en esta década incluyen integración de procesos, armonización, y aceleración. lizar procesos y modelos de procesos procuran-
do crear un entorno organizado para potenciar
Las organizaciones deben luchar por alcanzar un nivel de calidad que les permita ser competitivas el valor de las personas y de creatividad.
en el mercado global. El punto de inicio es definir la meta, entendiendo la situación actual y las
diferentes opciones, para poder así emprender el viaje por el camino correcto. 1 Geary A. Rummler, “Serious performance con-

sulting”, International Society for Performance Im-

Referencias: provement, 2004
• Proceso de Desarrollo de Software, Hanna Oktaba, Facultad de Ciencias – UNAM
• ¿Porqué usar MoProSoft como modelo de procesos de referencia?, Hanna Oktaba, www.amcis.org.mx El autor es fundador y actual presidente de la Aso-
• Software Engineering Institute – Carnegie Mellon University, www.sei.cmu.edu ciación Mexicana para la Calidad en Ingeniería de
• Diplomado en Calidad de Software, AMCIS 2002 – www.amcis.org.mx Software (AMCIS).
• Process Diversity in Software Development – IEEE Software, julio-agosto 2000 flopezlira@amcis.org.mx

www.softwareguru.com.mx ENE-FEB 2005 25

 CASO DE ESTUDIO
MoProSoft® es un
posible medio para
las organizaciones
que deseen lograr
una evaluación
exitosa en un modelo
internacional como
SW-CMM®
MoProSoft® es un modelo de procesos de
reciente creación, para la industria de
software en México que fomenta la estan-
darización de su operación a través de la
incorporación de las mejores prácticas en
gestión e ingeniería de software. El objetivo
de este modelo es mejorar la capacidad de
los procesos de las empresas.
La estructura de MoProSoft® considera tres
categorías: Alta Dirección, Gestión y Opera-
ción. Establece un mecanismo para alinear
las estrategias de las tres categorías. La
categoría de Alta Dirección contiene el pro-
ceso de Gestión de Negocio. La categoría
de Gestión está integrada por los procesos
de Gestión de Procesos, Gestión de Proyec-
tos y Gestión de Recursos. Éste último está
constituido por los subprocesos de Recursos
Humanos y Ambiente de Trabajo, Bienes,
Servicios e Infraestructura y Conocimiento
de la Organización. La categoría de Opera-
ción está integrada por los procesos de Ad-
ministración de Proyectos Específicos y de
Desarrollo y Mantenimiento de Software.
MoProSoft® está disponible en la página
www.software.net.mx
Antecedentes
Desde hace varios años, ULTRASIST ha rea-
lizado un esfuerzo de mejora incremental al
adoptar las mejores prácticas de diferentes
modelos internacionales. Como resultado,
la Organización alcanzó el nivel de madurez
4 de SW-CMM®, utilizando a MoProSoft®
como marco de referencia.
Claudia Alquicira trabaja en Avantare Consutores como consultor en programas de mejora en organizaciones de desarrollo de software. Sus áreas de interés son la ingeniería
de software, calidad y tecnología orientada a objetos. Claudia cuenta con una Maestría en Ciencias de la Computación y participó como ponente en el SEPG LA 2004
32 MAR-ABR 2005
MoProSoft
en la Práctica
Recomendaciones para su Implantación
Por Ma. Julia Orozco y Claudia Alquicira
Este artículo presenta la experiencia de la implantación de MoPro-
Soft® en una empresa de desarrollo de software y resume un ciclo
de mejora considerando desde la planeación estratégica hasta su
valoración. Se explica cómo se usó el modelo como marco de refe-
rencia para las partes de gestión y operación y cómo se utilizó el qué
y el cómo para la parte de Gestión de Negocio.
En la planeación estratégica del 2003, la
Organización decidió buscar una evaluación
en algún modelo reconocido en la industria.
Entre los modelos candidatos se encontraban
ISO 9000:2000, MoProSoft y SW-CMM®. En
ese momento MoProSoft® tenía la caracte-
rística de ser el documento base de la norma
mexicana para la industria de software, pero
por ser de reciente creación, no contaba con
su método de evaluación, ni con un organis-
mo que respaldara la aplicación del mismo.
La decisión que se tomó para adoptar el mo-
delo orientado en la industria mexicana y lo-
grar una evaluación reconocida, fue obtener
al menos un nivel 3 de SW-CMM® a través
de MoProSoft®.
Problemática
La Organización contaba con una serie de pro-
cesos para el desarrollo y mantenimiento de
software, administración de proyectos y para
establecer la mejora continua de los mismos.
El desempeño de los procesos de desarrollo y
mantenimiento se medía a través de indicado-
res, lo que permitió robustecer estos procesos
pero no proporcionaban el tipo de información
que necesitaba saber la alta dirección para
medir el cumplimiento de los objetivos estra-
tégicos. Durante varios años la Organización
establecía un Plan Estratégico para definir las
metas, pero no con base en un proceso docu-
mentado. Existía una brecha entre las metas
de negocio y las de los procesos de desarrollo
de software por no contar con una retroalimen-
tación bidireccional. Es decir, la dirección con-
sideraba los resultados de la valoración de los
procesos para realizar esta actividad de pla-
neación, mientras que el Grupo de Procesos se
preocupaba por mejorar los procesos con base
en los resultados de la evaluación anterior
(defectos fugados, defectos por caso de uso,
plataforma de trabajo, retrabajo, entre otros)
pero no se consideraban las expectativas de
la alta dirección (utilidad esperada, retorno de
inversión, valor presente neto, tasa interna de
retorno, entre otros).
Experiencia en la Implantación
MoProSoft® se utilizó para alinear las estra-
tegias de la parte operativa con las expec-
tativas de la alta dirección. El proceso de
Gestión de Negocio se estableció formal-
mente en la Organización. Una vez revisada
la misión, visión y valores de la Organiza-
ción, se revisaron los objetivos estratégicos
y se definieron indicadores que permitieran
evaluar el cumplimiento.
<Categoría>
Alta Dirección
<<Dir>>
+ Gestión de Negocio
Aborda las prácticas de Alta Dirección relacio-
nadas con la gestión del negocio. Proporciona
los lineamientos a los procesos de la Categoría
de Gestión y se retroalimenta con la información
generada por ellos.
Los objetivos estratégicos se agruparon en
cuatro perspectivas como sugiere el Cuadro
de Mando Integral (Balanced ScoreCard).
www.softwareguru.com.mx
En la Perspectiva Financiera se agruparon
aquellos objetivos que tienen que ver con el
cumplimiento de las expectativas de los accio-
nistas. En la Perspectiva del Cliente los objeti-
vos que nos llevan a satisfacer las necesidades
de nuestros clientes. En la Perspectiva Interna
los relacionados con la mejora de aquellos
procesos en los cuales debemos ser excelen-
tes, y finalmente, la Perspectiva de Aprendiza-
je y Crecimiento que considera los aspectos
críticos para mantener la excelencia.
Se definieron los procesos de negocio
requeridos en la Organización para dar
cumplimiento a los elementos del Plan
Estratégico, la estructura organizacional se
revisó y actualizó principalmente en lo que
respecta al Grupo de Procesos definiendo
responsables de procesos y especialistas. El
Plan de Comunicación se instituyó como un
mecanismo de difusión de los Planes a los
miembros de la Organización. Se consideró
un Proyecto de Inversión y se identificaron
los proyectos internos y externos para dar
cumplimiento a los objetivos. Como pro-
yectos internos se establecieron el Proyecto
de Mejora y el de Infraestructura y Fortale-
cimiento. Se establecieron las estrategias
para dar cumplimiento a los objetivos estra-
tégicos y se definieron metas e indicadores
para poder valorar el avance.
La alta dirección dio la responsabilidad al
Grupo de Procesos para detallar los Pro-
cesos de Negocio y definir los procesos de
apoyo para cumplir con los objetivos estra-
tégicos planteados.
La implantación del proceso de Gestión de
Negocio dio orden y disciplina a las activi-
dades de la alta dirección, lo que permitió
establecer la alineación de las metas de ne-
gocio con las de Gestión y Operación.
El aspecto más importante para definir una
métrica fue que el costo de producirla estuviera
balanceado con el beneficio potencial que será
ganado en la organización
Categoría de Gestión y Operación
El Grupo de Procesos realizó un análisis de
brecha de las prácticas establecidas en la
Organización con respecto a las estableci-
das en las otras categorías de MoProSoft®.
Como resultado se obtuvo que la Organiza-
ción contaba con procesos que cubrían gran
parte de la categoría de Gestión y toda la
categoría de Operación.
Con base en el análisis realizado, se prio-
rizaron los objetivos con la Dirección y se
elaboró el Plan de Procesos que contiene
la estrategia para definir, implantar, medir y
evaluar los procesos. Las métricas que se es-
www.softwareguru.com.mx
<<Categoría>>
Gestión
<<Ges>>
Gestión de Procesos
<<Ges>>
Gestión de Proyectos
<<Ges>>
Gestión de Recursos
Establecer los procesos de la organización, en
función de los procesos requeridos identificados
en el Plan Estratégico. Así como definir, planear, e
implantar las actividades de mejora en los mismos.
Categoría de Gestión
tablecieron fueron aquellas que permitieran
retroalimentar a la Organización en cuanto
al cumplimiento de los objetivos estratégi-
cos. El aspecto más importante que se tomó
en cuenta para definir una métrica fue que
el costo de producirla estuviera balanceado
con el beneficio potencial que será ganado
en la organización. El registrar, recolectar y
evaluar métricas lleva implícito un costo, que
para la mayoría de las empresas mexicanas
de desarrollo de software puede resultar pro-
hibitivo si no se garantiza un retorno de inver-
sión a corto plazo. Si bien es sabido que no
se puede mejorar lo que no se puede medir,
también es cierto que hay que empezar por
mejorar aquellos procesos que impacten a
las metas prioritarias de la Organización.
La estrategia que estableció el Grupo de Proce-
sos para implementar los cambios en la Orga-
nización, consistió en realizar las actividades
en forma iterativa e incremental de acuerdo a
las prioridades establecidas.
Al finalizar cada incremento se evalúo el cum-
plimiento de los objetivos establecidos en el
Plan Estratégico. Estas evaluaciones fueron
más frecuentes que las establecidas en los
años anteriores por ser un modelo de procesos
nuevo, que impactaba a toda la Organización.
Para este proyecto, se acordó contar con el
apoyo de consultores internos y externos con
conocimientos en CMM® y MoProSoft® para
asegurar el apego a los modelos. Durante la
definición y el ajuste del proceso se estable-
cieron las diferencias significativas entre los
modelos MoProSoft® y SW-CMM®. Con res-
pecto al proceso de Gestión de Proyectos, se
dividió en dos procesos, Ventas y Oficina de
Proyectos, tomando como base las prácticas
ya establecidas en la Organización.
Para los procesos de Gestión de Recursos y
sus subprocesos asociados, se estableció
una arquitectura diferente a la definida por
MoProSoft®. La Organización contaba con
un proceso que considera un Plan de Capaci-
tación para cumplir con las metas planteadas
en los objetivos estratégicos de aprendizaje y
crecimiento; considera los requerimientos de
los proyectos, las sugerencias del personal
e incluye el desarrollar las habilidades que
se desea que adquieran los miembros de la
Organización, como es el trabajo en equipo,
habilidades gerenciales, y manejo de con-
flictos. La capacitación que plantea se ofrece
en diferentes modalidades: interna, externa,
seminarios sobre nuevas tendencias tecnoló-
gicas y capacitación en la práctica.
El proceso de Recursos Humanos establecido
por MoProSoft® se maneja dentro del Proce-
so de Gestión de Proyectos por la Oficina de
Proyectos. En él se establecen los elemen-
tos a considerar en la selección, asignación,
aceptación, evaluación y desempeño de los
recursos humanos. Para la evaluación de
los miembros de la Organización se provee
un mecanismo que permite valorar su cre-
cimiento en dos direcciones: la horizontal
con respecto al desarrollo de habilidades y
la vertical con respecto a los conocimientos
y responsabilidades. El objetivo de esta eva-
luación es permitir un crecimiento gradual de
los miembros de la Organización para cumplir
con los objetivos estratégicos planteados en
la perspectiva de aprendizaje y crecimiento.
En cuanto al Plan de Infraestructura y Am-
biente de Trabajo, se considera dentro del
Proyecto de Infraestructura derivado del
Plan Estratégico.
Si bien la Organización contaba con una Base
de Conocimiento con la información referente
a las Categorías de Gestión y de Operación,
no consideraba la generada por la Alta Direc-
ción. Hoy en día el repositorio considera toda
la información de la Empresa.
SW-CMM® a Través
de MoProSoft®
Como resultado de este esfuerzo, la empresa
pudo comprobar que es factible implantar Mo-
ProSoft® y que es un posible medio para las
organizaciones que deseen lograr una evalua-
ción exitosa en un modelo internacional como
SW-CMM®. Para lograrlo es necesario cuidar
las prácticas establecidas en CMM® y no con-
sideradas en MoProSoft®, por ejemplo:
• En el proceso de Gestión de Negocio, escri-
bir una política que contenga los lineamientos
que rijan los procesos definidos consideran-
MAR-ABR 2005 33
 CASO DE ESTUDIO
Diagrama 1:
MoProSoft® como
marco de referencia.
do los compromisos establecidos en el nivel
que se desea alcanzar de SW-CMM®.
• En el subproceso Recursos Humanos y Am-
biente de Trabajo del proceso de Gestión de
Recursos, definir un mecanismo de renuncia
a la capacitación asignada.
• En el subproceso de Conocimiento de la Or-
ganización del proceso de Gestión de Recur-
sos, incluir las prácticas de administración
de configuración establecidas en CMM®.
• MoProSoft® no considera el Grupo de SQA
que maneja CMM®, pero sí establece verifi-
caciones y validaciones a productos y a pro-
cesos, sin embargo, para cumplir con CMM®
hay que conformar un Grupo de SQA que sea
independiente al proyecto.
• En cada uno de los procesos de MoProSoft in-
cluir las verificaciones de las actividades por el
SQA de acuerdo a cada área clave de CMM®.
• En las evaluaciones externas (proceso de ges-
tión de procesos) considerar un SQA externo.
Ambos modelos llevan al mismo fin, pero
cada uno sigue un camino diferente.
Fortalezas de MoProSoft®
Gestión de Negocio, sirve como vínculo entre
la parte de operación, gestión y dirección para
que los esfuerzos de la organización estén ali-
neados para alcanzar la misión y visión. Para
empresas de reciente creación pueden utili-
zar el qué y el cómo que define MoProSoft®
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
universidades, gobierno e iniciativa privada y ha sido ponente en diversos foros internacionales.
34 MAR-ABR 2005
Categorías
Optimizado
Administrado
Definido
Repetible
Inicial
CMM
como un medio que facilite la transición a un
modelo internacional.
Los modelos internacionales por lo general
consideraran una gran variedad de roles que
una micro y pequeña empresa mexicana no
puede implantar. MoProSoft® no restringe a
ningún rol para que pueda ser realizado por
una misma persona, o por diferentes personas
dentro del mismo proyecto y en la medida que
la empresa crece, éstos pueden paulatinamen-
te ser asignados a personas diferentes. Se
recomienda cuidar en la medida de lo posible
que una persona no sea juez y parte. Esto per-
mite a la micro y pequeña empresa crear la cul-
tura de procesos y fomentar la disciplina.
Aunque MoProSoft® fue pensado principal-
mente para la pequeña y mediana empresa,
puede ser usado como marco de referencia para
toda empresa que se inicia en un programa de
mejora, para asegurar que las estrategias a lo
largo de la organización están alineadas y para
asegurar que los procesos ya establecidos, con-
templan las mejores prácticas.
Recomendaciones Generales
para Implantar MoProSoft®
Es importante conservar las mejores prác-
ticas con las que cuenta una organización
y, en caso de ser requerido, ajustarlas
para el cumplimiento con el propósito, los
<Categoría>
Alta Dirección
<<Dir>>
+ Gestión de Negocio
<<Categoría>>
Gestión
<<Ges>>
Gestión de Procesos
<<Ges>>
Gestión de Proyectos
<<Ges>>
Gestión de Recursos
<<Categoría>>
Operación
<<Oper>>
Administración de
Proyectos Específicos
<<Oper>>
Desarrollo y
Mantenimiento
de Software
objetivos, la descripción del proceso esta-
blecidos por el modelo MoProSoft®. Como
ejemplo, definir un proceso de Gestión de
Recursos que incorpore los elementos de
los subprocesos de Recursos Humanos e
Infraestructura, Bienes, Servicios y hacer
un proceso en Gestión de Conocimiento de
la Organización.
La participación de consultores con expe-
riencia en el modelo que se desea implantar
siempre es recomendable. En MoProSoft®
por ser un modelo de reciente creación que
no cuenta con experiencia documentada, se
considera indispensable.
Para las organizaciones que inician un pro-
grama de mejora, el proceso de Gestión de
Procesos podría ser el primero a definir e im-
plantar puesto que con este proceso se ge-
nera el resto de los procesos. Se recomienda
una estrategia incremental de acuerdo a las
prioridades de la organización que permite
reducir los riesgos que conlleva la introduc-
ción de muchos cambios y permita a la Direc-
ción observar resultados a corto plazo.
La responsabilidad de asignación de recur-
sos humanos a los proyectos se puede atri-
buir al responsable de Gestión de Proyectos
y la parte de registro de recursos humanos a
un área administrativa.
www.softwareguru.com.mx
 PRÁCTICAS
REQUERIMIENTOS
Patrones de Casos de Uso
Por Saúl Cuesta Rodríguez
A
l desarrollar o construir algo,
como por ejemplo una casa o
una máquina, es muy útil apo-
yarse en la experiencia anterior, ya
sea de uno mismo o de otros. De esta
manera sabremos que la solución va
a funcionar, y tendremos identifica-
dos los problemas potenciales, así
como soluciones para éstos. Estas
soluciones a problemas comunes se
conocen como patrones, y se utilizan
en diversos aspectos del desarrollo
de software. Ya en un artículo ante-
rior de SG se habló sobre patrones de
diseño, específicamente del patrón
Modelo-Vista-Controlador. En esta
ocasión, estudiaremos la aplicación
de patrones al modelado de casos de
uso, y en específico abordaremos el
patrón CRUD.
Contrario a lo que se pudiera pensar,
un patrón de casos de uso no descri-
be un uso particular de un sistema.
Más bien, captura técnicas para que
el modelo sea mantenible, reusable,
y entendible. Entonces, podemos de-
cir que los patrones de casos de uso
capturan mejores prácticas para mo-
delar casos de uso.
La aplicación de patrones de casos de
uso nos trae los siguientes beneficios:
• Aumentar la productividad.
• Reutilizar elementos existentes (en
este caso fragmentos de modelos).
• Evitar el retrabajo por errores.
• No invertir tiempo en resolver pro-
blemas ya resueltos.
• Aplicar la teoría al trabajo práctico.
• Habilitar las herramientas de so-
porte para modelar el desarrollo.
Saúl Cuesta Rodríguez es consultor de ITERA especializado en las prácticas de requerimientos y modelado de negocios. Es graduado de la Universidad Tecno-
lógica de Panamá como Ing. en Sistemas.
40 NOV-DIC 2005
Captura y Organización Nombre: CRUD
de Patrones Intento: este patrón se utiliza en los
Para capturar y organizar los pa- casos donde se quiere realizar altas,
trones de caso de uso, recomiendo bajas, cambios y consultas a alguna
ampliamente generar un reposi- entidad del sistema. Su nombre es un
torio de patrones donde capturen acrónimo de las palabras en inglés
al menos la siguiente información Create, Read, Update, Delete.
para cada patrón: Palabras clave: Creación, altas, bajas,
cambios, catálogo
• Nombre: el nombre descriptivo
del patrón. Modelo 1: CRUD Completo
• Intento: captura cuál es el objeti-
vo de aplicar el patrón.
• Características: estados de los
patrones, si son simples o comple-
jos, comunes o infrecuentes.
• Palabras claves: palabras clave
que caractericen al patrón para fa-
cilitar su búsqueda.
• Tipo: si el patrón afecta la estruc- Descripción: el patrón CRUD Comple-
tura del modelo o la descripción de to consiste en un caso de uso para
un caso de uso. administrar la información (CRUD
• Modelo: un modelo de caso de Información), nos permite modelar
uso a aplicar. las diferentes operaciones para ad-
• Descripción: la descripción del ministrar una entidad de información,
modelo. tales como crear, leer, cambiar y dar
• Aplicabilidad: cuándo y cómo de baja.
aplicar el patrón. Aplicabilidad: este patrón deberá ser
• Discusión: completa discusión usado cuando todas las operaciones
sobre el patrón. contribuyen al mismo valor de nego-
• Ejemplo: un ejemplo donde uno cio y todas son cortas y simples.
o más de los patrones se aplica.
• Modelo de análisis: diagrama con Modelo 2: CRUD parcial
clases de análisis que proporciona
una realización de los casos de uso.
Una vez que hemos hablado sobre lo
que es un patrón de caso de uso, y
la forma de documentarlos, estudie-
mos el patrón conocido como CRUD,
en sus variantes completa y parcial.
www.softwareguru.com.mx
Descripción: alguna de las alternativas del
caso de uso puede ser modelada como caso
de uso independiente.
Aplicabilidad: este patrón es preferible cuan-
do uno de los flujos alternativos del caso del
uso es más significativo, muy largo, o mucho
más complejo que el patrón completo.
Discusión: muy a menudo los sistemas ma-
nejan información que, del punto de vista del
sistema, se crea muy fácilmente. Después de
un chequeo de sintaxis, o quizás un cierto che-
queo sin importancia de un cálculo o regla de
negocio, la información se almacena simple-
mente en el sistema. No es necesario realizar
cálculos, verificaciones complejas, o recupera-
ción avanzada de datos. La descripción del flu-
jo es pequeña, y probablemente sólo haya una
o dos trayectorias alternativas de menor im-
portancia en el flujo. Las consultas, cambios, o
bajas son operaciones igualmente simples.
¿Deben tales operaciones ser modeladas
como un caso de uso? ¿Y deben incluirse en
el modelo del sistema completo? La respues-
ta a ambas preguntas es sí. Son casos de uso
porque son funciones que debe ser capaz de
realizar el sistema. Alguien utilizará el sis-
tema para administrar esa información. Por
otra parte, deben ser incluidos en el modelo,
ya que de otra manera estará incompleto. Y
esto puede provocar que el proyecto no se
lleve a cabo adecuadamente.
Afortunadamente, esto no significa que ne-
cesariamente cada operación se debe expre-
sar como casos de usos separados. Según
el patrón CRUD, los podemos agrupar. Este
procedimiento tiene algunas ventajas ob-
vias. Primero, el tamaño del modelo será
reducido, hará más fácil de entender el mo-
delo porque tiene menos casos. En segundo
lugar, nadie estará interesado en un sistema
que contiene solamente un subconjunto de
estos casos de uso, ya que no generan el va-
lor completo (por ejemplo, leer y dar de baja,
pero no crear y cambiar). Agrupar estos flu-
jos juntos en un caso como Administrar X se
www.softwareguru.com.mx
asegura de que las cuatro operaciones esta-
rán incluidas en el modelo, y lo hace claro
para el lector del modelo. Tercero, el valor de
cada uno de los flujos por separado es muy
pequeño, y podríamos estar cayendo en
descomposición funcional; es la colección
entera de estas operaciones la que da valor
a los interesados.
Las cuatros operaciones no deben ser modeladas
como caso de uso independientes.
La variación denominada CRUD: Parcial, in-
dica que en caso de que solo algunas de las
cuatro operaciones sean simples mientras
que otras son complejas, se puede agrupar
las operaciones simples en un caso de uso y
dejar las otras modeladas como un caso de
uso separado.
Observar también que esto es una situación tí-
pica donde un caso de uso no tiene solamente
un flujo “básico”. Ninguno de los flujos se pue-
de decir que es más “básico” o “normal” que
los otros. Por lo tanto, un caso de uso CRUD
tendrá típicamente cuatro flujos básicos, y po-
siblemente algunos flujos alternativos, como
se demuestra en el ejemplo 1.
Una instancia de un caso de uso podrá reali-
zar una de las siguientes operaciones (crear,
leer, cambiar y dar de baja), y después dejar
de existir. Esta misma instancia del caso de
uso no continuará viviendo y esperando la
operación siguiente que se realizará. Esta
operación debe ser realizada por otra ins-
tancia del mismo caso de uso.
 PRÁCTICAS
REQUERIMIENTOS
Los patrones de casos de uso capturan mejores
prácticas para modelar casos de uso
Como regla general, cuando no
estamos seguros si combinar los
diversos casos de usos en uno o
crearlos como separados, la reco-
mendación es mantenerlos como
uno solo y después cuando se vea
el tamaño y complejidad del caso de
uso, se deberá tomar la decisión de
separarlos si es necesario.
A continuación mostramos un ejem-
plo de un boceto de caso de uso uti-
lizando el patrón CRUD. Por razones
de espacio, no está completo. El ob-
jetivo es ejemplificar la aplicación
del patrón.
Caso de Uso: Administrar Tarea
Este caso de uso permite
registrar, listar, modificar, o
eliminar la información de tareas
realizadas.
Flujo Básico
El caso de uso tiene cuatro diver-
sos flujos básicos:
Registrar tarea nueva
Modificar una tarea existente
Cancelar tarea
Consultar tarea fallida
Registrar tarea nueva
El caso de uso comienza cuando el
usuario elige registrar una nueva
tarea.
El sistema presenta una lista de
posibles clases de tareas, y pre-
gunta qué clase de tarea debe ser
registrada, con qué nombre, y cuan-
do se debe realizar.
El usuario provee la información
requerida.
El sistema comprueba que el tiempo
especificado es en el futuro y que
el nombre de la tarea es único.
El sistema registra la nueva tarea
y la marca como activa.
El caso de uso termina.
42 NOV-DIC 2005
Modificar tarea
El caso de uso comienza cuando el
usuario elige modificar una tarea
ya registrada.
El sistema recupera los nombres de
todas las tareas no marcadas como
activo y las presenta al usuario.
El usuario selecciona una de
las tareas.
El sistema recupera la información
sobre la tarea y la presenta
al usuario.
El usuario modifica cualquiera de
la información actual excepto el
nombre de la tarea.
El usuario acepta la información.
El sistema comprueba si el tiempo
especificado es en el futuro y al-
macena la información modificada.
El caso de caso de uso termina.
Cancelar tarea
El caso de uso comienza cuando el
usuario elige cancelar una tarea.
El sistema recupera y despliega to-
das las tareas futuras.
El usuario selecciona una de
las tareas.
El sistema recupera la información
sobre la tarea y la presenta al
usuario.
El usuario confirma la cancelación,
el sistema elimina la tarea; si no
se puede, no se hace ninguna modi-
ficación.
El caso de uso termina.
Consultar tarea fallida
El caso de uso comienza cuando el
usuario elige vista de la lista de
todas las tareas que han fallado.
El sistema recoge todas las tareas
con el estado fallado y presenta
sus nombres al usuario.
El caso de uso termina.
Flujos alternativos
Cancelar la operación
Nombre o Tiempo incorrecto
Otros Patrones de Caso
de Uso
Existen varios patrones adicionales
al CRUD que son utilizados para
modelar sistemas. Esta es una lista
de los más importantes:
• Reglas de negocio
• CRUD
• Login
• Reportes y Explotación de infor-
mación
• Inclusión y Extensión
• Sistema en Capas
• Múltiples Actores
• Jerarquía de Componentes
• Servicios Opcionales
Conclusión
La técnica de casos de uso nos permite
modelar y especificar los requerimien-
tos de nuestro sistema. Tiene muchos
beneficios, entre los más importantes:
primero nos permite planear nuestro
proyecto y segundo ayuda a llegar a
acuerdos con los usuarios, para que los
casos de uso sean mas claros y manteni-
bles es importante encontrar patrones
y documentarlos, de esta manera cuan-
do nos encontremos con un problema
igual o parecido podamos resolverlos
en menor tiempo. El concepto de patro-
nes no es algo que solo es aplicable a la
práctica de requerimientos. De hecho,
la disciplina de requerimientos copia
este concepto de la de análisis y dise-
ño. Lo que se busca con los patrones
es reutilizar lo aprendido en los nuevos
proyectos y usarlos en la organización
como estándares.
Referencias
• Pan-Wei Ng, Understanding types of
use cases and artifacts.
IBM Developerworks.
www-128.ibm.com/developerwor-
ks/rational/library/1809.html
www.softwareguru.com.mx
PRODUCTOS HERRAMIENTAS
Desarrollo Guiado por Pruebas
Automatización de Pruebas Unitarias
Por Ariel Súcari
E
l desarrollo guiado por pruebas (test-driven development), o
TDD, es una de las principales prácticas de Extreme Program-
ming (XP), que propone una serie de pasos para probar antes
de programar (test-first programming).
El proceso a realizarse es el siguiente:
• Se crea un caso de prueba que verifica una pequeña funcionalidad
del sistema.
• Se ejecuta el caso de prueba, y deberá tener un resultado NO exitoso,
ya que la funcionalidad que intenta probar aún no está construida.
• Una vez que se observa el fallo, se desarrolla únicamente el código
que hará que la prueba sea exitosa.
• Por último, se hace un refactoring del código para asegurar que se tie-
ne el diseño más simple para la funcionalidad que acaba de agregarse.
Una vez que estos pasos son llevados a cabo, se realiza lo que mo-
tiva a la metodología: la ejecución de todas las pruebas automatiza-
das que se tienen construidas hasta el momento.
Podemos visualizar gráficamente el párrafo anterior en el siguiente
diagrama de actividad en UML.
Ariel Súcari es consultor de It Era especializado en pruebas de software. Graduado de la Universidad CAECE en Buenos Aires, Argentina. Ha participado y coor-
dinado proyectos de la disciplina de pruebas en Inglaterra, Estados Unidos, Venezuela, Argentina y México durante los últimos 7 años.
14 MAY-JUN 2006
Luego de esta breve explicación que sólo intenta inducir a los
desconocedores e introducir a los entendidos, se pueden vislum-
brar cuáles podrían ser las ventajas y las desventajas de utilizar
dicha metodología.
Ventajas
• Requerimientos de última hora. ¿Cuántas veces un requerimiento in-
troducido a último momento le causó defectos en producción debido a
un error en el análisis de impacto? ¿En cuál de las siguientes situaciones
preferiría estar si necesita cambiar un sistema en producción?
a) Cualquiera sea el cambio que usted realice su forma de trabajo le
permite probar su impacto en todo el sistema en minutos.
b) Alcanza a realizar los cambios pero no tiene tiempo para probar,
entonces debe liberar y cruzar los dedos para que funcione y no afec-
te otras partes del sistema.
• Se desarrollan 100% de las pruebas. Todas las pruebas se rea-
lizan de manera automática y no existe el escenario en que no se
puede completar la creación de los casos de prueba debido a que
no se escribe una línea de código que no corresponda a un caso de
prueba automatizado.
• Cobertura de requerimientos al 100%. Debido a que los reque-
rimientos son expresados en forma de casos de prueba y dichos
casos son ejecutados automáticamente, cada vez que se agrega
una funcionalidad al sistema, estamos seguros de que al finali-
zar nuestro desarrollo habremos cubierto en 100% los requeri-
mientos del mismo, debido a que ninguno de nuestros casos de
prueba ha fallado.
Desventajas
• El éxito depende de los casos de prueba. Si se hizo una inter-
pretación incorrecta de un requerimiento, se escribirá un caso de
prueba que no satisfaga a los deseos del usuario, por lo tanto el
producto final será incorrecto.
• Interfaces gráficas. Si se hace el intento de probar las interfa-
ces gráficas y estas cambian, debemos perder tiempo en adaptar
nuestras pruebas automatizadas. Esto podría causar que en cada
versión se invierta tanto tiempo en reescribir las pruebas que se
opte por no hacerlo.
Complementando la Metodología
Después de involucrarme un tiempo con la metodología de de-
sarrollo guiado por pruebas y de disfrutar sus virtudes y sufrir
sus defectos, he aprendido a resolver estas limitantes a través del
www.softwareguru.com.mx
uso de un par de herramientas de IBM-Rational. A continuación
les comparto más al respecto.
Problema 1: Interfaces Gráficas
La herramienta Functional Tester de IBM-Rational cuenta con
una tecnología llamada ScriptAssure la cual utiliza algoritmos
configurables para localizar a los objetos durante la ejecución
de las pruebas, aunque éstos hayan cambiado desde la creación
del caso de prueba inicial. Es así que Functional Tester actualiza
de manera inteligente la forma en que reconoce a los objetos
en Java, aplicaciones Web y .NET sin intervención humana, por
lo que no requiere que se actualicen los scripts cada vez que
cambia la aplicación.
Las herramientas que no cuenten con una tecnología semejante a
la descrita, no lograrán reconocer la casilla de verificación y reque-
rirán que el desarrollador reprograme sus pruebas. Si esto ocurre
en una simple ventana de login como la del ejemplo, ¿qué sucederá
con aplicaciones complejas como en las que usted trabaja? Será
tanto el trabajo de mantenimiento de los scripts de prueba que sus
programadores dejarán de ser productivos.
Otras virtudes que encontré en esta herramienta y que afirmaron
mi decisión de adoptarla son:
• Los scripts de prueba se pueden programar en Visual Basic
.Net y Java.
• Tiene herramientas de depuración incluidas en el ambiente de
desarrollo tanto para VB .Net como para Java.
• Incluye la posibilidad de incluir pruebas manejadas por datos
• Soporta la introducción de expresiones regulares para el manejo
de patrones.
• Tiene un agregado para soportar aplicaciones para terminales
3270 y 5250.
• Soporta pruebas automatizadas para ambientes Siebel 7.7.
www.softwareguru.com.mx
Problema 2: El éxito Depende de los Casos de
Prueba
Para evitar el problema de tener casos de prueba que no concuer-
den con los requerimientos, lo que podemos hacer es que sean
los mismos analistas de negocio quienes desarrollen los casos de
prueba. Para esto, no necesitan tener conocimientos técnicos ni
desarrollar scripts. Simplemente utilizan otra herramienta de IBM-
Rational denominada Manual Tester, y en ella definen fácilmente
los casos de prueba.
Para especificar un caso de prueba, simplemente se define la serie
de pasos a seguir, y se especifican valores de entrada, así como el
resultado(s) esperado. Posteriormente, los desarrolladores se basan
en estos casos de prueba capturados en
el Manual Tester, para generar los scripts
para pruebas automatizadas. Este pro-
cedimiento para generar los scripts está
metodológicamente explicado y no da
lugar a errores u omisiones.
Algunos beneficios adicionales de cap-
turar los casos de prueba con el Manual
Tester son:
• Proporciona la posibilidad de colocar
imágenes para complementar los pasos y
contribuir a eliminar ambigüedad.
• Permite la reutilización de patrones de
prueba en diferentes pruebas.
• Incluye ingreso y verificación de datos
asistido durante la ejecución de las prue-
bas para reducir el error humano.
Conclusión
Más allá de las herramientas, es importante que se entien-
da el concepto que está detrás de todo esto. El principal
objetivo es lograr que los casos de prueba automatiza-
dos, que son la clave del éxito del desarrollo dirigido por
pruebas, no partan de una mala interpretación de los
requerimientos. El segundo y, no mucho menos impor-
tante, es encontrar la manera de que los programadores
no dejen de ser productivos por tener que escribir casos
de prueba automatizados para cada funcionalidad antes
de desarrollar. Este artículo resalta estas dos cuestiones
y dando un ejemplo de cómo resolverlas con un par de
herramientas en particular. Pero no es necesario que se
limiten a éstas. Los invito a que exploren las diferentes
herramientas para pruebas automatizadas disponibles
en el mercado, y tal como yo lo hice arriben a la solución
técnica que más les acomode, sin perder de vista los ob-
jetivos propuestos.
MAY-JUN 2006 15
 PRÁCTICAS

DISEÑO

Patrones de Diseño
COMBINA Y GANA
Por Eduardo Noriega

E
n este artículo, mostramos la fortaleza de utilizar y combinar Según este problema, necesitamos verificar cuentas bancarias y es-
diversos patrones de diseño en la solución de un problema. tado crediticio para diferentes países. Para solucionarlo, podemos
Para lo que desarrollamos un ejemplo en cuya solución utili- utilizar el patrón Abstract Factory. Que nos permite crear una clase
zamos los patrones Abstract Factory, Facade y Observer. concreta para cada país, y trabajar con ellas de una manera total-
mente uniforme, logrando que nuestra aplicación cliente se abstrai-
Como sabemos, los patrones de diseño, describen un problema ga de las complejidades de trabajar con uno u otro país.
que ocurre repetidas veces en algún contexto determinado del
desarrollo de software y entregan una buena solución ya pro- La solución se modelaría utilizando el siguiente diagrama UML.
bada. Esto ayuda, a diseñar correctamente en menos tiempo, a
construir soluciones reutilizables y extensibles, y facilita la docu-
mentación. Los patrones nos dicen cómo aplicar de manera eficaz
la herencia, el polimorfismo y todas las ventajas que posee el pa-
radigma orientado a objetos.

En el libro “Design Patterns: Elements of Reusable Object-Orien-

ted Software” (Erich Gamma, Richard Helm, Ralph Johnson y John
Vlissides), los autores presentan una excelente recopilación de
23 patrones, clasificados en patrones de creación, estructura y
conducta. Estos ofrecen excelentes soluciones a muchos de los
problemas, que como desarrolladores de software, encontramos
día con día.

Sin embargo, muchas veces, para solucionar un problema específico, no

basta con aplicar un determinado patrón, sino que, de manera creativa,
tenemos que combinar varios de ellos para conformar la solución. Por
lo tanto, mostraremos un problema y daremos su solución, combinando
varios de los patrones descritos en el libro antes mencionado.
Trabajemos entonces el siguiente problema
Se desea implementar una aplicación que verifique si un cliente
es elegible para un crédito hipotecario. Dicha verificación con-
sistiría en revisar sus cuentas bancarias y revisar su estado cre-
diticio. Estas operaciones de verificación son complejas y varían
de un país a otro. Deseamos que sea suficiente con cambiar un
parámetro, para que todas las verificaciones se hagan para un
determinado país. Además, que la incorporación de un nuevo
país al ambiente, sea algo sencillo. Deseamos además, que la
interfaz visual vaya mostrando como van avanzando cada una
de esas verificaciones.
En el diagrama podemos ver cómo obtendremos una clase abs-
tracta llamada AVerificador, la cual tendrá un método estático
GetPaís(). A ese método le pasaremos un indicador del país
que deseamos crear y nos devolverá una instancia de la clase
concreta con que se modela el país, ya sea México, USA u otra.
Esas clases concretas heredan de la clase abstracta AVerifica-
dor, que implementan los métodos comunes GetBanco(), Get-
Credito(), etcétera.
La clase Cliente declarará una variable del tipo AVerificador y la
instanciará a través del método estático GetPais() de esa misma
clase, obteniendo entonces una instancia del país en concreto.
De esa manera, bastará con cambiar el parámetro que le pasa-
mos al método GetPais y que indica el país con el que desea-
mos trabajar, para que toda la solución se enfoque en el país de
nuestro interés.

Eduardo Noriega de Armas es Director General del proyecto AprendaMas.Net (www.aprendamas.net). Realizó sus estudios de Licenciatura y Maestría en la Universi-
dad Central de Las Villas, en Cuba. Ha sido profesor en las Universidades Central de Las Villas en Cuba, Universidad de Guadalajara e Instituto Tecnológico y de Es-
tudios Superiores de Occidente (ITESO). Ha sido consultor en varias empresas y forma parte del equipo de desarrollo de la compañía Grupo Flextronics S.A. de C.V.

38 JUL-AGO 2006 www.softwareguru.com.mx

El método GetBanco() devolverá instancias de las clases Banco-
Mexico o BancoUSA, en dependencia del país con el que estemos
trabajando. Esas clases implementarán la interfaz IBanco, en la
que se declaran las características comunes de los bancos para
todos los países. De la misma manera, el método GetCredito() de-
volverá instancias de las clases CreditoMexico o CreditoUSA, en
dependencia del país desde donde se haya invocado. Esas dos
clases implementarán la interfaz ICredito, en la que se declaran
las características comunes de los créditos de todos los países.
La clase Cliente declarará variables del tipo IBanco e ICredito, a
las que, se le asignarán instancias de las clases BancoMexico,
BancoUSA, CreditoMexico o CreditoUSA, respectivamente. De
tal manera, podrá interactuar con las clases concretas de una
manera transparente, pues lo hará a través de las interfaces que
ellas implementan.
Así, tenemos nuestro problema solucionado en buena medida. No
obstante, el modelo puede mejorar. Sucede que la clase Cliente, va a
tener que declarar un Verificador, instanciar el país en concreto, obte-
ner su banco y su crédito e interactuar con ellos a través de sus inter-
faces. Lo que puede significar demasiada complejidad para un cliente;
mas si deseamos implementar diversos clientes para diversas tecno-
logías (digamos una aplicación Windows, una aplicación Web y otra
para móviles), sería mucho mejor extraer esa complejidad del cliente y
colocarla en una clase de alto nivel en la capa de negocio.
 PRÁCTICAS
DISEÑO
Esa clase, tratará toda la lógica del patrón Abstract Factory como un
subsistema, encapsulando su complejidad, ofreciendo al cliente una
sencilla y única interfaz; permitiendo que el trabajo del cliente sea lo
más sencillo posible.
La implementación de lo que hemos dicho, nos la da el patrón Faca-
de. Que nos sugiere la implementación de una Fachada que interac-
túe con el subsistema, ofreciendo al cliente una interfaz sencilla.
La solución se modelaría utilizando el siguiente diagrama UML:
Ya tenemos un cliente sencillo y una clase que hace la verificación
que deseamos. Sólo nos queda un punto por resolver. El problema
inicial dice “Deseamos además, que la interfaz visual vaya mostran-
do como van avanzando cada una de esas verificaciones”. ¿Cómo lo-
grar entonces que el cliente se entere que la Fachada de verificación
ha hecho cada uno de los pasos?
Nos podemos apoyar en el patrón Observer, que nos dice, cómo re-
lacionar dos clases pasando mensajes entre ellas, sin que esto con-
lleve al establecmiento de un acople fuerte. El patrón nos sugiere la
creación de una interfaz Sujeto (ISubject) que será el sujeto observa-
do, y una interfaz Observador (IObserver) que será quien se interese
por los cambios de estado en el sujeto.
ISubject ofrecerá un método Subscribe() que reciba un parámetro de
tipo IObserver, a través del cual un Observador podrá suscribirse a los
eventos del sujeto. Además, ofrecerá un método Unsubscribe(), que
también recibirá un IObserver para que éste se pueda desuscribir. Por
último, tendrá un método Notify, en el que recorra la lista de observa-
dores, invocándole a cada uno su método Update, para que el obser-
vador se entere que el sujeto cambió su estado y generó un evento.
40 JUL-AGO 2006
Por su parte, la interfaz IObserver ofrecerá ese método Update()
que será invocado por el sujeto, a través del cual, el observador se
enterará del cambio de estado en el sujeto y realizado una acción
al respecto.
La inclusión del patrón Observer en nuestra solución se refleja en el
siguiente diagrama:
Se observa en este caso, cómo la clase Cliente implementará
la interfaz IObserver, mientras que la clase FachadaVerif imple-
mentará la interfaz ISubject. A partir de ese momento, Cliente
se convierte en un Observador, mientras que FachadaVerif se
convierte en el sujeto observado. El Cliente entonces, se puede
suscribir a los eventos de la Fachada, y ésta, cuando verifique el
banco, invocará su método Notify para avisar al cliente que se
ha dado un paso. Pasará lo mismo cuando revise el crédito. De
tal manera el Cliente recibirá eventos a medida que se van ejecu-
tando los diferentes pasos de la verificación, además de contar
con la libertad de hacer ciertas acciones, como por ejemplo, ir
avanzando una barra de progreso, entre otras.
Así finalizamos este ejemplo. En él utilizamos tres patrones: el Abs-
tract Factory, el Facade y el Observer, para a través de su combina-
ción, obtener la solución a nuestro problema.
Referencias
• Profesional Design Patterns in VB.NET: Building Adaptable Applica-
tions. Tom Fischer, et al. Apress, 2003.
• Design Patterns: Elements of Reusable Object Oriented Design.
Erich Gamma, et al. Addison Wesley, 1995.
www.softwareguru.com.mx
´Fj‚ZhJhVW^a^YVY4
O9Œce9edi[]k_hbW
1PS
%POOB
.BVSFS

6OB
HSBO
QBSUF
EF
OVFTUSP
-P
BOUFSJPS
QBSFDF
VO
QPDP
SFEVOEBOUF
QFSP
&ORMAS )NCORRECTAS DE 3A
UJFNQP
TF
GSVTUSB
DPO
TJUJPT
XFC
EPOEF
OP
UJFOF
WBSJPT
QVOUPT
B
SFTBMUBS
Z
TF
EFCFO
UP BERSIUN3ISTEMAES5SABLE
FODPOUSBNPT
MB
JOGPSNBDJØO
RVF
CVTDBNPT
NBS
FO
DVFOUB
QBSB
DSFBS
TJTUFNBT
VTBCMFT &OUSF
MPT
FSSPSFT
NÈT
DPNVOFT
FTUÈ

$PO
QSPDFTBEPSFT
EF
UFYUP
RVF
QJFSEFO
IP 
-PT
VTVBSJPT
EF
VO
TJTUFNB
TF
FTQFDJGJDBO QFOTBS
RVF
DPO
IBDFS
VOB
EFNPT
SBT
EF
USBCBKP
TJ
TF
EB
VO
DMJD
FRVJWPDBEP

-PT
VTVBSJPT
UJFOFO
VO
DPOKVOUP
EF
NFUBT
USBDJØO
EF
VO
TJTUFNB
P
BQMJDBS
VOB

EFM
NPVTF
DPO
DPOUSPMFT
SFNPUPT
DPO
NV 
6O
TJTUFNB
EFCF
QFSNJUJS
B
MPT
VTVBSJPT
MP FODVFTUB
FOUSF
MPT
VTVBSJPT
ZB
FT
TVGJ
DIP
NÈT
CPUPOFT
EF
MPT
RVF
OFDFTJUBNPT
HSBS
EJDIBT
NFUBT
EF
GPSNB
FGJDJFOUF
DPO
MP
DJFOUF
QBSB
EFUFSNJOBS
TV
VTBCJMJEBE

DVBM
RVFEBSÈO
TBUJTGFDIPT
"VORVF
FTUBT
UÏDOJDBT
TPO
ÞUJMFT
QBSB

-B
VTBCJMJEBE
TF
WF
DPNP
MB
SFTQVFTUB
B
NV 
6O
TJTUFNB
TF
VUJMJ[B
EFOUSP
EF
VO
DPO PCUFOFS
SFUSPBMJNFOUBDJØO
OP
TPO
TV
DIBT
EF
FTUBT
GSVTUSBDJPOFT
FO
MB
JOUFSBDDJØO
UFYUP
FO
QBSUJDVMBS
QPS
FKFNQMP
CBKP
VO
GJDJFOUFT
QBSB
EFUFSNJOBS
TJ
VO
TJTUFNB

DPO
UFDOPMPHÓB
&TUF
BSUÓDVMP
QSFUFOEF
EBS
VO
BNCJFOUF
FTQFDÓGJDP
 FT
VTBCMF
$POTVMUBS
DPO
FYQFSUPT
FO

QBOPSBNB
TPCSF
MP
RVF
MB
VTBCJMJEBE
FT
Z
OP
VTBCJMJEBE
OPT
QVFEF
TFSWJS
QBSB
PCUF
FT

%F
MB
NJTNB
NBOFSB
SFDPNJFOEB
BMHV z#ØMO3ABERSIUN3ISTEMA OFS
SFDPNFOEBDJPOFT
4JO
FNCBSHP
OP

OBT
BDUJWJEBEFT
RVF
TF
EFCFO
MMFWBS
B
DBCP
QBSB
ES5SABLE QPEFNPT
DBMJGJDBS
MB
VTBCJMJEBE
EF
VO

DSFBS
TJTUFNBT
NÈT
VTBCMFT
Z
FYQMJDB
DØNP
TF
-B
ÞOJDB
GPSNB
EF
BWFSJHVBSMP
FT
PCTFSWBOEP
TJTUFNB
FO
CBTF
B
MB
PQJOJØO
EF
VO
FY
QVFEFO
JODPSQPSBS
EJDIBT
BDUJWJEBEFT
B
MPT
B
TVT
VTVBSJPT
VUJMJ[BSMP
QBSB
MMFWBS
B
DBCP
BD QFSUP
ZB
RVF
ÏTUF
OP
FT
SFQSFTFOUBUJWP

QSPZFDUPT UJWJEBEFT
SFBMFT
&TUP
TF
DPOPDF
DPNP
QSVFCBT
EFM
HSVQP
EF
VTVBSJPT
SFBMFT
EF
VTBCJMJEBE

z1UÏES5SABILIDAD &O
MBT
QSVFCBT
EF
VTBCJMJEBE
MPT
PCTFSWBEP ,A5SABILIDADCOMO0ROCESO
&M
UÏSNJOP
VTBCJMJEBE
TF
QVFEF
SFGFSJS
B
SFT
OP
MF
FOTF×BO
B
MPT
QBSUJDJQBOUFT
DØNP
1BSB
DSFBS
VO
TJTUFNB
VTBCMF
TF
SFDP
EPT
DPODFQUPT VUJMJ[BS
FM
TJTUFNB
Z
UBNQPDP
DPOUFTUBO
QSF NJFOEB
TFHVJS
VO
QSPDFTP
EF
EJTF×P
DFO

-B
VTBCJMJEBE
DPNP
BUSJCVUP
EF
DBMJEBE
EF
HVOUBT
EFCF
TFS
DPNP
TJ
MPT
QBSUJDJQBOUFT
USBEP
FO
FM
VTVBSJP
EPOEF
TF
JOWPMVDSB
B

VO
TJTUFNB
1PS
FKFNQMP
i/FDFTJUBNPT
EFTB FTUVWJFSBO
TPMPT
MPT
VTVBSJPT
EVSBOUF
FM
EFTBSSPMMP
EFM
TPGU
SSPMMBS
VOB
JOUSBOFU
VTBCMFw )BZ
USFT
GBDUPSFT
DMBWF
QBSB
SFBMJ[BS
MBT
QSVFCBT
XBSF
Z
TF
SFBMJ[BO
QSVFCBT
EF
VTBCJMJEBE


-B
VTBCJMJEBE
DPNP
VO
QSPDFTP
RVF
TF
EF
VTBCJMJEBE
FO
EJWFSTBT
FUBQBT
EFM
QSPZFDUP
&M
EJTF×P

BQMJDB
EVSBOUF
VO
QSPZFDUP
&TUP
UBNCJÏO
TF
t
-PT
QBSUJDJQBOUFT
EFCFO
TFS
VTVBSJPT
BD DFOUSBEP
FO
FM
VTVBSJP
FT
VO
DPOKVOUP
EF

DPOPDF
DPNP
iJOHFOJFSÓB
EF
VTPw
P
iEJTF×P
UVBMFT
P
GVUVSPT
EFM
TJTUFNB
6O
FSSPS
DP BDUJWJEBEFT
Z
UÏDOJDBT
DVZP
PCKFUJWP
FT

DFOUSBEP
FO
FM
VTVBSJPw
NÞO
FT
EFKBS
RVF
MPT
HFSFOUFT
QSVFCFO
FM
DSFBS
VO
TJTUFNB
VTBCMF
5BMFT
BDUJWJEBEFT

TJTUFNB
FO
MVHBS
EF
MPT
PQFSBEPSFT
RVF
TF
QVFEFO
JODMVJS
B
USBWÏT
EF
MBT
FUBQBT
EF

5SABILIDADCOMO!TRIBUTO TPO
MPT
RVF
SFBMNFOUF
WBO
B
VUJMJ[BS
FM
TJT EFTBSSPMMP
EF
VO
TPGUXBSF
EFTEF
FM
DPO
1BSB
EFGJOJS
VTBCJMJEBE
DPNP
BUSJCVUP
EF
DB UFNB
VOB
WF[
RVF
FTUÏ
FO
QSPEVDDJØO
DFQUVBM
IBTUB
MBT
QSVFCBT
GJOBMFT
Z
BVO
FO

MJEBE
FDIFNPT
VO
WJTUB[P
B
MB
EFGJOJDJØO
RVF
t
-PT
QBSUJDJQBOUFT
EFCFO
JOUFOUBS
SFBMJ FM
NBOUFOJNJFOUP
Z
TPQPSUF
/P
FT
VOB

VUJMJ[B
MB
OPSNB
*40
 [BS
MBT
UBSFBT
RVF
OPSNBMNFOUF
SFBMJ[B SFDFUB
QBTP
B
QBTP
&T
NÈT
VOB
GJMPTPGÓB

i-B
NFEJEB
FO
RVF
VO
QSPEVDUP
QVFEF
TFS
SÓBO
DPO
FM
TJTUFNB
&T
DSVDJBM
RVF
FTUBT
RVF
VOB
NFUPEPMPHÓB
4F
USBUB
EF
HFOVJ
VUJMJ[BEP
QPS
VTVBSJPT
FTQFDÓGJDPT
QBSB
BM UBSFBT
TFBO
SFBMJTUBT OBNFOUF
CVTDBS
MB
DSFBDJØO
EF
BMHP
RVF

DBO[BS
NFUBT
FTQFDÓGJDBT
EF
GPSNB
FGFDUJWB
t
&M
DPOUFYUP
CBKP
FM
RVF
TF
SFBMJ[B
MB
QSVF QVFEB
VUJMJ[BSTF
QPS
VOB
BVEJFODJB
SFBM

Z


FGJDJFOUF
Z
TBUJTGBDUPSJB
EFOUSP
EF
VO
DPO CB
EFCF
TFS
MP
NÈT
DFSDBOP
QPTJCMF
BM
DPO SFDPSEBS
RVF
FM
TJTUFNB
FT
QBSB
TVT
VTVB
UFYUP
EF
VTPw UFYUP
SFBM
FO
RVF
FM
TJTUFNB
TF
VUJMJ[BSÈ
SJPT
Z
OP
QBSB
TVT
EFTBSSPMMBEPSFT

$ONNA-AURER
ESCONSULTORAENDISE×ODEINTERFACESYARQUITECTURADEINFORMACIØN#ONMÉSDEA×OSDEEXPERIENCIAYHAFACILITADOMÉSDEPRUEBASDEUSABI
LIDAD$ONNACONTINUAMENTESORPRENDEASUSCOLEGASALHABLARCONGENTEENVEZDEHACERLOCONCOMPUTADORASYDISE×ARALAANTIGàITACONLÉPIZMARCADORESYHOJAS
DECOLORESMAADMOBCOMAUDONNABLOG

WWWSOFTWAREGURUCOMMX 3%0 /#4 

  3<>=@B/2/  B@./6961.1 

h!HORAMISMO
ERESUNPRISIONERO
DECADAAPLICACIØN
QUEUSASv
ˆ4HEODOR
(OLM.ELSON

&M
EJTF×P
DFOUSBEP
FO
FM
VTVBSJP
JO t
1FSDFQDJØO
-B
QFSDFQDJØO
TF
SFGJFSF
B
DJFOEP
NPEFMPT
NFOUBMFT
EF
DØNP
GVODJP
WPMVDSB
USFT
BTQFDUPT
QSJNPSEJBMFT MB
NBOFSB
FO
RVF
MBT
QFSTPOBT
DBQUBNPT
Z
OBO
MBT
DPTBT
&OUFOEFS
EJDIPT
NPEFMPT
OPT


$POPDFS
MBT
IBCJMJEBEFT
Z
MJNJUB PSHBOJ[BNPT
JOGPSNBDJØO
*OWPMVDSB
MB
BE QVFEF
BZVEBS
B
EJTF×BS
NFKPSFT
TJTUFNBT
ZB

DJPOFT
IVNBOBT RVJTJDJØO
EF
JOGPSNBDJØO
B
USBWÏT
EF
MPT
DJO RVF
OPT
EBO
VOB
HVÓB
TPCSF
iDØNP
QJFOTBOw


%JTF×BS
QBSB
VO
HSVQP
QBSUJDVMBS
DP
TFOUJEPT
DMÈTJDPT
NÈT
MB
QSPQJPDFQDJØO
OVFTUSPT
VTVBSJPT

EF
QFSTPOBT DPODJFODJB
EF
OVFTUSPT
NPWJNJFOUPT

Z
FM


5SBCBKBS
DPO
EJDIBT
QFSTPOBT
B
USB CBMBODF
-B
WJTUB
FT
FM
TFOUJEP
NÈT
SFMFWBOUF

%JTF×BS
QBSB
MPT
VTVBSJPT
&M
TFHVOEP

WÏT
EFM
QSPDFTP QBSB
FM
EJTF×P
EF
TJTUFNBT
DPNQVUBDJPOBMFT QVOUP
DSVDJBM
TPCSF
FM
EJTF×P
DFOUSBEP
FO

FM
VTVBSJP
FTUÈ
SFMBDJPOBEP
DPO
EJTF×BS
BMHP


$POPDFS
B
MBT
QFSTPOBT t
5PNB
EF
EFDJTJPOFT
&YJTUF
MB
DSFFODJB
EF
RVF
QBSB
VO
DPOKVOUP
QBSUJDVMBS
EF
QFSTPOBT
FT

1BSB
EJTF×BS
TJTUFNBT
VTBCMFT
MP
QSJ MPT
TFSFT
IVNBOPT
UPNBNPT
EFDJTJPOFT
EF
GPSNB
EFDJS
MPT
GVUVSPT
VTVBSJPT
EFM
TJTUFNB
1BSB

NFSP
RVF
TF
OFDFTJUB
FT
FOUFOEFS
MBT
MØHJDB
&TUP
FT
RVF
BOBMJ[BNPT
UPEBT
MBT
PQDJP EJTF×BS
VO
TJTUFNB
VTBCMF
SFRVFSJNPT
DPOP
IBCJMJEBEFT
Z
MJNJUBDJPOFT
EF
MPT
TFSFT
OFT
Z
FMFHJNPT
MB
RVF
DPOTJEFSBNPT
NÈT
DPOWF DFS
Z
FOUFOEFS
B
FTUBT
QFSTPOBT

IVNBOPT
"
DPOUJOVBDJØO
MJTUBNPT
BM OJFOUF
4JO
FNCBSHP
MB
NBZPSÓB
EF
MBT
EFDJTJPOFT

HVOBT
DBSBDUFSÓTUJDBT
DMBWF
Z
EF
TVNB
OP
TF
UPNBO
BTÓ
&O
DBNCJP
MP
RVF
UÓQJDBNFOUF
t
*EFOUJGJDBS
B
MPT
VTVBSJPT
&O
NVDIPT

JNQPSUBODJB
QBSB
MB
VTBCJMJEBE
QFSP
TVDFEF
FT
RVF
OPT
DPOGPSNBNPT
DPO
MB
QSJNFSB
TJTUFNBT
FT
GÈDJM
EFUFSNJOBS
RVJÏOFT
TPO
MPT

IBZ
NVDIBT
PUSBT
EFQFOEJFOEP
EF
SFTQVFTUB
SB[POBCMF
RVF
SFTVFMWF
VOB
TJUVBDJØO
VTVBSJPT
5BM
FT
FM
DBTP
EF
MB
NBZPSÓB
EF
MBT

DBEB
BVEJFODJB
Z
TJTUFNB
FTQFDÓGJDP "TÓ
RVF
EFCFNPT
FTUBS
DPOTDJFOUFT
EF
RVF
OVFT BQMJDBDJPOFT
EF
OFHPDJP
RVF
TF
EFTBSSPMMBO
B

USPT
VTVBSJPT
NVZ
QSPCBCMFNFOUF
OP
MFBO
UPEB
MB
NFEJEB
QBSB
VOB
BVEJFODJB
MJNJUBEB
Z
DP
t
.FNPSJB
-B
NFNPSJB
IVNBOB
UJF MB
JOGPSNBDJØO
RVF
MFT
QSFTFOUBNPT
TJOP
RVF
OPDJEB
4JO
FNCBSHP
OP
TJFNQSF
MPT
VTVBSJPT

OF
NVDIBT
MJNJUBDJPOFT
&OUSF
FMMBT
MB
MMFHBSÈO
IBTUB
MB
JOGPSNBDJØO
RVF
OFDFTJUBO
P
TPO
UBO
DPOPDJEPT
P
UBO
IPNPHÏOFPT
1PS

DBQBDJEBE
EF
NFNPSJB
iFO
USBCBKPw
Z
DSFFO
RVF
OFDFTJUBO

Z
ZB
OP
MFFSÈO
FM
SFTUP FKFNQMP
JNBHJOFNPT
FM
DBTP
EF
VO
QPSUBM
EF

QBSB
QPEFS
HVBSEBS
BMHP
FO
NFNPSJB
TFSWJDJPT
QÞCMJDPT
EF
MBSHP
QMB[P
SFRVFSJNPT
FTUVEJBS t
#ÞTRVFEB
EF
JOGPSNBDJØO
-BT
QFSTPOBT

MP
P
FOTBZBSMP
DPO
DJFSUB
EFEJDBDJØO
SFBMJ[BNPT
CÞTRVFEBT
EF
EPT
NBOFSBT
EJGF t
$POPDFS
B
MPT
VTVBSJPT
6OB
WF[
RVF

-PT
TJTUFNBT
VTBCMFT
NJOJNJ[BO
MB
SFOUFT
-B
QSJNFSB
FT
DVBOEP
TBCFNPT
FYBD UFOFNPT
JEFOUJGJDBEPT
B
OVFTUSPT
VTVBSJPT

DBOUJEBE
EF
JOGPSNBDJØO
RVF
TF
EFCF
UBNFOUF
DVÈM
FT
MB
JOGPSNBDJØO
RVF
CVTDBNPT
EFCFNPT
BQSFOEFS
TPCSF
FMMPT
Z
FOUFO
NFNPSJ[BS
&TUP
QVFEF
JOWPMVDSBS
FM
TBCFNPT
RVF
FYJTUF
Z
QPEFNPT
FYQMJDBS
MP
RVF

EFS
RVÏ
FT
MP
RVF
OFDFTJUBO
EFM
TJTUFNB
FO

EFTQMJFHVF
EF
JOGPSNBDJØO
SFMFWBOUF
CVTDBNPT
B
FTUF
UJQP
EF
CÞTRVFEB
TF
MF
DPOP DVFTUJØO
-BT
UÏDOJDBT
NÈT
ÞUJMFT
JOWPMV
SFDPSEBUPSJPT

FO
QVOUPT
BEFDVBEPT
DF
DPNP
iFMFNFOUP
DPOPDJEPw
&M
PUSP
UJQP
FT
DSBO
PCTFSWBS
B
MBT
QFSTPOBT
Z
IBCMB
DPO

P
QPS
FKFNQMP
QSPWFFS
PQDJPOFT
GMFYJ MB
FYQMPSBUPSJB
FO
MB
DVBM
OP
FTUBNPT
TFHVSPT
FMMBT
TPCSF
MBT
BDUJWJEBEFT
RVF
SFBMJ[BO
FO

CMFT
QBSB
FM
NBOFKP
EF
DPOUSBTF×BT EF
RVÏ
FT
MP
RVF
CVTDBNPT
OJ
TBCFNPT
DØNP
MVHBS
EF
QSFHVOUBSMFT
EJSFDUBNFOUF
MP
RVF

EFGJOJSMP
QSFDJTBNFOUF
&T
JNQPSUBOUF
DPOPOFDFTJUBO
IBDFSMP
OP
FT
CVFOB
QSÈDUJDB
ZB

t
&SSPSFT
1PEFNPT
FTUBS
TFHVSPT
EF
RVF
DFS
BNCPT
DPNQPSUBNJFOUPT
EF
CÞTRVFEB
ZB
RVF
MB
HFOUF
UÓQJDBNFOUF
TF
CBTB
FO
MBT
DB
MPT
VTVBSJPT
EF
OVFTUSPT
TJTUFNBT
UBSEF
P
RVF
DJFSUPT
NÏUPEPT
GVODJPOBO
NFKPS
QBSB
SBDUFSÓTUJDBT
RVF
ZB
DPOPDF
EF
VO
TJTUFNB

UFNQSBOP
DPNFUFSÈO
FSSPSFT
QPSRVF
UP CÞTRVFEBT
EF
FMFNFOUP
DPOPDJEP
Z
PUSPT
F
JHOPSB
PUSBT
QPTJCJMJEBEFT
RVF
QPESÓBO

EBT
MBT
QFSTPOBT
FTUBNPT
TVKFUBT
B
FRVJ QBSB
CÞTRVFEBT
FYQMPSBUPSJBT FYJTUJS
1BSB
DPOPDFS
NÈT
TPCSF
OVFTUSPT

WPDBSOPT
6O
TJTUFNB
VTBCMF
EFCF
FTUBS
VTVBSJPT
QPEFNPT
BQMJDBS
EJTUJOUBT
UÏDOJ
EJTF×BEP
QBSB
UPMFSBS
FSSPSFT
P
QPEFS
t
.PEFMPT
NFOUBMFT
6OB
NBOFSB
FO
RVF
DBT
UBMFT
DPNP
FOUSFWJTUBT
FODVFTUBT
GPDVT

SFDVQFSBSTF
GÈDJMNFOUF
EF
FMMPT
MBT
QFSTPOBT
FOUFOEFNPT
FM
NVOEP
FT
IB HSPVQT
Z
PCTFSWBDJØO

 3%0 /#4 WWWSOFTWAREGURUCOMMX

t
$PNVOJDBS
MBT
OFDFTJEBEFT
EF
MPT
VTVB UP
FO
FUBQBT
FO
MBT
RVF
FT
NVZ
UFNQSBOP
QBSB
#ONCLUSIØN
SJPT
&T
JNQPSUBOUF
DPNVOJDBS
MBT
DBSBDUF QPEFS
IBDFS
QSVFCBT
EF
VTBCJMJEBE
-PT
TJTUFNBT
DPO
BMUB
VTBCJMJEBE
QSP
SÓTUJDBT
Z
OFDFTJEBEFT
EF
MPT
VTVBSJPT
B
PUSPT
WFFO
CFOFGJDJPT
TVTUBODJBMFT
UBOUP

JOWPMVDSBEPT
FO
FM
QSPZFDUP
EF
UBM
GPSNB
t
5BSKFUBT
EF
JOGPSNBDJØO
&TUB
UÏDOJDB
FT
ÞUJM
QBSB
MPT
VTVBSJPT
DPNP
QBSB
MBT
PS
RVF
UPEPT
TF
QVFEBO
FOGPDBS
FO
MBT
OFDFTJ QBSB
EFGJOJS
MB
FTUSVDUVSB
EF
JOGPSNBDJØO
EF
HBOJ[BDJPOFT
6O
TJTUFNB
RVF
QFSNJ
EBEFT
EF
MPT
VTVBSJPT
6OB
IFSSBNJFOUB
ÞUJM
VO
TJTUFNB
JOGPSNBUJWP
UBM
DPNP
VO
TJUJP
XFC
UF
B
MBT
QFSTPOBT
SFBMJ[BS
BDUJWJEBEFT

QBSB
MPHSBSMP
FT
MB
DSFBDJØO
EF
iQFSTPOBKFTw
-P
RVF
TF
IBDF
FT

DSFBS
EJTUJOUBT
UBSKFUBT
Z
EF
NBOFSB
SÈQJEB
Z
TFODJMMB
SFTVMUBSÈ

GJDUJDJPT
RVF
SFQSFTFOUBO
FM
QFSGJM
UÓQJDP
EF
FO
DBEB
VOB
FTDSJCJS
FKFNQMPT
EF
JOGPSNBDJØO
VO
BIPSSP
EF
UJFNQP
Z
EJOFSP
QBSB
MB

OVFTUSPT
VTVBSJPT
P
EF
VO
DPOKVOUP
0USB
RVF
QPESÓB
DPOUFOFS
FM
TJTUFNB
1PTUFSJPSNFO PSHBOJ[BDJØO
IFSSBNJFOUB
FGJDB[
FT
FM
EFTBSSPMMP
EF
FTDF UF
TF
SFQBSUFO
MBT
UBSKFUBT
B
MPT
VTVBSJPT
Z
TF
MFT

OBSJPT
EF
VTP
RVF
TPO
QFRVF×BT
IJTUPSJBT
QJEF
RVF
MBT
PSHBOJDFO
FO
HSVQPT
&T
QPTJCMF
DSFBS
TJTUFNBT
VTBCMFT

RVF
EFTDSJCFO
DØNP
VO
VTVBSJP
SFBMJ[BSÈ
BQSFOEJFOEP
TPCSF
MBT
IBCJMJEBEFT
Z

DJFSUB
UBSFB
-PT
DBTPT
EF
VTP
TF
CBTBO
FO
t
4FTJPOFT
EF
QSJPSJ[BDJØO
&O
FTUBT
TFTJP MJNJUBDJPOFT
IVNBOBT
BQSFOEJFOEP

FTUF
DPODFQUP
OFT
TF
EB
B
MPT
VTVBSJPT
VOB
MJTUB
EF
GVODJP TPCSF
MPT
VTVBSJPT
EF
VO
TJTUFNB
Z

OBMJEBEFT
Z
TF
MFT
QJEF
RVF
MB
PSEFOFO
EF
USBCBKBOEP
DPO
FMMPT
EVSBOUF
FM
EF

5SBCBKBS
DPO
MPT
VTVBSJPT BDVFSEP
B
EJGFSFOUFT
DSJUFSJPT
1PS
FKFNQMP
TBSSPMMP
EF
VO
QSPEVDUP
3FBMJ[BSMP

&M
UFSDFS
BTQFDUP
EFM
EJTF×P
DFOUSBEP
FO
RVÏ
UBOUP
MB
VUJMJ[BO
RVÏ
UBO
JNQPSUBOUF
FT
QVFEF
TJHOJGJDBS
USBCBKP
BEJDJPOBM

VTVBSJPT
TF
SFGJFSF
B
JOWPMVDSBS
B
MPT
VTVBSJPT
P
RVÏ
UBO
SÈQJEP
EFCFSÓB
QPEFS
BDDFEFSMB
QFSP
DPOUSJCVZF
GVFSUFNFOUF
BM
ÏYJUP

EVSBOUF
FM
EFTBSSPMMP
EFM
TJTUFNB
&YJTUFO
EJT &TUB
FT
VOB
GPSNB
QSÈDUJDB
EF
QSJPSJ[BS
MPT
EF
VO
TPGUXBSF
%FTQVÏT
EF
UPEP
FT

UJOUBT
UÏDOJDBT
QBSB
MPHSBSMP
UBMFT
DPNP SFRVFSJNJFOUPT
EF
VO
TJTUFNB JSSFMFWBOUF
RVF
VO
TPGUXBSF
TF
IBZB

EFTBSSPMMBEP
FO
UJFNQP
P
FO
DPTUP
TJ

t
%JTF×P
DPMBCPSBUJWP
4F
SFBMJ[BO
TFTJPOFT
t
1SPUPUJQPT
FO
QBQFM
4F
DSFBO
MÈNJOBT
BM
GJOBM
OP
TF
VTB
EPOEF
TF
KVOUBO
EJTF×BEPSFT
EFTBSSPMMBEP DPO
EJCVKPT
EF
MBT
QBOUBMMBT
EFM
TJTUFNB
RVF

SFT
VTVBSJPT
GJOBMFT
Z
VTVBSJPT
EF
OFHPDJP
UFOHBO
TVGJDJFOUF
EFUBMMF
DPNP
QBSB
QPEFS

QBSB
QMBUJDBS
TPCSF
FM
EJTF×P
EF
VO
TJTUF FYQMJDBS
TV
VTP
-BT
MÈNJOBT
TF
VUJMJ[BO
QBSB
-B
WFSTJØO
PSJHJOBM
EF
FTUF
BSUÓDVMP
TF

NB
&M
PCKFUJWP
OP
FT
RVF
MPT
VTVBSJPT
TFBO
OBSSBS
FTDFOBSJPT
EF
VTP
-B
SB[ØO
QPS
MB
FODVFOUSB
QVCMJDBEB
FO

RVJFOFT
EJTF×FO
FM
TJTUFNB
TJOP
FOUFOEFS
RVF
MBT
MÈNJOBT
UJFOFO
EJCVKPT
FO
MVHBS
EF
XXXTUFQUXPDPNBVQBQFST
NFKPS
TVT
OFDFTJEBEFT
Z
BDMBSBS
DØNP
FT
TDSFFO
TIPUT
FT
QBSB
EFKBS
DMBSP
RVF
FM
TJTUFNB
LND@XIBUJTVTBCJMJUZJOEFYIUNM
RVF
FM
TJTUFNB
MBT
TPQPSUBSÈ
UPEBWÓB
FTUÈ
FO
EFTBSSPMMP
%F
PUSB
NBOFSB
-B
WFSTJØO
RVF
QSFTFOUBNPT
FO
FTUBT

MPT
VTVBSJPT
QVFEFO
UFOFS
MB
JEFB
EF
RVF
FM
QÈHJOBT
GVF
USBEVDJEB
Z
FEJUBEB
QPS

t
3FWJTJPOFT
EF
EJTF×P
XBMLUISPVHIT

-BT
TJTUFNB
ZB
FTUÈ
iQSÈDUJDBNFOUF
MJTUPw
TJN 1FESP
(BMWÈO
DPO
MB
BVUPSJ[BDJØO
EF

SFWJTJPOFT
TJSWFO
QBSB
WFSJGJDBS
EFDJTJPOFT
EF
QMFNFOUF
QPSRVF
ZB
TF
UJFOFO
MBT
QBOUBMMBT 4UFQ
5XP
%FTJHOT
1UZ
-UE
EJTF×P
Z
PCUFOFS
SFUSPBMJNFOUBDJØO
BM
SFTQFD

WWWSOFTWAREGURUCOMMX 3%0 /#4 

  >@Ê1B71/A  6;42;62?Ì. 12 @<3AD.?2 

"OUJQBUSPOFT
-B
.FKPS
'PSNB
EF
)BDFS
VO
1nTJNP
4JTUFNB
EF
4PGUXBSF
1PS
+BWJFS
(PO[gMF[
4gODIF[

, PT
BOUJQBUSPOFT
UBNCJnO
MMBNBEPT

USBNQBT
TPO
FKFNQMPT
CJFO
EPDV
NFOUBEPT
EF
NBMBT
TPMVDJPOFT
QBSB
QSP
BOBMPHrB
QPESrBNPT
QFOTBS
RVF
TJ
OFDFTJ
UBT
EJOFSP
UJFOFT
EPT
PQDJPOFT
FM
QBUSwO

CVFO
DPNQPSUBNJFOUP

USBCBKBS
BSEVB
CMFNBT
4F
FTUVEJBO
B
GJO
EF
QPEFSMPT
NFOUF
P
FM
BOUJQBUSwO
SgQJEP
Z
DPO
DPO
FWJUBS
FO
FM
GVUVSP
Z
FO
TV
DBTP
QBSB
RVF
TFDVFODJBT
B
MBSHP
QMB[P

SPCBS
VO
CBODP
TV
QSFTFODJB
QVFEB
TFS
SFDPOPDJEB
GgDJM
NFOUF
BM
JOWFTUJHBS
TJTUFNBT
EJTGVODJPOB &M
NJTNP
DPODFQUP
TF
BQMJDB
GgDJMNFOUF

MFT
EVSBOUF
VOB
BVEJUPSJB FO
JOHFOJFSrB
Z
FO
PUSBT
BDUJWJEBEFT
EPO
EF
FTUn
QSFTFOUF
FM
FTGVFS[P
IVNBOP
"Tr

&M
UnSNJOP
BOUJQBUSwO
TF
PSJHJOB
DPNP
BOUJQBUSPOFT
DPNP
SFJOWFOUBS
MB
SVFEB

VOB
DPOUSB
QBSUF
BM
UnSNJOP
QBUSwO
BDV MB
DPTB
FM
QSPHSBNB
%JPT
DBTBSTF
DPO
FM

vBEP
FO
BSRVJUFDUVSB
EF
TPGUXBSF
QBSB
EJBCMP
MB
UVCFSrB
EF
MB
FTUVGB
DPSO
DPC

EFGJOJS
MBT
CVFOBT
QSgDUJDBT
EF
QSPHSB KVOUPT
QFSP
OP
SFWVFMUPT

FUDnUFSB
%F
NBDJwO
EJTFvP
P
HFTUJwO
EF
TJTUFNBT
%F
KBO
MB
FOTFvBO[B
EF
DVgM
FT
MB
NFKPS
GPS
UBM
NBOFSB
QPESrBNPT
IBCMBS
EF
RVF
VO
NB
EF
OP
IBDFS
TJTUFNBT
EF
DwNQVUP

TJTUFNB
²CJFO
IFDIP³
FTUg
MMFOP
EF
QBUSP
OFT
Z
EFCFSrB
DBSFDFS
EF
BOUJQBUSPOFT
&O
MB
FMBCPSBDJwO
EF
VO
TJTUFNB
JOUFS
BM
NFOPT
FTF
TFSrB
VO
TJTUFNB
JEFBM WJFOFO
BM
NFOPT
EJWFSTPT
BDUPSFT
BS
RVJUFDUPT
EF
TPGUXBSF
BENJOJTUSBEPSFT
EFOBEB
DPO
QPDB
EPDVNFOUBDJwO
Z
QPDB

4J
BQMJDBNPT
VOB
BOBMPHrB
TPDJBM
QPESrB EF
QSPZFDUP
Z
EFTBSSPMMBEPSFT
1BSB
DBEB
DMBSJEBE
EF
TV
GVODJwO
FO
FM
TJTUFNB
$PO
NPT
EFDJS
RVF
TJ
B
U|
BNJHP
MFDUPS
OP
DBFT
VOP
EF
FMMPT
FYJTUFO
BOUJQBUSPOFT
RVF
GPSNF
FM
TJTUFNB
BWBO[B
FO
TV
EFTBSSPMMP

FO
FM
BOUJQBUSwO

OPNCSnNPTMF
FTUFSFP EFTDSJCFO
DPNQPSUBNJFOUPT
Z
TPMVDJPOFT
Z
DSFDF
TF
EJDF
RVF
FTUPT
GMVKPT
EF
MBWB

UJQPT

EF
DSJNJOBM
UFSSPSJTUB
QFSWFSUJEP
JODPSSFDUBT
-PT
BOUJQBUSPOFT
VOB
WF[
DP TF
TPMJEJGJDBO
FT
EFDJS
TF
WVFMWF
NVDIP

ESPHBEJDUP
CSVKP
EJDUBEPS
Z
TJNJMBSFT
OPDJEPT

DPOTUJUVZFO
QBSB
DBEB
VOP
EF
MPT
NgT
DPNQMJDBEP
DPSSFHJS
MPT
QSPCMFNBT

FOUPODFT
QPESrBNPT
BGJSNBS
RVF
OP
FSFT
BDUPSFT
JOWPMVDSBEPT
EFTDSJQDJPOFT
EF
RVF
PSJHJOBO
Z
FM
EFTPSEFO
WB
DSFDJFOEP

VOB
NBMB
QFSTPOB
-P
DVBM
OP
JNQMJDB
RVF
QSPCMFNBT
SFDVSSFOUFT
FO
MB
DPOTUSVDDJwO
HFPNnUSJDBNFOUF
TFBT
CVFOB
QBSB
TFSMP
EFCFSrBT
OP
TwMP
EF
TPGUXBSF
MFT
QSPQPSDJPOBO
VO
WPDBCV
OP
FODBKBS
FO
MPT
BOUJQBUSPOFT
NFODJP MBSJP
DPN|O
QBSB
JEFOUJGJDBS
QSPCMFNBT
Z
&TUP
TF
IBDF
QBUFOUF
DVBOEP

4F
EFDMB
OBEPT
TJOP
BEFNgT
DVNQMJS
DPO
VOP
P
EJTDVUJS
QPTJCMFT
TPMVDJPOFT
Z
MFT
TVHJF SBO
WBSJBCMFT
OP
KVTUJGJDBEBT

4F
DPOT
NgT
QBUSPOFT
MMBNnNPTMF
DVBMJEBEFT

SFO
QBTPT
QBSB
MB
SFJOHFOJFSrB
Z
SFPSHB USVZFO
DMBTFT
P
CMPRVFT
EF
DwEJHP
NVZ

IPOFTUP
USBCBKBEPS
CVFO
IJKP
ZP
CVFO
OJ[BDJwO
FTUSVDUVSBM
EF
VO
TJTUFNB HSBOEFT
Z
DPNQMFKBT
TJO
EPDVNFOUBS
P

QBESF
FUDnUFSB RVF
OP
TF
SFMBDJPOBO
DMBSBNFOUF
DPO
MB

!NTI PATRONESDE#ODIFICACIØN BSRVJUFDUVSB

6TBOEP
VO
JODPOTJTUFOUF

-PT
BOUJQBUSPOFT
FO
BSRVJUFDUVSB
EF
TPGU 3FWJTFNPT
BMHVOBT
UnDOJDBT
QBSB
DPEJGJ Z
EJGVTP
FTUJMP
EF
FWPMVDJwO
EF
VOB
BSRVJ
XBSF
TPO
TJNJMBSFT
B
TVT
BOgMPHPT
TPDJB DBDJwO
JODPSSFDUB
EF
TPGUXBSF
UFDUVSB

$VBOEP
FO
FM
TJTUFNB
FYJTUFO

MFT
TPMVDJPOFT
OFHBUJWBT
BDDJPOFT
RVF
NVDIBT
gSFBT
DPO
DwEJHP
QPS
UFSNJOBS
P

QSFTFOUBO
NBZPSFT
QSPCMFNBT
RVF
TPMV 
-BWB
'MPX
"MHP
BTr
DPNP
²QSPHSBNBS
SFFNQMB[BS

:
DMBSP
DVBOEP
EFKBNPT

DJPOFT
4JO
FNCBSHP
SFQSFTFOUBO
VO
DBNJ BM
FTUJMP
WPMDgO³

&T
DPOTUSVJS
HSBOEFT
DwEJHP
TJO
VTP
BCBOEPOBEP
JOUFSGBDFT
P

OP
GgDJM
Z
SgQJEP
1FSP
DPOUJOVBOEP
DPO
MB
DBOUJEBEFT
EF
DwEJHP
EF
NBOFSB
EFTPS DPNQPOFOUFT
PCTPMFUPT
FO
FM
DVFSQP
EFM

*AVIER'ONZÉLEZ3ÉNCHEZESPROFESORTIEMPOCOMPLETODEL4ECNOLØGICODE-ONTERREYCAMPUS'UADALAJARAYCONSULTORINDEPENDIENTEPARADIFERENTESEMPRESASDESA

,UIS2#UELLARES$IRECTORDE#ALIDADANIVELMUNDIALDE3OFTTEK)NFORMATION3ERVICES,UISESRECONOCIDOPORLA!MERICAN3OCIETYFOR
1UALITY!31 COMO#ERTIlED1UALITY-ANAGER#ERTIlED3OFTWARE%NGINEERY3IX3IGMA"LACK"ELT%NLOSÞLTIMOSCINCOA×OSHAESTADOA
RROLLADORASDESOFTWARE#UENTACONUNAMAESTRÓAEN)NGENIERÓACONESPECIALIDADENSISTEMASDISTRIBUIDOSOTORGADAPOREL#ENTRODE)NVESTIGACIØNY%STUDIOS!VANZADOS
CARGODELADElNICIØNEIMPLANTACIØNDELAESTRATEGIAPARA#--Y3IX3IGMAATRAVÏSDELASDIFERENTESÉREASDELCENTRODEDESARROLLODE
CARGODELADEl
#).6%34!6 DEL)NSTITUTO0OLITÏCNICO.ACIONALYOCHOA×OSDEEXPERIENCIACOMOARQUITECTODESOFTWARE
3OFTTEK ITESMMX7EBHTTPWWWJAVIERGSCOM
#ORREOELECTRØNICOJAVIERGS

 3%0 /#4 WWWSOFTWAREGURUCOMMX

 "OUJQBUSØO
TF
PSJHJOB
DPNP
VOB

DPOUSB
QBSUF
BM
UÏSNJOP
QBUSØO

BDV×BEP
FO
BSRVJUFDUVSB
EF

TPGUXBSF
QBSB
EFmOJS
MBT
CVFOBT

QSÈDUJDBT
EF
QSPHSBNBDJØO
EJTF×P

P
HFTUJØO
EF
TJTUFNBT

TJTUFNB
-PT
SFTVMUBEPT
TPO
QSFEFDJCMFT
MPT

BRVr
MB
DSrUJDB
FT
B
MB
GPSNB
FO
RVF
TF
BM
TJTUFNB
QPSRVF
FOUSF
UBOUP
²GBOUBT
DPOGPSNF
MPT
GMVKPT
TF
FOEVSFDFO
Z
TPMJEJ FTDSJCF
DBEB
VOB
EF
MBT
MrOFBT
EFTEF
MB
NB³
FODPOUSBS
MPT
FMFNFOUPT
SFMFWBOUFT

GJDBO
TF
FTDSJCF
DwEJHP
Z
QBTB
FM
UJFNQP

JOEFOUBDJwO
IBTUB
FM
MFOHVBKF
P
MFOHVBKFT
FT
JNQPTJCMF
SgQJEBNFOUF
TF
WVFMWF
JNQPTJCMF
EPDV VUJMJ[BEPT
Z
TV
JOUFSBDDJwO
:B
FO
FM
DPO
NFOUBS
FM
DwEJHP
P
FOUFOEFS
TV
BSRVJUFD UFYUP
TQBHIFUUJ
TJ
NF[DMBNPT
NgT
EF
VO
!NTI PATRONESDE!RQUITECTURA
UVSB
MP
TVGJDJFOUFNFOUF
CJFO
DPNP
QBSB
MFOHVBKF
EF
QSPHSBNBDJwO
FO
FM
NJTNP
BS "IPSB
DPOTJEFSFNPT
MBT
NBMBT
UnDOJDBT

IBDFS
NFKPSBT DIJWP
FM
TQBHIFUUJ
FT
NgT
TBCSPTP
-B
SF QBSB
EFGJOJS
DPNQPOFOUFT
Z
SFMBDJPOFT
FO

DFUB
DMgTJDB
DPO
MFOHVBKFT
TDSJQUT
EFM
UJQP
FM
TJTUFNB
FT
EFDJS
TV
BSRVJUFDUVSB
4J
MPT


5IF
(PE
6O
QSPHSBNB
PNOJQSFTFOUF
1)1
DPO
)5.-
Z
TB[POBEP
DPO
+BWB4DSJQU
EFTBSSPMMBEPSFT
UJFOFO
VOB
DPMFDDJwO
EF

Z
EFTDPOPDJEP
"RVFM
TJTUFNB
EPOEF
VOB
¡FT
EFMJDJPTP
FOUJnOEBTF
VO
FOPSNF
QSP NBMBT
DPTUVNCSFT
EF
DPEJGJDBDJwO
BOUJ
TPMB
DMBTF
w
NPEVMP

MB
GVODJwO
NBJO
P
CMFNB

&M
PSJHFO
EFM
TQBHIFUUJ
FT
SFHV QBUSPOFT

B
TV
BMDBODF
MPT
BSRVJUFDUPT
OP

FRVJWBMFOUF

IBDF
UPEP
"Tr
RVF
FM
QSP MBSNFOUF
VO
QSPHSBNB
DSFBEP
QBSB
IBDFS
OPT
RVFEBNPT
BUSgT
7FBNPT
HSBNB
FT
VO
TPMJUBSJP
Z
|OJDP
BSDIJWP
EF
VOB
QFRVFvB
EFNPTUSBDJwO
RVF
UFSNJOB

NVDIrTJNBT
MrOFBT
&O
DPOTFDVFODJB
UF FO
VO
EPT
QPS
USFT
USBCBKBOEP
DPNP
QSP 
3FJOWFOUBS
MB
SVFEB
4F
SFGJFSF
B
SFJN
OFNPT
VO
DwEJHP
EFTPSHBOJ[BEP
Z
GVFSUF EVDUP
GJOBM QMFNFOUBS
DPNQPOFOUFT
RVF
TF
QVFEFO

NFOUF
JOUFSEFQFOEFOEJFOUF DPOTFHVJS
QSFGBCSJDBEPT
EF
BOUFNBOP
Z

%POEF
FTUg
FM
QSPCMFNB
CJFO
QPEFNPT
DJ IBDFS
QPDP
SFVTP
FO
FM
DwEJHP
&O
CSFWFT


(PMEFO
)BNNFS
5BNCJnO
DPOPDJEB
UBS
MP
TJHVJFOUF
DPNP
FKFNQMPT


EFM
QBMBCSBT
RVFSFS
IBDFS
UPEP
VOP
NJTNP

DPNP
MB
UnDOJDB
EF
MB
CBSJUB
NgHJDB
&T
VO
UJFNQP
EF
NBOUFOJNJFOUP
TF
JOWJFSUF
FO
:
IBCMBSrBNPT
EF

1PDP
OJWFM
EF
SFVTP

WJDJP
SFMBDJPOBEP
DPO
BGFSSBSTF
B
VO
QBSB FOUFOEFS
BM
TJTUFNB
PSJHJOBM

&M
TQBHIFUUJ
FO
FM
DwEJHP
SFVTP
EF
VO
QSPZFDUP
B
PUSP

EJHNB
QBSB
TPMVDJPOBS
UPEPT
MPT
QSPCMF FT
DBVTB
EJSFDUB
EFM
TrOESPNF
EFM
QSPHSB DPO
MP
DVBM
DBEB
QSPZFDUP
FTUg
DPNFO
NBT
RVF
TF
OPT
QSFTFOUFO
BM
EFTBSSPMMBS
NBEPS
EFTFTQFSBEP
¡NFKPS
SFFTDSJCJNPT
[BOEP
EFTEF
DFSP

$POTUBOUFNFOUF
TF

TJTUFNBT
DPNP
QPS
FKFNQMP
TJFNQSF
RVF UPEP
FM
QSPHSBNB

:
PCWJBNFOUF
FM
SFVTP
SFFTDSJCFO
GSBHNFOUPT
EF
DwEJHP
DPO
MB

SFS
VTBS
FM
NJTNP
MFOHVBKF
EF
QSPHSBNB FT
JNQPTJCMF NJTNB
GVODJPOBMJEBE

$PO
FM
DPOTF
DJwO
QBSB
UPEPT
MPT
EFTBSSPMMPT
TFB
P
OP
DVFOUF
HBTUP
JO|UJM
EF
NBOP
EF
PCSB
Z

DPOWFOJFOUF
&T
FM
DBTP
EF
FOBNPSBSOPT
1FSP
TJ
QBSB
DPMNP
UFOFNPT
TwMP
VO
DIFG
P
UJFNQP
FO
SFJNQMFNFOUBS
DPTBT
RVF
ZB

EF
/FU

EF
+BWB
EF
1)1
&T
JNQPSUBOUF
FO
FM
DPOUFYUP
VO
²1SPHSBNBEPS
4PMJUBSJP³

FTUBCBO
IFDIBT

&M
TPGUXBSF
TF
WVFMWF

DPNQSFOEFS
RVF
DBEB
VOP
UJFOF
DBQBDJEB  2VJnO
FSB
FTF
IPNCSF
USBT
FM
NPOJUPS
2VF
JOOFDFTBSJBNFOUF
NgT
EFOTP
EFT
Z
MJNJUBDJPOFT
FO
BQMJDBDJPOFT
QBSUJDV OP
FTUg
EJTQPOJCMF
QBSB
FYQMJDBSOPT
TV
SF
MBSFT
&O
DPOTFDVFODJB
TF
USBUB
EF
VOP
FM
DFUB
4JNQMFNFOUF
TF
UJFOFO
QSPCMFNBT
-P
BOUFSJPS
QPS
MP
SFHVMBS
B
DBVTB
EF

VTP
PCTFTJWP
EF
VOB
IFSSBNJFOUB
Z
EPT
NVDIPT
QSPCMFNBT QPDP
DPOPDJNJFOUP
EFM
USBCBKP
ZB
FYJTUFO
VOB
UFSRVFEBE
EF
MPT
EFTBSSPMMBEPSFT
QBSB
UF
QPS
QBSUF
EFM
BSRVJUFDUP

MP
RVF
DPOMMF
VTBS
VO
QBSBEJHNB
EF
TPMVDJwO
FO
UPEPT

'BOUBTNBT
%FNBTJBEBT
DMBTFT
FO
VO
WB
B
CVTDBS
TPMVDJPOFT
QBSB
QSPCMFNBT
ZB

MPT
QSPHSBNBT
-P
DVBM
DPOMMFWB
PDBTJP QSPHSBNB
P
UBCMBT
FO
VOB
CBTF
EF
EBUPT
TPMVDJPOBEPT
OBMNFOUF
B
DPOTVNJS
NVDIP
NgT
FTGVFS[P
7BSJBT
DMBTFT
P
UBCMBT
DPO
NrOJNBT
SFT
QBSB
SFTPMWFS
VO
QSPCMFNB QPOTBCJMJEBEFT
.VDIBT
WFDFT
TF
VUJMJ[B

$BTBSTF
DPO
FM
EJBCMP
$SFBS
VOB
EFQFO
QBSB
EJTGSB[BS
MB
QSFTFODJB
EFM
BOUJQB EFODJB
IBDJB
VO
GBCSJDBOUF
RVF
OPT
QSPWFF


4QBHIFUUJ
$PEF
4F
EJDF
EF
VOB
QJF[B
USwO
5IF
(PE
4F
DPMPDBO
DMBTFT
JO|UJ EF
BMHVOB
TPMVDJwO
DPNQPOFOUFT


&M
QSP
EF
DwEJHP
GVFOUF
OP
EPDVNFOUBEP
EPOEF
MFT
RVF
EJTGSB[BO
FM
IFDIP
RVF
UPEP
FM
CMFNB
FT
JONJOFOUF

4F
EFQFOEF
DPN
DVBMRVJFS
QFRVFvP
NPWJNJFOUP
DPOWVM TJTUFNB
TF
FODVFOUSB
DPOTUSVJEP
FO
VOP
QMFUBNFOUF
EF
MP
RVF
FM
WFOEFEPS
IBHB


TJPOB
MB
FTUSVDUVSB
DPNQMFUB
EFM
TJTUF P
VOPT
DVBOUPT
BSDIJWPT
NwEVMPT
P
DMB -B
DBMJEBE
EF
MPT
QSPEVDUPT
EFM
QSPWFFEPS

NB

&O
FYQSFTJwO
DPMPRVJBM
DPEJGJDBS
DPO
TFT
&TUF
BOUJQBUSwO
TVHJFSF
VO
NPEFMP
OPT
DPNQSPNFUFO

&M
WFOEFEPS
OPT
UJFOF

MBT
MPT
²QJFT³
"
EJGFSFODJB
EFM
FTUJMP
EF
BOgMJTJT
ZP
EJTFvP
JOFTUBCMF
FM
EJTF BHBSSBEPT
$JUP
DPNP
FKFNQMP
FM
DBTP
EF

WPMDgO
EPOEF
MB
DSrUJDB
FT
B
MB
GPSNB
FO
vP
OP
DPJODJEF
DPO
MB
JNQMFNFOUBDJwO
Z
VOB
EF
MBT
VOJWFSTJEBEFT
NgT
JNQPSUBOUFT

RVF
FM
TJTUFNB
DSFDF
TF
BOFYBO
NwEV QPS
FMMP
FT
JNQPTJCMF
IBDFS
FYUFOTJPOFT
EFM
QBrT
DVZP
EFTBSSPMMP
DBTJ
DPNQMFUP
EFM

WWWSOFTWAREGURUCOMMX 3%0 /#4 

  >@Ê1B71/A  6;42;62?Ì. 12 @<3AD.?2 

4J
MPT
EFTBSSPMMBEPSFT

UJFOFO
VOB
DPMFDDJØO

EF
NBMBT
DPTUVNCSFT

EF
DPEJmDBDJØO

BOUJQBUSPOFT

MPT

BSRVJUFDUPT
OP
OPT

RVFEBNPT
BUSÈT

TJTUFNB
EF
BENJOJTUSBDJwO
FTDPMBS
FTUg
PSJFOUBEB
B
DVU

QBTUF


-B
UnDOJDB
$5&


SFBMJ[BEP
TPCSF
1-42-
FO
0SBDMF
&MMPT
DVCSF
UVT
FSSPSFT

-B
UnDOJDB
EF
NPSJS

OFDFTJUBO
TFHVJS
QBHBOEP
MBT
MJDFODJBT
EF
QMBOFBOEP
MB
EF
MB
OBWBKB
TVJ[B
MB
UnD
0SBDMF
QBSB
NBOUFOFSTF
PQFSBOEP
"|O
OJDB
EFM
WJFKP
Z
QPEFSPTP
%VLF
EF
:PSL
MB

DVBOEP
MPT
OVFWPT
EFTBSSPMMPT
MPT
FTUnO
UnDOJDB
EF
MB
FTQPOKB
FM
TVQFSWJTPS
QBSB
FMBCPSBOEP
ZB
FO
PUSBT
QMBUBGPSNBT
+BWB
OPJDP
Z
MB
UnDOJDB
EF
MB
QFMFB
Z
1I1
FOUSF
PUSBT
5JFOFO
DJODP
BvPT
EF

EFTBSSPMMPT
FO
1-42-
RVF
OP
MPT
EFKBO
"MHVOPT
EF
FTUPT
QBUSPOFT
TPO
JODMVTP

EFKBS
EF
QBHBS
MJDFODJBT
/P
FT
RVF
0SBDMF
JSSJTPSJPT
FSSPSFT
UBO
DPNVOFT
RVF
TF
TV
TFB
NBMP
4JO
FNCBSHP
QVFEF
TFS
DBSP
FO
QPOESrB
OBEJF
QPESrB
DPNFUFSMPT
Z
TJO
FN
FYUSFNP
QBSB
VOB
VOJWFSTJEBE
Q|CMJDB CBSHP
SFGMFYJPOFNPT
DVgOUPT
EF
OPTPUSPT

FTUVEJBOUFT
QSPGFTJPOJTUBT
FT
MB
QSJNFSB


4UPWFQJQF
$PDJOBEP
FO
²DBMJFOUF³
&T
PQDJwO
B
MB
RVF
SFDVSSJNPT

)F
EFTFBEP

MB
GPSNB
CSFWF
EF
SFGFSJSTF
B
MB
DSFBDJwO
EF
TwMP
DPNFOUBSMPT
OP
PCTUBOUF
QBSB
DBEB

JTMBT
BVUPNBUJ[BEBT
EFOUSP
EF
MB
NJTNB
FN VOP
EF
FTUPT
FYJTUF
VO
BOgMJTJT
QSPGVO
QSFTB
DBEB
EFQBSUBNFOUP
DSFB
TV
QSPQJP
EF
QSPHSBNBEPSFT³
$POTJTUF
FO
MB
DSFFODJB
EP
Z
NJOVDJPTP
EF
TVT
DBVTBT
TrOUPNBT

TVCEFQBSUBNFOUP
EF
TJTUFNBT

²*TMBT³
JO EF
RVF
BTJHOBS
NgT
QFSTPOBM
B
VO
QSPZFDUP
DPOTFDVFODJBT
Z
USBUBNJFOUP
$POPDFS
MPT

EFQFOEJFOUFT
Z
FO
DPOGMJDUP
VOBT
DPO
PUSBT
BDPUBSg
FM
UJFNQP
EF
FOUSFHB
3FHVMBSNFOUF
BOUJQBUSPOFT
FT
|UJM
QBSB
SFGBCSJDBS
NJHSBS

$BEB
JTMB
EFTBSSPMMB
MB
QBSUF
EFM
TJTUFNB
RVF
DPNP
VOB
GPSNB
EFTFTQFSBEB
EF
JOUFOUBS
DP BDUVBMJ[BS
P
SFBMJ[BS
SFJOHFOJFSrB

OFDFTJUB
QBSB
TBUJTGBDFS
TVT
SFRVFSJNJFO SSFHJS
SFUSBTP
EFM
QSPZFDUP

-MFHB
VO
QVOUP

UPT
TJO
QSFPDVQBSTF
QPS
FM
SFTUP
OP
FYJTUF
EPOEF
FOUSF
NgT
QFSTPOBM
TF
BTJHOF
NgT
TF
$PO
FM
BWBODF
UBO
WFSUJHJOPTP
EF
MB
UFDOP
VO
QMBO
P
FKF
HVrB

FM
FTDFOBSJP
SFTVMUBOUF
SFUSBTB
FM
QSPZFDUP
MPHrB
JOGPSNgUJDB
SFTVMUB
JOUFSFTBOUF
DP
JNQMJDB
VOB
QPCSF
P
OVMB
JOUFSPQFSBCJMJEBE
NFOUBS
RVF
MBT
NFKPSFT
QSgDUJDBT
EF
VOB

PCWJBNFOUF
OP
FYJTUF
FM
SFVTP
Z
DPOTFDVFO 
1SPKFDU
.JTTNBOBHFNFOU
-B
KFGB
P
FM
nQPDB
QVFEFO
FWPMVDJPOBS
Z
DPOWFSUJSTF

UFNFOUF
TF

JODSFNFOUBO
DPTUPT

$POUSBSJP
KFGF
RVF
OP
TBCFO
DPPSEJOBS
&M
QSPZFDUP
TF
FO
BOUJQBUSPOFT
FO
FM
MVTUSP
TJHVJFOUF

B
MP
RVF
TF
QPESrB
TVQPOFS
DBEB
WF[
FT
NgT
EFTDVJEB
Z
OP
TF
NPOJUPSFB
EF
NBOFSB
BEF )PZ
ErB
QPEFNPT
DJUBS
QPS
FKFNQMP
MB

DPN|O
FTUF
UJQP
EF
BDDJPOFT
EBEB
MB
QSFNV DVBEB
FT
NVZ
EJGrDJM
EF
EFUFDUBS
FO
FUBQBT
QSPHSBNBDJwO
FTUSVDUVSBEB
WB
FO
DBNJ
SB
EF
EFQBSUBNFOUPT
FTQFDrGJDPT
EFOUSP
EF
JOJDJBMFT
QFSP
SFQFOUJOBNFOUF
FNFSHF
EF
OP
EF
TFSMP
FO
DJFSUP
DPOUFYUP
²TPMVDJwO

VOB
NBDSPFNQSFTB
QPS
DPOUBS
DPO
BDDFTP
B
HPMQF
Z
TVFMF
WPMUFBS
EF
DBCF[B
MB
TJUVBDJwO
TFODJMMB
Z
SgQJEB
DPO
DPOTFDVFODJBT
OFHB
5FDOPMPHrBT
EF
*OGPSNBDJwO
EFM
QSPZFDUP
4F
NBOJGJFTUB
DPO
SFUSBTPT
FO
UJWBT
B
MBSHP
QMB[P³
MBT
GFDIBT
EF
FOUSFHB
ZP
gSFBT
JODPNQMFUBT
)BCMBNPT
EF
VO
FTDFOBSJP
EPOEF
QSFWBMF
DF

6OB
GBMUB
EF
FTUSBUFHJB
UFDOPMwHJDB

$PSODPC
-PT
FNQMFBEPT
TF
PCTUBDV -FDUVSBT
SFDPNFOEBEBT
EF
MB
FNQSFTB


'BMUB
EF
FTUgOEBSFT
MJ[BO
VOPT
B
PUSPT

1FSTPOBT
DPOGMJDUJWBT
+&&
"OUJ1BUUFSOT
#JMM
%VEOFZ


'BMUB
EF
QFSGJM
EF
TJTUFNB

'BMUB
EF
P
EJGrDJMFT
EF
USBUBS
RVF
GPSNBO
QBSUF
EFM
4UFQIFO
"TCVSZ
+PTFQI
,SP[BL
BOE

JODFOUJWPT
QBSB
MB
DPPQFSBDJwO
FO
FM
EF FRVJQP
EF
EFTBSSPMMP
EFTWrBO
V
PCTUBDV ,FWJO
8JUULPQG
&E
+PIO
8JMFZ


TBSSPMMP
EF
TJTUFNBT

'BMUB
EF
DPNVOJ MJ[BO
FM
QSPDFTP
EF
QSPEVDDJwO
QPSRVF
4POT


*4#/

DBDJwO

'BMUB
EF
DPOPDJNJFOUP
TPCSF
MPT
USBOTGJFSFO
TVT
QSPCMFNBT
QFSTPOBMFT
P

FTUgOEBSFT
UFDOPMwHJDPT

'BMUB
EF
JOUFS EJGFSFODJBT
DPO
PUSPT
NJFNCSPT
EFM
FRVJ "OUJQBUUFSOT
3FGBDUPSJOH
4PGUXBSF

GBDFT
QBSB
MB
JOUFHSBDJwO
EF
TJTUFNBT QP
BM
QSPZFDUP
#BKP
FTUB
DJSDVOTUBODJB
FM
"SDIJUFDUVSFT
BOE
1SPKFDUT
JO
$SJTJT

QSPZFDUP
OP
TF
EFTBSSPMMB
DPSSFDUBNFOUF
8JMMJBN
+
#SPXO
&E
+PIO
8JMFZ


!NTI PATRONES DE !DMINISTRA BVORVF
FM
QFSTPOBM
FT
CVFOP 4POT

*4#/

CIØNDE0ROYECTO
'JOBMNFOUF
MPT
BENJOJTUSBEPSFT
UBNQPDP
FT #ONCLUSIØN "OUJQBUUFSOT
JO
1SPKFDU
.BOB
UgO
FYFOUPT
EF
TFHVJS
DJFSUPT
BOUJQBUSPOFT &M
MJTUBEP
EF
BOUJQBUSPOFT
FT
NVZ
BNQMJP
HFNFOU
8JMMJBN
+
#SPXO
&E

DBTJ
UBOUP
DPNP
FM
EF
QBUSPOFT
3FDPNJFO +PIO
8JMFZ

4POT

*4#/


5IF
.ZUIJDBM
.POUI
.BO
.FKPS
DPOPDJ EP
B
MFDUPS
MB
DPOTVMUB
BEJDJPOBM
EF
MPT
TJ 
EP
DPNP
FO
FM
FOUPSOP
DPNP
FM
²T|QFS
FRVJQP
HVJFOUFT
-B
UnDOJDB
10$1
QSPHSBNBDJwO

 3%0 /#4 WWWSOFTWAREGURUCOMMX

 s
ana

e
Villagr

d
o
el

o
Por Jo

l
De
e
sarro l
oj u e g
V i
¿Po
d
r D ó nde Empe
zar?

han
o los vid
cre
os, y siem
alme
eojueg ar uno. Fin spués de
; de
gustad roceso para esarrollarlos er proyecto é
bía
pre hante,

,
me el p rad prim enc
iño siempre de cómo eso de aprenderfecto como ntonces comscasa;
esde n curiosidad e era tiemp eojuego pe mpiezo?” E s era muy e guaje
D tenidoos, decidí qunutos un vidpor dónde euel entonce r: “¿Qué len ¿qué
añ mi ¿Y aq ui al?,
hace 6 ar por unos a realidad: “rnet, que en ar de disminor en especi n los jue-
idealiz ue volver a l ión en Inte taban en lugn compilad ómo se hace tenía.
tuve q ar informac das aumen ¿se usa algú render?, ¿c eguntas que
a busc a que mis duse utiliza?, é necesito aps muchas pr
parecí gramación juego?, ¿qu lgunas de la
de protura tiene unlas?” Eran a
estruc ra las conso
gos pa

24 ENE-FEB 2007 www.softwareguru.com.mx

 Muy rápido me di cuenta de 3 cosas: la pri-
mera es que no existía algún libro ni tutorial
que enseñe todo lo que se necesita saber; la
segunda es que toda la información existen-
te estaba en inglés (y eso no ha cambiado);
y la tercera, es que ni siquiera ahí me podría
escapar de las matemáticas –la dirección en
la que se mueve un objeto, determinar si está
dentro del rango de visión de la cámara vir-
tual, determinar si un vehículo chocó contra
un edificio; todo eso requiere matemáticas.
Desafortunadamente, en México todavía no
existe una industria de desarrollo de video-
juegos como tal, y es una lástima, porque es
una industria de billones de dólares. Ya exis-
ten carreras de desarrollo de videojuegos en
universidades internacionales, pero en mu-
chas universidades de nuestro país ni siquie-
ra se toma en serio la materia de gráficas por
computadora, que es la base de todo.
Esto en gran parte se debe a falta de infor-
mación, muchas personas creen que es lo
mismo jugarlos que desarrollarlos. Un juego
2D puede ser fácil, pero uno 3D es algo muy
diferente y se necesitan muchas personas
trabajando en conjunto para crearlo. No es
que una sola persona no pueda, pero se tar-
daría mucho más tiempo. Un juego comer-
cial tarda entre 1.5 y 3 años para ser desa-
rrollado, con un equipo de 25 personas en
promedio. Un juego 3D generalmente tiene
programación orientada a objetos, cálculos
trigonométricos y de álgebra lineal que se
ejecutan durante todo el juego, estructuras
de datos especializadas, y también puede
existir una red neuronal para el manejo de
la inteligencia artificial, así como algo de
teoría de autómatas finitos y teoría de gra-
fos aplicada, entre muchas otras cosas. Y
aún así, hay maestros de universidades que
cuando se les presenta un juego como una
www.softwareguru.com.mx
idea para un proyecto final, solo dicen en
tono despectivo “¿otro jueguito?”
Tuve la oportunidad de participar en el Festi-
val de Desarrollo de Videojuegos Creanimax
2006, y me di cuenta que por fin se están
haciendo esfuerzos para entrarle a esta in-
dustria. Me di cuenta de que hay algunas
compañías interesadas en desarrollar jue-
gos, pero falta apoyo y habilidades técnicas.
También me enteré de un par de universida-
des en Guadalajara que están incorporando
una carrera de animación y arte digital a su
oferta académica. Hay muchas personas in-
volucradas ya en el modelado y animación
3D –y son buenos–. Entonces no vamos tan
mal, sólo falta ponernos las pilas, organizar-
nos y darle importancia también a la parte de
la programación.
Así que el objetivo de este artículo, es tra-
tar de dar una pequeña orientación para
aquellos que desean empezar a desarrollar
videojuegos y tengan preguntas parecidas
a las que tenía yo cuando empecé.
¿Qué se necesita saber para
desarrollar videojuegos?
Programación. Lo primero que se necesita es
saber programar en algún lenguaje orienta-
do a objetos, yo en lo personal uso C++, pero
también se puede utilizar C#, Delphi, Java,
etcétera. En cuanto a compiladores, no hay
gran diferencia, se pueden utilizar el Visual
C++ 2005 Express Edition de Microsoft o el
C++ de Borland.
Game Engines. Los juegos generalmente
tienen módulos clave para manejar tareas
como mostrar gráficas, manejar recursos,
interpretar y ejecutar scripts, reproducir
efectos de sonido, manejar la inteligencia
artificial, manejar el input del usuario. Estos
módulos clave, junto con otros, forman de
manera colectiva lo que se llama un Game
Engine, un producto que ofrece todas estas
características, y hay quienes las usan para
ahorrarse algo de trabajo al programar. De
hecho, los estudios dedicados a los vide-
ojuegos, utilizan Game Engines comerciales
o desarrolladas por ellos mismos. Utilizar un
Game Engine cuando se está iniciando en la
programación de videojuegos, podría ser una
limitante hasta cierto punto, porque primero
se tendría que estudiar la documentación de
ésta para saber utilizarla y si no se tienen los
fundamentos teóricos suficientes, cuando se
quiera modificar una parte del engine para
adaptarla al juego deseado, será mucho más
difícil. Existe una gran variedad de engines,
desde algunas gratuitas y/o, open source
como Irrlicht, hasta otras comerciales como
el Unreal Engine 3, cuyo licenciamiento pue-
de rebasar los cien mil dólares.
Matemáticas. Es deseable tener cono-
cimientos generales de álgebra lineal y
trigonometría, sobre todo para el área de
programación de gráficas. Si no se tie-
nen estos conocimientos, se tendrán que
aprender al mismo tiempo que se hace con
la teoría y programación de gráficas.
¿Qué se necesita aprender para
desarrollar videojuegos?
Esta pregunta no es fácil de contestar, so-
bre todo porque existen diferentes áreas
dentro de la programación de videojue-
gos: gráficas, redes, inteligencia artificial,
sonido, lógica principal.
El área en el que está centrado este artículo
es en la de gráficas, y para esta área se nece-
sitan aprender básicamente dos cosas:
•Teoría de gráficas: involucra aprender las
bases de los sistemas de coordenadas 2D
ENE-FEB 2007 25

y 3D, las bases de los objetos 3D que son
representados como modelos poligonales
(vértices, normales, caras, etcétera); las
báses de la arquitectura gráfica (diferentes
tipos de transformaciones y proyecciones);
las matemáticas involucradas (vectores,
planos, matrices y todas sus operaciones
relacionadas). Diferentes modelos de ilumi-
nación, mapeado de texturas, entre otras co-
sas. Es necesario tener estos conocimientos,
ya que se aplican a las APIs para programa-
ción gráfica existentes y son necesarios para
explotar todo su potencial.
•Una API para programación de gráficas: que
es básicamente una librería que usamos en
nuestro código para poder mandar gráficas a
la pantalla, sin tener que accesar al hardware
directamente (en su lugar, los drivers se en-
cargan de procesar las peticiones hechas por
las APIs). Las dos APIs de gráficas más usa-
das son OpenGL y Direct3D, y dado que los
resultados que se pueden obtener con ellas,
son, hasta cierto punto similares, la elección
de una u otra es cuestión personal.
¿Qué es DirectX?
DirectX es una serie de APIs de Microsoft para
manejo de gráficas, input del usuario, soni-
do, video, y funciones de redes que se pue-
den usar en aplicaciones de multimedia en
general, no solamente juegos. En versiones
anteriores de DirectX, las gráficas 2D y 3D
se manejaban con las APIs DirectDraw y Di-
rect3D, respectivamente. A partir de DirectX
8, éstas se fusionaron en DirectX Graphics,
pero es mejor conocida como Direct3D.
26 ENE-FEB 2007
¿Qué es OpenGL?
OpenGL es una API para el manejo de grá-
ficas exclusivamente, no tiene otro tipo de
funciones utilizadas en los juegos. OpenGL
es multiplataforma, lo que significa que el
mismo código puede correr en Windows,
Mac, X Window, con mínimas modificacio-
nes. Esta es una de las ventajas que, puede
decirse, tiene con respecto a Direct3D, el
cual es exclusivamente para Windows.
Dado que OpenGL es multiplataforma, no inclu-
ye comandos para manejo de ventanas, porque
estos son diferentes en cada caso. Dependien-
do de la plataforma, hay métodos para crear
una ventana con soporte para OpenGL. Para
agilizar o hacer más fácil el manejo de ventanas.
Ya existen algunas librerías que se utilizan junto
con OpenGL, por ejemplo: SDL y GLUT.
OpenGL, a diferencia de DirectX, no se baja
como un paquete, de algún sitio de Internet,
ya que es implementado por los drivers. To-
das las máquinas con Windows 95 o posterior,
incluyen los drivers de OpenGL 1.1, aunque la
versión más reciente de OpenGL es 2.0 –Win-
dows Vista tendrá los drivers de OpenGL 1.4–.
Entonces, la versión de OpenGL que se tenga,
depende de dos cosas: la primera es nuestra
tarjeta de video –no todas las tarjetas sopor-
tan las últimas versiones de OpenGL –, y la
segunda, es actualizar los drivers de nuestra
tarjeta de video para tener la versión más re-
ciente que soporte la tarjeta.
Para utilizar OpenGL, es necesario configurar
nuestro compilador para que pueda encontrar
la libreria (OpenGL32.lib) y los archivos de
encabezado (gl.h, glu.h, glaux.h) de OpenGL.
Así mismo, necesitamos incluir los archivos
de encabezado en los archivos de código
fuente donde se usen funciones de OpenGL.
¿Cómo puedo programar
videojuegos para Xbox360,
PlayStation 3, GameCube?
En el caso de Xbox360, para desa-
rrollar un juego se necesita obtener
un “Kit de Desarrollo”, que consta de
una consola Xbox360 especial para
desarrollo, herramientas, SDKs, y do-
cumentación. El desarrollo se hace
en una PC con Visual Studio o Co-
deWarrior por ejemplo. Dicha PC está
conectada a la consola especial de de-
sarrollo, generalmente por ethernet.
Una vez compilado el código, éste se
pasa a la consola; la forma de cómo
hacerlo, depende de cada sistema. En
Xbox, se cuenta con unos plugins en
Visual Studio que copian los datos de
la PC al disco duro del Xbox, y después
el Xbox monta el directorio que se co-
pió, como si fuera el disco duro inter-
no, para empezar a correr el juego.
Para obtener el kit de desarrollo, se nece-
sita ser un desarrollador registrado con
Microsoft, y los kits son muy caros. Aun-
que existe el XNA Game Studio Express,
éste, no es suficiente para hacer juegos
comerciales, en realidad, es un producto
dirigido más para estudiantes y hobbyists.
Además, para ser aceptado como desarro-
llador, se debe seguir un proceso que está
sujeto a aceptación por parte de Microsoft.
Se puede encontrar más información en:
www.xbox.com/en-us/dev/ default.htm
Otros fabricantes de consolas piden requisitos
adicionales. Por ejemplo, Nintendo pide que
se cuente con respaldo financiero de algún
distribuidor de juegos internacional. Así que,
en general, para desarrollar un videojuego
para consolas, se necesita tener una compañía
establecida con presupuesto suficiente.
Si quieres aprender cómo es el desarrollo
para consolas, una muy recomendada para
empezar sería Gameboy Advance (GBA), ya
que es de las menos complejas. En el sitio
www.jharbour.com/gameboy/default.aspx
se encuentra gratuitamente el ebook “Pro-
gramming The Nintendo Game Boy Advan-
ce”, que nunca se publicó como libro debido
a cuestiones legales. En éste, se encuentra
información de cómo ejecutar nuestros pro-
www.softwareguru.com.mx
 Tema Tìtulo Autor
Matemáticas/Física Mathematics for 3d Game Eric Lengyel
Programming and Computer Graphics dos por medio de Shaders.
OpenGL OpenGL Programming Guide: OpenGL Architecture
The Official Guide to Learning OpenGL Review Board
Beginning OpenGL Game Programming. Dave Astle y
Kevin Hawkins
More OpenGL Game Programming. Dave Astle
Gráficas 3D Interactive Computer Graphics: Edward Angel
A Top-Down Approach using OpenGL. de correr ya sea en OpenGL o DirectX).
Real-Time Rendering Tomas Akenine-Moller Las tarjetas gráficas con arquitectura pro-
y Eric Haines
Desarrollo de Juegos Game Programming Gems. Mark DeLoura
(Serie de 6 libros hasta el momento). (Editor)
Core Techniques and Algorithms in Daniel Sanchez-Crespo
Game Programming ders respectivamente (los últimos también
Inteligencia Artificial AI Game Programming Wisdom 3 Steve Rabin
Modelado Modeling a Character in 3DS Max Paul Steed
pios juegos de GBA en una PC, usando un gun libro que enseñe todo lo relacionado al
emulador, así como información de cómo desarrollo de videojuegos, así que los cate-
correrlos en una consola GBAreal. goricé en 6 grupos principales, y por razones
de espacio, sólo menciono unos cuantos de
Referencias en línea cada categoría.
Algunos links con mucha información son
los siguientes: ¿Qué tarjeta gráfica me puede
www.opengl.org – El sitio oficial de OpenGL, servir para empezar?
tiene documentación y foros de OpenGL para El mercado de las tarjetas gráficas es domina-
principiantes y avanzados. do por dos compañías, ATI y NVIDIA. Las dos
ofrecen tarjetas gráficas de muy buena calidad
msdn.microsoft.com/library/en-us/directx9_ y de una gran variedad de precios, dependien-
c/directx_sdk.asp – Información de DirectX. do de la generación de la tarjeta. Muchas ve-
ces, al ver las cajas de las tarjetas pueden sur-
www.gamedev.net – Un sitio con mucha docu- gir más preguntas, ya que la información que
mentación de desarrollo de juegos en general y tienen, puede parecer extraña. Por ejemplo, es
foros para los diferentes aspectos del desarro- importante entender lo que son los Shaders.
llo.
Shaders: hasta hace algunos años, se decía
www.gamasutra.com – Un sitio donde se pue- que las tarjetas gráficas tenían una arqui-
den encontrar las más recientes noticias de tectura fija (Fixed-Function Pipeline) ya que
la industria de los videojuegos, pero también la información enviada desde la aplicación,
cuenta con algo de información técnica. siempre pasaba por las mismas operaciones
dentro de la tarjeta gráfica. Esto ha cambia-
www.flipcode.com – Un sitio que ya no se man- do, y actualmente las tarjetas gráficas tienen
tiene por sus creadores, pero tiene una extensa una arquitectura programable.
colección de artículos, todavía en línea, relacio-
nados al desarrollo de videojuegos. Una arquitectura programable significa que
desde la aplicación, se le puede indicar a la
¿Qué libros me pueden servir? tarjeta gráfica que ejecute ciertos programas
La tabla en la parte superior de esta página pequeños (llamados Shaders) ella misma, li-
lista algunos libros que considero buenos berando al CPU completamente de ejecutar
y que son útiles, independientemente del esas funciones. Es por esto que las tarjetas
nivel de conocimiento de programación de gráficas actuales, cuentan con su propia
videojuegos que se tenga. Como ya lo había memoria y procesador, conocido como GPU
mencionado, hasta el momento, no sé de al- (Graphics Processing Unit). Muchos de los
www.softwareguru.com.mx
efectos visuales avanzados que vemos en
los juegos de hoy en día, son implementa-
Hace algunos años, los Shaders eran escri-
tos en lenguaje ensamblador, por tal razón
no eran tan populares. Actualmente la mayo-
ría de los Shaders, son escritos en lenguajes
de “alto nivel”, muy parecidos a C, los tres
más usados son: GLSL (específico de Open-
GL); HLSL (específico de DirectX) y Cg (pue-
gramable tienen dos núcleos o procesadores
programables, uno se ejecuta a nivel de ob-
jetos y otro se ejecuta a nivel de pixeles. Los
Shaders que se pueden ejecutar en ellos, se
conocen como Vertex Shaders y Pixel Sha-
se conocen como Fragment Shaders).
Las tarjetas gráficas con arquitectura pro-
gramable, también tienen soporte para la ar-
quitectura fija, y es decisión de la aplicación,
utilizar una u otra arquitectura o incluso uti-
lizar las dos. Es por eso que muchas veces,
aunque tengamos un procesador avanzado,
si no tenemos una tarjeta gráfica con arqui-
tectura programable como lo requieren algu-
nos juegos, no podremos ejecutarlos.
Tips generales
•Es más fácil empezar por 2D, y algunas co-
sas de 2D se aplican a 3D también.
•Es más sencillo aprender OpenGL que Di-
rectX (en mi opinión).
•Jugar muchos juegos. Es la mejor manera
de sacar ideas para juegos nuevos.
•Ayudar a otros. También se aprende mucho
cuando se enseña.
•Tratar de hacer un clon de algún juego 2D
sencillo (Tetris, Pong) y después mejorarlo.
•Para un juego 3D, es más rápido desarro-
llarlo en equipo.
Conclusión
El tema de desarrollo de videojuegos
es muy extenso, pero espero haber
respondido las preguntas básicas
acerca de cómo empezar. El siguiente
artículo tiene información mas espe-
cífica en cuanto a la estructura de un
juego. Si dejé alguna pregunta sin
responder, me pueden contactar en
joel.villagrana@gmail.com y trataré
de responder lo más pronto posible.
ENE-FEB 2007 27
 Open Source
al Rescate
E l objetivo principal de este artículo es pre-
sentar un panorama sobre las herramientas
de software libre u open source, relacionadas
con la generación de un ambiente de desarro-
llo integral, que cubra las diferentes etapas in-
volucradas en la creación de software.
Aunque la mayor parte de las herramientas
mencionadas son ampliamente utilizadas hoy
en día, otras no cuentan con el mismo nivel de
difusión y adopción. Sin embargo, la intención
es destacar el impacto que tienen todas ellas
en relación con el desarrollo colaborativo. Vale
la pena resaltar que, estas herramientas no
sólo son exclusivas para el desarrollo de pro-
yectos open source, sino que se pueden utili-
zar para cualquier tipo de proyecto.
Un vistazo a las diferentes
necesidades
Desde un punto de vista muy simplista y, sin
estar apegado a alguna metodología especí-
fica, podemos identificar las siguientes eta-
pas en el ciclo de vida de un proyecto:
•Planeación y costeo.
www.softwareguru.com.mx
Por Francisco Castrillo
•Diseño y arquitectura.
•Desarrollo y pruebas unitarias.
•Estabilización y pruebas de estrés.
•En vivo (ya en producción).
•Carga real, uso real, ambiente real ...
•Detección de errores, cambios, mejoras ...
¿Cómo seleccionar las mejores herramientas
para cada una de estas etapas? Las revisiones
de producto son útiles, pero no son la última pa-
labra, porque cada situación es única (como los
proyectos), y los procesos de adopción en cada
organización son muy variados. Algunos de
los aspectos a considerar dentro de esta gama
son: metodología y procesos; presupuesto para
hardware-software, infraestructura actual; ta-
maño de proyectos y equipos de trabajo.
A pesar de estas limitantes para la selección
de herramientas, lo que está claro, es que
debemos seleccionar aquéllas que nos ayu-
den a producir, conservar y administrar todo
el material generado en los proyectos, así
como los que promuevan la estandarización
en el uso de las mismas.
MAR-ABR 2007 21
 Herramientas de colaboración
Comencemos por mencionar algunas he-
rramientas orientadas a coordinar y facili-
tar la colaboración entre los miembros de
un equipo de trabajo. Aquí tenemos las si-
guientes categorías:
Control de versiones
El control de versiones es uno de los pilares
de un buen desarrollo de software. Usado de
forma adecuada, proporciona una bitácora
de todos los cambios realizados a la docu-
mentación y al código fuente, siendo así una
gran ayuda para la corrección de bugs. Una
recomendación adicional es que todos los
artefactos de los proyectos (código fuente,
contenido estático, scripts para builds, do-
cumentación de análisis y diseño, material
de cursos, acuerdos con el cliente, etcétera)
sea administrado con una herramienta de
control de versiones.
Hoy en día existen dos grandes tecnologías
para el control de versiones: CVS y Subver-
sion; la primera de ellas es prácticamente de
adopción universal; la segunda, cuenta con
algunas mejoras de implementación que la
colocan como el sucesor natural de CVS. En-
tre las características comunes están:
•Repositorio central accesible vía Internet.
•Resolución de conflictos vía “merging”,
en lugar del concepto de “locking”.
•Gran diversidad de clientes multiplatafor-
ma para acceder a los repositorios.
Entre las principales diferencias a nivel
conceptual (no de implementación), está el
reemplazo de etiquetas (tags) y ramas (bran-
ches) de CVS por simple copiado y renombra-
do de archivos y directorios en Subversion.
Issue tracking
Utilizado para manejar las listas de pendien-
tes a resolver y las solicitudes de mejora. Es
indispensable contar con visibilidad de los
asuntos por resolver, así como un mecanis-
mo automatizado de asignación de tareas y
notificación de alertas. Toda esta funciona-
lidad la provee una herramienta como Bug-
zilla, la cual fue originalmente desarrollada
para atender las necesidades del proyecto
Mozilla, y ahora se ha convertido en la he-
rramienta por excelencia para manejo de
issues. Los usos que se le pueden dar a la
herramienta son muy variados: los desarro-
22 MAR-ABR 2007
lladores pueden rastrear defectos o bugs;
los usuarios solicitan soporte, asignación de
tareas de codificación y/o corrección, con-
trol de actualizaciones o parches y discusión
sobre posibles mejoras.
Discusiones técnicas
En este rubro se pueden utilizar una diver-
sidad de mecanismos que promuevan el en-
tendimiento técnico del proyecto, así como
la facilidad de dejar evidencia escrita del
por qué se tomaron ciertas decisiones a lo
largo del proyecto. Dentro de estas posibi-
lidades nos encontramos los sitios web por
proyecto, los foros de discusión, las listas de
correo, HowTo’s y FAQ’s.
En lo personal, me gusta la utilización de
una lista de correo por proyecto, ya que es
tan accesible y cotidiano como el correo
electrónico, con la gran ventaja de dejar
un histórico de las discusiones en web.
Una de las opciones más utilizadas para
generar estas listas de correo es Mail-
Man, que ofrece una interfaz web para
utilizar listas de correo electrónico, diver-
sas opciones de entrega y suscripción a
las listas. Otra alternativa de más reciente
aparición son los grupos de Google, que
además de proporcionar la funcionalidad
de listas de correo, permite adjuntar ar-
chivos y crear páginas (tipo Wiki) desde la
misma interfaz web.
Herramientas de desarrollo
En cuanto a las herramientas de desa-
rrollo se refiere, existen una infinidad
de posibilidades para categorizarlas. Sin
embargo, me enfocaré en esta ocasión, a
las más apegadas a las etapas de cons-
trucción o implementación.
Editores de texto
Si consideramos que las herramientas son
una extensión de nuestras manos, esto apli-
ca mejor que en ningún otro caso para los
editores de texto. Lo ideal es conocer un
editor lo mejor posible y utilizarlo para cual-
quier tarea de edición: código, documenta-
ción, scripts, notas, entre otras.
Las características esenciales que debe te-
ner un editor son:
•Configurable. Todo debe poderse adaptar a
las preferencias del usuario (fonts, colores,
asociación de shortcuts, etcétera).
•Extensible. Un editor no debe pasar de
moda si surge un nuevo lenguaje o formato
de texto.
•Programable. Ya sea mediante la utilización
de macros u otra funcionalidad equivalente,
se deben poder realizar tareas complejas.
Entre los editores open source más popula-
res encontramos a Emacs, Xemacs y Judit,
por mencionar algunos.
A pesar de la sencilla interfaz gráfica que
presenta, Emacs es uno de los editores más
potentes que he conocido. Algunas de sus
características son:
•Ampliamente configurable y programable a
través de Lisp.
•Ligero: no se requiere mucho espacio de
memoria para su instalación y ejecución.
•Utiliza atajos o shortcuts. A pesar de que
es un poco difícil aprenderse los atajos, una
vez que se tienen dominados son extrema-
damente útiles.
•Funcionalidad robusta y de gran diversidad:
búsquedas, ejecución de comandos, ftp, so-
porte para múltiples buffers, highlighting,
indentación automática; soporta diversos
modos de edición, juegos, calendario, con-
trol de versiones, mail, etcétera.
Automatización de tareas de compilación y
despliegue (build systems)
El estándar de facto para los proyectos en
Java, es Ant. Para quienes están familiari-
zados con Unix, Ant es el equivalente al co-
mando “make”, con la diferencia de que Ant
utiliza archivos XML en lugar de makefiles.
En cada archivo XML se describen los pasos
y dependencias para ejecutar cada tipo de
tarea: compilación, empaquetado, desplie-
gue en servidores, etcétera. Las tareas se
invocan a través de línea de comandos, o
directamente desde un IDE.
Ant es muy fácil de extender e incorporar
tareas diversas como envío de correos
electrónicos, verificación de estándares
de codificación (CheckStyle), integración
de control de versiones, pruebas unitarias
(JUnit), automatizar la ejecución de tareas
en servidores, etcétera.
Con el uso extensivo que se ha hecho de Ant,
surgió Maven, cuyo uso es menos generali-
www.softwareguru.com.mx
zado. Maven agrupa las “mejores prácticas”
y asume cierta estructura de directorios
con el fin de estandarizar tareas. Adicional-
mente, provee una estructura que permite
declarar las dependencias complejas entre
librerías de diferentes proyectos.
En lo personal, me gusta más la flexibilidad
que provee Ant, ya que cuento con una in-
fraestructura de muchas plantillas de pro-
yectos diversos que me dan un buen punto
de partida para cualquier nuevo proyecto.
Sin embargo, creo que Maven puede ser
una buena opción para quienes no cuen-
ten con dicha infraestructura, o bien, para
aquellos casos en que las dependencias
entre proyectos o componentes es bastante
significativa.
Entornos gráficos de desarrollo (IDE)
Los IDE’s son herramientas visuales que in-
tegran muchas de las características antes
mencionadas (control de versiones, build
systems, edición), y otras más avanzadas
(modelado UML, construcción de interfaces
gráficas, debugging, instalación en servido-
res de aplicaciones, refactoring) que no cu-
brimos en este artículo.
La tarea de elegir un IDE es verdadera-
mente difícil. Cada una de las opciones
presenta ventajas y desventajas. Sin em-
bargo, podemos tomar en cuenta algunas
consideraciones al momento de hacer
esta elección:
•Naturaleza del proyecto a realizar. Es im-
portante considerar las características del
proyecto a desarrollar para así, poder delimi-
tar las necesidades que se deben cubrir. Una
vez que se tiene un panorama del proyecto
y sus requerimientos, podemos buscar un
apoyo en los IDEs para que faciliten algunas
de las tareas más laboriosas.
•Hardware disponible. Aunque a veces este
punto se pasa por alto, no debemos olvidar
que generalmente los ambientes de desa-
rrollo requieren de una capacidad mínima
para que funcionen de manera óptima.
•Flexibilidad de la herramienta. Existen he-
rramientas que hacen verdaderas maravillas
Francisco Castrillo es Director de Soluciones de Nexusware, empresa pionera en México en el desarrollo de soluciones corporativas basadas en Java. Como
expositor, ha impartido seminarios relativos a la tecnología Java EE en diversos foros a nivel nacional e internacional. Francisco es miembro del Consejo de la
Comunidad Java México (www.comunidadjava.org) y es egresado de Matemáticas Aplicadas del ITAM.
www.softwareguru.com.mx
en la generación de cierto tipo de proyectos,
pero que al momento de quererlas integrar
con otro tipo de tecnologías o herramientas,
empiezan a generar problemas.
•Estabilidad. Algunos IDEs tienden a de-
teriorar su funcionalidad al momento de
ser utilizados en proyectos grandes con
muchos componentes.
•Documentación. Es conveniente revisar si
existe buena documentación y soporte so-
bre el funcionamiento del IDE.
•Perfil del desarrollador. Algunas caracte-
rísticas de los IDEs pueden ser útiles para
unos y un estorbo para otros. De nada sirve
tener asistentes para tareas que podemos
realizar de mejor manera utilizando otro tipo
de herramientas, metodologías, etcétera.
Hablando principalmente de desarrollos
en Java, al día de hoy destacan dos op-
ciones como alternativas open source:
Eclipse y NetBeans. En cuanto a la filosofía
que promueven con su arquitectura, am-
bos fueron implementados alrededor de
un pequeño núcleo con todas sus carac-
terísticas implementadas como plug-ins.
Ambos sirven como plataforma base para
otras herramientas de valor agregado que
proveen las empresas que fundaron a es-
tos proyectos.
Por ejemplo: en el caso de NetBeans, éste
sirve de base para el Java Studio Creator y
Java Studio Enterprise, ambas herramientas
de Sun Microsystems. La primera está diri-
gida a desarrolladores de Visual Basic que
buscan hacer el salto a la plataforma Java;
mientras que la segunda, está más dirigida a
desarrollo de aplicaciones corporativas.
De forma similar, en el caso de Eclip-
se, existen diversos productos de IBM
construidos sobre esa plataforma, es-
pecialmente de las líneas de Rational y
Websphere. Tal es el caso del WebSphere
Studio Application Developer.
A pesar de que la opción de utilizar un IDE
puede ser muy tentadora, en algunas oca-
siones es mejor utilizar sólo un buen editor
de texto. De cualquier forma, no olvidemos
que las herramientas de programación de-
ben ayudar a:
•Minimizar costos de desarrollo.
•Automatizar procesos.
•Reducir errores.
Para decidir si es conveniente o no utilizar
una herramienta de desarrollo, debemos
preguntarnos si ésta nos ayuda o no a cum-
plir con estos objetivo.
Conclusión
Independientemente de la selección de
herramientas para generar nuestro en-
torno de desarrollo colaborativo, con-
viene tener muy presente dos cosas:
1. Las herramientas de colaboración
no son un sustituto de la comunica-
ción directa con los otros miembros
del equipo de trabajo, también es
importante establecer las “reglas de
uso” de las herramientas para facili-
tar su adopción
2. En cuanto a las herramientas de de-
sarrollo, yo considero de mayor valor
contar con un “esquema estándar” de
proyecto, que funcione con cualquier
herramienta de desarrollo, en lugar de
“casarme” con alguna en particular.
Referencias
•SourceForge - sourceforge.net
•CVS - www.nongnu.org/cvs
•Subversion - subversion.tigris.org
•Bugzilla - www.bugzilla.org
•Google Groups - groups.google.com
•Emacs - www.gnu.org/software/emacs
•Jakarta Ant - apache.ant.org
•CheckStyle - checkstyle.sourceforge.net
•JUnit - www.junit.org
•Maven - maven.apache.org
•MailMan - www.list.org
•Netbeans - www.netbeans.org
•Eclipse - www.eclipse.org
MAR-ABR 2007 23
 // PRÁCTICAS /* DISEÑO */

El Mariachi Orientado a Objetos

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

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

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

Cuando desarrollamos sistemas, todos nos hemos enfrentado a

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

Cantemos con Mariachi

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

public void bailar() {

// hacer nada …
}

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

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

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

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

Figura 4. Mariachi con cantante de opera

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

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

La figura 5 muestra una solución utilizando interfaces.

Figura 5. Mariachi usando interfaces

www.sg.com.mx JUL-AGO 2007

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

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

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

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

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

Figura 7. Mariachi utilizando el patrón de estrategia

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

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

Carlos “Fofo” Ordóñez es Ingeniero en Sistemas Computacionales por el ITESO. Actualmente labora como arquitecto de software en Vision Consulting
Occidente, ubicada en el Centro de Software de Guadalajara. Colabora como profesor de asignatura en el ITESO, donde imparte materias de Progra-
mación e Ingeniería de Software. La información en este artículo representa el punto de vista del autor y no necesariamente el de Vision Consulting o
ITESO. fofo@iteso.mx

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

 // COLUMNA
// COLUMNA /*PRUEBA DE SOFTWARE*/
La Calidad del Software Mexicano
Pruebas de software inadecuadas: un Inhibidor de Crecimiento
Luis Vinicio León Carrillo es Director de e-Quallity S.A. de C.V., empresa especializada en prueba de software. Es profesor-investigador
del Departamento de Electrónica, Sistemas e Informática del ITESO. Es doctor por la Universidad Técnica de Clausthal, Alemania; su tesis
tiene que ver con aplicaciones de métodos y lenguajes formales que incrementan significativamente la eficiencia y la efectividad de la
prueba de software.
Me da mucho gusto retomar esta columna en la revista, después de un
receso de aproximadamente un año. Durante ese tiempo hemos visto
cosas interesantes que buscaremos sistematizar y exponer aquí duran-
te éste y los siguientes números.
En [1] describimos los problemas que pueden presentarse cuando el
software no se prueba adecuadamente, analizándolos a la luz de dos
proyectos extremos en los que participamos.
Aquí presentaremos los resultados de la evaluación de la calidad de una
muestra de productos mexicanos en el marco del Concurso e-Quallity
2007, del cual hicimos la premiación en el pasado Congreso SG’07 Confe-
rencia y Expo. No se trata de un estudio estadístico riguroso, pero vemos
estos datos como una aportación inicial para llenar el enorme hueco de
información que tenemos respecto a métricas de calidad de los productos
mexicanos y su repercusión en la industria.
El impacto de probar inadecuadamente el software
En los Estados Unidos, tan solo en 2003, las pérdidas en su industria por
la inexistencia o mala aplicación de pruebas a productos de software as-
cendieron a casi $600 mil millones, que equivalen a aproximadamente
el 1% de su producto interno bruto [2].
Dichas pérdidas consideran no solamente las del sector de Tecnologías
de Información, sino de muchos otros sectores que utilizan el software
en sus operaciones. Se trata de pérdidas que no son sólo cuantiosas,
sino que desgastan gran parte de su sector productivo.
En México no tenemos datos semejantes, pero es posible pensar en un
comportamiento parecido. Sin embargo, en nuestro país el efecto sería
mucho más nocivo (aunque de menor cuantía): mientras que la indus-
tria del software estadounidense es mucho más grande y madura, la
nuestra está apenas despegando; esto dificulta ganar inercia positiva
en muchos sentidos: el crecimiento de la industria se vuelve más lento,
se dificulta generar confianza en esa tecnología, lo que a la vez disminu-
ye la atracción de inversiones en empresas tecnológicas, lo que a su vez
dificulta el crecimiento... un indeseable círculo vicioso.
La muestra y el proceso
El método que utilizamos para la evaluación de productos está formado
por 3 fases:
1. Un diagnóstico del software: un tester experimentado realiza pruebas
exploratorias y detecta una primera capa de defectos. Utilizando esa in-
formación y nuestro modelo estadístico, se genera una estimación de
30 FEB-ABR 2008
los defectos que aún se encuentran en el producto, así como del costo
de detectarlos.
2. Dependiendo de los datos del diagnóstico, el interesado puede optar
por contratar las pruebas profundas.
3. Si después de estas pruebas y luego de aplicar nuestro modelo de
calidad de productos, el software muestra un excelente comportamien-
to (después de las pruebas regresivas [3]), se hace acreedor a ostentar
nuestro sello de calidad. (Este modelo fue validado con apoyo del Con-
sejo Nacional de Ciencia y Tecnología, CONACYT.)
Utilizando esta experiencia, a mediados del año pasado lanzamos este
concurso, en el que convocamos a la comunidad desarrolladora nacio-
nal de software a enviarnos productos terminados pequeños (máximo
30 meses-hombre de desarrollo) para encontrar el producto con la me-
nor densidad de defectos (cantidad de defectos entre tamaño).
Una cantidad considerable de productos fueron rechazados, ya fuera
porque se excedían en el tamaño o porque no estaban completamente
terminados. La muestra final sobre la que se generaron los datos que
mostraremos consta de 24 productos. Su tamaño se midió utilizando
una métrica interna semejante a los puntos de función.
A los productos concursantes les aplicamos una variación del diagnós-
tico descrito arriba y, a cada participante le enviamos la primera capa
de defectos que detectamos en su producto, la estimación de los que
aún quedaban en su sistema, y la comparación de su producto frente a
otros, en términos de densidad de defectos.
Resultados y análisis
El tamaño promedio de los productos fue de 20.4 meses-hombre de
desarrollo, la mayoría de ellos fueron aplicaciones administrativas. La
figura 1 presenta datos concretos sobre la calidad de los productos.
Producto… Defectos / Caso de Defectos aún en el
prueba software
más maduro 1/10 150
promedio 1/4 500
menos maduro 10/17 900
Figura-1: Densidad de defectos en productos mexicanos pequeños
Los datos concuerdan con nuestra experiencia: el promedio de los
productos que hemos probado difiere del mostrado aquí en sólo
unas cuantas centésimas (antes de las correcciones y pruebas re-
www.sg.com.mx
gresivas). Esto es grave, pues significa que
uno de cada cuatro casos de prueba deja al
descubierto algún defecto (aunque no nece-
sariamente crítico).
Dichos datos son relevantes, pues una den-
sidad de defectos como la del promedio
puede tener un impacto significativo en el
crecimiento de las empresas desarrollado-
ras, como se muestra en la figura-2. En ella
la curva negra muestra el consumo “con-
vencional” de los recursos al desarrollar un
nuevo producto de software, considerando
patrones de [4]; la curva verde muestra los
ingresos por ventas del producto; la azul
representa los costos de mantenimiento
cuando el software es probado adecuada-
mente antes de ser liberado y se elimina
la mayoría de los defectos; y la curva roja
representa los costos de mantenimiento
cuando no se prueba o se prueba inadecua-
damente el software.
Figura-2: Impacto económico de las pruebas.
La gráfica muestra algo que vemos en
nuestra práctica diaria y posiblemente
nos hemos acostumbrado a: cuando no
se prueba adecuadamente el software las
consecuencias recaen en los costos de
mantenimiento, estos pueden mermar sig-
nificativamente las utilidades, dificultando
la inversión en las áreas de mercadotec-
nia e innovación en el producto, este factor
provoca la dificultad de crecimiento en esa
unidad de negocio.
www.sg.com.mx
Conclusión
Así como en los Estados Unidos, en
México la prueba de software inade-
cuada también puede tener un im-
pacto negativo severo en la industria
en general.
Dicho impacto se acentúa porque in-
hibe el crecimiento no sólo del sector
de las Tecnologías de Información,
sino de muchos otros que utilizan
software en sus empresas.
Este no es un estudio concluyente,
pero genera información que debiera
motivar a continuar obteniendo da-
tos parecidos. En ese sentido, conti-
nuaremos poniendo nuestro granito
de arena con el Concurso e-Quallity
2008, que lanzaremos durante el pri-
mer trimestre de este año.
Estén pendientes, visiten:
www.e-quallity.net
—Luis Vinicio
Referencias
• [1] León-Carrillo, L. “The Impact of Software
Testing in small Settings”, en Oktaba H. and
Piatini, M. (Eds). “Software Processes in small
Enterprises”. Por publicarse.
• [2] Tassey, G. “The Economic Impacts of In-
adequate Infrastructure for Software Testing”.
Final Report. National Institute of Standards &
Technology. 2002.
• [3] www.e-quallity.net/definiciones.php
• [4] The Project Management Institute. “A
Guide to the Project Management Body of
Knowledge”. USA, 2000.
FEB-ABR 2008
 // PRÁCTICAS /*-CASO DE ESTUDIO*/

CMMi por Medio de

MoProSoft
Experiencia de Kernel Technologies
Por Claudia N. González y Eduardo Olivares

En Septiembre del 2007 Kernel Technologies Group S.A. de C.V. fue
la primera empresa mexicana en alcanzar el nivel 2 de CMMi bajo la
nueva versión del modelo para desarrollo de software versión 1.2.
Pero más importante que esto es el hecho de que basaron su estra-
tegia de implementación en el Modelo MoProSoft. En este artículo,
compartimos algunas de nuestras experiencias y opiniones relacio-
nadas con este proceso de mejora, esperando que le sean de utili-
dad a los lectores de SG.
Para nosotros fue una gran ayuda contar con MoProSoft como refe-
rencia, ya que a diferencia de CMMi, MoProSoft sí cuenta con una
secuencia y lista de actividades a realizar bajo un enfoque y lógica
de negocio. La documentación que proporciona MoProSoft fue de
gran ayuda en la implementación de CMMi ya que es muy clara en
las actividades que deben realizarse, las entradas y salidas de cada
proceso, así como la asignación específica de responsabilidades.
Factores críticos de éxito
A continuación explicamos los que consideramos fueron factores crí-
ticos de éxito para lograr el nivel 2 de CMMi.
Capacitación
El proceso de mejora inició con una estrategia fuerte de capacita-
ción en CMMi para los responsables de definición de procesos. El
propósito fue que estas personas tuvieran en claro la razón de ser
del modelo y las exigencias que involucra. Igual de importante fue
la capacitación impartida al “sponsor” del proyecto, ya que ayudó a
que comprendiera la envergadura del proyecto que estaríamos reali-
zando y que esto requería de su fuerte compromiso y participación.
Para esta capacitación nos apoyamos en la empresa Innevo.
Apego a las actividades de MoProSoft
Decidimos utilizar directamente las actividades de MoProSoft para
hacer checklists de aseguramiento de calidad, revisando por ejem-
plo que se llevaran a cabo todas y cada una de las actividades de pla-
neación para generar el plan de proyecto y plan de desarrollo. Adicio-
nalmente se siguieron las verificaciones y validaciones tal como las
propone MoProSoft. Esto nos permitió asegurar tanto calidad en los
procesos como en los productos de trabajo. La capacitación en los
temas de aseguramiento de calidad se complementó internamente
explicando y revisando los checklists de cumplimiento de activida-
des, así como los artefactos para verificación y validación.
Complementar actividades utilizando el análisis de brecha
Una presentación realizada por la AMCIS en marzo del 2005 para mos-
trar los resultados de las Pruebas Controladas de MoProSoft contenía
un análisis de brecha entre el modelo MoProSoft vs. CMMI N2 en su
versión escalonada, indicando que el 67% de las prácticas se cubrían
en forma total, el 10% se cubrían en forma amplia, 17% en forma par-
cial y el 6% no estaban cubiertas. Nosotros pusimos especial atención
en esta información, ya que ese 67% significaba que solo tendríamos
que completar el 33% restante en cuanto a definición de procesos,
ahorrando así tiempo y esfuerzo en ésta fase del proyecto. Fue así que
conseguimos de parte de AMCIS el detalle de este análisis de brecha
realizado por Cecilia Montero (Lead Assesor) y Gisela Rivera, donde se
detalla la relación entre las prácticas de las Areas de Proceso de CMMI
y los procesos/actividades que las cubrían. Tomando como base éste
mapeo, iniciamos a analizar qué procedimientos, actividades y pro-
ductos tendríamos que agregarle al MoProSoft para que cumpliera
totalmente con cada práctica. Así que para cada brecha definida, defi-
nimos un plan de acción para cubrirla.
Métricas y revisión a nivel gerencial
A fin de asegurar el buen desempeño de los proyectos y el apego a
los procesos, se establecieron reuniones periódicas a nivel gerencial
para revisar los indicadores de los proyectos. Los indicadores que
usamos son índice de cronograma, índice de esfuerzo, índice de cos-
to, así como el uso de semáforos para mostrar cuando un indicador
estaba fuera del rango establecido por la dirección. La definición de
indicadores se basó en las recomendaciones del PMBOK 3ª Edición.
Se agregó una actividad de revisión de los defectos encontrados en
procesos y productos, a fin de tomar acciones correctivas. Se utilizó
una plantilla para llevar a cabo la reunión, donde ya se establecían
los puntos a revisar en la reunión y fue de gran utilidad para no dejar
pasar aspectos de monitoreo como son el manejo de datos, riesgos
asociados a un defecto, y obtener compromiso de los involucrados.

Claudia N. Gonzalez es Licenciada en Sistemas Computacionales por el ITESM y cuenta con reconocimiento por la AMCIS como Practicante MoProSoft, Con-
sultor Profesional MoProSoft, y Evaluador Profesional MoProSoft. Desde 1985 ha trabajado en empresas de desarrollo de software asumiendo diferentes roles
principalmente en tareas de gerencia de proyectos de desarrollo de software y de capacitación y consultoría de procesos.
Eduardo Olivares es Ingeniero Administrador de Sistemas por la UANL y Maestro en Ciencias Computacionales por el ITESM. Cuenta con el certificado de PMP
y con el certificado como PSP Developer y PSP Instructor por el SEI. Desde 1989 ha trabajado como desarrollador, líder de proyectos y jefe de oficina de proyec-
tos en áreas de TI de diferentes grupos empresariales, así como docente del área de Tecnologías de Información del ITESM y de la UDEM.

32 FEB-ABR 2008 www.sg.com.mx

 “La definición de los procesos fue de gran
importancia para la implementación del modelo”.
Para todos los procesos se monitorearon las actividades planeadas
y el esfuerzo estimado contra el real.
Asignación de esfuerzo para actividades del modelo
Quizá uno de los puntos más complejos, pero a la vez más impor-
tantes es estimar el esfuerzo en todas las actividades relaciona-
das con el modelo, tanto CMMI como MoProSoft, de manera que
debe quedar asentado y asignado el tiempo para: la persona que
define y establece los procesos, el encargado de las actividades
de administración de configuración, aseguramiento de calidad de
procesos y productos, capacitación, administración de proyectos
y mantenimiento a la matriz de rastreo. Algunos roles pueden ser
compartidos; por ejemplo la persona de calidad puede también
dar capacitación o participar de la definición de procedimientos,
el configurador puede participar en actividades de desarrollo o
mantener la matriz de rastreo. En nuestra experiencia, el tiempo
de todas las actividades de soporte al proyecto incluyendo tiempo
para medición y análisis, planeación, monitoreo de proyecto, ase-
guramiento de calidad y administración de requerimientos; en un
proyecto que anteriormente tomaba 1,000 horas llevando sólo Mo-
ProSoft, se incrementa en cerca del 20% del esfuerzo después de
haber agregado las actividades del análisis de brecha hacia CMMi
nivel 2. Lo anterior debe considerarse una inversión que paga en
beneficios de calidad y confianza hacia los compromisos del pro-
yecto con el cliente.
Herramientas
Es de gran ayuda apoyarse en herramientas que faciliten la adopción
y aplicación del proceso. Recomendamos considerar herramientas
de trabajo para administración del proceso de cambios en configu-
ración, manejo de la matriz de rastreo, levantamiento y seguimiento
a incidencias, bases de datos con datos del proyecto (WBS, costos,
riesgos, cambios) o herramientas para registro y seguimiento a las
actividades, son importantes para reducir el tiempo de uso de hojas
electrónicas más susceptibles a errores.
Lecciones aprendidas
1. Tal vez la lección aprendida más distintiva de nuestro proyecto,
fue el entender que para cubrir el 33% de actividades pendientes no
significaba invertir un 33% más de esfuerzo ya que las prácticas no
cubiertas en MoProSoft se trataban de cuestiones un tánto comple-
jas de definir e implementar como lo son Administración de Configu-
ración (CM) y Medición y Análisis (MA).
2. Aunque iniciamos las actividades de verificación y validación utilizan-
do como guía los criterios presentados en MoProSoft, nos dimos cuen-
www.sg.com.mx
ta que para asegurar la calidad de producto y proceso como requiere
CMMI tuvimos que detallar checklists que apoyaran ésta práctica.
3. MoProSoft define sus procesos por área de responsabilidad, sin
embargo la secuencia de actividades se da naturalmente entre las
áreas. Por ejemplo, durante el proceso de venta, se requiere que se
realice un entendimiento de requerimientos y una planeación para
poder definir el alcance del proyecto que se está vendiendo. Para
aclarar esta secuencia de actividades nos apoyamos en diagramas
de flujo inter-procesos, lo que ayudó a que se entendiera mejor la
relación entre ellos.
4. MoProSoft define algunas actividades de manera muy general
por lo que en algunas de ellas tuvimos que definir procedimientos
más detallados y/o realizar minutas para asegurar que se cumpliera
completamente la práctica CMMI. Algunos de ellos son: la imple-
mentación de un procedimiento de control de cambios para revi-
sar y autorizar cambios a requerimientos, actividades específicas
de administración de configuración como lo es, establecer un plan
de administración de configuración que indica nombrado de ítems,
permisos, líneas base y niveles de autoridad para su promoción, au-
ditorías físicas y funcionales a realizar. La mayoría de los requisitos
de CMMi estaban cubiertos en las prácticas de MoProSoft reforzán-
dolas con el uso de minutas para cada reunión y dando instruccio-
nes muy específicas, sobre los acuerdos y compromisos que deben
reflejarse en cada reunión, sin dejar margen a ambigüedades. En la
versión de este artículo que se publicará en el sitio web de SG se
incluirá un anexo con un ejemplo de una actividad que fue detallada
de esta forma.
5. Implementar otros procesos MoProSoft como son la Planeación
Estratégica y la Gestión de Procesos ayudaron a la implementación
del proceso y a que la organización lo apoyara, así como a la opera-
ción misma del negocio.
Conclusión
CMMI está enfocado principalmente a organizaciones gran-
des. Sin embargo el enfoque que seguimos de utilizar como
marco de referencia MoProSoft fue un gran acierto que nos
acercó muy rápidamente a nuestro objetivo de lograr el
nivel 2 de madurez en CMMI, apenas 8 meses después de
tener implantado MoProSoft. Ahora vamos por el siguien-
te nivel y además de seguir utilizando MoProSoft como un
marco de referencia relevante nos apoyaremos en PSP/TSP
para acelerar nuestro siguiente objetivo en madurez de pro-
cesos mediante CMMI.
FEB-ABR 2008 33
 // COLUMNA invitada
Lecciones Aprendidas de la Quiebra
de Air-Go Technologies
Cuando el ego nos alcanza
Por Héctor Obregón
D e 1996 a 2002 tuve la oportunidad de
participar como fundador y Director General
de una empresa de servicios de desarrollo
de software en México. Esta empresa inicial-
mente se llamó InterSoftware y más adelan-
te Air-Go en su último año y medio de vida.
En ella perseguimos el sueño de crear la
mejor empresa de su tipo en México. Duran-
te varios años creímos que lo lograríamos y
después, en un periodo de tiempo muy cor-
to, fallamos por completo resultando final-
mente en la desaparición del negocio.
InterSoftware/Air-Go pasó de 5 colaborado-
res en 1996 a más de 300 en el año 2001.
Para el 2002 había desaparecido como en-
tidad funcional. Nuestra empresa fue de las
primeras en México en el desarrollo de apli-
caciones para dispositivos móviles (1998),
búsqueda formal de certificación CMM
(1998), implementación de un modelo de
fábricas de software de bajo costo (1999),
obtención de fondeo institucional de capital
de riesgo (1999), exportación de servicios
de desarrollo de software a Estados Unidos
(2000), y crecimiento mediante la consoli-
dación con competidores (2001). Aunque
nuestra visión puede haber sido la correcta
en varios aspectos, quizá se adelantó un
poco a su tiempo y, mucho más importante,
nuestra ejecución fue incompetente.
En este artículo comparto mis experiencias
personales a través del proceso del fracaso
de esta empresa así como las que considero
son las principales lecciones que espero ha-
ber aprendido durante el proceso.
Las causas del fracaso
Tuvimos mucho éxito en un periodo corto
de tiempo y con relativa facilidad. Desafor-
tunadamente, en mi caso personal eso me
condujo a una actitud de soberbia que me
cegó a la posibilidad de visualizar los pro-
blemas que se avecinaban con el tiempo
suficiente para actuar y prevenirlos. Varios
de mis colaboradores y socios se acercaron
34 AGO-OCT 2008
conmigo para alertarme sobre esto pero
esta soberbia me impidió escucharlos. Una
tremenda frase que jamás olvidaré refleja
la actitud que tenía en 1999. Poco después
de haber acordado la primera ronda de fi-
nanciamiento institucional para la empresa
por un monto de un millón de dólares, le co-
menté a mi socio co-fundador de la empre-
sa: “Ya no es posible que fallemos después
de esto.”. Varios años después, inmerso en
la crisis del negocio, otro de mis socios, un
empresario exitoso radicado en Estados
Unidos me comentaría que mantiene en su
oficina un enorme poster de PanAm Airlines
(ahora desaparecida) para nunca olvidar
que, sin importar el tamaño o el éxito alcan-
zados, la posibilidad de perderlo todo siem-
pre estará vigente.
El éxito aparente también nos había colo-
cado a mí y a algunos de mis colaboradores
dentro de nuestra zona de confort. Nues-
tros ingresos personales eran más que
suficientes para llevar una vida cómoda y
estaban totalmente desconectados de la
rentabilidad y la generación de valor de
la empresa. Aún cuando como socios de-
beríamos haber estado más preocupados
por el desempeño financiero del negocio,
la realidad de nuestro día a día era dema-
siado cómoda.
Sin duda otra de nuestras fallas fue el in-
tentar hacer demasiadas cosas al mismo
tiempo. En un periodo muy reducido de
tiempo expandimos nuestras operaciones
a Guanajuato, Monterrey y, mucho más di-
fícil, Estados Unidos. Todo esto sin tener
experiencia previa sobre las implicaciones
de administrar un crecimiento acelerado.
Alcanzamos a nuestro nivel de incompeten-
cia rápidamente. Acabamos haciendo mu-
chas cosas mal en lugar de pocas bien. Lo
más grave fue que estas operaciones dis-
trajeron la atención de la dirección del ne-
gocio principal que probablemente hubiera
podido salir adelante con más atención.
Mi ego en ese momento influyó también en
algunos conflictos con mis socios. Llegue a
estar más preocupado por mi posición in-
terna y externa como Director General que
por la salud del negocio. Fue fácil distraerme
con juegos de poder donde ya no se trataba
de lo mejor para el negocio sino de lo más
placentero para el propio orgullo. En parti-
cular este problema se hizo manifiesto en
nuestro intento fallido de fusión con otra
de las empresas líderes del mercado en ese
momento: Kiven. Mi conflicto con su Direc-
tor General, fue el factor determinante para
el fracaso de esta operación que probable-
mente, bien ejecutada, hubiera resultado de
gran beneficio para ambas empresas.
Tomamos riesgos extremos en la operación
financiera de la empresa. La supervivencia y
el muy acelerado crecimiento durante 4 años
no nos sensibilizaron al nivel de riesgo que
adquirimos. Adicionalmente en el periodo
1996-2000 era muy fácil para una empresa
innovadora en el sector de IT obtener fondos
y financiamiento debido al entusiasmo ge-
neral en los mercados sobre las posibilida-
des de este tipo de empresas. Este entorno
reforzó la precepción que teníamos de ser
prácticamente infalibles.
La experiencia del fracaso
La postura personal de orgullo que condujo
a mi empresa a fracasar se enfrentó con la
dura realidad en aún menos tiempo del que
había tomado el “éxito”. Cuando disminuyó
el ritmo de crecimiento de la compañía ha-
cia fines del año 2000 debido a la combina-
ción de una desaceleración de la economía
y del tamaño que habíamos alcanzado ya,
en cuestión de un trimestre se hicieron sen-
tir en el flujo de efectivo los problemas de
rentabilidad sistémicos que el negocio te-
nía. Durante años la acelerada tasa de cre-
cimiento en ventas (de alrededor de 100%
anual) permitía financiar la operación de la
empresa aun cuando su rentabilidad real
fuera entre mediocre e inexistente.
www.sg.com.mx

Pocas cosas son más difíciles que enfrentar-
se a dificultades de flujo de efectivo de corto
plazo en la operación del negocio. Rápida-
mente nuestras líneas de financiamiento
estaban saturadas y nos enfrentamos a pro-
blemas para solventar los costos de opera-
ción más indispensables como la nómina de
nuestro personal. Simultáneamente la “luna
de miel” con los inversionistas instituciona-
les terminaba y nos enfrascamos en discu-
siones sobre cómo solucionar el problema
sin llegar a acuerdos a la velocidad que la
situación demandaba. Los clientes se per-
cataron de nuestros problemas y, natural-
mente, perdieron la confianza en nosotros
como proveedores lo que aceleró nuestra
caída. Provocando que los inversionistas
institucionales perdieran la posibilidad de
creer en mí y se negaran a proporcionar
fondos adicionales para “darle la vuelta” al
problema. Aún cuando nuestros colabora-
dores hicieron un importante esfuerzo por
seguir operando, aun ante la falta de pago,
naturalmente esto nos llevó a un desgaste
finalmente insalvable.
Para fines del 2001, la única opción que me
quedaba para evitar el cierre inmediato de
la empresa era aceptar mi remoción como
Director General para tomar las funciones de
ventas. Fue muy poco y demasiado tarde.
Consideraba, y sigo considerando, a mis
principales colaboradores como mis amigos.
El afecto hacia y desde ellos dificultó enor-
memente contar con la claridad suficiente
para tomar las decisiones adecuadas.
En cuestión de meses pasé de una posición
de orgullo desmedido al otro extremo emo-
cional. Me sentí la persona más incompeten-
te y estúpida del mundo. Las malas noticias
adicionales, por pequeñas que fueran, me
provocaban crisis de pánico. Resultaba casi
imposible levantarse a trabajar todos los días
y la magnitud del problema me sobrepasó
tanto personal como profesionalmente.
www.sg.com.mx
“Debemos respetar a cualquier socio
potencial de tal manera que sus aportaciones
sean genuinamente efectivas, para el
desarrollo del negocio”.
Superar el vacío
Ahora, varios años después, no puedo más
que sentirme afortunado de haber superado
ese momento extraordinariamente doloroso
y difícil. Hay una serie de elementos que
fueron clave para poder salir adelante.
Sin duda lo más importante fue el que, aún
durante el punto más álgido, conté con el
apoyo de varias personas que siguieron
creyendo en mí. Esta confianza fue el sal-
vavidas que en ese momento me permitió
no ahogarme. Puedo mencionar a Mauricio
Mingramm, mi actual socio en emlink, a
Marcos Achar, Director General de Comex
(que continúa siendo nuestro cliente) , a mi
tío Raúl Obregón, y a un compacto equipo
de colaboradores que continuaron creyendo
en mí a pesar de todos los errores que co-
metí. A todos ellos les estaré agradecido el
resto de mi vida por su apoyo y confianza.
Durante este trance descubrí el significado
de la fe. No soy un hombre religioso. Sin em-
bargo, jamás había estado en una situación
donde tuviera que simplemente creer que
iba a salir adelante sin tener la más remota
idea de cómo lo lograría ni ningún funda-
mento lógico para creer que fuera posible.
Creer genuinamente en algo sin ningún fun-
damento racional es para mí el significado
más claro de la fe.
Fue necesario procesar emocionalmente el
fracaso y asumirlo. Esto no me fue posible
hacerlo rápidamente. Se requiere un espa-
cio de tiempo para poder procesar el duelo.
Sin temor a exagerar, me parece que el dolor
de ese momento haya sido similar al de la
pérdida de un ser querido. No es posible sa-
lir adelante de un dolor de este tipo sin darle
oportunidad de seguir su curso.
Necesité aprender a mirar siempre hacia el
futuro y rápidamente dar vuelta a las pági-
nas del fracaso. La tentación del enojo y de
aferrarse al éxito anteriormente logrado era
fuerte y creo que me hubiera hecho perder
más tiempo y dedicarle energía a persecu-
ciones sin sentido.
En la medida de lo posible, busque enfren-
tar la situación con la máxima franqueza
posible con los distintos afectados por el
cierre de la empresa. Había que darle malas
noticias a muchas personas. A los colabo-
radores, socios, acreedores, clientes y pro-
veedores. Todos se vieron afectados negati-
vamente por los errores que cometimos. En
la gran mayoría de los casos, el trato franco
con ellos evitó problemas muchos mayores.
Los casos donde no me fue posible hacerlo
o no dediqué el tiempo necesario fueron los
que se complicaron después convirtiéndo-
se, por ejemplo, en serios dolores de cabeza
legales. Sin embargo, creo que no es posi-
ble satisfacer a todos los afectados. Hay que
entender esto y prepararse para asumir las
consecuencias.
10 lecciones aprendidas
Las siguientes lecciones de aprendizaje per-
sonal no pretenden ser una receta general
para quien se encuentre en una situación
similar. No son resultado de un amplio es-
tudio de casos. Simplemente son un breve
resumen de lo más significativo de lo vivido
personalmente a lo largo de la experiencia
relatada y de la posterior búsqueda de cons-
truir una nueva empresa, emLink.
1. La gente vale la pena
Mencioné que el afecto con y desde mis cola-
boradores dificultó la toma de algunas deci-
siones importantes. Sin embargo, no me ima-
gino ni me interesa la construcción de una
relación de trabajo sin afecto. Estoy absolu-
tamente convencido de que la construcción
de un afecto es indispensable para lograr una
motivación de conjunto y un liderazgo efecti-
vo. Así que, en lugar de renunciar a este me
parece que lo mejor es incorporarlo dentro de
una ética de trabajo y claridad en la defini-
ción y evaluación de objetivos profesionales.
AGO-OCT 2008 35
 // COLUMNA invitada

“Los clientes se percataron de nuestros

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

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

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

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

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

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

 // PRÁCTICAS
Líneas de Productos de Software
Aplicando adaptación masiva al software
por Gilberto Grajales
Como sabemos, los sistemas de software cada vez son más com-
plejos, debido tanto a los pasos agigantados que da la tecnología,
como a la importancia que continuamente cobran los sistemas de
información en nuestras vidas. A lo largo de los años, nuevos mé-
todos, técnicas y herramientas han sido creados para mitigar esta
creciente complejidad de desarrollar software.
Una de las técnicas que han surgido para mitigar dicha complejidad,
es la reutilización, la cual consiste en desarrollar elementos de soft-
ware que puedan utilizarse más de una vez con la mínima cantidad
de modificaciones, garantizando que al reutilizar un elemento de
software libre de defectos, implicará que el sistema que lo utilice no
tendrá problema alguno en lo que respecta a dicho elemento.
Tal fue el éxito de aplicar la reutilización, que ésta evolucionó de al-
guna manera hasta generar el concepto de “Líneas de Productos de
Software” (LPS) –conocido también como Familias de Sistemas de
Software– para el cual se conocen indicios desde los años 70 cuan-
do Parnas mencionó los beneficios de tener una familia de sistemas
compartiendo características entre ellos[1].
Adaptación de productos de forma masiva
Las LPS parten de las ideas de la producción en serie (como lo
hizo Henry Ford), dando la capacidad a una organización de pro-
ducir o generar (nótese que no se usa el término desarrollar)
sistemas de software en forma masiva, satisfaciendo las deman-
das del mercado; entre otros beneficios significativos. La adap-
tación masiva consiste en la capacidad para generar productos
que comparten en gran parte características comunes, pero
también mantienen características propias de cada uno de ellos.
Tomando como ejemplo una línea de productos de automóviles,
se puede ver que para un modelo específico de auto se pueden
fabricar unidades con características propias tales como el co-
lor, el número de puertas, transmisión automática o estándar,
eléctrico o no, etcétera. Manteniendo las características esen-
ciales del modelo.
Líneas de productos de software
Según el Instituto de Ingeniería de Software (SEI) una LPS se define de la
siguiente manera:
“Una LPS es un conjunto de sistemas de software compartiendo ca-
racterísticas comunes y administradas que satisface las necesidades
Gilberto Grajales obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas (CIMAT) realizando investigación sobre Líneas
de Productos de Software aplicado al área de Ingeniería de Requerimientos. Ha jugado distintos roles en proyectos de desarrollo de software. Actualmente labora en
JPE Consultores donde se dedica a la consultoría, capacitación y mejora de procesos en Ingeniería de Software. Tiene un especial interés en las áreas de Ingeniería
de Requerimientos y Calidad de Software. Puede ser contactado en gilberto@jpeconsultores.com
44 AGO-OCT 2009
/*MEJORA DE PROCESOS*/
específicas de un segmento de mercado particular o misión y que
son desarrolladas de forma preescrita a partir de un conjunto común
de elementos clave”.
Como lo indica la definición, una LPS consiste en un conjunto de
elementos clave para producir sistemas de software que com-
parten características comunes (llamadas similitudes), pero al
mismo tiempo mantienen características propias (llamada varia-
bilidad). Para proporcionar estas características individuales a
cada miembro de la familia, la adaptación masiva debe ser lo
suficientemente flexible para satisfacer tal necesidad, pues ade-
más el número distinto de miembros está limitado a una serie de
restricciones las cuales también deben satisfacerse; a esto se le
llama administración de la variabilidad.
Fases o etapas para implementar una LPS
En una LPS se propicia una reutilización a alto nivel, desarrollando
los elementos comunes que servirán como base para la generación
de cada miembro de la familia. Las etapas esenciales a ejecutar
son tres:
1. De ingeniería de dominios en la cual se desarrollan los elemen-
tos comunes.
2. De ingeniería de aplicaciones donde se generan los sistemas que
son miembros de la familia. Dichos miembros se generan a partir
de los elementos comunes, pero tomando en cuenta el modelo de
variabilidad definido.
3. Un conjunto de actividades que orquestarán las dos etapas anteriores.
Es decir, se necesita de un proceso para ejecutar de manera ordenada la
ingeniería de dominios y la ingeniería de aplicaciones.
Las dos primeras etapas están compuestas por las fases tradicionales del
modelo de cascada (Requerimientos, Diseño, Implementación, Pruebas)
pero con objetivos distintos como ya se mencionó.
Enfoques de adopción de una LPS
Se han planteado varios enfoques como estrategia para reali-
zar la adopción de una LPS, entre ellos algunos tienen nombre
distinto de acuerdo al “framework” o metodología en la que es-
tán contenidos, pero consisten en la misma estrategia. Básica-
mente, existen tres enfoques de adopción los cuales han sido
reportados bajo otros nombres, sin embargo, en esencia son lo
mismo. Dischos enfoques son:
www.sg.com.mx
Proactivo: funciona cuando la implantación de la LPS se
hace desde cero, es decir que aún no se cuenta con sistemas de
software que pertenecerán a la familia. Debido a la complejidad
y al enorme esfuerzo que demanda este enfoque, es apropia-
do para las empresas que tienen una visión muy clara de los
productos que conformarán la familia, además de que tienen
niveles de madurez para predecir con gran certeza tal proceso
y cuentan con los recursos económicos y humanos suficientes
para realizar la inversión.
Extractivo: inicia con la selección de uno o más sistemas ya
existentes, que serán parte de la familia de productos; efectuando
un tipo de ingeniería inversa para extraer los artefactos de software
comunes para establecerlos como elementos comunes y modelar la
variabilidad que existe entre ellos. Este enfoque es ad-hoc para or-
ganizaciones que quieren efectuar la transición de una manera rápi-
da, de desarrollar sistemas individuales a generar sistemas a partir
de una LPS.
Reactivo: toma la esencia del proceso de espiral o iterativo
para efectuar la transición poco a poco. Se realizan los pasos como
en el enfoque proactivo, pero para cada ciclo o espiral, de esta
manera se van eliminando riesgos y se va aclarando la visión de las
similitudes y variabilidades de los productos que serán miembros
de la familia. Es adecuado para organizaciones que mantienen
planes de trabajo agresivos, que no pueden dedicar los recursos
humanos suficientes para la adopción y sólo pueden disponer de
un subconjunto de ellos.
Beneficios de una LPS
La implantación de una LPS no es una tarea sencilla, sino que re-
quiere un gran esfuerzo y sobre todo una gran inversión para su
éxito. Sin embargo, los beneficios obtenidos motivan a realizarlo.
Los beneficios de un proyecto de mejora de procesos de software
han sido presentados y documentados[2, 3] y se dice que el retor-
no de inversión va en un rango de 5:1 de costo-beneficio. En un
caso de estudio de la empresa Cummins Engine Inc.[4] se adoptó
una LPS después de haber realizado un proyecto de mejora de pro-
cesos; y reportan que la mejora de procesos por sí sola tuvo un
radio de costo-beneficio entre 2:1 y 3:1; y la implantación de la LPS
en adición a la mejora de procesos arrojó un costo-beneficio de
10:1. Lo cual muestra evidencia de que si un SPI vale la pena, una
LPS vale aún más.
Existen muchos beneficios que una LPS puede proporcionar, destacando
los siguientes entre los más relevantes:
• Obtención de las ganancias de una producción a gran escala.
Como se mencionó en la adaptación masiva, una LPS habilita a producir
www.sg.com.mx
sistemas de software a partir de una plataforma de artefactos comunes
de manera que los productos sólo necesiten ensamblarse en vez de ser
desarrollados individualmente.
• Mejora la capacidad para el “Time-to-market”. Muchas veces
las demandas del mercado exigen tener estrategias de mercado-
tecnia que implican tener productos o implementar ideas inno-
vadoras antes de cierta fecha. Bajo un esquema tradicional de
desarrollo de sistemas individualmente, dichas estrategias son
demasiado difíciles de ejecutar haciendo perder a una organi-
zación la oportunidad de crecer en un mercado cambiante, pues
como se dice por ahí: “el que pega primero pega dos veces”. Con
una LPS, una organización puede tomar el reto de establecer es-
trategias de mercadotecnia agresivas, ya que cuentan con la ca-
pacidad de generar productos de forma acelerada. En la figura 1
se muestra una gráfica que representa el tiempo de desarrollo de
sistemas de software con y sin una LPS, donde el eje horizontal
representa el número de sistemas distintos desarrollados ,y el
eje vertical el tiempo de liberación en el mercado. Como se puede
ver al inicio, el tiempo de desarrollo de la LPS hace que éste sea
mucho mayor que el desarrollo de los primeros sistemas indivi-
duales ,debido a que primero se deben desarrollar los elementos
comunes, sin embargo, conforme se empiezan a desarrollar más
sistemas, el tiempo de liberación en una LPS se reduce radical-
mente en comparación al desarrollo individual, lo cual demues-
tra que a un mediano plazo los beneficios serán mucho mayores;
pues como se mencionó, una organización se puede comprome-
ter a liberar cierto producto de su LPS en menos de la mitad del
tiempo que le llevaría desarrollarlo individualmente.
Figura 1. Time-to-Market con y sin una LPS.
AGO-OCT 2009 45
 // PRÁCTICAS /*MEJORA DE PROCESOS*/

• Reducción de costos de desarrollo. Con una LPS los costos
de desarrollo de los sistemas miembros de la familia, están muy
por debajo de los costos de desarrollo de sistemas individuales.
Al igual que en el “time-to-market”, al inicio el desarrollo de los
elementos comunes tiene mayor costo que desarrollar un sistema
individualmente. No obstante, una vez obtenidos, el costo dismi-
nuye. Se puede decir que la tasa de incremento en el costo acumu-
lado es mucho menor en una LPS que en sistemas individuales.
• Mejora de la calidad de los productos. Desde que el desarrollo
de los elementos comunes es similar al desarrollo de los artefactos
para un sistema individual, dichos elementos son probados cons-
tantemente por cada producto generado, y por formar parte de to-
dos los productos de la familia se puede decir que la calidad es más
fácil y fielmente asegurada en todos ellos.
• Logro de las metas de reutilización de la organización. Dado
que las LPS se basan en la reutilización de artefactos para un con-
junto de sistemas, la reutilización planeada se obtiene al desarrollar
la plataforma de elementos comunes.
• Reducción de la necesidad de contratar nuevo personal. Des-
de que el proceso de generación de los productos de software se au-
tomatiza cada vez más, la necesidad de contratar gente disminuye
debido a que dichos productos son generados cada vez con menos
ingenieros de software, lo cual de alguna manera ayuda a disminuir
los costos a la organización.
• Incremento de la satisfacción del cliente. Por varios de los be-
neficios mencionados anteriormente, los clientes y usuarios de los
sistemas generados con la LPS obtienen productos de software de
mucha mayor calidad a precios mucho más bajos que los que obten-
drían con un proveedor que no cuenta con una LPS.
cación de características relevantes de sistemas de software que
pertenecen a un dominio. Se dice que estas características son
aspectos del dominio visibles al usuario final.
A pesar de que el método FODA está compuesto de tres fases,
para las cuales hay una serie de actividades individuales [6], la
más relevante es la del modelado de características, pues es la
que definirá las similitudes y variabilidades implícitas en el do-
minio. Dicho modelo de características se define por medio de
un árbol donde quedarán especificados los elementos comunes y
variables del dominio.
Por ejemplo, en la figura 2 se muestra un árbol de características
para una línea de automóviles donde se pueden ver las caracte-
rísticas comunes (como la transmisión y el caballaje) y las carac-
terísticas variables. Las variables pueden ser opcionales y estar
contenidas o no en un sistema particular del dominio (como es el
caso del aire acondicionado). También puede haber características
alternativas de las cuales sólo una se puede implementar en un
sistema particular del dominio (por ejemplo: la transmisión pue-
de ser manual o automática,pero no ambas). Además, dentro de
un modelo de características se pueden incluir algunas reglas de
composición las cuales definen algunas relaciones entre caracte-
rísticas opcionales y/o alternativas.
Existen principalmente dos tipos de ellas: la primera es donde la
existencia de una implica o requiere la existencia de la otra; y la
segunda es donde la existencia de una implica o requiere que no
exista la otra (que sean mutuamente exclusivas). Para nuestro mo-

Existen otros beneficios no menos importantes, sin embargo los que

aquí se presentaron son los más significativos. Si se desea obtener
más información acerca de estos otros beneficios se recomienda
consultar el capítulo 2 en [4].

El método FODA
Desde antes de existir el concepto de LPS existía la herramienta de
análisis de dominio (AD), que se enfoca en analizar los aspectos
comunes de un dominio particular que podíría consistir de un con-
junto de sistemas relacionados. A partir de esto, surgieron muchos
métodos de AD, siendo el método FODA (Feature-Oriented Domain
Analysis) el que marcó una pauta en el desarrollo del AD, pues ha
sido ampliamente utilizado para extraer las similitudes y variabili-
dades de un dominio. El principal objetivo de FODA es la identifi- Figura 2. Árbol de características para una línea de automóviles.

46 AGO-OCT 2009 www.sg.com.mx

 “Una LPS consiste en un conjunto de elementos clave para
producir sistemas de software, que comparten características
comunes, pero mantienen elementos propios”.

delo de ejemplo en la figura, existe una regla donde la existencia Referencias

de aire acondicionado requiere que el caballaje sea mayor a 100.
Conclusiones
En este artículo se dió un vistazo a los fundamentos sobre los
que descansan las líneas de productos de software. Como se
pudo ver, la misma complejidad del sofware hace que nue-
vos métodos sean desarrollados para mitigarla, como lo son
las LPS. Pero además de intentar reducir la complejidad de
desarrollo de software, las LPS tienen otros beneficios signi-
ficativos, como la disminución del costo de desarrollo, que
motivan a las organizaciones a tomar el reto de invertir en la
implantación de una LPS.
[1]. Parnas, D.L. “On the Design and Development of Program Families”.
IEEE Transactions on Software Engineering, SE-2:1-9, March 1976.
[2] Ferguson, P. et al. “Software Process Improvement Works!” (CMU/SEI-99-
TR-027, ADA371804)”. Software Engineering Institute, November 1999.
[3] Goldenson, D. & Herbsleb, J. “After the Appraisal: A Systematic Survey
of Process Improvement, its Benefits, and Factors that Influence Suc-
cess (CMU/SEI-95-TR-009, ADA302225)”. Software Engineering Institute,
August 1995.
[4] Clements, P. & Northrop, L. “Software Product Lines: Practices and
Patterns”. Reading, MA: Addison-Wesley, 2002.
[5] Kang, K. et al. “Feature-Oriented Domain Analysis (FODA) Feasibility
Study, Technical Report CMU/SEI-90-TR-21”. Software Engineering Institu-
te, November 1990.

www.sg.com.mx AGO-OCT 2009 47