ENE-FEB 2007

• Análisis de ROI
• POJOs y
Frameworks Ligeros
• Evaluación de
Arquitecturas
Software Guru CONOCIMIENTO EN PRÁCTICA
Año 03 No.01 • Enero-Febrero 2007 • www.softwareguru.com.mx
ESPECIAL
Desarrollo de
Software en
Universidades
[ ENTREVISTAS ]
Desde Creanimax
Bill Plympton
René Castillo
Ernesto Gálvez
Desarrollo de
Videojuegos
¿Por dónde comenzar?
México, $65.00
Noticias • Eventos • Fundamentos • UML • Infraestructura • Reflexiones
[ Novedades ]
WCF
// CONTENIDO
directorio
Dirección Editorial
Pedro Galván
Dirección de Operaciones
Mara Ruvalcaba
Coordinación Editorial
Susana Tamayo
Asesoría Editorial
Edgardo Domínguez
Arte y Diseño
Dafne Ortega
Oscar Sámano
Consejo Editorial
Francisco Camargo, Ralf Eder, Raúl Trejo,
Guillermo Rodríguez, ITESM-CEM;
Hanna Oktaba, UNAM-AMCIS;
Luis Cuellar, Softtek;
Luis Vinicio León, e-Quallity - ITESO.
Editorial
Quizá muchos de ustedes se vean sorprendidos con la portada de esta edición,
la número13 de SG, la primera del año que
apenas comienza. Y es que para abrir este
2007, decidimos enfocarnos en un tema
que está de moda: los videojuegos. Al
igual que todos los temas que abordamos,
hemos buscado hacerlo desde la perspectiva no de usuarios, sino de creadores. Por
otra parte, escoger este tema nos permitió tomarnos algunas libertades no sólo
en el diseño, sino también en los contenidos. Consideramos que este número
tiene un buen balance de temas y niveles
de profundidad. Tenemos desde artículos
amigables que van dirigidos al público en
general, hasta los muy clavados que son
para nuestros fieles gurús. Tal vez por
error llegue a haber algunos despistados
que tomen esta revista pensando que encontrarán información sobre los últimos
juegos y consolas. Al principio se llevarán
una desilusión, pero estamos seguros que
se les pasará cuando descubran que aquí
hay información para aprender a desarrollar sus propios juegos.
Además del desarrollo de videojuegos,
tenemos un artículo especial que recalca
la importancia y necesidad de los centros
de desarrollo de software en las universidades. Consideramos que estos centros
son vitales para generar los profesionistas de software que necesitamos. Com-
02
ENE-FEB 2007
plementamos todo esto con las opiniones
de nuestros columnistas, que ya son parte fundamental del contenido; echaremos
un vistazo por Windows Communication
Foundation, que es uno de los pilares de
Windows Vista; veremos cómo determinar el ROI de un esfuerzo de mejora de
procesos, y también conoceremos sobre
los famosos POJOs. Vale la pena hacer un
paréntesis para mencionar que durante
todo el tiempo que estuvimos haciendo
este número, cada que se mencionaba
el término POJO, Susana no podía evitar
pensar en cierta ave de color amarillo.
Mientras editábamos los textos de este
número, llegamos a la conclusión de que
tienen un dejo de nostalgia, porque la mayoría de los colaboradores que participaron,
hacen referencias al pasado, a su juventud.
En realidad, queremos llegar tanto a los jóvenes que apenas comienzan como a todos
aquellos que crecieron mirando la evolución
de un mundo que hoy nos ha rebasado.
Equipo Editorial
FE DE ERRATAS:
Queremos pedir una disculpa porque en el número
anterior Jorge Palacios escribió el reportaje del Cluster
FidSoftware y no apareció su crédito; por otra parte, el
subtítulo en la columna de Hanna Oktaba debió decir:
International Process Research Consortium (IPRC).
Colaboradores
Ariel García, Sergio Orozco,
Luis Daniel Soto, Jaime Sánchez,
Marco A. Dorantes, Jorge Palacios, Joaquín
Arellano, Carlos Gutiérrez, Oscar Guillén,
Angélica Su, Alfredo Calvo, Ixcoatl Pérez, Omar
Gómez, Ana Vázquez, Mario Gutiérrez, Haarón
González, Charlie Macías, Emilio Osorio,
Consuelo Jiménez, Joel Villagrana.
Ilustración de Portada
www.tollhaus.com.mx
Ventas
Claudia Perea
Marketing
Natalia Sánchez
Circulación y Subscripciones
Daniel Velázquez
Contacto
info@softwareguru.com.mx
+52 55 5239 5502
SG Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col.
El Parque, C.P. 53398, Naucalpan, México. Prohibida
la reproducción total o parcial del contenido sin previo
aviso por escrito de los editores. Todos los artículos son
responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva
de Derechos al Uso Exclusivo: 04-2004-090212091400102. Certificado de licitud de título: 12999. Certificado
de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en diciembre de
2006 en Litográfica Roma. Distribuido por Rrecca Comercializadora y Sepomex.
www.softwareguru.com.mx
24
contenido
ene-feb 2007
EN PORTADA
Desarrollo de Videojuegos
Nuestro artículo de portada en esta ocasión,
abarca desde los primeros pasos hacia la
creación de videojuegos hasta un amplio
panorama de esta industria y la oportunidad
que representa para nuestro país.
Productos
LO QUE VIENE
12
IBM Rational SDP, Apache Axis 2, JBoss
Seam y Unity3D NOVEDADES
14
Windows Communication Foundation
Especial
Centros de Desarrollo de
Software en Universidades Columnas
Tejiendo Nuestra Red 08
por Hanna Oktaba y Ana Váquez
Cátedra y Más
por Mario Gutiérrez
46
Mejora Continua
por Luis Cuellar
10
Tierra Libre
por Emilio Osorio
48
Tendencias en Software
por Luis Daniel Soto
44
16
Prácticas
MEJORA DE PROCESOS Análisis de ROI
36
La mejora de procesos requiere una inversión
significativa de recursos. Alfredo Calvo y Angélica
Su nos explican cómo estimar el ROI.
DISEÑO
POJOs y Frameworks Ligeros
38
Ixcoatl Pérez nos muestra cómo combinar POJOs
con frameworks como Spring e Hibernate, para
desarrollar aplicaciones empresariales.
ARQUITECTURA
40
Evaluación de Arquitectura de Software
Omar Gómez nos enseña a evaluar arquitecturas
para determinar si cumplen con los requerimientos.
En Cada Número
20
Entrevista
Bill Plympton, René Castillo, Ernesto Gálvez
www.softwareguru.com.mx
Noticias y Eventos
CLÚSTERS
UML
Fundamentos
INFRAESTRUCTURA
REFLEXIONES
04
06
42
50
52
56
ENE-FEB 2007
03
// NOTICIAS
Oracle Open World
Del 22 al 26 de octubre, los más innovadores desarrollos
en tecnología, aplicaciones y soluciones desfilaron por el
Centro Moscone de San Francisco, California, durante el
Oracle OpenWorld 2006.
En un imponente ambiente de alrededor de 41 mil participantes de todo el mundo, se llevaron a cabo más de 1,400
sesiones en torno a las principales aplicaciones de Oracle, 400 demos en vivo de desarrolladores, conferencias
a cargo de importantes usuarios y ejecutivos de Oracle, y
una Expo con más de 300 expositores. Durante el evento,
como noticia principal y sorpresa para muchos, Oracle
anunció que dará soporte total a estándares abiertos, por
medio del programa llamado Unbreakable Linux.
Lanzamiento de Windows Vista
El pasado 29 de noviembre se realizó la presentación de Windows Vista y Office 2007, dedicada a los desarrolladores de
software y profesionales de TI. Dicho evento se realizó en el
World Trade Center de la Ciudad de México, y resaltó por su
magnitud y variedad. La gran sorpresa fue que la conferencia
de arranque la impartió Jesús Ramírez, Director Técnico de la
Selección Sub 17 de futbol, actuales campeones mundiales.
Su plática estuvo enfocada en el poder de la mente cuando
se aplica de manera correcta, y en la importancia del trabajo
en equipo. Posteriormente se llevaron a cabo sesiones para
ahondar en los distintos detalles de esta nueva versión, y el
nuevo modelo de desarrollo de aplicaciones que introduce.
Toman Protesta los Miembros de
la Mesa Directiva de la ANIEI
El pasado 12 de diciembre, en las instalaciones de la Rectoría de la UAM, se llevó a cabo la toma de protesta de los
miembros de la Mesa Directiva de la Asociación Nacional
de Instituciones de Educación en Informática (ANIEI). Para
su periodo 2006 - 2008, la Lic. Ma. de Lourdes Sánchez, por
segunda ocasión, estará a cargo de la presidencia de esta
asociación. La ANIEI ha fungido como pieza fundamental
en la vinculación Industria-Academia-Gobierno, ya que entre sus principales objetivos está el ejecutar la estrategia
2 del programa PROSOFT, enfocada en diseñar el modelo
paracurricular de Desarrollador de Software, Ingeniero de
Software, Arquitecto, y Administrador en Proyectos, así
como adecuar los modelos educativos relacionados con la
informática, tareas clave para el esperado crecimiento de la
industria de software en México.
04
ENE-FEB 2007
www.softwareguru.com.mx
// EVENTOS
13 al 16 Febrero 2007
27 Febrero al 2 Marzo 2007
Congreso Nacional de Software Libre
Facultad de Ingeniería UNAM, Cd. de México
Info: www.consol.org.mx
Email: consol@consol.org.mx
Expo Comm 2007, Von Conference & Expo, Expo Móvil
Centro Banamex, Cd. de México
Info: www.expocomm.com.mx
Tel: (55) 1087-1650 ext. 1160
Email: marcela@ejkrause.com
27 Febrero 2007
22 al 24 Marzo 2007
Select
Centro Banamex, Cd. de México
Info: www.select.com.mx
Tel: (55) 5256 1426
Email: liliana.garcia@select.com.mx
Centro de Investigación en Matemáticas (CIMAT)
Hotel Real de Minas, Guanajuato, Gto.
Info: www.cimat.mx/Sitios/seissigma
Email: seissigma@cimat.mx
CONSOL 2007
Tendencias 2007
Softtek, Única Empresa Privada que
Opera dos Centros CMMI5 y uno CMM5
en América Latina
Softtek concluyó con éxito la valoración en CMMI 5 de sus Centros de
Entrega de Servicio Near Shore en Aguascalientes y México D. F. Estos
se suman al Centro en Monterrey, que fue evaluado CMM 5 en 2004.
Blanca Treviño, Presidente y CEO de Softtek comentó: “El contar con
una red de Centros certificados en los más altos niveles de CMM,
proporciona cuantiosos beneficios a nuestros clientes en función de
productividad, eficiencia en costos y certeza de resultados.” Softtek
ha sido pionero en la implementación de prácticas de ingeniería de software en América Latina, y en los servicios de Near Shore outsourcing.
Hoy en día, la empresa cuenta con 7 Centros, 4 de ellos en México, 2 en
Brasil, y uno más en España, a los que se sumará un nuevo Centro en
Asia que iniciará operaciones hacia finales de 2007.
IMSS, Primer Organismo de Gobierno
en Alcanzar la Evaluación CMMI
La Coordinación de Tecnología para la incorporación y Recaudación del Seguro Social (CTIRSS) fue acreditada con el nivel
3 de capacidad y nivel 2 de madurez de CMMI. La CTIRSS,
a cargo del Lic. Marco Rojano, quien forma parte del equipo del Lic. Igor Rosette, Director de Innovación y Desarrollo
Tecnológico del IMSS, se ha convertido en la primera unidad
de gobierno en México y una de las 50 a nivel mundial en obtener dicha evaluación. Esto representa una recompensa al
esfuerzo de más de 3 años de trabajo de un área conformada
por más 60 personas, quienes además de desarrollar y mantener en operación más de 50 aplicaciones que soportan los
procesos de incorporación y recaudación de todo el Instituto, se pusieron como meta el hacer crecer una organización
de clase mundial.
www.softwareguru.com.mx
Linux World Conference & Expo
III Simposio Metodología Seis Sigma
TI-M, Primera Empresa en el Norte
de México en Obtener CMMI Nivel 3
TI-M (anteriormente TI Móvil) fue acreditado bajo el nivel 3
de CMMI. La implementación y evaluación fueron posibles
gracias al apoyo de consultores de It Era. El proceso de
implementación tuvo una duración total de dos años, y el
grupo evaluador fue dirigido por el SCAMPI Lead Appraiser
Carlos Galván.
TI-M se ha destacado por minimizar el riesgo en el portafolio
de proyectos de TI y maximizar el rendimiento de las inversiones de clientes como Ternium-Hylsa, Sigma Alimentos,
Ipsos Bimsa, entre otros.
GULEV Congreso Internacional de Software
Libre 2006
Del 7 al 9 de diciembre se llevó a cabo la VI edición del GULEV
Congreso Internacional de Software Libre, en Cancún, Quintana
Roo. Este año se contó con la presencia de algunas de las más
importantes figuras del Software Libre como Miguel de Icaza
(Novell) quien ha iniciado proyectos como GNOME y Mono,
Rasmus Lerdorf creador de PHP uno de los lenguajes de programación más populares en el mundo, Bruce Momjian creador de
PostgreSQL un potente gestor de Bases de Datos, Bdale Garbee
(HP) y por primera vez en un evento en latinoamerica, Guido Van
Rossum, creador del lenguaje Python.
El evento fue un éxito, y se anunció que próximamente habrá
muy gratas sorpresas alrededor del evento de Software Libre
con mayor tradición en México.
ENE-FEB 2007
05
// REPORTAJE
/* CLÚSTERS */
Teraloc
De Morelos para Todo México
Por Jorge Palacios
Teraloc es una integradora de empresas del área de Tecnología de Información, que está basada en la ciudad de Cuernavaca, Morelos y
opera desde 2003. Principalmente se enfoca a desarrollar y comercializar productos de sus asociados para la gestión publica, apoyándose
en diferentes herramientas y distintas metodologías en las que se trabaja la administración de proyectos, ITIL, PSP/TSP.
Teraloc cuenta con 6 socios, que son:
•Synerware - Especializada en el software para agencias automotrices.
•Morelos Web - Dedicada al desarrollo y hosting de paginas web
para el Estado de Morelos.
•Victec - Enfocados al desarrollo de aplicaciones de referenciación
geográfica.
•AE Sistemas - Desarrolla aplicaciones administrativas dando servicios a la medida de las necesidades del cliente.
•Pineda y Asociados especializados en metodologías para BPM.
•AFRM procesos - que se dedica al modelado de procesos.
La unión de estas seis empresas, da como resultado, Teraloc, que
como ya explicamos, es una integradora de empresas de TI en el estado de Morelos. Estas forman parte de la Asociación de la Industria
del Software en Morelos, que es la AISAC. Teraloc surge con el objetivo de crear un corredor tecnológico en esta zona, estableciéndolo
como la integradora y la Asociación de Intelsoft.
¿Por qué Teraloc?
El vocablo Teraloc proviene de la combinación del prefijo Tera, que
se refiere a cantidad 1x1012, como se entiende en Megabytes, Gigabytes y Terabytes, y Loc, que se refiere a las siglas utilizadas para
referirse a líneas de código (lines of code). Este nombre se debe a
que el enfoque inicial estaba orientado a la maquila de desarrollo
de software. Sin embargo, la experiencia ha hecho ver a Teraloc,
que es mejor enfocarse en segmentos de mayor valor, y por eso ha
decidido enfocarse en la gestión y automatización de procesos de
negocio (BPM), y metodologías de administración de proyectos y
desarrollo de software.
Como ya mencionamos, Teraloc nació hace cuatro años, al parejo
del programa ProSoft. Desde un inicio han contado con el apoyo de
dicho programa, y han aprovechado los recursos provenientes de
este fondo para dirigirlos principalmente al área de capacitación.
De hecho, Teraloc fue la primera compañía del estado de Morelos
en firmar un convenio con Prosoft, siendo la primera entidad para
el desarrollo del impulso del software.
Pero las habilidades del personal no son todo. También se necesitan procesos maduros y repetibles, y clientes interesados en adquirir tus productos y servicios. Fue por eso que desde un inicio, Teraloc definió un plan de
desarrollo estratégico, que además de la capacitación, consideraba otros
aspectos como la definición de procesos, y la generación de demanda.
Los resultados de tales esfuerzos han sido, sin duda positivos, dando como resultado que la oferta de valor de Teraloc sea más competitiva en términos de calidad y precio. Adicionalmente, Teraloc provee
soluciones para la comunidad, tales como apertura de empleos y
soluciones a nivel gubernamental.
Mercado meta
Teraloc tiene bien definido cual es su mercado meta, el cual está
compuesto de:
•Empresas medianas y grandes que necesiten redefinir y/o automatizar sus procesos internos y externos a través de diversas tecnologías de información para dar un soporte adecuado en la toma de
decisiones.
•Micro y pequeña empresa agrupada.
•Gobierno en sus 3 niveles.
Principales logros
Entre los logros más recientes de Teraloc y sus empresas asociadas,
podemos resaltar los siguientes:
•Selección de Syner IP para el programa de aceleración Techba en
Austin, Texas.
•Creación de la cátedra AISAC en el ITESM Campus Ciudad de México
y Santa Fe.
•Definición del Modelo APTI de TeraLOC para la administración de
proyectos de TI y su adopción en la AISAC.
•Plataforma e-learning para capacitación a distancia vía web.
•Integración de IT Learning en el consejo de educación a distancia de
la Secretaría de Economía.
Para mayor información, visita www.teraloc.com.
La primera etapa en el desarrollo de Teraloc, estuvo enfocada en
la generación y formación de recursos humanos. Teraloc desde el
principio se ha manejado con un enfoque académico en la formación de gente, generando confianza a través de cursos de capacitación donde reciben certificaciones conjuntas. De acuerdo
con la gente de Teraloc, esto ha sido la base para establecer lazos
de comunicación y, que la integradora siga funcionando y dando
grandes resultados.
06
ENE-FEB 2007
www.softwareguru.com.mx
// COLUMNA
/*TEJIENDO NUESTRA RED*/
Lo Que Pasó en Luxemburgo
Avances de MoProSoft en el WG24
La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fundadora de la AMCIS. Actualmente es miembro de
International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.
E
n esta ocasión voy a contarles sobre la
segunda participación de la Delegación
Mexicana en una reunión del ISO/IEC JTC1
SC7 WG24, cuyo nombre es “Software Life
Cycle Profiles and Guidelines for use in Very
Small Enterprises (VSE)”.
Ya en el número de julio-agosto 2006, platicamos sobre la primera participación de la
Delegación en la ciudad de Bangkok, donde
nuestra norma mexicana basada en MoProSoft y EvalProSoft fue presentada y se seleccionó, de entre varios documentos similares
de otros países como base para los trabajos
del grupo. En esa primera reunión, la Delegación Mexicana se comprometió a realizar la
traducción de MoProSoft al inglés; realizado
en un grupo de trabajo que integra el NYCE
(el organismo que emitió la norma), y que se
entregó a través de la Dirección General de
Normas, al responsable del WG24.
La Delegación en esta ocasión estuvo integrada por Francisco López Lira, Ana Vázquez
y yo, que somos miembros de la AMCIS y
hemos trabajado en diversos proyectos relacionados con la norma. El objetivo fue incluir
en los productos del WG24 la mayor cantidad de elementos de MoProSoft. La reunión
se llevó a cabo en Luxemburgo del 2 al 6 de
octubre, y asistieron delegados de Bélgica,
Luxemburgo, Finlandia, Canadá, Irlanda, Estados Unidos, Tailandia, Sudáfrica y Australia, siendo ésta, la primera participación de
los dos últimos.
El objetivo de dicha sesión fue definir el conjunto de actividades que las VSE implementarán en su primer ciclo de mejora, y que en
adelante, llamaremos “primer perfil”. Las actividades realizadas fueron las siguientes:
•Presentación de las cuatro partes de la
norma MoProSoft.
•Selección de los procesos de MoProSoft
que integrarán el primer perfil.
•Selección de las actividades de estos procesos que integrarán el primer perfil.
08
ENE-FEB 2007
Después de hacer un análisis de los objetivos
de cada uno de los procesos, así como los
costos y beneficios asociados, los procesos
seleccionados fueron los que se encuentran
en la categoría de Operación: Administración
de Proyectos Específicos (APE) y, Desarrollo
y Mantenimiento de Software (DMS).
Los participantes se dividieron en dos grupos para analizar las actividades de cada
uno de estos procesos, y seleccionar las que
consideraban indispensables para el primer
perfil. Nuestro papel consistió principalmente, en explicarles el “porqué” de algunos elementos que tiene el modelo y su relación con
la práctica que conocemos.
Posteriormente, se realizó una discusión
conjunta de ambos grupos para generar
consenso. Cabe aclarar que no contaban con
el “acordeón”, de la versión “coloreada” por
niveles de capacidades.
En general, las actividades seleccionadas del
proceso de Administración de Proyectos Específicos fueron las que corresponden al nivel de
capacidad 1, y de Desarrollo y Mantenimiento
de Software de los niveles 1 y 2. Dicho de otra
forma, del proceso APE se eligió la planeación,
registro y control de los principales parámetros
de administración de proyectos como costo,
tiempo y riesgo, mientras que del DMS se escogieron las actividades de Especificación de
Requerimientos, Análisis y Diseño, Construcción, Integración y Pruebas, con sus respectivas verificaciones y validaciones.
En adición, se incluyeron algunas actividades para controlar los cambios y las versiones de los productos, subsanando así la
ausencia del proceso de Conocimiento de la
Organización en este primer perfil.
¿Nada nuevo? En realidad no, ya que estas
buenas prácticas están contenidas en otros
estándares como el ISO/IEC 12207, además
de ser conocidas por buena parte de la industria. Lo que sí pretende aportar el WG24,
son herramientas de diversos tipos para
ayudar en la implementación de estas prácticas en las VSE, como son la secuencia de
actividades, roles, descripciones de productos, formatos, etcétera.
La próxima reunión será en mayo de 2007,
en San Petersburgo. Para entonces se espera que el delegado de Finlandia, Timo Varkoi,
experto en el estándar ISO/IEC 12207, tenga el mapeo de MoProSoft hacia esa norma,
que este primer perfil haya sido revisado o
probado en los países de origen de los delegados, y que los documentos del grupo tengan un número ISO/IEC asignado.
El trabajo va para largo. Ya nos dimos cuenta
que con dos reuniones de trabajo al año no
se puede avanzar mucho. El objetivo es generar una secuencia de 3 a 4 perfiles, cada
vez más amplios, no necesariamente correspondientes a niveles de capacidades o de
madurez, que sirvan de guía a las empresas.
El perfil final incluirá a MoProSoft completo.
Y de Luxemburgo... lo que les podemos contar
es que es un país con historia milenaria. Su número de habitantes no rebasa a la delegación
más pequeña del DF, no tiene fronteras; es por
supuesto muy limpio, y tiene la parte antigua
con castillos y callejones como de cuento de
hadas. Sin embargo, es un país fundador de la
Unión Europea, un país que hace competencia
a Suiza en el área bancaria y, que a la vez, está
preocupado por apoyar e innovar a sus pequeñas empresas. Nuestros anfitriones fueron del
Centre de Recherche Public Henri Tudor, el cual
desde hace veinte años se dedica al apoyo de
las PyMES en el uso de las Tecnologías de Información para su beneficio.
Otra vez nos da envidia, ¿verdad? Mejor
aprendamos de otros y agreguemos nuestros granitos de arena. Porque lo que podemos hacer, también puede servir de ejemplo a los demás.
— Hanna Oktaba y Ana Vázquez
www.softwareguru.com.mx
// COLUMNA
/*MEJORA CONTINUA*/
Procesos y Variabilidad
La Diferencia entre Productos y Servicios
Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality
(ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la
definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.
Ú
ltimamente he tenido que viajar a diferentes lugares, lo que me
ha dado algo de tiempo para leer. En la Harvard Business Review de noviembre 2006, encontré un artículo sumamente interesante, titulado: “Breaking the Tradeoff of Efficiency and Services”.
El artículo, básicamente habla sobre el hecho de que una de las grandes
diferencias entre las compañías de productos y las de servicio, radica en
que en una organización de servicios, el cliente constantemente irrumpe
en la operación, a través de un comportamiento impredecible, pidiendo
servicios en tiempos no apropiados, una gran cantidad de actividades
adicionales, o cambiando continuamente de opinión. Esto genera grandes variaciones en el proceso, y hace mucho más complicada la operación orientada a servicios, que la enfocada a producto.
En un servicio, conforme aumenta la variabilidad, también aumenta
el costo. Por ejemplo, si el cliente cambia con frecuencia de decisión,
en cuanto a si quiere su sistema con una funcionalidad específica
o no, el costo de la aplicación se eleva, y se genera trabajo que finalmente no se utilizará. Para poder resolver esta problemática, el
autor del artículo que leí, plantea la necesidad de definir el tipo de
interrupción que genera el cliente, y tomar la decisión entre:
a) Manejar la variabilidad en forma controlada. Por ejemplo, los procesos de Starbucks están diseñados para ofrecer un gran número de
opciones, y aun así, controlarlas dentro del mismo proceso.
b) Reducir la variabilidad. Por ejemplo, un restaurante maneja tipos
de cocina y menús para reducir las posibilidades de variación dentro
de las elecciones a seguir.
Máquinas y personas
Tal vez lo que más me llamó la atención del artículo, fueron las implicaciones que esta diferencia entre productos y servicios tiene en el área de
sistemas. Todos sabemos que desarrollar sistemas es, tanto un producto (el sistema en cuestión) como un servicio (análisis de la problemática, diseño de la solución, etcétera). Esta dualidad hace que el desarrollo
de sistemas sea una labor sumamente compleja y llena de decisiones,
y el gran problema que nos trae es que lo que a un cliente dejó sumamente maravillado, a otro simplemente no le trae ningún valor, por lo
que es difícil hacerlo repetible. Por desgracia, muchas de las teorías de
Ingeniería de Software y modelos de Calidad, se basan en modelos de
manufactura, en donde el cliente genera una variabilidad mínima.
Esto nos lleva a una amplia diferenciación entre dos extremos de pensamiento: por un lado están los que ven la calidad como una lista de
proceso, plantillas, y reglas inquebrantables que todo proyecto debe
seguir para minimizar la variabilidad. Por otro lado, están los que
piensan que no tienen sentido los modelos de calidad, pues por más
procesos que se tengan, siempre existirán miles de decisiones que se
10
ENE-FEB 2007
toman en su momento, y lo mejor es tener gente inteligente que pueda
resolver de forma autónoma todos los problemas que se le presenten.
El proceso que se siga, será a discreción de dichos individuos.
La estrategia de calidad inteligente, es precisamente la que se mueve en medio de estos dos mundos, la que da una serie de reglas,
prácticas técnicas y lineamientos. Se asegura que éstos se sigan de
acuerdo a como se planeó al principio del proyecto, y tiene apoyo
constante del resto de la organización para asegurarse de lograr un
buen balance entre flexibilidad y variabilidad.
Ni muy muy ni tan tan
Veamos de nuevo el desarrollo de software como un servicio. Los
procesos de calidad tienen dos funciones primordiales:
1) Lograr generar un producto sin defectos y bajo un presupuesto
predeterminado
2) Reducir el costo de manera constante al capitalizar el conocimiento, para que el siguiente producto se haga de forma más rápida.
En otras palabras, estamos buscando complacer al usuario lo más
eficientemente posible, por ende, con la menor variación posible.
Así, todo proyecto debe iniciar preguntándole al cliente cuáles son sus
requerimientos no funcionales más importantes y por qué. Con esta
información, podemos crear una serie de métricas que nos ayuden a
ver si estamos cumpliendo con lo que un cliente en particular considera calidad. Algunos clientes tienen muy claro que las métricas más
importantes de su proyecto son la entrega a tiempo, sin defectos y
bajo el presupuesto acordado. Sin embargo, tenemos muchos otros
con ideas diferentes, hay algunos que no les preocupan esas cosas;
buscan una compañía con la que se puedan entender, por lo que para
ellos, lo más importante es la flexibilidad en la forma de trabajo, y una
gran comunicación entre las personas del proyecto. Mientras que a
otros, lo que les interesa es que su gente se quede con el conocimiento necesario, aunque cueste más caro. Sin importar cuáles son los requisitos, es muy importante conocerlos, medirlos, y en base a ellos,
establecer en dónde se debe guiar al cliente y en dónde seguirlo.
A final de cuentas
Bajo ningún motivo, un proceso substituye a tener gente capaz de
resolver y entender las necesidades del cliente. Por lo tanto, la idea
de que exista un proceso, es buscar cómo disminuir, en la medida
posible, la mayoría de las variaciones en el proyecto, para así lograr
resultados más eficientes, y al mismo tiempo tener a nuestros clientes siempre contentos, sin importar lo que estén buscando.
—Luis Cuellar
www.softwareguru.com.mx
// PUBLIREPORTAJE
eDeveloper V10 de Magic Software Enterprises es el nuevo paso evolutivo de una herramienta de programación que por más de dos décadas, ha
estado entregando tecnología innovadora para los desarrolladores de
aplicaciones que se enfocan en minimizar los costos, ajustándose a los
estándares que prevalecen en la industria.
M
uchos de los conceptos actualmente aceptados como
parte esencial para la administración de todo el ciclo de
desarrollo, han sido la parte central de la productividad de eDeveloper a través de toda su historia.
Estos conceptos incluyen: repositorios para abarcar las descripciones de una aplicación completa, Reglas de Negocio para
obtener los mayores niveles de abstracción, Desarrollo Declarativo por medio de metadatos para reducir la codificación de
manera drástica.
Todo esto se logra sin definir una sola línea de código, ya que
todas la reglas de negocio están interconstruidas en el motor autómata, que es el núcleo central de la tecnología Magic.
Esto nos lleva a ser un Lenguaje visual 4GL y, a ser considerados
como una herramienta RAD+D, donde la última D, es la facilidad
de poner en Ejecución (Deployment) nuestros desarrollos.
Aunado a esto, tenemos la posibilidad de que las aplicaciones desarrolladas con eDeveloper sean rápidamente escalables, facilitando la implementación de nuevas versiones de sus sistemas.
También tenemos la capacidad de que sus desarrollos corran en
distintas plataformas, como UNIX, Linux o Windows, y con conexiones a las bases de datos líderes en la industria, incluida la
capacidad de explotar datos de sistemas AS/400.
Tenemos un rápido Retorno de la Inversión hecha con eDeveloper, ya que las ventajas que se le presentan al programador, le
permiten incrementar su eficiencia. Las mayores ventajas que
se otorgan son el uso de un paradigma de desarrollo uniforme,
tanto para aplicaciones C/S o para Web; una independencia de
la base de datos a utilizar, permitiendo que el desarrollador se
olvide de las tareas mundanas de conexión a las distintas bases
de datos que pudieran utilizarse en su organización; la interoperabilidad con las distintas tecnologías emergentes, como el
uso de XML, ejecución de servicios de mensajería MSMQ, la
interacción con plataformas J2EE y el uso de Web Services.
Con estas características de conexión tan diversas, tenemos la
capacidad de generar aplicaciones compuestas, sin que esto disminuya la velocidad de desarrollo.
Lo que nos permite ser compatibles con las Arquitecturas Orientadas a Servicios (SOA), y a su vez, ser una herramienta para el
Desarrollo de Aplicaciones Orientadas a Servicios (SODA), pero
siempre contemplando los estándares existentes en la industria;
como en el caso, por poner un ejemplo, de nuestra conexión a
Systinet, que es un aplicativo estándar para la comunicación,
tanto de consumo como de proveedor de Web Services.
Nuestros desarrollos se guardan en documentos XML, pero sin que
el desarrollador tenga que escribir una sola línea XML. eDeveloper
es tan compatible con XML, que puede ocupar un documento XML,
y editarlo como si se tratase de una tabla de una base de datos.
El entorno de desarrollo, conocido como Editor de Tareas, conjunta todas las características necesarias para el desarrollo de la
lógica, así como la presentación de un programa o tarea.
La edición de las formas que se dispondrán al usuario final, podrán tener la mejor presentación, siendo compatibles con los estilos gráficos de Windows XP, para el caso de aplicaciones C/S,
o compatibles con los estilos diseñados por el editor de páginas
HTML de su elección, para el caso de aplicaciones Web.
El programador podrá trabajar de la misma forma en C/S como en
Web, basados en un mismo paradigma de desarrollo. Todo está
basado en una tecnología que conocemos como Browser Client,
el cual, pondrá a nuestra disposición, la facilidad de crear aplicaciones para Internet o Intranet, pero dándole al usuario final, la
apariencia de que trabaja en C/S. Un concepto de una aplicación
para cliente ligero basado en un navegador.
El motor autómata permite ejecutar nuestras aplicaciones ya sea
corriendo dentro del módulo de ejecución de aplicaciones, como
en el caso de aplicaciones Stand-Alone o C/S, o corriendo como
servicios, para el caso de Servidores de Procesos o Servidores de
Aplicaciones Web. Y con la capacidad de portabilidad a distintas
plataformas, esto nos ofrece un espectro de posibilidades mayor.
Esto, y mucho más, es el eDeveloper V10. Mayor información en
www.rocasistemas.com.mx
// PRODUCTOS
/* LO QUE VIENE*/
Rational Software Delivery Platform 7.0
Desarrollo Global de Aplicaciones SOA
IBM lanzó la versión 7 de su línea de herramientas de desarrollo de software, Rational Software Delivery Platform (SDP) que es un conjunto de herramientas para
desarrollar software, basadas en Eclipse, y complementada con procesos que engloban mejores prácticas, como el Rational Unified Process.
Esta versión está principalmente orientada a la construcción y mantenimiento
de aplicaciones orientadas a servicios. Otro aspecto importante, es que atiende
las características y necesidades del desarrollo de software moderno y global,
donde los equipos de desarrollo están dispersos geográficamente, por lo que las
herramientas de desarrollo deben soportar y facilitar esta forma de trabajo.
Algunos de los productos específicos incluidos como parte de esta nueva
versión están:
•IBM Rational Application Developer – Un IDE completo para diseñar, desarrollar,
depurar e instalar aplicaciones SOA y J2EE en ambientes empresariales.
•IBM Rational Software Modeler – Un modelador visual basado en UML 2.1, para
que los arquitectos, analistas y diseñadores plasmen y comuniquen los requerimientos y diseño de los sistemas a construir.
•IBM Rational Functional Tester – Una herramienta de pruebas avanzada que
provee pruebas automatizadas funcionales y de regresión.
Más información en www-306.ibm.com/software/rational
Apache Axis2
JBoss Seam 1.1
Aplicaciones Web con Funcionalidad Compleja,
pero Desarrollo Sencillo
Seam es el framework de JBoss para desarrollar aplicaciones Web 2.0. Dicho framework integra tecnologías
populares como AJAX, Java Server Faces, EJB3, Java
portlets y workflow, bajo un modelo unificado.
Seam facilita el desarrollo de aplicaciones web ricas y basadas en estados (stateful), a través del manejo sencillo
de objetos con estado, que residen en el servidor, que
interactúan con componentes AJAX del lado del cliente.
La versión 1.1 de Seam se liberó recientemente, y entre
sus nuevas capacidades están:
•Modelo de componentes basado en POJOs, que elimina la dependencia a EJBs para manejar estado.
•Nuevo framework de persistencia basado en Java
Persistente API e Hibernate.
•Integración con ICEfaces y Ajax4jsf para generar componentes GUI de nueva generación.
•Soporte de conversaciones atómicas, las cuales
son requeridas por el modelo de operación de las
aplicaciones AJAX.
Mayor información en www.jboss.com/products/seam
Web Services Open Source de 3ra Generación
Axis2 es un motor de web services desarrollado por la Apache Software Foundation, y por lo tanto, open source. Axis2 se encuentra
actualmente en su versión 1.1, la cual fue recientemente liberada y
recibida con gran entusiasmo por la comunidad.
De acuerdo con los expertos, hoy en día estamos en la tercera generación de middleware para web services, y Axis2 forma parte de
ésta. Mientras que las dos primeras generaciones se enfocaron en
demostrar que los web services “eran posibles”, la tercera generación se enfoca en hacerlos eficientes y confiables. Es decir, algo que
vaya más allá de los prototipos, y que sea una alternativa real para
sistemas de misión crítica.
Apache Axis2 fue diseñado y construido desde cero, a partir de las
lecciones aprendidas con Apache Axis, el cual puede ser considerado
un middleware de web services de 2da generación. Axis2 es mucho
más eficiente, escalable y modular que su antecesor. Además, es
altamente extensible a través de módulos opcionales para soportar
especificaciones avanzadas de web services como son WS-Security,
WS-Trust, WS-Reliable Messaging, o WS-Eventing.
Más información en ws.apache.org/axis2
12
ENE-FEB 2007
Unity 1.6
Desarrollo de Juegos 3D Multiplataforma
Unity es una herramienta para desarrollar juegos de
3D, que se pueden ejecutar en un navegador web, o
standalone. Con Unity se puede generar gráficas de
gran detalle, a una gran velocidad. Vale la pena notar
ue, Unity utiliza Mono como máquina virtual para la
ejecución de scripts multiplataforma.
Unity es utilizado por diversos estudios desarrolladores de juegos, y recibió el segundo lugar en la categoría “Mejor uso de las gráficas de Mac OS X”, durante el
pasado Developer Conference de Apple.
En el sitio web de Unity (unity3d.com) se puede descargar
una versión de evaluación, y también se puede echar un
vistazo a la galería de cosas hechas con dicha herramienta. Quedarás impresionado por el detalle y velocidad de
las gráficas que se ejecutan en tu navegador.
www.softwareguru.com.mx
// PRODUCTOS
/* NOVEDADES*/
Windows Communication Foundation
Un Framework para Desarrollar Aplicaciones Distribuidas
Por Haarón González
V
ivimos en un mundo cada día más conectado. Las organizaciones se han enrolado en la era de Internet, ofreciendo servicios
electrónicos que les permiten integrar o exponer su información interna, hacia clientes u otros procesos empresariales externos. Esta
conectividad, combinada con la necesidad de integrar sistemas heterogéneos, ha influenciado el establecimiento de un nuevo paradigma: las arquitecturas orientadas a servicios (SOA), de las cuales
hemos oído tanto en los últimos meses.
A pesar de que ya existían múltiples tecnologías para construir este tipo
de sistemas, como lo son CORBA y DCOM, en definitiva los servicios web
basados en XML fueron un paso importante para descubrir y asimilar el
verdadero potencial del concepto de software como servicio, o software
que se conecta con software, abriendo una nueva gama de posibilidades para construir aplicaciones distribuidas, debido a la adopción de
estándares abiertos para conectar personas, sistemas y dispositivos.
Múltiples proveedores de plataformas tecnológicas ya soportan en sus
productos el uso de web services y sus estándares para permitirnos integrar sistemas, aunque éstos utilicen diferentes plataformas operativas. Sin embargo, las capacidades de integración a través de servicios
web no son del todo ricas, de alguna manera están limitadas a cierto
tipo de escenarios. En otras palabras, los servicios web se quedan cortos en funcionalidad. Por ejemplo, hacer trabajar tecnologías J2EE con
.NET es factible, pero complicado a la vez, requiere de consideraciones
técnicas adicionales para reforzar la seguridad, compartir la identidad
de usuario, soportar transacciones distribuidas.
Los retos que se tienen en la actualidad para hacer realidad la visión
de orientación a servicios son:
•¿Cómo podemos asegurarnos de que las conexiones entre los servicios sean confiables, y se repongan a fallos en la comunicación?
•¿Cómo establecer todo un mecanismo de seguridad integral para el
intercambio de mensajes entre servicios?
•¿Cómo crear aplicaciones que expandan sus fronteras de confianza y
participen en procesos transaccionales locales y remotos?
•¿Qué modelo de programación debo utilizar para construir servicios?
•¿Cómo puedo hacer que una aplicación esté orientada a servicios y
pueda beneficiarse de este estilo de arquitectura?
Para resolver estas necesidades, se ha creado la tecnología Windows
Communication Foundation (WCF).
Windows Communication Foundation
Es uno de los pilares del .NET Framework 3.0. Básicamente provee
un subsistema de programación para la construcción de aplicaciones
distribuidas orientadas a servicios. WCF permite el desarrollo de ser-
vicios seguros, confiables y transaccionales que interoperan ya sea
con plataformas Microsoft u otras; soportando coexistencia con anteriores tecnologías para aprovechar las inversiones existentes. Ofrece
mecanismos de implementación mucho más sofisticados que los que
actualmente utilizamos para distribuir servicios y conectar sistemas.
WCF combina y extiende las tecnologías actuales para construir sistemas distribuidos bajo plataforma Microsoft, hablamos de .NET Enterprise Services (COM+), MSMQ, .NET Framework Remoting, Web Service Enhancement (WSE), ASP.NET Web Services (ASMX) y System.Messaging,
con la intención de proveer un solo marco de trabajo o unificado.
Como ya comenté, WCF es parte del .NET Framework 3.0, lo que
significa que es parte integral e interna de Windows Vista, pero que
también estará disponible en otros sistemas operativos que soporten el .NET Framework 3.0, como Windows XP SP2 y Windows Server
2003 SP1. Adicionalmente, existen proyectos basados en Mono, para
llevar soporte de WCF a plataforma Unix/Linux.
Objetivos de Diseño
WCF hace posible lo anterior gracias a los siguientes objetivos de diseño:
•Soportar internamente un gran conjunto de protocolos para servicios web: las tecnologías actuales para web services proveen soporte para un tipo de interoperabilidad muy básica entre aplicaciones.
Por ejemplo, estas tecnologías carecen de la habilidad de lograr interoperabilidad garantizando una seguridad integral y comunicación
confiable. WCF soporta interoperabilidad segura, confiable y transaccional, a través de soporte interno para las especificaciones WS-*.
•Diseño orientado a servicios: los principios del desarrollo orientado
a servicios han permitido hacer frente al reto de construir software
que se adapta con rapidez a las necesidades del negocio. WCF es el
primer modelo de programación construido desde cero para facilitar
implícitamente el desarrollo de aplicaciones orientadas a servicios.
•Modelo de programación unificado: WCF provee una API diseñada
para el desarrollo de sistemas conectados, lo cual trae mejoras en
productividad al desarrollar este tipo de sistemas.
Fundamentos de WCF
La figura 1 ilustra el flujo de un servicio que utiliza WCF. Los EndPoint
son la unidad principal de exposición de funcionalidad en un servicio,
un servicio puede albergar múltiples EndPoint cada uno con su propia configuración. Los EndPoints pueden ser configurados de manera
programática (en código) o declarativa (en configuración XML) y son
prácticamente nuestros canales de conversación con las aplicaciones cliente o con otros consumidores de nuestros servicios, ya que
Haarón González trabaja para DirectApps, una empresa de Sacramento, CA dedicada a construir soluciones web para automatizar flujos de trabajo, servicios
de infraestructura y staffing. Haarón es Licenciado en Informática egresado del Instituto Tecnológico de Mexicali, y cuenta con las certificaciones MCP, MCAD
y MCT, además de ser reconocido como Microsoft MVP en la categorÌa ASP.NET, y ser orador regional de INETA (International .NET Association).
14
ENE-FEB 2007
www.softwareguru.com.mx
definen en donde, cómo y qué se intercambia. Los EndPoints están
compuestos por:
• Address define: donde exponer un servicio, en otras palabras, una
dirección en la red en donde reside un servicio.
• Binding define: cómo exponer un servicio, o qué protocolos de transporte (TCP, HTTP), codificación (texto, binario, MTOM) y requerimientos
de seguridad (SSL, WS-Security) se utilizarán en la conversación.
• Contract define: qué exponer en un servicio, es decir, qué estructuras (datos) y operaciones (métodos) se pueden intercambiar durante
una conversación entre servicios.
Un ejemplo sencillo
Una vez definido nuestro contrato, lo implementamos en la clase
CalculoService, que es donde realmente existirá la funcionalidad de
nuestro servicio.
using System.ServiceModel;
namespace BasicWCFDemo.Server
{
[ServiceBehavior(Name = “CalculoService”)]
public class CalculoService : ICalculoService
{ public int Suma(int x, int y)
{ return x + y; }
public int Resta(int x, int y)
{ return x - y; }
public int Multiplicacion(int x, int y) { return x * y; }
}
}
El siguiente paso es especificar el hospedaje de nuestro servicio, y
eso lo hacemos a través de la clase ServiceHost. Con ServiceHost podemos hacer que cualquier aplicación pueda convertirse en un huésped de algún servicio, eliminando dependencias a otros productos
del servidor. Por ejemplo, el siguiente código hace que nuestra aplicación de consola sea un huésped de servicio.
using System.ServiceModel;
Figura 1. Flujo de un servicio con WCF.
Para construir servicios WCF requerimos hacer referencia a System.
ServiceModel incluido en .NET Framework 3.0. Primeramente hay que
definir el contrato, ya que es muy importante especificar las reglas para
lograr una conversación. En WCF existen los atributos DataContract y
OperationContract. Los DataContract nos permiten calificar código para
que sean tomadas como las estructuras de datos que vamos a utilizar
para intercambiar mensajes. Los OperationContract nos permiten calificar código para que sea tomado como los métodos o puntos de entrada
que pueden invocarse durante el intercambio de mensajes.
Veamos el código para definir un contrato:
using System.ServiceModel;
namespace BasicWCFDemo.Server
{
[ServiceContract(Namespace = “http://DemoWCFService.ServiceContracts/2006/11”,
Name = “ICalculoService”)]
public interface ICalculoService
{ [OperationContract(Action = “Suma”, IsOneWay = false)]
int Suma(int x, int y);
[OperationContract(Action = “Resta”, IsOneWay = false)]
int Resta(int x, int y);
[OperationContract(Action = “Multiplicacion”, IsOneWay = false)]
int Multiplicacion(int x, int y);
}
}
www.softwareguru.com.mx
namespace BasicWCFDemo.Server
{
class Program
{
static void Main(string[] args)
{
Uri direccionUrl = new Uri(“http://localhost:8080/BasicWCFDemoServer”);
ServiceHost servicioHost = new ServiceHost(typeof(CalculoService), direccionUrl);
servicioHost.AddServiceEndpoint(typeof(ICalculoService), new BasicHttpBinding(),
direccionUrl);
servicioHost.Open();
Console.WriteLine(“Servicio escuchando...”);
Console.ReadKey();
servicioHost.Close();
}
}
}
Si observamos detenidamente el código, encontraremos que se ha especificado la dirección (address) donde reside nuestro servicio en la red,
el canal (binding) utilizado para intercambiar mensajes (BasicHttpBinding) y el contrato usado por el servicio. Aquí es donde sucede la magia,
ya que es donde podemos configurar nuestro servicio basado en los
tres conceptos más importantes: Address, Binding y Contract.
Conclusión
WCF se puede usar para conectar sistemas que se ejecutan en contextos locales, Intranet, Extranet e Internet. WCF provee un marco de
referencia unificado y con capacidades avanzadas para el desarrollo
de aplicaciones distribuidas.
ENE-FEB 2007
15
// ESPECIAL
¿Centros de Desarrollo
de Software en las Universidades?
Una Realidad aún sin Explotar
Por Joaquín Arellano
de una carrera de Ingeniería
¿paraEldeegresado
Software, está realmente preparado
afrontar como se debe, los retos que
demanda el mercado laboral?, lamentablemente, en la mayoría de los casos, el alumno promedio sólo obtiene los conocimientos
teóricos y prácticos que le enseñan en las
aulas, y que a pesar de que son buenos, no
son del todo suficientes. ¿Cuál puede ser una
de las causas? Hoy en día, no sólo es necesario dominar algún lenguaje de programación
orientado a objetos –pensando que es la única opción para un problema–, sino también,
poder codificar en el clásico notepad o en un
editor básico, saber que existen técnicas de
producción de sistemas; aprender de memoria el modelo de cascada o espiral, u otro, saber de la existencia de UML, pero no saberla
aplicar; conocer y desarrollar en una sola
base de datos, y en general, conceptos básicos del mundo de IT; se requiere ampliar así
como profundizar en dichos conocimientos y
en muchos más, no por soberbia, sino porque
el mercado lo exige, demanda profesionistas
mejor preparados en áreas de conocimientos
más recientes, cada vez más usadas.
Por otra parte, para incrementar su competitividad, el
egresado necesita tener un background más amplio de lo
que los planes de estudios actuales ofrecen. Esto, debido
a que el mercado laboral es muy exigente, competitivo,
y no sólo requiere profesionistas que sepan conceptos y
fundamentos básicos de Information Technology (IT, por
sus siglas en inglés); sino que también se requiere que estén familiarizados con:
•IDEs: como Java Studio Creator 2, Visual Studio
2003/2005, Eclipse, NetBeans, Zend Studio, etcétera.
•No sólo dominar un lenguaje de programación (orientado a objetos, estructurado, procedural, etcétera),
sino que además, sepan usar de forma básica otros
lenguajes (si no dominarlo, saber qué alcance tiene
cada uno y cuáles son sus ventajas sobre otros lenguajes) en caso que sea necesario moverse a un nuevo
lenguaje.
•Cómo interactúan diferentes lenguajes con diferentes
proveedores de bases de datos (Oracle, SQL Server, MySQL, Informix, PostgreSQL, etcétera).
•La ya tan mencionada Web 2.0.
•Modelos arquitectónicos como MVC (Model View Controller), o SOA (Service Oriented Architecture).
•Poder entender adecuadamente y llevar a la práctica
(en escala) conceptos de ingeniería de software, pasando por modelado de objetos, calidad en el software, PSP,
TSP, ITIL y, ¿por qué no?, CMM/CMMI y varios más.
•Creación de Software confiable, seguro, adaptable, administrable, entre otros.
•Facilidad de adaptarse a cambios, tiempos y tecnologías.
Joaquín Alonso Arellano Ramírez, se ha desempeñado como desarrollador, implementador y administrador de sistemas, coautor del artículo “Confiabilidad del Software: desarrollando productos confiables”. Sus intereses en el área de sistemas incluyen, sistemas en plataforma WEB y Técnicas de Producción de Sistemas. Trabaja
en el departamento de desarrollo de sistemas escolares del ITESM Campus Monterrey y forma parte del equipo que implementa el modelo CMMi en el mismo instituto.
16
ENE-FEB 2007
www.softwareguru.com.mx
“El egresado necesita tener un background
más amplio de lo que los planes de estudios
actuales ofrecen”.
¿Dónde puede el alumno aprender esto?, dónde más,
sino en su misma universidad, ¿de qué forma?, promoviendo centros de desarrollo de software en los que el
alumno pueda, de forma voluntaria, involucrarse y profundizar en conceptos como los antes mencionados,
mientras desarrolla proyectos reales, que no necesariamente tienen que ser grandes (en complejidad y tamaño)
para que el alumno pueda usar los conceptos anteriores,
sino a través de proyectos planeados y estructurados,
todo, al mismo tiempo que cursa su carrera. Esto ayuda
a que el alumno mientras estudia una carrera de Ingeniería de Software, tenga la posibilidad de aplicar todos los
conocimientos que adquiere a lo largo de sus estudios,
más una gran parte, de los que ya hemos mencionado, en
proyectos reales. Muchos de los conceptos, si no es que
la gran mayoría, se pueden obtener mediante iniciativas,
como por ejemplo:
•Acercamiento con empresas de software que aplican
CMM/CMMI, ITIL, PSP, TSP; conceptos de ingeniería de
software y herramientas tecnológicas actuales que requieren de los egresados cierto grado de conocimiento.
•Una gran gama de sitios en Internet en donde se puede
obtener material de alta calidad de los conceptos y tecnologías ya mencionados, y de muchos más, que quizá se me
puedan estar pasando.
•Acercamiento con gobiernos Estatal y Federal, para incentivar dichos centros en la educación pública y privada.
Estructura propuesta
Profundizando un poco en cómo se podrían estructurar dichos centros, considero tres bloques esenciales, como se
muestra en la siguiente figura.
•Software gratis. Algunos de ellos se pueden obtener
bajo algún tipo de licenciamiento, y en ciertos casos,
existen cursos, también gratuitos, que ofrecen las empresas, para capacitarse en el uso de dicha tecnología.
•Programas de certificaciones gratuitos, como los que
ofrece Microsoft con su Academia Latinoamericana de
Management (ITIL), Desarrollador Cinco estrellas 2005,
por mencionar uno.
•Evaluación de software, que muchas empresas ofrecen, como Flex 2 de Adobe (recién liberado) y las versiones constantes de los productos de Sun, IBM, Zend,
ActiveGrid, etcétera.
•Convenios como los que algunas universidades tienen con empresas como Microsoft, Macromedia (ahora
Adobe), Oracle, Sun, en donde el alumno puede tener
acceso a versiones gratuitas de software, o como las
versiones educativas que ponen a disposición un gran
número de empresas, como Zend Technology.
Estructura en 3 Bloques Esenciales.
www.softwareguru.com.mx
ENE-FEB 2007
17
// ESPECIAL
“De la curiosidad nace el interés, y es por
medio de centros de desarrollo de software
que el alumno puede despertar su inquietud
por conocer más, de lo que los planes de
estudio suelen cubrir”.
Zona operativa y de control
La integrarían personas que formen parte de las academias de IT de las mismas universidades, y alumnos; es de
academias de IT forme parte de esta zona, es para lograr
un vínculo entre los salones de clase y los centros de desarrollo de software; mientras que la de los alumnos, es
fortalecer los aspectos administrativos y de control de
proyectos de software en ellos, y no sólo la parte técnica
(el desarrollo del software como tal).
Zona de desarrollo de SW
Estaría conformada 100% por los alumnos que hayan
obtenido un nivel de conocimientos adecuado, que les
permita explotarlo en dichos proyectos. El nivel de conocimiento puede ser delimitado mediante varias formas:
de algún semestre en adelante, número de materias cursadas, conocimientos técnicos, promedios, etcétera.
Zona de soporte y apoyo:
En esta zona se encontrarían profesionistas de IT externos, empresas públicas y privadas, gobierno y demás
personas e instituciones que puedan aportar sus conocimientos para el beneficio de los centros. Las empresas
públicas, privadas y gobierno serían los “patrocinadores” de proyectos específicos, aportando SW licenciado para fines educativos, programas de capacitación,
charlas, orientación y soporte de las metodologías que
usan, por mencionar algunos. La forma puede ser variada, no necesariamente tiene que ser presencial; y los
profesionistas de IT aportarían los conocimientos que
han adquirido a lo largo de su carrera, permitiendo entre otras cosas, alentar a los estudiantes a seguir creciendo en el mundo de las IT’s y de igual forma, dando
soporte a proyectos que les interesen.
Como puntos finales es necesario recalcar, que el nivel
de conocimientos que un alumno pueda llegar a tener,
aprender, manejar y conocer, de los conceptos aquí presentados, dependerá en gran parte, de su propia inquietud, complementada por los consejos y apoyo que reciba
de todas las personas que formen parte de los centros,
así como de los proyectos manejados. De la curiosidad
nace el interés, y es por medio de centros de desarrollo
18
ENE-FEB 2007
de software que el alumno puede despertar su inquietud
por conocer más de lo que los planes de estudio suelen
cubrir. Esto con el fin último, de presentar egresados al
mercado laboral, con la confianza, el respaldo técnico y
conocimientos para enfrentar los retos laborales que el
mundo de IT necesita.
Sin duda se requiere de inversiones económicas, instalaciones, tiempo, esfuerzo y personal, pero no tienen
que ser necesariamente exigentes, es posible hacer
uso de mucho de lo que las instalaciones de las universidades tienen, para dar soporte a centros de esta
clase y los resultados compensarían la inversión.
No es necesario destacar los beneficios que los alumnos principalmente, las empresas públicas y privadas,
instituciones educativas y el gobierno podrían obtener,
porque son obvios. “El objetivo no sólo es beneficiar al
alumno sino también a todas las partes que se vean involucradas en proyectos de este tipo. Las formas de cristalizar los centros son variadas. Se propone una estructura operacional básica de cómo se podrían administrar
los centros, pero el hecho es que necesitan realizarse”,
como bien lo menciona el Dr. Carlos Montes de Oca en
la edición mayo-junio 2006 de la revista Software Guru,
y agregaría algo que sin duda muchos compartirán conmigo: que si México quiere competir internacionalmente
como país, en el desarrollo de software de calidad, es necesario que los alumnos y egresados estén a la par sobre
lo que día con día surge en este mundo cambiante de las
IT’s, siendo la propuesta aquí presentada, un medio por
el cual se puede lograr.
NOTA
El propósito de mencionar el software y las empresas aquí citadas, es con el fin de divulgar el
gran esfuerzo hecho, en términos generales, por
empresas de TI para dar a conocer a la comunidad los productos, tecnologías y metodologías
que ofrecen y promueven bajo diferentes esquemas de licenciamiento.
www.softwareguru.com.mx
// ENTREVISTA
El pasado mes de octubre en la ciudad de Guadalajara, Jalisco,
se realizó el primer Festival Nacional de Animación y Videojuegos, Creanimax 2006, donde se dieron lugar profesionistas y
entusiastas del medio, para compartir conocimientos, secretos, y conocer un poco más de cerca lo que se está haciendo
tanto en México como en otras partes del mundo.
Bill Plympton
Software Guru estuvo presente, y tuvimos la oportunidad de
platicar con tres interesantes personajes, cada uno con su muy
particular estilo y espacio en el universo de la animación 3D
y el desarrollo de videojuegos. Se trata de Bill Plympton, con
más de veinte años de experiencia, creador de cortos animados
como “Guard Dog”; Ernesto Gálvez, CEO y socio fundador de
Immersion Games, y René Castillo, animador en stop motion,
creador de “Poncho Balón” y de la película animada “Hasta los
Huesos”. A continuación lo que compartieron con nosotros.
20
ENE-FEB 2007
“Sobreviviendo como animador independiente” Nos
llamó la atención el título de tu ponencia, ¿qué es lo
que compartes con los asistentes?
Creo que ahora es un momento muy especial, parece ser
que hay mucho interés en la animación. Es la segunda
“época dorada” en animación. Y creo que es posible convertirse en un animador independiente y hacer dinero. Me
gusta compartir con la gente mi propia experiencia, cómo
he sobrevivido haciendo pequeños filmes, comerciales y
largometrajes. Me gusta revelar el secreto de mi éxito con
las personas, decirles cómo hacer las cosas y al mismo
tiempo, mostrar un poco de mi nuevo trabajo.
¿Podrías compartir con nosotros el secreto de tu éxito?
Me parece que es muy importante que el filme sea divertido, creo que a la gente le gusta reírse con la animación,
por lo tanto, debe ser divertido. También creo que debe
ser corto, alrededor de cinco minutos, y deber ser barato,
es decir, no invertir cientos y cientos de dólares. Si puedes
hacerlo, si puedes cumplir con estos tres requisitos, tu filme será exitoso y podrás hacer mucho dinero.
Seguro que hay algunos tips para todos aquellos que
quieren iniciarse en la animación independiente.
Por supuesto. Quizá el más importante es dibujar, hacerlo
siempre, nunca dejarlo; tener un cuaderno donde constantemente se anoten ideas, porque ésas, eventualmente
se convierten en proyectos. Es vital también, ver muchos
filmes, es importante conocer la animación, la historia de
la animación, debes amarla, deber tener pasión por ella ,
yo lo hago, trabajo doce horas al día haciendo mis filmes,
y esa es la clase de pasión que debes tener.
¿Cuál crees que sea el papel de México en el mundo de
la animación?
Justo de eso platicaba en la mañana con una persona, México
tiene una maravillosa tradición de historias y artistas, desde
los aztecas y los mayas, hasta las grandes leyendas; y creo
que el artista de hoy, ama al contador de historias, ama las
artes visuales, y son exactamente los dos ingredientes que
se necesitan para convertirse en un éxito. No creo que se necesite mucho dinero, no creo que se necesite mucha tecnología, sólo contar historias interesantes y entretenidas.
¿Ves futuro en los animadores mexicanos?
Bueno, René Castillo es una gran estrella, es una gran celebridad. Lo conocí hace alrededor de cinco años en un festival, y me gustan mucho sus filmes. Me parece que ahora,
como sabes, los cineastas mexicanos son muy populares,
por tanto, creo que México está explotando, en términos
de producción cinematográfica.
¿Cuál es el panorama de la industria actualmente?
Creo que está creciendo, y eso hace que sea el momento
perfecto para la animación. Hay muchísimos mercados, y
trabajos ahí, esperando por el talento.
BILL PLYMPTON
Nació en Portland, Oregon el 30 de abril de 1946. Sus filmes cortos se han mostrado
alrededor de los Estados Unidos, sobre todo durante festivales de animación. Con un
peculiar sentido del humor y visión burlona del día a día, que se reflejan en sus “Microtoons” y otros populares cortos para MTV, Plympton se ha hecho famoso con “Guard
Dog” que le valió la nominación al Oscar en 2005. Su más reciente producción se titula
“Idiots and Angeles”. Para conocer más de cerca su trabajo: www.plymptoons.com
www.softwareguru.com.mx
René Castillo
¿Cuál fue tu primer encuentro con la animación?
Desde niño hacía muñequitos de plastilina, era algo que no podía dejar
de hacer, tenía dinero y compraba plastilina para crear monitos diferentes,
nunca copiaba, y hacía mis historias. Pero a pesar de ese acercamiento,
no contemplé jamás la animación como una posibilidad. Y fue hasta los
23 años cuando iba en el coche, en el radio escuché un anuncio que decía:
“curso de animación con plastilina”. Me dije: “yo puedo hacer eso”, así es
que llamé, me inscribí y al día siguiente ya estaba ahí.
¿Qué opinas de eventos como Creanimax?
Cuando empecé a hacer animación, hace quince años, había dos
personas a quién preguntarles, y no te decían nada. Por tanto, esto
representa un gran crecimiento, relacionado con la tecnología que
nos acerca las herramientas; tiene que ver también con el software,
que nos permite ahora, hacer cosas de gran calidad y en un tiempo
aceptable. Antes, sólo Disney hacía películas, y usaban novecientas
personas para hacer un largometraje. Hoy en día, con cincuenta personas lo puedes hacer, y eso es gracias a la tecnología. Hay como un
“boom” en todo el mundo, justamente por eso, porque hay un sinfín
de plataformas para hacer animación 3D.
Hacer stop motion es laborioso. ¿Cuánto tiempo tardas?
Normalmente en un segundo de animación me tardo una hora. Si es
complicado y a 24 cuadros por segundo, me tardo hasta cinco horas
por segundo. Es que tienes que mezclar escultura, actuación y todo. Es
un proceso muy artesanal, extremadamente artesanal, de hecho, es la
técnica de animación más cara y lenta de todas. Además hay que tomar
en cuenta todo el tiempo previo, hay que hacer los personajes, las maquetas, iluminar, todo lleva consigo una preproducción bastante larga.
¿Qué tipo de software utilizas?
La verdad es que utilizo softwares diferentes, pero para stop motion, utilizo Adobe Premiere o Final Cut para hacer un animatic, que
es algo parecido a una maqueta que te permite ver cómo será tu
proyecto. La animación hay que planearla siempre y mucho, sea la
técnica que vayas a usar, siempre hay un trabajo de trazo a lápiz, de
story board, y luego un sistema de edición no lineal para armar tu
maqueta. Después, para animar stop motion, utilizo un software que
se llama Frame Thief, que graba cuadro por cuadro, es muy sencillo
porque grabas desde tu cámara, mientras ves cómo corre la animación. Todas son herramientas muy buenas que permiten previsualizar el avance de tu animación. Antes no teníamos nada de esto,
y era completamente a ciegas, animabas y después tardabas otros
dos días editando cuadro por cuadro, era hasta entonces cuando
podías ver cómo se veía. Ahora lo puedes ver al instante. También
hacemos animación en Flash, por ejemplo, Poncho Balón. Usamos
también software de animación 3D, tanto Maya como 3ds Studio
Max y claro, software como Photoshop que es básico y Word para
escribir, que es el primer paso. Digamos que la computadora es una
parte fundamental.
¿Cómo ves la industria de animación en México?
En México hay mucho talento, todavía es una materia pendiente,
pero puede llegar a ser una gran industria, representa ingresos importantes para Estados Unidos y Canadá, así como para muchos países asiáticos. Yo creo que podemos ser muy buenos maquiladores
a un costo relativamente bajo, súper competitivos con imagen, por
ejemplo, pero además, podemos generar propiedades, proyectos.
Aunque quizá, el principal problema aquí en México, son los animadores. No encontramos animadores, porque no hay, todavía no están
listos, la gente está aprendiendo por su cuenta y eso lleva mucho
tiempo. Y es que si te preguntas: ¿qué va primero?, es todo, las escuelas, los proyectos, las empresas, todo va de la mano.
¿Alguna vez te ha cruzado por la mente desarrollar videojuegos?
Totalmente, por supuesto, con Poncho Balón ya estoy en pláticas
con gente de aquí (Creanimax) para hacer un juego. Me parece magnífico que podamos encontrarnos, y veamos en conjunto todas las
posibilidades que tenemos. Porque quizá tú quieras desarrollar un
videojuego basado en un personaje que nadie conoce, y eso te dificulte darlo a conocer, pero si yo tengo un personaje, que a parte
estoy lanzando, y tengo grandes planes para él, de pronto podemos
lanzar un juego, es decir, sumamos esfuerzos.
RENÉ CASTILLO
Es egresado de la carrera de Comunicación por el ITESO en Guadalajara, Jalisco. Su afición desde pequeño por modelar personajes de plastilina lo llevó a encontrar en la animación stop motion el lugar perfecto para darle rienda suelta a su creatividad. Muestra
de su sobresaliente trabajo son los filmes animados “Hasta los Huesos” y “Sin Sostén”.
Además de la animación en Flash, “Poncho Balón”. www.ponchobalon.com
www.softwareguru.com.mx
ENE-FEB 2007
21
// ENTREVISTA
Ernesto Gálvez
¿Cómo surge Immersion Games?
Hace cuatro años decidimos fundar nuestra compañía,
queríamos hacer videojuegos, pero no teníamos presupuesto para hacerlo ni siquiera para pagar el primer mes de nuestros salarios, así que decidimos explorar otras áreas relacionadas también con gráficos
3D, pero orientadas hacia desarrollo de soluciones de
seguridad, de arquitectura, etcétera. Así nos mantuvimos durante mucho tiempo, viviendo de regatearle a los
clientes, eso nos cansó, nos aburrió, pero fue lo que nos
permitió ir creciendo poco a poco, y entonces decidimos
arriesgarlo todo y desarrollar videojuegos.
22
ENE-FEB 2007
¿Cómo captaron la atención de inversionistas? Porque
desarrollar un videojuego requiere capital y proyección para ser exitoso.
Se dio la oportunidad de que unos inversionistas metieran su dinero en nuestra compañía, pero nunca se
atrevieron, porque siempre nos vieron como un grupo
de jóvenes, pensaban que podían perder su dinero fácilmente. Mientras eso sucedía, contactamos con una compañía
norteamericana, porque pensábamos que con aquel dinero, compraríamos tecnología de otros para hacer nuestros
videojuegos, pero eso nunca sucedió. Un día, producto de
nuestra desesperación hablamos con dicha empresa con la
propuesta de hacer mejoras en su tecnología, a cambio de su
código fuente, y el uso de esa tecnología. Llevamos más de
un año y medio cerrando el negocio, pensamos que todo sería de un mes para otro, pero por suerte, al leer las propuestas técnicas de lo que ambos queríamos hacer, aceptaron, y
no sólo eso, sino que disminuyeron el valor de la tecnología
como en un 70%. Después nos pidieron imágenes de lo que
estábamos haciendo, cuando las vieron, nos ofrecieron su
tecnología a cambio de regalías cuando el juego estuviera
terminado. Luego de un par de semanas trabajando echaron
un vistazo a lo que estábamos haciendo, se dieron cuenta
que sí cumplíamos lo prometido, así que nos ofrecieron hacer
un juego en conjunto, y de ahí arrancamos.
¿Cómo dieron a conocer su trabajo en la industria?
En uno de los eventos más importantes de la industria de videojuegos, el GDC (Game Developers Conference), cuando lo
hicimos, causamos un gran impacto, e incluso, compañías de
talla mundial como Epic Games, dueña de uno de los mejo-
res motores gráficos llamado Unreal Engine 3, al ver nuestro
trabajo, decidió que usáramos su tecnología para desarrollar
el videojuego. Después conseguimos un publisher que nos financiara, y ahora estamos por terminar nuestros dos primeros
juegos: Monster Madness y CellFactor, uno lo terminamos en
diciembre, el otro en febrero.
¿Cuál es tu apreciación de Latinoamérica en el mundo
del desarrollo de videojuegos?
Desde el punto de vista, ya no tanto de lo artístico o técnico,
sino desde el punto de vista productivo, y en muchas conferencias he dicho lo mismo, el hecho de que estemos en
países en vías de desarrollo, ha provocado que aprendamos
a utilizar muy bien los poco recursos con los que contamos.
Queremos dar la oportunidad que nunca tuvimos. Sabemos
que en Latinoamérica hay muchos entusiastas, hay mucha
gente que quiere hacer videojuegos, pero desafortunadamente, dependiendo de dónde quieras competir, los niveles
que se necesitan de conocimiento son bastante fuertes, y
queremos que la gente se entere de eso, que hay una gran
oportunidad, pero que no se puede aprovechar si no has
desarrollado el conocimiento suficiente, que por el hecho
de que a ti te gusten los videojuegos o tengas una gran visión alrededor del tema o tengas el empuje o el dinero, no
significa que seas la persona indicada para hacerlo. El truco
está en que armes equipo de gente muy talentosa y que si
tú eres programador, y has programado algo para videojuegos, pero sabes que a tu nivel le falta, y terminas encontrándote con otra persona que hace cosas en un fin de semana
y todas son geniales, pues hazte a un lado, mantente en el
equipo, pero deja que sea él el que lo haga, y lo mismo en
la parte artística.
Tengo entendido que quieren impulsar la industria en
Latinoamérica, platícanos un poco al respecto.
Queremos trabajar muy fuerte para desarrollar la industria en Latinoamérica. Hemos encontrado en NAGA (National Gamers Association) un punto de apoyo para crear
una serie de programas, que por ejemplo, nos permitan
compartir todo el conocimiento que hemos adquirido.
Desarrollar programas de capacitación, pero no sólo eso,
también hacer que la industria mundial comience a dirigir la mirada hacia nosotros; que nos vean como un mercado interesante.
ERNESTO GÁLVEZ
Nacido, radicado en Colombia e ingeniero de profesión, es el CEO y socio fundador de
Immersion Games, junto a otras tres personas. Está encargado de la ingeniería de producción que está relacionada con el uso de las máquinas y los procesos para producir
cualquier clase de producto. En sus propias palabras: “Siempre he sido conciente de
que la universidad lo que hace es darte criterios y volverte una persona racional para
solucionar problemas y al final puedes terminar en cualquier área”.
www.immersionsoftware.com www.cellfactorgame.com www.monster-madness.com
www.softwareguru.com.mx
De
s
o
g
e
u
oj
e
d
o
l
l
sarro
e
d
i
V
el
Por Jo
ana
Villagr
bía
pre hante,
m
e
i
s
os, y
alme
eojueg ar uno. Fin spués de
nde
d
ó
i
v
D
s
r
cre
; de
o lo
,
¿Po
gustad roceso para esarrollarlos er proyecto é
n
a
h
me
el p
enc
rad
prim
iempre de cómo eso de aprenderfecto como ntonces comscasa;
s
o
ñ
i
esde n curiosidad e era tiemp eojuego pe mpiezo?” E s era muy e guaje
tenidoos, decidí qunutos un vidpor dónde euel entonce r: “¿Qué len ¿qué
ui
aq
¿Y
añ
mi
al?,
hace 6 ar por unos a realidad: “rnet, que en ar de disminor en especi n los jueidealiz 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
zar?
Empe
D
24
ENE-FEB 2007
www.softwareguru.com.mx
Muy rápido me di cuenta de 3 cosas: la primera 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 existente 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 virtual, 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 videojuegos como tal, y es una lástima, porque es
una industria de billones de dólares. Ya existen carreras de desarrollo de videojuegos en
universidades internacionales, pero en muchas universidades de nuestro país ni siquiera 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 informació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 tardaría mucho más tiempo. Un juego comercial tarda entre 1.5 y 3 años para ser desarrollado, 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 grafos 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 Festival de Desarrollo de Videojuegos Creanimax
2006, y me di cuenta que por fin se están
haciendo esfuerzos para entrarle a esta industria. Me di cuenta de que hay algunas
compañías interesadas en desarrollar juegos, pero falta apoyo y habilidades técnicas.
También me enteré de un par de universidades en Guadalajara que están incorporando
una carrera de animación y arte digital a su
oferta académica. Hay muchas personas involucradas ya en el modelado y animación
3D –y son buenos–. Entonces no vamos tan
mal, sólo falta ponernos las pilas, organizarnos y darle importancia también a la parte de
la programación.
Así que el objetivo de este artículo, es tratar 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 orientado 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 videojuegos, 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 puede rebasar los cien mil dólares.
Matemáticas. Es deseable tener conocimientos generales de álgebra lineal y
trigonometría, sobre todo para el área de
programación de gráficas. Si no se tienen 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, sobre todo porque existen diferentes áreas
dentro de la programación de videojuegos: 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 necesitan aprender básicamente dos cosas:
•Teoría de gráficas: involucra aprender las
bases de los sistemas de coordenadas 2D
ENE-FEB 2007
25
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?
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 iluminación, mapeado de texturas, entre otras cosas. Es necesario tener estos conocimientos,
ya que se aplican a las APIs para programació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 encargan de procesar las peticiones hechas por
las APIs). Las dos APIs de gráficas más usadas 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, sonido, video, y funciones de redes que se pueden 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 Direct3D, 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 modificaciones. 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 incluye comandos para manejo de ventanas, porque
estos son diferentes en cada caso. Dependiendo 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. Todas 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 –Windows 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 soportan las últimas versiones de OpenGL –, y la
segunda, es actualizar los drivers de nuestra
tarjeta de video para tener la versión más reciente que soporte la tarjeta.
Para utilizar OpenGL, es necesario configurar
nuestro compilador para que pueda encontrar
En el caso de Xbox360, para desarrollar un juego se necesita obtener
un “Kit de Desarrollo”, que consta de
una consola Xbox360 especial para
desarrollo, herramientas, SDKs, y documentación. El desarrollo se hace
en una PC con Visual Studio o CodeWarrior por ejemplo. Dicha PC está
conectada a la consola especial de desarrollo, 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 copió, como si fuera el disco duro interno, para empezar a correr el juego.
Para obtener el kit de desarrollo, se necesita ser un desarrollador registrado con
Microsoft, y los kits son muy caros. Aunque 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 desarrollador, 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 “Programming The Nintendo Game Boy Advance”, que nunca se publicó como libro debido
a cuestiones legales. En éste, se encuentra
información de cómo ejecutar nuestros prowww.softwareguru.com.mx
Tema
Tìtulo
Autor
Matemáticas/Física
Mathematics for 3d Game Programming and Computer Graphics
Eric Lengyel
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: A Top-Down Approach using OpenGL.
Edward Angel
Real-Time Rendering Tomas Akenine-Moller y Eric Haines
Desarrollo de Juegos Game Programming Gems. (Serie de 6 libros hasta el momento).
Mark DeLoura
(Editor)
Core Techniques and Algorithms in Game Programming Daniel Sanchez-Crespo
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
emulador, así como información de cómo
correrlos en una consola GBAreal.
Referencias en línea
Algunos links con mucha información son
los siguientes:
www.opengl.org – El sitio oficial de OpenGL,
tiene documentación y foros de OpenGL para
principiantes y avanzados.
msdn.microsoft.com/library/en-us/directx9_
c/directx_sdk.asp – Información de DirectX.
www.gamedev.net – Un sitio con mucha documentación de desarrollo de juegos en general y
foros para los diferentes aspectos del desarrollo.
www.gamasutra.com – Un sitio donde se pueden encontrar las más recientes noticias de
la industria de los videojuegos, pero también
cuenta con algo de información técnica.
www.flipcode.com – Un sitio que ya no se mantiene por sus creadores, pero tiene una extensa
colección de artículos, todavía en línea, relacionados al desarrollo de videojuegos.
¿Qué libros me pueden servir?
La tabla en la parte superior de esta página
lista algunos libros que considero buenos
y que son útiles, independientemente del
nivel de conocimiento de programación de
videojuegos que se tenga. Como ya lo había
mencionado, hasta el momento, no sé de alwww.softwareguru.com.mx
gun libro que enseñe todo lo relacionado al
desarrollo de videojuegos, así que los categoricé en 6 grupos principales, y por razones
de espacio, sólo menciono unos cuantos de
cada categoría.
¿Qué tarjeta gráfica me puede
servir para empezar?
El mercado de las tarjetas gráficas es dominado por dos compañías, ATI y NVIDIA. Las dos
ofrecen tarjetas gráficas de muy buena calidad
y de una gran variedad de precios, dependiendo de la generación de la tarjeta. Muchas veces, al ver las cajas de las tarjetas pueden surgir más preguntas, ya que la información que
tienen, puede parecer extraña. Por ejemplo, es
importante entender lo que son los Shaders.
Shaders: hasta hace algunos años, se decía
que las tarjetas gráficas tenían una arquitectura fija (Fixed-Function Pipeline) ya que
la información enviada desde la aplicación,
siempre pasaba por las mismas operaciones
dentro de la tarjeta gráfica. Esto ha cambiado, y actualmente las tarjetas gráficas tienen
una arquitectura programable.
Una arquitectura programable significa que
desde la aplicación, se le puede indicar a la
tarjeta gráfica que ejecute ciertos programas
pequeños (llamados Shaders) ella misma, liberando al CPU completamente de ejecutar
esas funciones. Es por esto que las tarjetas
gráficas actuales, cuentan con su propia
memoria y procesador, conocido como GPU
(Graphics Processing Unit). Muchos de los
efectos visuales avanzados que vemos en
los juegos de hoy en día, son implementados por medio de Shaders.
Hace algunos años, los Shaders eran escritos en lenguaje ensamblador, por tal razón
no eran tan populares. Actualmente la mayorí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 OpenGL); HLSL (específico de DirectX) y Cg (puede correr ya sea en OpenGL o DirectX).
Las tarjetas gráficas con arquitectura programable tienen dos núcleos o procesadores
programables, uno se ejecuta a nivel de objetos y otro se ejecuta a nivel de pixeles. Los
Shaders que se pueden ejecutar en ellos, se
conocen como Vertex Shaders y Pixel Shaders respectivamente (los últimos también
se conocen como Fragment Shaders).
Las tarjetas gráficas con arquitectura programable, también tienen soporte para la arquitectura fija, y es decisión de la aplicación,
utilizar una u otra arquitectura o incluso utilizar las dos. Es por eso que muchas veces,
aunque tengamos un procesador avanzado,
si no tenemos una tarjeta gráfica con arquitectura programable como lo requieren algunos juegos, no podremos ejecutarlos.
Tips generales
•Es más fácil empezar por 2D, y algunas cosas de 2D se aplican a 3D también.
•Es más sencillo aprender OpenGL que DirectX (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 desarrollarlo 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 especí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
second) ejecuta. Qué tan rápido corre un
juego, depende de muchos factores, principalmente aspectos de hardware como procesador, memoria, tarjeta gráfica; aunque también, influyen aspectos de nuestra lógica de
programación. Por lo general, en el desarrollo
de un juego se intenta tener por lo menos
60fps, para que el movimiento de los objetos
sea contínuo.
•Una parte de liberación de recursos – Ejecutada al finalizar el juego, aquí se libera la
memoria obtenida de manera dinámica en
todos los subsistemas del juego.
Conceptos básicos
n
u
e
d
o
l
l
o
D
2
o
g
ue
r
r
a
s
De
J
Definamos algunos conceptos básicos que
nos ayudarán a entender el código de nuestro juego 2D:
na
gra
el Villa
Por Jo
pto
Conce
ración
nfigu
s y Co
D
esarrollar un juego de video en 2D con OpenGL no es tan complicado como podrías pensar. A través de una serie de artículos, mostraré
cómo se desarrolla un juego sencillo, que sirva para dar una idea clara de
las funciones y estructura básica de un juego. Por razones de espacio en la
revista, en esta primera parte sólo introduciré algunos conceptos básicos
y de configuración; y en próximas entregas continuaré con los diferentes
aspectos a resolver, en el desarrollo de un juego 2D.
Estructura básica de un juego
•Una parte de inicialización - Aquí se crea
nuestra ventana principal, se cargan todos
los archivos que necesita el juego (modelos
3D, imágenes, sonidos) y se crean e inicializan los diferentes subsistemas del juego
(gráficas, input del usuario, inteligencia artificial, etcétera).
•Actualización - Por ejemplo la posición
de un enemigo, verificar si el usuario ha
presionado algun botón, actualizar la posición de un cohete se disparó, verificar si
un vehículo ha colisionado contra algún
objeto del mundo.
•Render – Es la parte más importante, es decir,
el mandar todas las gráficas a la pantalla.
•Un ciclo principal - Este ciclo principal ejecuta la lógica del juego una y otra vez, hasta
que el usuario sale del juego. La lógica básica dentro de este ciclo es:
Este ciclo se ejecuta muchas veces por segundo, y cada ejecución se conoce como Frame. Una medida del rendimiento de nuestro
juego, es indicar cuantos FPS (frames-per-
28
ENE-FEB 2007
Framebuffer. OpenGL cuenta con una colección de búfers donde se almacena información que se presentará en la pantalla. El
búfer principal, es el búfer de color, que es
un arreglo bidimensional que almacena el
color final de los pixeles. También existe el
búfer de profundidad (Z-buffer), que almacena la información de profundidad (respecto
a la cámara virtual) de cada pixel generado
cuando se hacer un render de un objeto,
esto sirve para determinar si cada pixel del
objeto es visible al hacer la comparación de
los pixeles generados contra la información
que ya se tiene en el Z-Buffer.
En las aplicaciones gráficas se tienen cuando ménos dos framebuffers, uno para mostrar en la pantalla y otro para hacer un render en él, mientras el otro, se muestra en la
pantalla. Al terminar de hacer un render en
un búfer, se hace un intercambio, el búfer
en el que se hizo el render es mostrado en
la pantalla, mientras se hace render en el
otro. Es necesario usar dos búfers, ya que
de lo contrario, tendríamos un efecto visual
desagradable al hacer render sobre el búfer
en pantalla.
Render. Es el proceso de tomar una representación matemática tridimensional de un
objeto y presentarlo como una imagen bidimensional en la pantalla. Para este proceso
se toma toda la información relacionada al
objeto como color, posición y textura.
Proyecciones. Las 3 etapas conceptuales
de la arquitectura gráfica son: Aplicación,
Geometría, y Rasterización. En la etapa de
Geometría, se toman los objetos y sus datos asociados y se “proyectan” en la pantalla. Hay dos formas principales de hacerlo:
para 2D se usa la proyección ortogonal, en
www.softwareguru.com.mx
ésta, la apariencia de los objetos es la misma, independientemente de la distancia
desde donde se vean. Para 3D se utiliza la
proyección en perspectiva; donde la apariencia de los objetos cambia, dependiendo
de la distancia con respecto a la cámara virtual, que es como percibimos los objetos
en la vida real.
Transformaciones. En un juego, el movimiento de los objetos se realiza por medio
de transformaciones. Trasladar un proyectil
de una posición a otra, rotar la cámara virtual, hacer más grande un objeto, son ejemplos de transformaciones.
Matrices. Para almacenar información acerca del tipo de proyección usada en un juego, e información de las transformaciones
y parámetros actuales de la cámara virtual,
OpenGL utiliza la Projection Matrix y la ModelView Matrix respectivamente.
la información actual de las propiedades
de los objetos hasta que se le indican nuevas propiedades.
GL Utility Toolkit (GLUT)
GLUT es una librería que simplifica la creación
y manejo de ventanas con soporte para OpenGL. En GLUT podemos definir nuestras callback functions, que son las funciones llamadas automáticamente cuando ocurren ciertos
eventos como cuando se cambia de tamaño
la ventana, cuando se hace clic con el mouse
o cuando se recibe input del teclado.
GLUT se puede descargar en www.xmission.
com/~nate/glut.html, y si quieres configurar Visual Studio para usar GLUT, puedes
encontrar una guía para esto en csf11.acs.
uwosh.edu/cs371/visualstudio/
El siguiente código es un ejemplo de un esqueleto que inicializa OpenGL y GLUT.
Viewport. Podemos definir un área dentro
de una ventana, a la cual va a afectar nuestro render. Generalmente, el viewport tiene
el mismo tamaño de la ventana, pero si quisiéramos hacer una aplicación que muestre
nuestros objetos desde varias perspectivas
(como lo hace 3dsmax por ejemplo) tendríamos que definir diferentes viewports dentro
de nuestra ventana.
#include <stdio.h>
#include <stdlib.h>
#include <GL/glut.h> // funciones de GLUT y OpenGL
Geometría. Todos los objetos que vemos en
un juego 3D están compuestos por pequeños triángulos, que al ser representados en
conjunto, determinan la forma del objeto.
Las formas básicas que se mandan a la tarjeta gráfica son cuadrados, triángulos, líneas,
y puntos. Cada una de estas primitivas tiene
información asociada como vértices, normales, y coordenadas de textura.
void InitializeOpenGL()
{
// Color que se utilizará cuando se limpie la pantalla (RGBA)
glClearColor( 0.0f, 0.4f, 0.9f, 1.0f );
Texturas. Son básicamente, imágenes que
van a ser “pegadas” a nuestra geometría
para darle la apariencia final. Una restricción importante para las texturas de un juego, es que su tamaño debe ser potencia de
2, por ejemplo 128x128, 256x256, 512x512
pixeles. Para determinar qué parte de la
textura se pegará en cada triángulo de la
geometría, se utilizan las coordenadas de
textura. Al hacer el render, se deben pasar
las coordenadas de textura por cada vértice de la geometría. OpenGL funciona como
una máquina de estados, es decir, guarda
}
/* Declaracion de callback functions, etc */
void SG_DisplayFunction();
void SG_KeyboardFunction( unsigned char key, int x, int y );
void SG_SizeFunction( int width, int height );
void SG_MouseFunction( int button, int state, int x, int y );
void InitializeProjection( int width, int height );
void InitializeOpenGL();
/* ... */
// Parámetros para el uso del Z-buffer
glClearDepth( 1.0f );
glEnable( GL_DEPTH_TEST );
glDepthFunc( GL_LEQUAL );
glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );
//...
glFlush(); // Termina los comandos de render pendientes
glutSwapBuffers(); // Intercambia el front y back buffer
}
void SG_SizeFunction( int width, int height )
{
InitializeProjection( width, height );
}
void SG_KeyboardFunction( unsigned char key, int x, int y ){ /*...*/ }
void SG_MouseFunction( int button, int state, int x, int y ){ /*...*/ }
int main( int argc, char** argv )
{
/* Código de inicialización de GLUT */
glutInitDisplayMode( GLUT_DOUBLE | GLUT_DEPTH |
GLUT_RGBA );
glutInitWindowPosition( 0, 0 );
glutInitWindowSize( 800, 600 );
glutInit( &argc, argv );
/* Creación de la ventana */
glutCreateWindow(“Juego 2D – SG 2007”);
/* Callback Functions */
// Función llamada cada vez que el usuario cambia
// de tamaño la ventana
glutReshapeFunc( SG_SizeFunction );
// Función llamada cuando la ventana necesita ser redibujada
glutDisplayFunc( SG_DisplayFunction );
// Función llamada cada que nuestra aplicación esta “libre”
glutIdleFunc( SG_DisplayFunction );
// Función llamada cada que se recibe input del teclado
glutKeyboardFunc( SG_KeyboardFunction );
// Función llamada cada que se recibe input del mouse
glutMouseFunc( SG_MouseFunction );
// Inicialización de OpenGL
InitializeOpenGL();
// El loop principal de la aplicación
glutMainLoop();
return 0;
}
Como se puede observar, el uso de GLUT
permite simplificar a unas cuantas líneas,
un código de inicialización que podría tomar el doble de líneas o más, usando la API
de Windows.
glShadeModel( GL_SMOOTH ); // Tipo de shading
InitializeProjection( 800, 600 ); // Proyección
//...
void InitializeProjection( int width, int height )
{
glViewport( 0, 0, width, height ); // Viewport
glMatrixMode( GL_PROJECTION ); // Proyección
glLoadIdentity();
glOrtho( 0, width, 0, height, -10, 10 ); // 2D
/* Cambiar para poder procesar las transformaciones de la
camara virtual */
glMatrixMode( GL_MODELVIEW );
glLoadIdentity();
}
void SG_DisplayFunction()
{
// Limpia el bufer de color y el Z-buffer
Conclusión
En esta primera parte, revisamos los
conceptos básicos para arrancar con el
desarrollo de nuestro juego. En entregas posteriores veremos cómo crear el
mundo gráfico de nuestro juego, mover los objetos, detectar colisiones,
reproducir sonidos, y muchos otros
aspectos involucrados en el desarrollo
de un juego. ¡Hasta entonces!
Joel Villagrana, egresado de la Universidad de Guadalajara como Ingeniero en Computación, ha estado en contacto con la programación de videojuegos desde hace 4 años cuando estudió una maestría en Ambientes Virtuales en Inglaterra. Actualmente trabaja para IBM, pero en su tiempo libre sigue aprendiendo
las nuevas técnicas de gráficas 3D. Participó en el libro “More OpenGL Game Programming”, publicado en 2005. Recientemente participó en Creanimax 2006.
La información de estos artículos representa su punto de vista y no necesariamente el de IBM Corporation. joel.villagrana@gmail.com
www.softwareguru.com.mx
ENE-FEB 2007
29
XNA
a
cantaba
odos
n
T
e
e
e
d
em
er
lcance
ien qufenomenal vdesA
b
l
y
a
u
s
era
ego
ar a
do m
recuer s. Para mí, asmas, o jug
de Ju
,
o
a
l
i
l
r
o
a
r
a
it
nd
nt
Desar
la secun las maquindo por los fapequeños.
n
e
a
b
a
más
esta
o co
canz
uandohoras jugandara no ser al en pedazos
pasar corriendo p e explotaban
qu
an
Pac-M s asteroides
truir lo
e
Por Jaim
ez
Sánch
C
Con historias así, es que surge la industria de
los videojuegos, y precisamente este tipo de
juegos simples, pero contagiosos, se conocen
actualmente como juegos ocasionales o casual
gaming. Lo interesante de dicha tendencia en
videojuegos, no es tanto la capacidad de poderlos jugar una y otra vez, sino que además,
puedes disfrutarlos en diferentes dispositivos y
competir contra diferentes adversarios en línea.
En este sentido, el Xbox 360 abrió un mercado
muy interesante a través de su Xbox Live, con el
que los usuarios pueden descargar de Internet
contenidos y juegos. Sin embargo, esto presentó dos problemas principales; el primero es que,
para desarrollar juegos para diferentes plataformas (por ejemplo, Xbox y PC), se necesitaban
bases de código diferentes e independientes.
El segundo problema, es que la capacidad de
desarrollar juegos para consolas sólo estaba
disponible para las grandes casas desarrolladoras de juegos, utilizando kits de desarrollo caros
y con disponibilidad limitada. Esto eliminaba la
posibilidad de que un desarrolaldor casual pudiera hacer un juego para Xbox, por ejemplo.
Para resolver tales problemas, se creó XNA.
XNA es un framework basado en .NET, que
facilita el desarrollo de videojuegos y permite usar una misma base de código para tanto
plataforma Xbox como Windows.
30
ENE-FEB 2007
Figura 1. Aquí se ilustran las capas que componen el XNA Framework.
Para desarrollar juegos basados en el framework XNA, se utiliza XNA Game Studio,
que es un ambiente de desarrollo basado en
Visual Studio C#. XNA Game Studio estará
disponible en dos versiones:
•XNA Game Studio Express. Versión gratuita
basada en Visual Studio Express C# dirigida
a los desarrolladores casuales o por hobby.
Actualmente está disponible como beta, y en
cualquier momento se liberará la versión final.
•XNA Game Studio Professional. Dirigido a
profesionales que crean juegos para comercializar. Se espera que sea lanzado en el segundo semestre de 2007.
Cuando estás desarrollando un videojuego,
lo más complejo se encuentra en generar el
código, que se va a encargar de operar las
controladoras de videos, las interfaces de
entrada o controles, los eventos a los que
www.softwareguru.com.mx
debe de responder, etcétera. Toda esta lógica, la administra XNA, de tal manera que,
es mucho más fácil comenzar a desarrollar
tu videojuego usando las interfaces que te
provee, además, cuando lo instalas, vienen
pre cargadas una serie de plantillas que te
permiten comenzar a crear tu juego en menos de 5 minutos.
Lo importante, es que sepas que, generar un
videojuego, no es cosa sencilla, ya que tienes que diseñar la historia del juego, todo
el arte, las animaciones, objetos en 3D, el
audio, y ya una vez que tienes todos estos
componentes, comienza lo divertido: integrarlos. Pero no te desanimes, ya verás que
con un poco de práctica, pronto estarás desarrollando juegos divertidos, que podrás
compartir con tus amigos o incluso, jugarlos
en línea.
Capas de XNA
Ahora, ya que entendimos qué onda con XNA,
vamos a verlo un poco más a detalle. El framework está organizado en 4 capas orientadas a
diferentes propósitos:
•La capa base del framework XNA es la capa
denominada de “Plataforma”, que es donde se
maneja toda la lógica de bajo nivel, por ejemplo
lo que es Direct 3D, XACT, etcétera. Digamos
que es como el cerebro de XNA.
•Encima de la capa de plataforma se encuentra la del framework básico, o central. Aquí es
donde se procesa la información general del
videojuego, es decir, el audio, los procesamientos matemáticos, almacenamiento, etcétera.
•Para facilitar el desarrollo de los juegos, se
diseñó un conjunto de interfaces que forman la
capa denominada, framework extendido.
•La última capa es la de juego, que es donde
se lleva toda la lógica como tal. Lo interesante
es que tú puedes generar componentes que
permitan que los demás puedan acceder a
tu juego y configurar cómo se desarrolla.
Por ejemplo, podrías hacer una interfaz
para que pudieran descargar nuevas naves
espaciales, o en un ambiente un poco más
comercial, podrías vender espacio publicitario en tu videojuego. Imagina que pudieras
rentarle a una compañía de refrescos, un espacio para que publiciten sus productos, y
al término del periodo, venderle ese mismo
espacio a una compañía de automóviles, y lo
único que cambiaría en tu juego, es la manera en la que se consume dicho componente.
Sería genial, ¿no?
Figura 2. Interfaz de desarrollo de Game Studio
Express de XNA.
Figura 3. Plantilla de desarrollo Space War.
Conclusión
Para dar inicio
Figura 4. Juego en ejecución.
Ya que conoces cómo está diseñada a gran
escala la arquitectura de XNA, muy seguramente tu siguiente pregunta sería: ¿Cómo lo
empiezo a utilizar?
Game Studio Express de XNA, desde el sitio
msdn.microsoft.com/directx/xna/gse.
Lo primero que tienes que hacer es descargar Visual Studio Express C#. Lo puedes
encontrar en el sitio msdn.microsoft.com/
vstudio/express/visualcsharp. Una vez que
instales C# Express necesitas descargar el
Una vez que instalaste los programas, estarás
listo para comenzar a desarrollar tu juego. Te
recomiendo que para comenzar te bases en
alguna de las plantillas de videojuegos que ya
vienen instaladas, esto te va a permitir entender cómo está estructurado el videojuego.
Desarrollar un videojuego involucra
tomar en cuenta muchos aspectos.
Afortunadamente, XNA elimina algo de
esa complejidad y es una excelente opción para desarrollar juegos tanto para
Xbox como Windows. Lo mejor de todo
es que XNA Game Studio Express es
gratis, así que si eres un desarrollador
de software y conoces algo de C#, anda
ya, y desarrolla tus primeros juegos.
Jaime Sánchez Beltrán, con más de 10 años de experiencia en la industria de Tecnologías de Información, actualmente se desempeña como evangelista
para empresas de software en Microsoft, entre sus labores se encuentra la divulgación tecnológica, y generación de programas que impulsen el ecosistema
de TI. Ha participado como conferencista nacional e internacional, empujando la innovación en TI. Anteriormente trabajó para Microsoft en Texas, soportando
las cuentas Premiere de América Latina.
www.softwareguru.com.mx
ENE-FEB 2007
31
a
i
c
n
e
g
i
l
e
t
In
l
a
i
c
fi
i
t
r
A
lo
ión a do
c
a
c
i
l
a
Ap
s Delg
Por Dr.
o
e Vide
os d
s Jueg
Carlo
L
a Inteligencia Artificial (IA) en los juegos de video, ha cobrado auge en los últimos años. Dado que las imágenes desplegadas por las consolas de la siguiente generación (Wii, PlayStation 3 y Xbox 360) cada vez se acercan más a la realidad, ahora, el reto radica en hacer que estas imágenes cobren “vida” y realicen comportamiento
que el jugador perciba como inteligente. Esto es, que el comportamiento sea tan creíble como las imágenes desplegadas. Para cumplir este gran reto, los videojuegos están utilizando cada vez, con mayor frecuencia, técnicas
de Inteligencia Artificial avanzadas, como lo son Redes Neuronales, Algoritmos Genéticos, y Planeación, y ya
no sólo técnicas que se han usado tradicionalmente, como las Máquinas de Estado Finito (FSM) para simular el
comportamiento de los personajes, y el Algoritmo A* para encontrar rutas. El presente artículo se divide en dos
partes: la primera es un vistazo a lo que es la IA más interesante en los juegos de video actuales, y la segunda, es
un ejemplo de IA reactiva para un juego que estamos desarrollando en Nibbo Studios.
Juegos cuya IA vale la pena notar
Estos son algunos de los juegos que consideo
vale la pena destacar por su uso de IA:
1. Creatures, un juego de vida artificial creado por Steve Grand para Cyberlife en el Reino
Unido. En este juego, cada una de las criaturas (Norns) tiene diferentes genes. Los Norns
se aparean entre sí para dar vida a nuevas
criaturas, que van evolucionando su DNA y
adquiriendo algunos rasgos de generaciones
anteriores. El cerebro de las criaturas es simulado por una red neuronal sencilla. Steve
Grand incluso, se ha auto proclamado un dios
digital, ya que según él, ha creado “vida” dentro de una computadora.
2. Black and White de Peter Molyneaux de
Lionhead Studios, donde se puede entrenar
a las bestias que dependen del dios (el juga-
32
ENE-FEB 2007
dor). Esto se realiza por medio de la técnica
de IA conocida como aprendizaje reforzado,
donde se premia a la criatura si realiza la acción que le pedimos (por medio de un caricia
en el lomo) o se castiga si no hace lo que se
pide (a través de un latigazo).
con estos objetivos. Esto acarrea el beneficio de que las acciones y los objetivos están
“desacopladas”, por lo que es más sencillo
expandir el sistema de IA de manera eficaz.
3. F.E.A.R. (First Encounter Assault Recon),
IA por Jeff Orkin de Monolith Productions.
Cuenta con la Inteligencia Artificial más interesante, ya que se utilizan técnicas como
el uso de un planeador para complementar
a otras que se han utilizado con mayor frecuencia en la IA de los juegos de video, como
son las maquina de estado finito (FSM) y el
algoritmo A*. Lo interesante de utilizar el
planeador, es que solamente es necesario
especificar cuál es el conjunto de objetivos
que persigue el personaje y cuáles son las
acciones que puede realizar para cumplir
Ahora daré un ejemplo de la IA del videojuego mexicano Überpong, desarrollado por Nibbo Studios (www.nibbo.net) en la ciudad de
Aguascalientes. Überpong actualmente se
encuentra en pruebas beta, y pronto saldrá al
mercado. Este videojuego ha ganado dos premios a nivel nacional, incluyendo el mejor videojuego en PC desarrollado por una empresa
mexicana en el concurso del capítulo mexicano
de la IGDA (International Game Developers Association) en noviembre del 2006. Überpong
es un videojuego que combina los géneros
de deportes y de acción para traer el clásico
Ejemplo: Überpong
desarrollado por Nibbo Studios
www.softwareguru.com.mx
Figura 1. Contestación del enemigo (paddle derecho)
en el nivel de la tierra.
Figura 2. Enemigo (paddle derecho) recibiendo la
pelota en el nivel del hielo.
juego de Pong al siglo XXI. Para lograrlo, se
dotó de algoritmos de física computacional,
detección de colisiones y de Inteligencia Artificial que a continuación se describe:
La Inteligencia Artificial de los enemigos de
Überpong se divide en 4 dimensiones, una
para definir cómo el control (paddle) del
enemigo se aproxima a la pelota, y las otras
3, para definir la personalidad del enemigo.
El sistema de IA está influenciado en los
estudios doctorales de un servidor. En este
tipo de IA, por medio de reglas sencillas se
simula comportamiento que parece ser más
complejo. Sistemas similares de IA se han
utilizado para simular animales artificiales,
y también para guiar robots en ambientes
complejos y cambiantes.
Para definir cómo se aproxima el paddle del
enemigo a la pelota, se definieron un conjunto de parámetros que se especifican en
el archivo XML de la IA. Entre éstos se encuentran:
1. Qué método utilizará para aproximarse a
la pelota (siguiéndola o prediciendo a cada
instante dónde llegará la pelota).
2. Parámetros para definir un sistema primitivo de visión.
3. Velocidad máxima del paddle.
4. Aceleración máxima del paddle.
5. Porcentaje de decaimiento de la velocidad
del paddle.
Para definir la personalidad del enemigo, se
crearon los perfiles de personalidad, estos
están dados en 3 dimensiones:
•La primera dimensión define si el enemigo
será agresivo, precavido, o miedoso; esto
es, si tratará de acelerar la pelota, no hará
nada o si tratará de desacelerar la pelota.
•La segunda dimensión define si el enemigo
es arriesgado o no; esto es, si tratará de aplicar efecto o no a la pelota.
•La tercera dimensión define si el enemigo es
impulsivo o calculador; esto es, qué estrategia
utilizará para aplicarle los ítems al jugador: si es
impulsivo, los aplicará en cuanto los tenga disponibles y si es calculador, los aplicará cuando
ocasione más daño al jugador, por ejemplo, vol-
tear la pantalla cuando la pelota esté cerca del
jugador, le dará menos tiempo de reaccionar.
El juego se puede ver en acción en las figuras
1 y 2 (que se muestran en la esquina superior
izquierda).
Conclusión
La Inteligencia Artificial es sin duda,
un campo con mucho potencial, que
tiene grandes áreas de oportunidad
en los juegos de video. Espero que
con este breve artículo les haya
dado una idea del tipo de consideraciones que se deben tener en IA
para videojuegos, y también espero, haber despertado su curiosidad
para que conozcan más sobre esta
fascinante área.
El Dr. Carlos Delgado Mata es socio fundador de Nibbo Studios, y ha estado encargado de la Inteligencia Artificial y Física Computacional del más
reciente proyecto. Además, es profesor investigador en el campus académico de la Universidad Panamericana, Universidad Bonaterra. Es autor de mas de
30 artículos en el área de Agentes y Entornos Virtuales Inteligentes. Es fundador y co-chair de la conferencia internacional especializada en el área IVEVA
(Intelligent Virtual Environments and Virtual Agents).
www.softwareguru.com.mx
ENE-FEB 2007
33
La
a
i
r
t
s
u
d
In
uillén
scar G
g. O
Por In
s
cia
instan ías
e Todo
a
d
r
e
e
m
c
i
pr
an
pañ
al Alc
gos, enn en las comambién
s
e
o
u
j
g
o
e
e
Ju
vid
nsa
s. T
llo de
ria de riente y, pie ros crecimo o Francia.
t
o
s
r
u
r
d
a
n
s
De
no o
terra
e la i
nosot
abla d iajan al leja muchos de nidos, Ingla el nuestro.
h
e
s
uandoas mentes v on los que Estados U íamos sería
nuestr los juegos cpaíses comos que pensar
sy
en
paí
niponamos pensar n el último
podríaiertamente, e
Pero c
C
Aunque desde hace cerca de diez años han existido intentos de desarrollo de juegos de video
en México, aún muy poca gente conoce la existencia de aquellas compañías que luchan por
un sueño común: desarrollar juegos, con propiedad intelectual propia, “Hechos en México”.
Desgraciadamente, los primeros proyectos no
cautivaron al público de la manera que sus creadores hubieran querido. Sin embargo, a medida
que pasan los años, cada vez más gente creativa se dispone a embarcarse en tan aventurada
tarea, y en conocer los errores del pasado, que
han servido de lección para muchas compañías
que están comenzando.
Antecedentes y
lecciones aprendidas
Los factores que ocasionaron que los proyectos
pioneros fracasaran, son varios, y se necesitaría
hablar, en particular de cada una de las empresas involucradas, para buscar-encontrar qué fue
lo que hizo falta. Sin embargo, a manera general
podemos englobar los más importantes y de los
cuales, se trata un poco a continuación.
Originalidad. Al no tener una clara visión del
mercado se suele pasar por alto varios factores
externos que pueden hacer que un producto no
se venda como se tiene planeado. Si a cualquier
desarrollador de juegos se le pregunta qué
piensa de su creación, lo más seguro es que la
34
ENE-FEB 2007
defienda a capa y espada. Por lo mismo, muchas veces estas personas suelen no estudiar
el mercado para conocer a su competencia y
el tema que se elige para el juego a desarrollar
se escoge simplemente basándose en el gusto
personal de quienes lo van a crear. Debido a
esto, podemos ver que algunos de los primeros
juegos mexicanos fueron muy similares a juegos reconocidos mundialmente. Esto provocó
que el consumidor, al tener que elegir entre dos
juegos similares, uno desarrollado por un estudio reconocido, y otro por un grupo de personas
que apenas comienzan y del cual no se sabe
mucho, obviamente se inclinará por el primero.
Piratería. La piratería es otro factor que incidió y sigue causando molestias a los desarrolladores en nuestro país. Se estima que
más del 80% de los videojuegos que se venden en México son adquiridos en el mercado
informal. Este vicio, que las autoridades han
dejado pasar, origina que las personas consideren normal comprar un juego por veinte
pesos o menos, en el mercado de la esquina,
sin ponerse a pensar en todo el esfuerzo que
hay detrás, y por el cual el producto comprado
en una tienda legítima, tiene un precio mucho
más elevado. Es risible entonces, ver que haya
gente que luego de conseguir de manera ilegal
videojuegos desarrollados en México, se pregunte por qué la compañía que lo desarrolló ya
no continuó sacando más proyectos.
conoce
e
t
n
e
g
oca
ellas
“Muy pencia de aquchan por
la exist ñías que lu
compaño común: , con
un sueollar juegos ual
desarrdad intelectMéxico”.
propie, hechos en
propia
Malinchismo. El malinchismo mexicano es otro
factor importante que no podemos dejar fuera
de la ecuación. Pongamos por ejemplo el juego
Mythic Blades desarrollado por la compañía Vermillion Games de Querétaro. Cuando Vermillion
mostró las primeras versiones de su producto
en los foros especializados mexicanos, lo único
que recibió fue críticas. Miguel Pineda, socio
fundador de Vermillion Games, una vez comentó que los comentarios más viscerales hacia el
juego fueron por parte de los propios paisanos.
Esto casi los llevó a abandonar el proyecto. Sin
embargo, al mostrar su juego en páginas de Internet y foros extranjeros, la aceptación fue tal
que terminaron el juego y éste fue comercializado en varios países por una distribuidora norteamericana, recibiendo grandes alabanzas por el
arte gráfico del mismo.
Esfuerzos recientes de promoción
Eventos como Creanimax 2006, que se realizó el pasado mes de octubre en Guadalajara,
Jalisco; donde se dieron cita varias de las más
importantes personalidades en materia de
Animación y Videojuegos no sólo nacional sino
internacional, y los concursos organizados por
el capítulo en México de la IGDA (International
Game Developers Association) junto con Oelli,
la empresa organizadora del Electronic Game
Show, y la Secretaría de Economía, son puntos
importantes de exposición de la creatividad de
www.softwareguru.com.mx
los jóvenes mexicanos. En los concursos de ambos eventos se premiaron proyectos realizados
por estudiantes, profesionistas y empresas,
basándose en diferentes factores como el gameplay del juego, el arte y música, pero sobre
todo, la originalidad de los mismos.
Cabe mencionar que entre los premios otorgados en el concurso de la IGDA, se dio a los mejores proyectos la oportunidad de viajar a San
Francisco el próximo año, para asistir al Game
Developers Conference, donde podrán exhibir
sus proyectos en un pabellón que pretende
acercar a los desarrolladores nacionales con los
del resto del mundo. Esperemos que estos apoyos continúen y que las empresas nacionales
sepan sacar el máximo provecho de los mismos,
y que la industria de videojuegos en nuestro
país dé el gran paso y dé a conocer al mundo la
creatividad con la que contamos.
Algunas empresas mexicanas
A continuación, una breve reseña de algunas
empresas representativas de esta naciente industria de videojuegos en México.
Artefacto Estudio. Es una compañía que trabaja
en una amplia gama de proyectos que van desde aplicaciones web, hasta creación de imagen
corporativa y desarrollo de videojuegos. Su
proyecto “Xtreme Drive” los hizo merecedores
del tercer lugar en el concurso más reciente de
desarrollo de videojuegos de la IGDA.
AztecTech Games. Parte del Instituto Aztec Tech,
el cual es considerado como la primera escuela
de desarrollo de videojuegos en Latinoamérica.
Sacó al mercado dos de los primeros juegos
para PC de creación mexicana: “World Masters”y
“Hellcopters”, en los que se trabajó cerca de seis
años y que, desgraciadamente no lograron capturar la atención del público mexicano.
Digital Moon Studios. Compañía originaria del
estado de México que se dedica a la realización
de proyectos a manera de outsourcing. Poco se
conoce acerca de los juegos en los que han participado, debido a los contratos de confidencialidad que se requieren para conseguir este tipo
de proyectos.
Dimtv. Empresa dedicada a la creación de juegos publicitarios. Han logrado concretar negocios con empresas nacionales e internacionales
a las cuales les han desarrollado juegos basados en su marca o producto.
Idle Hands Games. Enfocados en la creación
de juegos para dispositivos móviles, esta empresa del D.F. cuenta ya con siete juegos en su
haber; que se basan en ideas simples, pero
entretenidas y se venden por medio de descargas directas al celular. Entre sus juegos más
populares se encuentra “Ruta 666”, en el que
el usuario toma el papel de un chofer de autobús, que intenta realizar su trabajo en el caos
vial de la ciudad de México.
Nibbo Studios. Empresa de Aguascalientes
que ha desarrollado diferentes proyectos
como los kioscos con pantalla táctil, presentados en la Feria de San Marcos 2006 en el
stand del Gobierno Estatal; un juego didáctico para la enseñanza del teclado de la computadora de nombre “Mecapumble” y el juego
en 2D que aún se encuentra en desarrollo,
llamado “Überpong”. Este último logró conseguir el segundo lugar en el concurso de desarrollo de juegos durante Creanimax 2006 y
el primer lugar en la categoría profesional en
el concurso organizado por la IGDA.
Nusof Studios. Ganadores del segundo lugar de
la categoría profesional del concurso de la IGDA.
Su proyecto más sobresaliente “Biops 2” es un
juego tridimensional de armas en primera persona (first person shooter), con buenos gráficos
y un nivel adecuado de emoción y dificultad.
Radical Studios. Sacaron al mercado un juego
“multi-jugador masivo en línea” (MMOG por
sus siglas en inglés), en el cual se permitía jugar
en tiempo real contra enemigos programados y
personas que estuvieran en línea en el mismo
momento que se estuviera jugando. La idea de
esta compañía era seguir mejorando el juego de
manera continua, cobrando mensualidades a
los suscriptores para permitirles tener acceso al
juego. Desgraciadamente, la empresa no pudo
soportar los costos de operación y cerró operaciones al poco tiempo de haber comenzado.
Ranflosoft. Sorprendió a muchos con su juego
de peleas basado en personajes políticos y del
folclor mexicano. Aún y cuando la calidad gráfica y el gameplay del juego dejaban mucho que
desear, “Kombate Mexicano” siempre lograba
sacar una sonrisa en las personas que lo probaron por primera vez.
Snake & Eagle Studios. Esta compañía, asociada con la casa editorial Linaje, desarrolló el
proyecto “Antrophos”, que consistía en un có-
mic futurista que daba oportunidad al lector de
terminar cada uno de los capítulos, viviéndolo
en un juego adjunto en forma de CD con cada
tomo. El principal problema que enfrentó este
proyecto, fue no haber considerado los largos
tiempos que toma desarrollar un videojuego, ya
que la idea original era que, tanto el juego como
el cómic, salieran mensualmente. Se lanzaron al
mercado dos tomos y se desarrolló una versión
especial del juego en formato de Arcadia, mismos que se pueden adquirir todavía, a través de
la página de Internet de la casa editorial.
Xibalba Studios. Con base en Monterrey, esta
compañía está formada por egresados de Digipen, una de las más prestigiosas escuelas de
desarrollo de videojuegos. Hasta la fecha, sólo
han mostrado una demo tecnológica de su motor de juegos, pero se sabe que trabajan en un
proyecto basado en el juego maya de la pelota,
que llevará el nombre de “Underworld Tournament”, y que se espera salga para el Xbox Live.
Vermillion Games. Compañía formada por
los hermanos Pineda de Querétaro. Su juego
“Mythic Blades”, es considerado por muchos,
el mejor juego de video desarrollado en México hasta la fecha. La calidad que han logrado
imprimir en el arte gráfico y la programación,
hizo que distribuidores internacionales de videojuegos se fijaran en él, y se esté vendiendo ya en diversos lugares del mundo.
Conclusión
A pesar de los retos y dificultades que
enfrenta esta industria en nuestro país,
las esperanzas de que siga creciendo
son muchas, ya que existe gente que
cree firmemente que México puede
dejar de ser un país consumidor y convertirse en un país creador de propiedad intelectual y juegos de calidad. Si
quieres conocer más sobre desarrollo
de videojuegos en nuestro país, te recomiendo que entres al sitio del capítulo en México del IGDA, disponible en
http://mexico.vjuegos.org/
Ing. Oscar Miguel Guillén Hernández. Ingeniero en Electrónica y Sistemas Digitales por la Universidad Panamericana campus Bonaterra de la ciudad de
Aguascalientes. Socio fundador y Director Creativo de la empresa de tecnologías de entretenimiento Tecnochtitlán S.A. de C.V. de la cual se desprende la marca
de juegos de video Nibbo Studios. Creador de los personajes de los juegos Mecapumble y Überpong. Co-coordinador de los proyectos creados por la empresa
y encargado del área artística de la misma.
www.softwareguru.com.mx
ENE-FEB 2007
35
/* MEJORA DE PROCESOS */
// PRÁCTICAS
Análisis del ROI
Una Herramienta para Justificar la Mejora de Procesos
Por Angélica Su y Alfredo Calvo
M
ucho se ha cuestionado si la mejora de
procesos de software basada en CMMI,
realmente trae beneficios tangibles para las
compañías de nuestro país. Las empresas que
quieren comenzar a implementar un esfuerzo
de esta naturaleza, se cuestionan cómo poder
justificar los recursos que van a invertir para
ello, y si se aprovecharán de manera adecuada.
Aunque para muchas de estas empresas, la obtención de un nivel de madurez sigue siendo el
principal móvil para implementar CMMI. La realidad muestra que, tales iniciativas, logran un
éxito significativo cuando son vistas como un
objetivo de negocio, que traerá consigo beneficios económicos y que resolverá problemáticas
relevantes en la organización.
Las preguntas que típicamente surgen al plantear un programa de mejora son: ¿cuánto nos
va a costar?, ¿qué beneficios vamos a obtener?, ¿cómo justifico el gasto ante el Consejo?,
¿existe información de resultados obtenidos
por empresas similares en México?
de utilidad del 35%? O quizá destinarlo a mejorar la infraestructura de cómputo. A fin de
cuentas, la implementación de un programa de
mejora de procesos de software compite por
recursos humanos y económicos limitados.
Actualmente, las compañías utilizan el ROI
para evaluar los proyectos de inversión que
tienen en puerta. Sin embargo, para un programa de mejora basado en CMMI, la complejidad de este análisis radica en obtener
la información suficiente y confiable para
calcularlo correctamente.
Análisis del Retorno de Inversión
El proceso para analizar el ROI de un programa
de mejora se ilustra en la siguiente figura, y se
describe a continuación:
Para poder generar un adecuado entendimiento de implicaciones y beneficios asociados con
un programa de mejora, el análisis del Retorno
de Inversión o ROI (Return of Investment) es
una herramienta de utilidad, que permite apoyar la justificación de la inversión en términos
tangibles para los tomadores de decisiones en
la organización.
El ROI es un concepto sencillo de comprender
y aplicar. Supongamos el caso de una empresa que enfrenta la decisión de si invertir o no,
en un programa de mejora. El análisis del ROI
significa evaluar si la inversión es rentable,
comparada con otros proyectos u opciones
de inversión disponibles, es decir, ¿por qué no
mejor invertir este dinero en el banco a taza del
8%?, o ¿por qué no invertirlo como capital de
trabajo en proyectos para buscar un margen
1. Determinar el alcance de la
iniciativa de mejora
A fin de acotar el alcance del programa de mejora, la organización debe decidir:
•La representación del modelo que utilizará
(escalonada o continua).
•Las áreas de proceso a implementar.
•El nivel de madurez objetivo.
•Las áreas involucradas (una división, toda
la organización, todos los tipos de proyecto,
o sólo aquellos que pertenezcan a una u otra
tecnología, etcétera).
2. Estimar el esfuerzo y los costos
asociados
Como en cualquier proyecto, es necesario
identificar los recursos que se requerirán para
poder implementar el programa de mejora. Los
principales rubros a considerar son:
•Capacitación.
•Esfuerzo para la definición, despliegue y soporte del proceso.
•Herramientas.
•Consultoría especializada.
•Evaluaciones formales.
Es importante contemplar los costos asociados, no sólo para la implementación del programa, sino también para mantenerlo operando, aun después de haber alcanzado un nivel
de madurez.
3. Dimensionar los beneficios
Figura 1. Procedimiento para el análisis del ROI.
Un programa de mejora debe estar gobernado por los objetivos de mejora definidos por
el negocio. La experiencia después de innumerables sesiones de trabajo con directores
de empresas de TI para identificar los objetivos de negocio, nos arroja que los cinco
principales son:
•Mejorar la utilidad de los proyectos.
•Cumplir dentro del tiempo y costo estimado.
•Mejorar la satisfacción del cliente.
Alfredo Calvo es Consultor Sr. de IT ERA en CMMI, Planeación Estratégica y Balanced Scorecard. Alfredo es CMM CBA-IPI Lead Assessor e
Instructor de PSP y TSP autorizado por el SEI, así como Premio Nacional de Tecnología 2000. Ha sido desarrollador, líder de proyecto, gerente y
director de TI para diversas empresas y cuenta con amplia experiencia brindando servicios de consultoría en mejora de procesos.
Angélica Su es Gerente de Línea de Negocio de CMMI en IT ERA. Cuenta con más de 12 años de experiencia en el ámbito de mejora de procesos,
ha participado en diversos proyectos de implementación de modelos como CMMI, MoProSoft, RUP, ITIL para diversas compañías. Participó como
editora en MoProSoft y EvalProSoft, las cuales actualmente forman parte de norma mexicana de software.
36
ENE-FEB 2007
www.softwareguru.com.mx
El análisis del ROI es una
herramienta de utilidad, que
permite apoyar la justificación de la
inversión en términos tangibles.
•Mejorar la calidad del producto.
•Mejorar la productividad del equipo.
El punto más complicado para realizar un adecuado análisis del ROI, es el dimensionamiento
y la cuantificación de los beneficios que se obtendrán con CMMI, debido sobre todo, a la carencia de información; la buena noticia es que
ahora existen resultados cuantitativos publicados que pueden servir como base para este
análisis. En la tabla 1, se pueden observar los
resultados del uso de CMMI publicados por el
SEI, con datos relevantes como: la disminución
del costo en un 20%, aumento en calidad en un
50%, aumento en precisión del calendario del
37%, aumento en productividad del 62% y un
ROI medio de 4.7 a 1.
Categoría de Rendimiento Número
Desempeño medio
de datos
Desempeño Desempeño
Inferior
mayor
Costo
20%
21
3%
87%
Calendario
37%
19
2%
90%
Productividad
62%
17
9%
255%
Calidad
50%
20
7%
132%
Satisfacción
del Cliente
14%
6
-4%
55%
Retorno de
Inversión
4.7 : 1
16
2:1
27%
Tabla 1. Resultados publicados por el SEI. www.sei.cmu.
•Ti-M. Evaluada en diciembre del 2006 como
CMMI Nivel 3, con información de uso de sus
procesos en más de 15 proyectos. Sus estimaciones de esfuerzo tienen variaciones respecto a la realidad, de menos del 10% (de -8% a
+5%), lo cual habla de la madurez y confiabilidad de su operación.
• Dextra Technologies. Empresa trabajando
con procesos CMMI Nivel 3, actualmente presenta datos recopilados durante 2 años, que
reflejan un efectivo control en la densidad de
defectos en sus proyectos. Esto le ha permitido
mejorar el empleo de sus recursos, disminuyendo el retrabajo en actividades de calidad.
• Mexware Consulting. Comenzó a implementar su programa de mejora de procesos
en 2005 y actualmente implementa proyectos con procesos de Nivel CMMI3. Sus resultados a la fecha para 20 proyectos ejecutados reflejan una desviación promedio de
esfuerzo y tiempo del 5%
• A nivel gubernamental, está el caso de la Coordinación de Tecnología para la Incorporación
y Recaudación del IMSS, que en octubre de
2006 obtuvo el Nivel 3 de capacidad de CMMI.
Dentro de los resultados actualmente reportados, presenta proyectos con desviación promedio del 6.3%, un índice de apego a procesos
definidos del 98.1% y un ROI de 3.5 a 1.
edu/cmmi/results.html.
Estos datos pueden ser tomados “como referencia”, con las debidas reservas, ya que
cada empresa es diferente, y los criterios
para captar, calcular y presentar dicha información no necesariamente podrían ser aplicables a su empresa.
Las empresas que han aportado datos al SEI
son empresas del tamaño de Boeing, Lookheed
Martin, GM, Siemens, etcétera; y para la empresa promedio en nuestro país genera inquietud, sobre si estos datos les son aplicables o
no. La mala noticia aquí, es que actualmente
no existe un registro similar para las empresas
mexicanas, pues son aún pocas las que han
implementado con éxito el CMMI, y menos
todavía, las que cuentan con información histórica confiable. A continuación, se presentan
datos de empresas mexicanas con las cuales
hemos trabajado en la empresa It Era.
www.softwareguru.com.mx
Algunos de los ejemplos típicos que se presentan como metas de mejora pueden ser:
•Disminuir el retrabajo por corrección a
defectos en un X%
•Disminuir el retrabajo por mala especificación de requerimientos en un X%
•Acotar la desviación en esfuerzo y tiempo
a un X%
•Aumentar la rentabilidad en un X%
En la tabla 2 se presenta un ejemplo para
estimar los beneficios en una empresa con
60 desarrolladores, tomando como base un
aumento en productividad del 10%.
4. Calcular el ROI
El cálculo del ROI, se realiza dividiendo la
estimación de los beneficios estimados entre los costos asociados con el programa.
Siguiendo el ejemplo anterior, si consideramos una inversión de 75 mil dólares, un
60
Desarrolladores
260
Días laborales
8
Horas x día
124,800
Horas hombre al año
$ 30.00
Tarifa promedio (USD)
$ 3,744,000
Ingresos estimados
anuales (USD)
$ 374,400
Ahorros estimados por aumento
en productividad del 10% por
año (USD)
Tabla 2. Ejemplo de beneficios estimados.
beneficio esperado de 374 mil dólares al
año tenemos:
ROI = 374,400 / 75,000 = 4.99
5. Presentación de resultados
Comunicar a la organización el análisis realizado, los objetivos de negocio, las metas de mejora y los beneficios esperados, es importante
para generar el compromiso y patrocinio de
todos los participantes que pueden apoyar a
que el programa de mejora tenga éxito.
Principales consideraciones
•Se requiere acceso a información relevante
y sensible.
•Calcular los beneficios no es una tarea trivial.
•Falta de consistencia en la medición del ROI.
•Las organizaciones no tienen datos de su
situación actual.
Conclusión
El análisis del ROI es una herramienta de suma utilidad para
evaluar la conveniencia de un programa de mejora. Se requiere contemplar los costos asociados con
la implementación y el mantenimiento del programa de mejora. Es
indispensable establecer objetivos de negocio cuantificables que
guíen y gobiernen el programa de
mejora. Los beneficios económicos se determinan en b ase a estos
objetivos de negocio.
ENE-FEB 2007
37
// PRÁCTICAS
/* DISEÑO */
POJOs y Frameworks Ligeros:
Simplificando el Desarrollo
Por Ixcoatl Pérez
Q
uienes han desarrollado aplicaciones empresariales usando la especificación 2 de
EJB (Enterprise Java Beans), conocen el excesivo
tiempo que se consume en el ciclo Editar-Compilar-Debugear. Incluso, posiblemente se han
vuelto expertos en pasatiempos como Sudoku,
u otra actividad que haga más llevadera la espera en este ciclo. Es cierto que algunas veces
la utilización de tal tecnología es la mejor decisión que podemos tomar, sin embargo, también
existen muchos proyectos donde su uso no es él
más recomendado, e incluso hace el desarrollo
más lento y tedioso, afectando la productividad
del equipo de desarrollo.
Un típico diseño basado en
Arquitectura EJB 2
Veamos un ejemplo simple de tipos de cambios, donde se nos solicita el servicio de
Captura de Operaciones de compra-venta de
dólares hacia otras instituciones bancarias.
La figura 1 muestra cómo podría diseñarse
este servicio con un Session EJB.
El acceso hacia los objetos de datos (Data Access Object - DAO) es a través de un EJB llamado CapturaService, donde cualquier validación
y/o proceso de lógica de negocio es ejecutada.
Por ejemplo, si la institución bancaria existe, o
si la cantidad que se desea cambiar está dentro de los límites aceptables.
Figura 1. Diseño de Captura de Operaciones con EJB 2.
El resultado es un objeto de datos llamado
CapturaResultDTO con el resultado de la operación. Los métodos que acceden la base de
datos están encapsulados en DAOs, los cuales
pueden ser implementados con JDBC o algún
otro mecanismo de persistencia. Este diseño
aparenta estar bastante bien, pero esconde varios problemas que describo a continuación.
Problemas frecuentes en EJBs
Framework pesado y complejo. EJB 2 es un
framework muy completo, que resuelve requerimientos comunes en las aplicaciones empresariales, tales como el manejo de transacciones distribuidas, seguridad y persistencia. Esto
trae varias ventajas, pero también lo convierte
en un modelo muy pesado y complejo.
Poca productividad. La arquitectura EJB 2 nació con el propósito de facilitar el desarrollo
de aplicaciones empresariales, y ciertamente
nos evita la necesidad de codificar procesos
estructurales de bajo nivel, pero esa ayuda
se paga con altísimos costos de tiempo. Hacer cualquier modificación a un EJB, requiere
además de editar y compilar, instalar cada
componente EJB en el Servidor de Aplicaciones, configurar los archivos XML, levantar el
Servidor de Aplicaciones para que se tomen
los cambios, y buscar soluciones a problemas
generados por los mismos EJBs.
No fomenta la Orientación
a Objetos
Mucha gente piensa que por el hecho de escribir código en un lenguaje que soporte OO, ya
están desarrollando con objetos y todo el paradigma que éste conlleva. Sin embargo, lo anterior no es una estrategia basada en tecnología,
sino en la organización del código. La cultura
de la programación orientada a componentes
de EJB 2, no fomenta la orientación a objetos,
ya que los session y message-driven beans son
estructuras monolíticas y clases muy pesadas.
Por otro lado, los Entity Beans que son creados para representar entidades de negocio,
tienen muchas limitaciones que los hacen difíciles para implementar un modelo de objetos.
Como resultado, es difícil desarrollar un verdadero estilo Orientado a Objetos sobre la plataforma J2EE. Este tipo de desarrollos es lo que
Martin Fowler llama “anemia domain model”,
y parecido a la falta de vitalidad en la sangre
anémica, los modelos de objeto anémicos únicamente modelan superficialmente el problema, ya que contienen clases que implementan
poco, o nada de comportamientos.
Desarrollando con POJOs y
Frameworks ligeros
Antes de la especificación EJB 3, muchos
desarrolladores desilusionados con EJB buscaron alternativas, y encontraron que los
POJO son una de esas, convincente a EJBs.
Un POJO (Plain Old Java Object) es simplemente un objeto de Java que no implementa
ninguna interfase especial. Su nombre fue
creado por Fowler, Rebbecca Parsons y Josh
MacKenzie para darle a los objetos regulares
de Java un nombre de sonido divertido.
Los POJOs por sí solos, no son suficientes para
crear una aplicación empresarial completa,
ya que carecen de los servicios que brinda
un contenedor de EJB. Por eso, la solución es
complementarlos con el uso de Frameworks
Ligeros como Spring e Hibernate, que reemplazan algunas de las partes pesadas de la
Ixcoatl Pérez es Consultor TI especializado en sector financiero, con experiencia desarrollando sistemas empresariales para diferentes industrias en USA y
México. Es experto en análisis y diseño orientado a objetos, desarrollo web, RUP y arquitectura J2EE. Ixcoatl cuenta con las certificaciones Sun Certified Java
Developer, Sun Certified Web Component Developer y Sun Certified Business Component Developer.
38
ENE-FEB 2007
www.softwareguru.com.mx
plataforma J2EE. Hibernate y Spring tienen características importantes, el no ser intrusivas, es una de ellas. Proveen transacciones y persistencia sin requerir que las clases implementen ninguna interfase en
especial (por ello siguen siendo POJOs). La aplicación es ensamblada
con contenedores ligeros que implementen Dependecy Injection en
lugar de usar la búsqueda de componentes con JNDI.
Estos frameworks solucionan diferentes necesidades a lo largo de un
desarrollo empresarial. Los beneficios son mayores cuando se combinan adecuadamente con patrones de diseño y mejores prácticas de
desarrollo. Por ejemplo, el patrón de Modelo de Domino nos brinda
todo el beneficio del Desarrollo OO, ya que las reglas de negocios son
la base de la implementación, al tiempo que los objetos de dominio
ignoran que serán persistidos, ya que, transparentemente son mapeados hacia la Base de Datos relacional. Un framework de persistencia
como Hibernate nos brinda una solución ORM (Object-Relational Mapping), y si se requiere mapear POJOs hacia sentencias SQL, iBATIS,
nos brinda una solución bastante conveniente para ejecutar sentencias SQL. Con un el uso de interfaces se evita acoplar un modelo de
dominio hacia un framework de persistencia específico, lo que nos da
mayor flexibilidad e incluso es posible probar el modelo de domino sin
un esquema de Base de Datos. El desarrollo con POJOs también nos
brinda un beneficio extra, ya que el Desarrollo Orientado-a-Pruebas
(Test Driven Development - TDD) es bastante simple y compatible con
los POJOs, al no depender de un servidor de aplicaciones.
Tal vez la principal razón para usar Session Beans, es la capacidad
de tener transacciones administradas por el contenedor (ContainerManaged Transaction - CMT). Esto permite que el contenedor EJB
automáticamente comience una transacción cuando un método es
invocado, haciendo el commit cuando termina exitosamente, o el rollback en caso de no ser así. Ahora bien, si optamos por la opción de
POJOS y frameworks ligeros, el framework de Spring nos provee una
solución equivalente a CMT para POJOs, además de tener un rango
amplio de características que lo hacen muy fácil de usar. Cuando un
método POJO es llamado, Spring automáticamente comenzará una
transacción y hará el commit o rollback correspondiente. Aquí lo interesante es que Spring puede administrar las transacciones usando
el framework de persistencia, el administrador de transacciones de
JDBC, o el Java Transaction API (JTA), según sea deseado. Esto es tan
simple como definir un POJO como un Spring Bean, con unas cuantas líneas de XML similar al deployment descriptor de EJB, y con eso
tenemos un POJO que es transaccional. La aplicación obtiene un
SpringBean llamando a la fábrica de SpringBean con el nombre y tipo
esperado. Tan simple como:
BeanFactory factory = new XMLBeanFactory(new FileInputSteam(“capturaFacade.xml”)) ;
Debido al alto nivel de configuracion de Spring, la fábrica de SpringBean puede ser configurada para regresar un proxy en lugar del
objeto original. Este proxy, también conocido como interceptor, es
un objeto que finge ser el objeto original, pero que puede ejecutar
código adicional antes y después de la invocación del objeto original, y por tanto sirve para muchos propósitos, como administrar
transacciones, seguridad o conexiones a la base de datos. CapturaFaçade puede ser envuelto en un interceptor, el cual administra las
transacciones con algún administrador de transacciones propio del
framework de persistencia que estemos usando.
Diseño basado en POJOs
Revisemos por último el diseño del servicio de Captura de Operaciones de compra-venta de dólares, pero ahora con POJOs. Este diseño
tiene más componentes que el basado en EJB, y puede parecer más
complejo, pero su diseño es más modular y mucho más fácil de probar
y extender. Aun cuando son más clases, cada una tiene un pequeño
número de responsabilidades fáciles de entender y bien definidas.
Se agregó un nuevo modulo CantidadPolicy, donde aplicamos políticas de filtro que tengan que ver con la cantidad que se compra o
vende. Esto es más que nada, un ejemplo de lo fácil que se puede
agregar nueva funcionalidad, es decir, un objeto con responsabilidad
simple y específica.
Figura 2. Diseño del servicio usando POJOs.
Usamos interfaces para simplificar el desarrollo orientado a pruebas, ya
que es posible reemplazar la implementación del repositorio Hibernate
por algún otro framework de persistencia, sin modificar el código.
CapturaFacade cF = (CapturaFacade) factory.getBean(“CapturaFacade”, CapturaFacade.class);
Nota: Utilizamos un Façade con la intención de desacoplar las responsabilidades de un CapturaService y la capa de presentación.
www.softwareguru.com.mx
En resumen, los frameworks ligeros como Spring e Hibernate nos permiten usar POJOs, con todas sus conveniencias; y tener los mismos beneficios de usar EJB Session Beans, sin tener sus complicaciones.
ENE-FEB 2007
39
// PRÁCTICAS
/* ARQUITECTURA */
Evaluando la Arquitectura de Software
Parte 1. Panorama General
Por Omar Gómez
U
no de los factores que determina el éxito o fracaso de un sistema de software, es su arquitectura. Con esto nos referimos a la
estructura o conjunto de estructuras del sistema, las cuales están
compuestas de elementos de software, propiedades externas visibles de estos elementos y las relaciones entre sí [1].
del sistema que están en operación, por ejemplo: rendimiento, confiabilidad, disponibilidad, tolerancia a fallas. En cambio, los atributos de desarrollo son las cualidades del sistema que son relevantes
desde una perspectiva del desarrollo de software, por ejemplo: facilidad de modificación, facilidad de re-utilización, flexibilidad.
El diseñar debidamente una arquitectura de software, garantiza que el
sistema de software cumpla con uno o varios atributos de calidad. Por
ejemplo, que sea fácil de usar, confiable o seguro. Sin embargo, si la arquitectura no se diseña de forma apropiada, el sistema de software resultante no logrará sus objetivos [2]. De nada sirve un sistema de software
que no cumple con los tiempos de respuesta requeridos por el cliente, o
que es complejo de modificar, difícil de usar o vulnerable a ataques.
Primeros inicios
Por lo regular, se conoce hasta el final del desarrollo del sistema de
software, si éste cumplió o no con los atributos de calidad que se
especificaron en los requerimientos no funcionales. Dicho conocimiento tardío, implica tomar demasiados riesgos innecesarios, un
ejemplo es, descubrir fallas en el sistema de software debido a que
en la fase de diseño no se eligió apropiadamente una arquitectura.
Para reducir tales riesgos y, como una buena práctica de ingeniería,
es recomendable llevar acabo evaluaciones a la arquitectura.
La finalidad de este artículo es dar a conocer un panorama general sobre evaluaciones a arquitecturas de software. En él, presento el propósito de evaluar, conceptos sobre atributos de calidad, primeros intentos
de evaluación, momentos en los que se pueden realizar evaluaciones,
clasificación de las técnicas de evaluación, planeación de evaluaciones,
y beneficios que se obtienen al evaluar una arquitectura.
Porqué es necesario evaluar una arquitectura
de software
El propósito de realizar evaluaciones a la arquitectura, es para analizar e identificar riesgos potenciales en su estructura y sus propiedades, que puedan afectar al sistema de software resultante, verificar
que los requerimientos no funcionales estén presentes en la arquitectura, así como determinar en qué grado se satisfacen los atributos de calidad. Cabe señalar que los requerimientos no funcionales,
también son conocidos como atributos de calidad. De acuerdo al estándar IEEE 610.12-1990 [3], un atributo de calidad es una característica que afecta la calidad de un elemento. En esta definición, el término “característica” se refiere a aspectos no funcionales, mientras
que el término “elemento” se refiere a un componente o sistema.
Los atributos de calidad se clasifican en dos grupos [4]: operacionales y de desarrollo. Los atributos operacionales son las cualidades
Los primeros esfuerzos en realizar evaluaciones a arquitecturas de software utilizando un proceso estructurado y definido, fueron descritos en
un trabajo seminal hecho por Parnas y Weiss [5] en 1985. En él se propone
utilizar revisiones de diseño activas, que consisten en detectar errores e
inconsistencias, por ejemplo aquellos que no fueron detectados en la fase
de requerimientos. Este proceso consiste en elaborar una serie de cuestionarios cuidadosamente escritos, de tal manera que el revisor no pueda
responderlos de una manera pasiva, es decir, con un “Sí” o un “No”.
Cada cuestionario se diseña para encontrar diferentes tipos de errores, por lo que cada uno, evalúa aspectos específicos del diseño.
Estos, a su vez, junto con la documentación del diseño, se entregan
para su evaluación a un grupo de revisores expertos en uno o varios
aspectos específicos del diseño. En promedio, la duración de dichas
revisiones se lleva de uno a dos días, dependiendo de la complejidad
del diseño, así como del número de revisores.
¿Cuándo es recomendable evaluar?
La evaluación a la arquitectura puede efectuarse en varios momentos,
dependiendo de la etapa de construcción en que se encuentre. La evaluación clásica se efectúa una vez que la arquitectura se ha terminado y aún
no se implementa. La evaluación temprana se lleva acabo una, o varias
veces durante la etapa de construcción de la arquitectura, mientras que
la evaluación tardía, se realiza cuando la arquitectura existe y la implantación se ha completado. Clements, Kazman y Klein [6] proponen dos reglas
de oro para determinar el momento de efectuar la evaluación:
1. Realizar una evaluación cuando el equipo de desarrollo inicia a
tomar decisiones que afectan directamente a la arquitectura; y...
2. Cuando el costo de no tomar estas decisiones podría pesar más,
que el costo de realizar una evaluación.
Técnicas de evaluación
Existen varias técnicas para evaluar arquitecturas de software, que
se clasifican en cualitativas y cuantitativas. Dentro de las técnicas de
evaluación cualitativas se pueden utilizar: escenarios, cuestionarios
o listas de verificación. Por otro lado, en las técnicas de evaluación
cuantitativas se pueden emplear: métricas, simulaciones, prototipos, experimentos o modelos matemáticos; en la figura 1 se muestran de manera gráfica estas técnicas.
Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas. Actualmente es
profesor de la Universidad de Guadalajara, es miembro de la Association for Computing Machinery ACM y del IEEE Computer Society. Puedes contactarlo
en ogomez@ieee.org
40
ENE-FEB 2007
www.softwareguru.com.mx
Realizar una evaluación no
planeada, representa retrasos
en los tiempos de entrega, así
como un incremento en los
costos del proyecto.
La mayoría de los métodos de evaluación utilizan escenarios, que son
secuencias específicas de pasos que involucran el uso o la modificación
del sistema. Por lo regular, las técnicas de evaluación cualitativas son
usadas cuando la arquitectura se encuentra en construcción, mientras
que las técnicas de evaluación cuantitativas, se usan cuando la arquitectura ya ha sido implantada. Por ejemplo, es posible hacer uso de modelos matemáticos tales como teoría de colas, para medir el desempeño
de un conjunto de componentes EJB en una aplicación J2EE [7].
por los resultados obtenidos de la evaluación, ya que puede decidir continuar o no con el proyecto, dependiendo de los resultados.
Un ejemplo de este caso es el siguiente, tras haber efectuado una
evaluación temprana, se determinó que no es posible implantar la
arquitectura con la infraestructura disponible, ya que esta no cumplirá con los tiempos de respuesta requeridos por el cliente.
Resultado de la evaluación
Una vez que se ha efectuado la evaluación, se debe elaborar un reporte. Que debe presentarse como un documento preliminar, con la finalidad de que se corrija por las personas que participaron en la evaluación. El contenido del reporte responde a dos tipos de preguntas [6]:
•¿Se ha diseñado la arquitectura mas apropiada para el sistema?
•¿Cuál de las arquitecturas propuestas es la más apropiada para el
sistema a construir?
Además de responder estas preguntas, el reporte también indica el
grado en que se cumplieron los atributos de calidad.
Conclusiones
En esta primera parte presentamos un panorama general sobre las
evaluaciones a las arquitecturas de software. Entre los puntos más
importantes destacaron: el propósito de evaluar, los momentos y
los tipos de técnicas de evaluación, así como los resultados que se
obtienen de ésta. En la próxima ocasión, expondremos de manera
detallada, algunos de los métodos de evaluación a arquitecturas de
software más usados en la actualidad.
Figura 1. Clasificación de las técnicas de evaluación.
Planear o no la evaluación
Las evaluaciones pueden ser planeadas o no planeadas. Una evaluación planeada es aquella que ha sido contemplada dentro del
ciclo de vida de desarrollo, por lo que es parte de las actividades del proyecto. Son varios los beneficios que se obtienen de
realizar evaluaciones, algunos de estos son descubrir defectos e
inconsistencias en la fase de diseño, asegurar que se cumplan
los atributos de calidad, así como reducir los costos del proyecto.
Comúnmente una evaluación no planeada, se presenta cuando la
arquitectura de software contiene varios defectos que han sido
detectados en etapas tardías del desarrollo, por ende, realizar
una evaluación no planeada, representa retrasos en los tiempos
de entrega, así como un incremento en los costos del proyecto.
Es recomendable que en el proyecto se contemple realizar una o
varias evaluaciones a la arquitectura.
¿Quiénes participan en la evaluación?
Generalmente las evaluaciones a la arquitectura se hacen por los
miembros del equipo de desarrollo, tales como el arquitecto, diseñador y administrador del proyecto. Sin embargo, puede haber
excepciones en las que se contrate a un grupo de personas especialistas para realizar la evaluación. El cliente también se interesa
www.softwareguru.com.mx
Referencias
1. Len Bass, Paul Clements & Rick Kazman. “Software Architecture in
Practice”. SEI Series In Software Engineering. Segunda edición. Addison
Wesley, 2003.
2. Anthony Finkelstein & John Dowell. “A Comedy of Errors: The London Ambulance Service Case Study”. Proceedings of 8th International
Workshop on Software Specification and Design (IWSSD-8), Schloss
Velen; Alemania, Marzo 1996.
3. “Standard Glossary of Software Engineering Terminology.”, Institute of
Electrical and Electronics Engineers (IEEE), 1990.
4. Jan Bosch & Peter Molin. “Software Architecture Design: Evaluation
and Transformation”. Proceedings of IEEE Engineering of Computer
Based Systems Symposium (ECBS ‘99) 1999.
5. David L. Parnas & David M. Weiss. “Active Design Reviews: Principles
and Practices”. Proceedings of 18th International Conference on Software
Engineering 1985.
6. Paul Clements, Rick Kazman & Mark Klein. “Evaluating Software Architectures”. SEI Series in Software Engineering. Addison Wesley, 2002.
7. Yan Liu & Ian Gorton. “Performance Prediction of J2EE Applications
Using Messaging Protocols.” International SIGSOFT Symposium on
Component-based Software Engineering (CBSE). Mayo 2005.
ENE-FEB 2007
41
// UML
Brindándole un Hogar al Software:
DIAGRAMAS DE DISTRIBUCIÓN
Por Charlie Macías y Sergio Orozco
Imagina tu casa con un televisor de plasma de 50 pulgadas, un refrigerador que te
envía mensajes cuando la leche o el huevo
están por terminarse; una estufa con parrilla
electrónica que se apaga sola; una sala de
piel que da masajes y autoregula su temperatura; dos líneas telefónicas con teléfonos
inalámbricos de 5.8 Ghz de largo alcance y
una cama king size automática con masajes;
todo esto para que lo disfrutes tú, tus padres
y tus cinco hermanitos. De fantasía, ¿cierto?
Contenido en una maravillosa casa duplex
de interés social de 70 metros cuadrados.
¡Espera! ¿Maravillosa casa duplex para todo
esto? Hablemos de incongruencias. No parece ser el lugar más apropiado para tener
esas comodidades, ¿cierto?
Soñar no cuesta, no planear sí
Antes de decidir comprar los anteriores componentes, tienes que asegurarte que van a
caber o, funcionar en tu casa. Y si no caben, y
tienes el presupuesto, tendrás que mudarte
a otra casa más apropiada.
Bueno, pues eso mismo sucede con el desarrollo de software. Antes de decidir desarrollar una aplicación con ciertos requerimientos, tienes que asegurarte que cuentas con
la infraestructura apropiada para ponerlos a
funcionar sin problema. Si no cuentas con
ella, tendrás que decidir cuál será el equipo
y ambiente adecuados (computadoras, servidores, sistemas operativos, etcétera) para
instalar y hacer funcionar tu aplicación. Por
supuesto, restringiéndote al presupuesto
disponible para tal fin.
Antes de llenar tu casa con todo tipo de muebles y componentes, de seguro visualizarás si
tu casa tiene espacio dónde colocarlos. Si eres
suficientemente precavido evaluarás si la instalación eléctrica o hidráulica es la apropiada
para que funcionen correctamente. Si eres un
diseñador de interiores o un arquitecto, bosquejarás algún plano para asegurarte de estar
tomando la decisión correcta.
Así mismo ocurre en el caso del software,
antes de desarrollar un conjunto de componentes que formarán una aplicación, pensarás si el equipo e infraestructura con la que
cuentas es apropiada para dicho sistema. Antes de desarrollar el software, e incluso antes
de comprometerte con tu cliente a desarrollarlo, tendrás que asegurarte de identificar
si se cuenta con el equipo apropiado o con el
presupuesto para adquirirlo y así poder hacer
funcionar correctamente la aplicación.
Proponer o Restringir
Al inicio del proyecto, en lo que podemos llamar fase de Inicio o Concepción (“Inception”)
en el caso del Proceso Unificado, tendrás que
desarrollar un primer diagrama de distribución para identificar las restricciones físicas
de hardware en el proyecto (el equipo e instalaciones con las que cuenta el cliente para
el proyecto), o en su defecto, documentar el
hardware propuesto, en el cual se tendrá que
invertir para hacer funcionar el software.
En la fase posterior, la de Elaboración, este
diagrama tendrá que ser refinado para dejar
especificadas las decisiones tomadas con
respecto a esta perspectiva del sistema.
El diagrama de distribución es el artefacto de UML que nos permite representar los
elementos físicos de un sistema; lo que mu-
cha gente conoce tradicionalmente como la
arquitectura física. En este puedes visualizar las computadoras (clientes, servidores,
PDAs), elementos adicionales de hardware
(impresoras, ruteadores) y las conexiones
(la red). Incluso puedes indicar qué sistema
operativo corre en una computadora o en
cuál de las computadoras pondrás a correr
ciertos componentes de tu aplicación.
Los componentes de software realizan la
dinámica de un sistema; representan agregaciones de clases. Son los moldes de fabricación que construyen a los objetos que
colaboran en tiempo de ejecución para llevar
acabo lo que especifican los requerimientos.
Estos componentes tienen que ser colocados
en el hardware para que los podamos usar.
Entender la manera, lugares y necesidades
que los alojarán es un factor importante en
la definición del dominio de la solución.
Elementos del Diagrama
de Distribución
Nodo. Representa un recurso de cómputo que puede alojar artefactos y que
se puede interconectar con otros nodos
para describir topologías de redes.
Dispositivo. Representa un recurso físico de cómputo que posee capacidad
de procesamiento; se representa igual
que un nodo.
Entorno. Ejecutable. Representa un
recurso lógico de cómputo dentro
del cual se alojan manifestaciones de
componentes de cierto tipo.
Charlie Macías es arquitecto de software y consultor senior en UML de Milestone Consulting. Sergio Orozco es director general, consultor e instructor senior
de Milestone Consulting (UML Value Added Training Center), empresa especializada en capacitación práctica y consultoría en UML, CMMI y orientación a
objetos. Milestone Consulting es la primer empresa mexicana miembro de la OMG
Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting (UML Value Added Training Center), empresa
especializada en capacitación práctica y consultoría en UML, CMMI y orientación a objetos. Milestone Consulting es la primer empresa mexicana miembro de la OMG. info@milestone.com.mx www.milestone.com.mx
42
ENE-FEB 2007
www.softwareguru.com.mx
“Por más extraño que parezca, ni las
clases ni los componentes se ejecutan
en el hardware, ya que estos tipos de
elementos carecen de manifestación en
el mundo físico”.
Rutas de Comunicación. Asociación
que se modela sólo entre objetivos
de distribución (nodos, dispositivos
o entornos ejecutables) indicando
que estos pueden intercambiar mensajes y señales.
Componente. Representa unidades
autocontenidas de software que
realizan a las clases, o a cualquier
elemento empacable
Artefacto. Representa la manifestación de un componente en el
mundo físico.
Un artefacto es una pieza de información física
que usa o produce un proceso de desarrollo de
software, una distribución o el funcionamiento
de un sistema. Ejemplos de artefactos, son los
archivos que distribuimos en el hardware, como
los archivos JAR, WAR, EAR, EXE y DLL. En la
siguiente figura podemos observar la relación
que existe entre el concepto tradicional de componente y el artefacto donde se manifiesta.
Figura 2. Relación entre el artefacto y el componente
manifestado.
Ambientando la Casa
Los componentes necesitan de un ambiente
donde se ejecutarán. Si deseas dejar gráficamente documentada esta información. El
ambiente de ejecución se puede representar
de manera similar a los nodos, es decir, en
forma de cubo. Sólo que dicho ambiente se
aloja dentro de un dispositivo, como se puede ver en la ilustración.
Figura 1. Dos recursos de cómputo con capacidad
de procesamiento conectados y alojando artefactos.
Un artefacto no es una Ilusión
Un concepto que para muchos resulta difícil de
entender, es el artefacto. Especialmente por su
relación con el concepto de componente. El nivel de abstracción es diferente en ambos casos,
aunque podemos referirnos en cierta situación,
a elementos muy similares.
Por más extraño que parezca, ni las clases ni
los componentes se ejecutan en el hardware,
ya que estos tipos de elementos carecen de
manifestación en el mundo físico. Para lograr
la manifestación de las clases y componentes
necesitamos un artefacto.
www.softwareguru.com.mx
Figura 3. Artefacto que se ejecuta en un ambiente de
ejecución dentro de un dispositivo.
Así que antes de decidir llenarte de comodidades, asegúrate de contar con el espacio y
las características necesarias en tu casa. Antes de invertir en la compra o desarrollo de
un software, asegúrate que tendrá un hogar
apropiado donde hospedarse.
ENE-FEB 2007
43
// COLUMNA
/*TENDECIAS EN SW*/
Office Business Applications (OBA) y
Line of Business Integration (LOBi)
El Próximo Patrón Estratégico
Luis Daniel Soto es director de Evangelización en nuevas tecnologías en Microsoft México. Entre sus funciones actuales están la de administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Es jurado del “Gran Orden del Honor
al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de TI. Ganó el primer lugar en el concurso nacional
para software de exportación en 1989. blogs.msdn.com/luisdans
E
n la columna anterior hablé sobre Software as a Service (SaaS), el
cual puede ser denominado como un patrón estratégico, tal vez el
de mayor proyección e importancia hacia el resto de ésta década. Otros
patrones estratégicos que existen actualmente en el mercado son:
•Win32 – la mayoría de aplicaciones actuales para Microsoft Windows.
•Dispositivos – teléfonos, portátiles, conectados a tv, embebido.
•Empresarial – cliente-servidor, 3 capas.
•Videojuegos – escritorio, consola, portátil, teléfonos.
Office System 2007 como plataforma de desarrollo
En esta ocasión, me referiré al que consideramos en Microsoft, el segundo patrón estratégico en importancia para el futuro: Office Oriented
Applications. Las Office Business Applications (OBA) son una nueva
categoría de aplicaciones de negocio, que permite utilizar aplicaciones de negocio (line of business systems) desde Microsoft Office.
En particular, es interesante la plataforma del servidor, que incluye
una gran cantidad de nuevas tecnologías, entre las que destacan:
•Colaboración: Blog y Wiki, RSS, Web Services API.
•Administración de contenido: Extensible Type System, Records
Repository API, Web Management API, Information Rights API,
Document Converter.
•Inteligencia de negocios: Excel Services Web API, Excel Services
Calculation Engine, Filter Web Parts, Data Connection Library.
•Procesos de negocio y formas: Pluggable SSO, Infopath Services.
•Búsqueda empresarial: Web Services Search API, Business Data
Catalog, iFilters.
•Portal: Web Parts Framework, User Profile API, Audience Targeting API.
Imagina que tienes una capa de datos (backend), y una capa de lógica e integración con procesos de negocio (que residen en “lineof-business applications”, tales como ERPs, CRMs y SCMs), pero te
falta tu capa de presentación. En lugar de desarrollar una aplicación
web, un cliente windows, o utilizar el front-end de un CRM específico,
puedes utilizar aplicaciones de Microsoft Office como tu capa de presentación y dejar que los usuarios interactúen con los procesos de
negocio, a través de programas como Outlook que ya conocen bien,
y que de todos modos, tienen abiertos durante todo el día.
El siguiente diagrama ilustra a grandes rasgos la arquitectura de este
nuevo tipo de aplicaciones.
Office 2007 será el gran habilitador de este tipo de aplicaciones. Los
objetivos principales de esta versión son:
1. Mayor productividad en lo que cada herramienta ofrece.
2. Transformarse en un cliente de tres áreas poco desarrolladas en las
empresas: a) Comunicaciones unificadas y colaboración; b) Administración de contenido empresarial; c) Inteligencia de negocios.
3. Convertirse finalmente en una plataforma de desarrollo auténtica.
Es importante señalar que estos servicios descansan en los nuevos
“Windows SharePoint Services 3.0” (WSS 3.0) que se ofrecen gratuitamente para usuarios de Windows Server 2003 y Small Business Server.
La infraestructura que ofrece WSS 3.0 incluye: flujos de trabajo, meta
datos, búsqueda, auditoría, ayuda personalizada y otros servicios.
Conclusión
OBA permitirá “abrir el retorno de inversión de toda la tecnología empresarial”. Consiste en aprovechar la plataforma existente al máximo.
Algunos ejemplos: Panorama (BI en Sharepoint), Oracle Siebel (CRM
desde Outlook), Hummingbird (Administración de documentos desde
Word), Fractal Edge (Visualización desde Excel) y Mind Manager (Mapas mentales con Open XML), son algunos ejemplos concretos.
Microsoft trabaja ya en “Office 14”, y la principal inversión a futuro
será precisamente la categoría denominada LOBi (Line of Business integration). Evalúenlo con sus usuarios, y decidan ustedes mismos.
—Luis Daniel Soto
Referencias
Figura 1. Arquitectura de aplicaciones orientadas a Office.
44
ENE-FEB 2007
•Arquitectura OBA: msdn.microsoft.com/architecture/office
•Desarrollo OBA: msdn.microsoft.com/office
•WSS 3.0: www.microsoft.com/technet/windowsserver/sharepoint
www.softwareguru.com.mx
// COLUMNA
/* CÁTEDRA Y MÁS */
Realidad Virtual
Estimulando la Imaginación
El Dr. Mario Arturo Gutiérrez Alonso es profesor asistente del Departamento de Computación y Sistemas de Información de la Escuela
de Ingeniería y Arquitectura del ITESM Campus Toluca. Sus áreas de interés son la Realidad Virtual, Animación 3D y la Inteligencia Artificial
aplicadas al desarrollo de interfaces multimodales y simulación.
E
l término Realidad Virtual engloba
una gran cantidad de ideas filosóficas, aplicaciones y áreas de investigación,
todas ellas con un tema en común: “crear
la sensación de estar ahí”, en un lugar
que no existe o que en un momento dado
es imposible alcanzar. No está muy claro
quién fue el primero en acuñar el término; se mencionan autores como Damien
Broderick, escritor australiano autor de
“The Judas Mandala” (1982), y Jaron Lanier, investigador norteamericano fundador de VPL Research, una compañía que
desarrollaba productos y aplicaciones de
Realidad Virtual.
Uno de los primeros ejemplos de sistemas
de Realidad Virtual es el “Sensorama”, de
Morton Heilig, desarrollado en 1962; un
dispositivo mecánico que proyectaba una
película de cine cuya reproducción era relativamente interactiva, e incluía la estimulación de múltiples sentidos: visión, sonido, olfato y tacto. El sistema simulaba un
paseo en bicicleta donde además de audio
y video, se liberaban diferentes aromas,
dependiendo del lugar a visualizar en ese
momento. Se trataba de una verdadera interfase multimodal o sistema multimedia,
desarrollada antes que las computadoras
digitales tuvieran posibilidades concretas
de simular entornos virtuales.
Cuando se habla de Realidad Virtual, tal
vez las imágenes que vienen a la mente
son las inspiradas por películas como “The
Lawnmower Man” o más recientemente
“The Matrix”. Estas y otras producciones
cinematográficas, presentan un estado de
la tecnología que aún no se ha alcanzado, y estimulan la imaginación al mostrar
la posibilidad de crear simulaciones que
sean indistinguibles o mucho más atrac-
46
ENE-FEB 2007
tivas que la misma realidad. Lo cierto es,
que estamos aún lejos de tener simuladores que confundan la mente del usuario a
tal grado, que ya no sea posible distinguir
lo real de lo sintético.
Simular realidades alternativas y entornos
virtuales, implica una gran cantidad de
áreas de conocimiento. La idea principal
es que el camino hacia una simulación de
la realidad, pasa por la estimulación simultánea y coherente de todos nuestros sentidos: vista, oído, olfato, tacto y gusto. La
mayor parte de la investigación y el desarrollo se han enfocado en la vista y el oído.
El primer prototipo de visualización de inmersión total, que utilizó tecnología digital
fue el Head Mounted Display (HMD), desarrollado por Ivan Sutherland y Bob Sproull
del XEROX PARC en 1962.
El HMD de Sutherland y Sproull, fue uno
de los primeros intentos por presentar al
usuario una interfase en la que la interacción imitara la forma en que nos desenvolvemos en la vida real: las imágenes
presentadas en una pantalla situada frente a los ojos, se actualizan dependiendo
de los movimientos de la cabeza, como si
el usuario estuviera “dentro” del entorno
artificial. La tecnología del HMD ha evolucionado mucho en cuanto a la calidad de
las imágenes, pero nunca ha tenido mucha
aceptación, debido a que el dispositivo es
muy incómodo (ver cybersickness).
Recientemente, los sistemas de visualización han adoptado el uso de proyectores,
y entre los dispositivos más sofisticados,
se encuentran los CAVE (Cave Automatic
Virtual Environment), seis o más pantallas de proyección que forman un área en
la que, el usuario puede colocarse y verse
rodeado de imágenes sintéticas proyectadas en estéreo –simulando profundidad– con la ayuda de lentes polarizados
especiales. La calidad de las imágenes
sintéticas, ha mejorado mucho con los
desarrollos del hardware especializado
para la síntesis de gráficas en 3D. Hoy en
día una PC con tarjeta de gráficos profesional, tiene poder de cómputo suficiente
para visualizar escenas animadas complejas de gran realismo. Para tener una
idea más clara, una aplicación 3D actual,
es capaz de animar una escena urbana
(parques y edificios), con alrededor de 35
mil personajes con comportamiento interactivo e independiente de alta calidad
visual, a más de 30 cuadros por segundo
(calidad de cine) para más información:
http://vrlab.epfl.ch (VRlab-EPFL Suiza).
En cuanto al audio, las tecnologías actuales permiten la reproducción de sonido
envolvente de alta calidad, y podemos
decir que en buena medida, este reto ha
sido superado.
El resto de los sentidos presentan problemas mucho más complejos de atacar,
siendo el olfato y el gusto los menos estudiados. Sin embargo, existen trabajos
de investigación relevantes que tratan
de resolver el problema de la producción
y liberación controlada de diversos tipos
de aromas. Así mismo, hay prototipos
como el “food simulator” que trata de imitar el masticar y saborear alimentos –un
tipo particular de interfase háptica– (ver
los trabajos de H. Iwata, Universidad de
Tsukuba, Japón).
Considerando el trabajo de investigación y
los productos ya existentes en el mercado,
el tacto es el tercer sentido humano más
estudiado. Las interfaces hápticas (haptic
www.softwareguru.com.mx
Las interfaces hápticas son dispositivos
electromecánicos –robots–,
que permiten simular la sensación de
tocar objetos con las manos y otras
partes del cuerpo.
interfaces) son dispositivos electromecánicos –robots–, que permiten simular la
sensación de tocar objetos con las manos y
otras partes del cuerpo, como el torso. Las
interfases hápticas más comunes son los
sistemas tipo PHANTOM. Estos dispositivos son brazos mecánicos con una especie
de pluma o estilete, la cual, al ser manipulada por el usuario, permite simular la resistencia de diferentes materiales; como si
tocáramos con una pluma, superficies con
distinta textura y resistencia: metales, rocas, esponjas, etcétera. Otros dispositivos
hápticos comerciales, son los producidos
por la compañía Immersion Co. tales como
la “Haptic Workstation”: un exoesqueleto
que produce retroalimentación de fuerza
en las muñecas y los dedos de ambas manos. Al combinar estas interfases con un
sistema de sonido envolvente y un HMD, o
un sistema CAVE, se pueden obtener entornos virtuales interactivos, muy útiles para
realizar estudios de ergonomía en cabinas
de todo tipo de vehículos; simulaciones de
intervenciones quirúrgicas; terapias de inmersión total para el tratamiento de fobias
(fobia social, aracnofobia, claustrofobia) y
juegos de video, entre otros.
Son muchos los retos de investigación
a superar, antes de tener un sistema de
Realidad Virtual en verdad convincente y
accesible al público. En su mayoría, los
prototipos actuales son desarrollados por
universidades y empresas que le apuestan
a las tecnologías emergentes. Sin embargo,
poco a poco los frutos de la investigación
se van filtrando en aplicaciones comerciales, y hoy en día tenemos efectos visuales
de gran realismo en el cine y en juegos de
video. Estos últimos son lo más cercano
al triángulo ideal de la Realidad Virtual,
pues son la integración de tres componenwww.softwareguru.com.mx
tes principales: interacción, inmersión y
tiempo real. Una de las áreas de investigación más vanguardistas, en cuanto al
componente interactivo se refiere, son
las llamadas “brain interfaces”, trabajos
pioneros encaminados a utilizar las señales eléctricas producidas por el cerebro
y capturadas mediante electrodos, como
medio de comunicación del usuario con
la computadora. Los avances actuales
permiten un control con cierta precisión
del cursor de un mouse y la ejecución de
acciones simples como abrir o cerrar una
aplicación. Quizás el fin último será llegar
a un sistema como el de “The Matrix”, en
el que la simulación interactiva se realice estimulando directamente el cerebro,
pero afortunada o desafortunadamente,
aún estamos muy lejos de ello.
La experiencia demuestra que, no se requiere de dispositivos muy complejos para
lograr una inmersión total del usuario,
y hacerle olvidar el mundo que lo rodea
en favor de una realidad alternativa. Una
pantalla de computadora o televisión con
imágenes y sonido bien diseñados, son capaces de mantener la atención del usuario
y aislarlo del mundo exterior por horas y
hasta días, como todo buen aficionado a
los videojuegos podrá constatar.
En todo caso, a los interesados en incursionar en el fascinante mundo de la
Realidad Virtual, les recomiendo documentarse en temas de gráficas por computadora, aprender a programar aplicaciones
en OpenGL y/o Direct3D (DirectX) y revisar
la abundante literatura científica sobre interacción humano-computadora, entornos
virtuales y Realidad Virtual en general.
—Por Mario Gutiérrez
ENE-FEB 2007
45
// COLUMNA
/*TIERRA LIBRE*/
SimpleJ
Regresando la Diversión al Desarrollo de Software
Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde
1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones.
Ferviente entusiasta de la aplicación social de la tecnología, a ultimas fechas esta involucrado con Organizaciones de la Sociedad Civil. Emilio estaré
encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en oemilio@tecnonirvana.org
M
éxico no escapa a la crisis mundial de déficit de profesionistas con
capacidades reales de programación. El desarrollo de software
atrae cada vez a menos jóvenes, y muchos de estos cambian de carrera
antes de graduarse. No es extraño encontrar en las universidades, generaciones de carreras orientadas al desarrollo de software, con menos de
10 alumnos. Mucho se ha hablado de las causas de esta crisis, algunos
culpan a la falta de profesionalismo y experiencia real de los maestros,
otros, al mal ejemplo que damos los que somos parte de esta industria:
nuestras jornadas de trabajo, niveles de estrés y costumbres geeks no
son muy atractivas para jóvenes de 18 años que sólo se quieren divertir.
Hace un par de años, Gerardo Horvilleur, mejor conocido como “El
Mago”, se preguntaba si parte del problema no sería la creciente
complejidad de los entornos de desarrollo de software.
Si tienes más de 35 años, aceptarás que la forma de empezar a programar actual –no importa si profesas la religión de .Net, Java o algún culto menor– no se compara en nada con las “micros”, gloriosas
máquinas como las Commodore, Apple o Tandys que llenaron nuestra
adolescencia de disfrutes computacionales. Recordarás el ansia de
esperar el siguiente Compute Gazzete o Ahoy! en el Sanborns, para
copiar los programas de BASIC, sazonados con alguna otra rutina de
ensamblador de 6510 en glorioso código hexadecimal. Este tipo de
cosas te iniciaron en la programación y gracias a ellas decidiste que
querías hacerlo por el resto de tus días.
Los chavos de hoy, no tienen estas maravillosas opciones. No conozco mucho el caso de .Net, pero en el de Java al menos, creo que bajar
Glassfish, Netbeans, y demás cosas “básicas” para programar, no
llama tanto la atención de un adolescente como jugar el videojuego
de moda y convertirse en consumidores, más que en creadores. Con
las micros, si querías un juego, casi tenías que hacerlo. Ahí es donde
Mago cree que está el problema: “los jóvenes ya no eligen estudiar
programación, simplemente porque no es tan divertido y sencillo
como lo era en esos tiempos”.
Afortunadamente, Gerardo no se quedó con las manos cruzadas, y desarrolló Simple J, una novedosa apuesta a despertar la curiosidad de
los chavos, creado con la intención muy noble de regresar la programación a su origen esencial: diversión. SimpleJ recrea un entorno de
desarrollo virtual en Java, que permite crear juegos de video y compartirlos con el mundo. Simple J simula una computadora simplificada,
para que sea más sencillo aprender a programar y evitar distracciones
en detalles irrelevantes. La decisión de enfocarse en videojuegos me
parece genial, es algo que los chavos conocen bien y les llama la atención. Sin darse cuenta, estarán aprendiendo a programar.
48
ENE-FEB 2007
No se necesita ser un experto para comenzar con SimpleJ. En el sitio
de SimpleJ (www.simplej.com) está disponible un tutorial enfocado a quienes no saben absolutamente nada de programación, y los
guía durante los primero pasos de la programación. Se comienza
con cosas sencillas, y va aumentando la complejidad poco a poco,
como si el programador fuera “pasando de nivel”, de tal forma que
hacer un juego, se convierte en sí mismo, en un juego.
Una parte muy importante de la escena de programación de hace
20 años, eran los grupos de usuarios donde los adolescentes nos
presumíamos unos a otros lo que habíamos aprendido: scrolls de
letras, música sintetizada, campos de estrellas que giraban, justo
como en la “Guerra de las Galaxias”. Este componente es esencial
en el desarrollo de buenos programadores, ya que normalmente vienen en múltiplos, y aprenden juntos, ya sea colaborando o
compitiendo. SimpleJ promueve esto, a través de un applet que
permite publicar los juegos desarrollados dentro de una página
web para presumirlos al mundo. Así que, espero pronto encontrar
muchos blogs de chavos mostrándole al mundo sus creaciones.
Adicionalmente, SimpleJ cuenta con una comunidad donde por
medio de foros, se pueden hacer preguntas, o ponerse de acuerdo con alguien más para hacer un videojuego. Mago personalmente contesta todas las dudas que puede, pero la comunidad es
principalmente soportada por alumnos de todo tipo de instituciones académicas, desde universitarios del ITAM, hasta estudiantes del bachiller Juan de Dios Bátiz del IPN. Estas son escuelas
visionarias, que han entendido el potencial de dicha herramienta
en el proceso educativo. Espero que pronto se unan muchas más
instituciones académicas a este esfuerzo.
Finalmente, una de las partes más importantes de este desarrollo –además de que es 100% mexicano–, es su modelo de
negocios. SimpleJ es software libre, licenciado con GPL y completamente abierto. Mago ha decidido concentrar sus esfuerzos
para hacer sustentable este proyecto a través de la venta de un
libro que tiene disponible para aprender a programar juegos de
video con SimpleJ.
Si tienen algún hijo o familiar adolescente y con intereses tecnológicos, no dejen pasar la oportunidad de pasar un buen rato con ellos
recordando viejos tiempos, y ayudando a que la industria de software
en México tenga los mejores programadores. Una felicitación desde
aquí, al talento y entusiasmo de Gerardo (mago@simplej.com), sin
duda, un ejemplo a seguir en el software libre mexicano.
— Emilio Osorio
www.softwareguru.com.mx
// FUNDAMENTOS
Enseñar a Programar es Mucho Más
Que Sólo Enseñar un Lenguaje de Programación
Por Consuelo Jiménez
Cuando estamos inmiscuidos en
el área de la enseñanza, muchas
veces repetimos patrones, y terminamos enseñando de la misma forma en que nos dictaban
clase nuestros maestros. Usted,
que ya ha aprendido a programar, ¿recuerda sus inicios?
Remontémonos a aquella clase de Pascal,
Cobol, Fortran, Basic o C. Como podrá recordar, lo que se hacía era básicamente
analizar a detalle los resultados, o bien,
proporcionar los datos necesarios para generarlos. Posteriormente, se realizaba el
diagrama de flujo, lo cual implicaba diseñar
la solución, y antes de pasar a construirlo, se verificaba a través de una prueba,
que eso realmente estaba correcto. Todos
aprendimos, pero, ¿será esta la manera
más efectiva de enseñar? Tomemos unos
minutos de nuestro tiempo para considerar
ciertos aspectos de la enseñanza.
Para poder analizar un problema, encontrar
rápidamente una solución y construirla, se
requiere del desarrollo de ciertas habilidades. Esto se da a través de un adecuado
proceso de enseñanza-aprendizaje. Sin embargo, los cimientos deben definirse desde
un primer contacto con algún curso de programación. Por lo general, hay un trabajo
previo con problemas razonados donde
están involucradas diferentes variables y
con aplicaciones prácticas; esto ayudará a
que ese primer encuentro se convierta en
un reto atractivo.
Para que un estudiante pueda llegar a
construir programas sin importar el lenguaje de programación, es muy importante el desarrollo de la lógica. El objetivo no
es enseñarle instrucciones como, “imprimir”, “leer”, etcétera. –Cualquiera puede
aprenderse líneas de texto y su significado–, sino que debemos enfocarnos en enseñarles cuándo y cómo usarlas, cuándo y
cómo combinarlas, incluso mejorar la solución usando otras instrucciones. El alumno
necesita entender a detalle el significado
de cada tema y complementar esto con su
práctica y aplicación, al mismo tiempo que
utiliza un lenguaje de programación.
Muchas veces, para los alumnos resulta
difícil entender significados como, ciclos,
condicionales, métodos, archivos, arreglos,
y más aún si esto se combina con la teoría
de objetos y cómo pueden ser aplicados.
Así pues, surge en el estudiante la típica
pregunta: “¿y para qué me sirve esto que
me están explicando?”
No hay que olvidar que, cuando el lenguaje
de programación es sencillo, esas instrucciones que se aprenden rápidamente se
pueden memorizar; pero quizás esto sólo
serviría cuando la persona ya tiene un camino recorrido en cuanto a la lógica de programación, de otra forma no lograremos un
aprendizaje significativo.
Uno de los puntos que debemos observar
con atención, es que siempre se debe tener
una estrategia de enseñanza donde se mantenga una relación directa entre aquello que
se está enseñando, y la vida real; de prefe-
rencia algo que los estudiantes ya hayan experimentado previamente. Por ejemplo, cuál
es el proceso que tiene una tienda de autoservicio cuando la cajera pasa el producto
por un lector de código de barras, o qué sucede cuando ellos entran a un sitio en Internet para comprar un libro, o bien, qué pasa
en un restaurante de comida rápida cuando
solicitan algún tipo de alimento. A través de
estos ejemplos, entenderán el significado y
la aplicación de aquello que se está explicando y así, despertaremos el interés por
resolver cierto tipo de problemas.
No será lo mismo si el primer bloque de
problemas a resolver que enfrenta alguien
que está aprendiendo a programar, son
series de Ulam, Fibonnaci, funciones exponenciales, logarítmicas, números primos,
o generar las raíces de una ecuación cuadrática. Como educadores, debemos despertar el interés de nuestros estudiantes;
de nosotros depende captar y conservar la
atención para lograr un nivel de aprendizaje satisfactorio. Muchas veces esto se logra cuando nos enfocamos al desarrollo de
juegos, donde ellos tengan la capacidad
de cumplir con las especificaciones que se
les indicó, y que además, puedan aplicar
su maravillosa creatividad, que puedo asegurar que nos dejará asombrados.
Como instructores, siempre hay que considerar el tipo de público que en ese momento tengamos en frente. Además, nos
ayuda mucho si mostramos los temas de
la manera más gráfica posible, sobre todo
cuando se trata de temas abstractos como
archivos, arreglos y métodos. Podemos
Ing. Ma. del Consuelo Jiménez Fernández es profesor asociado del departamento de Ciencias Computacionales en la Universidad de Monterrey. Ha recibido en más de diez ocasiones el primer lugar en el concurso de investigación vinculada a la docencia de la UDEM, y también ha recibido el premio a la calidad
docente. Sus áreas de especialidad son: Metodologías para el Desarrollo de Software, Lenguajes de Programación, y Administración de Proyectos. Actualmente, es una de las evaluadoras en las propuestas de proyectos para la incubadora en UDEM. cjimenez@udem.edu.mx
50
ENE-FEB 2007
www.softwareguru.com.mx
“El desarrollo de juegos nos ayuda a
despertar el interés de nuestros
estudiantes, para lograr así un nivel
de aprendizaje satisfactorio”.
apoyarnos en paquetes que permiten simular o animar la teoría relacionada a
estos temas, y que tienen ejemplos representativos y claros.
Otro aspecto importante que convendría
considerar en la enseñanza de la programación, es que cuando no existen bases
firmes en el área matemática, se le dificulta más al alumno captar rápidamente
operaciones tan simples como, cálculo
de porcentajes, promedios, frecuencias,
divisores, etcétera; todos ellos son conceptos que se enseñan desde la primaria,
pero que por no llevarlos a la práctica
suelen olvidarlos fácilmente. Es recomendable tener diseñado un curso en un ambiente en línea, más para estos casos, de
tal forma que la persona que requiera un
refuerzo pueda acceder a manera de autoestudio a aquellos módulos que le ayuden a repasar o entender esos conceptos.
¿No cree usted que los cursos enfocados
a desarrollar la lógica de programación,
deberían ser parte esencial de los programas académicos desde la primaria?
Si nuestro objetivo es enseñar a programar,
y vemos que existen áreas de oportunidad
para ello, sería preciso hacer un análisis al
grupo de personas que recibimos a través
de algún instrumento diagnóstico, así podremos definir estrategias y estilos adecuados de enseñanza-aprendizaje. El diseño de
nuestras estrategias nos ayudará a lograr
nuestra principal meta: “pensar de forma
lógica”, para luego programar utilizando un
lenguaje de programación.
En realidad, son muchos los elementos
que en un primer curso, los estudiantes de
programación tienen que aprender y dominar: la lógica, el lenguaje para programar
donde la sintaxis puede ser simple o compleja; los estándares, el desarrollo de la
www.softwareguru.com.mx
documentación y el entorno de desarrollo.
Si logramos que tengan estas bases bien
cimentadas, entonces de ahí, se desprenderán la correcta definición y relación que
tengamos entre los estilos de enseñanza y
aprendizaje.
Todos los que nos dedicamos a la enseñanza de la programación, fuimos inspirados
por algún buen maestro, y nuestro deber
ahora, es transmitir lo mejor posible esta
pasión por lo que hacemos, tomando lo
mejor de nuestros instructores, y añadiendo lo que hemos aprendido en el camino.
¿No le gustaría a usted, que cada uno de
sus estudiantes por lo menos, conservara
una actitud positiva ante lo aprendido? El
balón está de nuestro lado.
Algunos puntos clave para tomar
en cuenta:
•Analice a su público o grupo.
•Defina sus estrategias de enseñanza
y aprendizaje, considere los estilos.
•Apóyese de elementos gráficos,
animaciones o simulaciones.
•Tenga como apoyo su curso en línea
y retroinforme de manera constante.
•Cree un banco copioso de ejercicios,
material de contenido y exámenes.
•Sea sencillo en su explicación.
•Cambie siempre la actitud de su
grupo cuando ésta sea negativa.
•Utilice problemas que permitan a
la persona establecer una relación
con lo real.
•Practique para poder aplicar lo
aprendido.
•Y por favor, si tiene dudas al manejar un tema, pida a sus alumnos
tiempo para investigarlo, y explíquelo cuando se sienta seguro. Ellos se
lo agradecerán.
SEP-OCT 2006
43
// INFRAESTRUCTURA
Asterisk
Demasiado Bueno y Aun Así, es Cierto
Por Ariel García
Durante el año pasado tuvimos la oportunidad de publicar varios artículos relacionados con tecnologías de VoIP (voz sobre IP), ToIP (telefonía IP), protocolos y aplicaciones basados en SIP
(Session Iniciation Protocol). Toda esta tecnología se integra para poder brindarnos comunicaciones punto a punto de voz, datos y video. En esta ocasión, vamos a conjuntar todos estos
conceptos en una aplicación open source, que está siendo adoptada significativamente y merece
nuestra atención en este número.
Para aquellos que no están familiarizados
con el mundo de la telefonía y desconocen
las características de un PBX (Private Branch Exchange), por favor continúen leyendo.
Para quienes cuentan con amplia experiencia en este tema, si así lo desean, pueden
ir directamente a la explicación de Asterisk
(www.asterisk.org).
¿Qué es un PBX?
Un PBX en la jerga de TI, es lo que conocemos terrenalmente como un conmutador
de teléfonos. Sin embargo, hay que hacer la
distinción del alcance de funcionalidad que
tiene este equipo. El PBX usualmente está
compuesto por tarjetas de circuitos electrónicos, semejantes a un motherboard, que
se insertan en gabinetes. Con este hardware, además de la funcionalidad de telefonía interna, tenemos servicios de correo
de voz, transferencia de llamadas, conferencias, enrutamientos, configuraciones de
call center, identificador de llamadas, códigos de seguridad, tarificación, etcétera.
Por lo general, algunos servicios como por
ejemplo, el correo de voz, viene asociado a
una tarjeta en el gabinete.
Típicamente, dichos equipos trabajan con
troncales analógicas o digitales, con conexión directa a las centrales de fibra óptica o cobre de los proveedores telefónicos.
En algunos casos es posible trabajar con líneas directas comerciales, pero esto sucede por lo regular en implementaciones pequeñas, donde quizás no sea necesario el
uso de un PBX, dado los costos que implica tenerlo, que provienen de mantenimiento de hardware y software de las tarjetas,
52
ENE-FEB 2007
servicios de programación o capacitación
para hacerlo con personal interno, contratos de 7x24 en caso de fallas, dada la criticidad del servicio, etcétera.
La tecnología de ToIP, trajo la evolución de
estos equipos PBX en los hoy llamados call
managers. Un call manager es simplemente
un servidor que, a través de software provee
la misma funcionalidad de un PBX, sin necesidad de adquirir y mantener las costosas
tarjetas y gabinetes de los PBX.
A través de la implementación de ToIP, los
costos de operación y mantenimiento del
equipo de telefonía se reducen de forma
dramática, dado que ofrecen la misma funcionalidad a precios más bajos con mayor
redundancia, y una mejor oferta de soluciones, dado que se incorpora el video en tiempo real y los beneficios del mundo IP.
Aunque un call manager es más eficiente
en términos de costos que un PBX, también
requiere de una inversión considerable de
capital para su implementación. O cuando
menos, así lo era antes de que el open source llegara al mundo de la telefonía IP. Aquí es
donde entra Asterisk.
¿Qué es Asterisk?
Asterisk es una aplicación que tiene toda
la funcionalidad de un call manager, y por
ende, las de un PBX, corre bajo plataforma
Linux BSD o Mac OSX, y además tiene la fabulosa cualidad de ser open source.
Antes de continuar, deseo resaltar la magnitud del párrafo anterior con un ejemplo: una
solución de ToIP o de un PBX con la funcionalidad antes mencionada, significa una inversión que va desde 50 hasta 100 mil dólares,
en una implementación pequeña. No puedo
ser más explicito en el impacto que podría
tener Asterisk en nuestra empresa.
El software fue escrito originalmente por
Mark Spencer de Digium Inc. y constantemente el código se está enriquecido por la
comunidad open source de todo el mundo.
A la fecha, se continúan realizando pruebas,
desarrollo de parches y extensiones que han
impulsado fuertemente al desarrollo y adopción de dicha aplicación
El programa no requiere de hardware adicional para soportar VoIP, y existe una buena
variedad de dispositivos para que Asterisk
pueda interconectarse con equipo tanto digital como analógico. La mayor parte de estos dispositivos provienen de Digium, que es
la marca que patrocina a Asterisk. Se cuenta
con hardware para poder conectar la aplicación a troncales E1 y T1 para conexiones PRI
(Primary Rate Interface) que son las interfaces más comunes usadas por las empresas
con un alto volumen de llamadas. Para las
pequeñas y medianas empresas, se cuentan
con dispositivos para la conexión de líneas
tradicionales, que pueden usarse a través de
módulos con puertos FXS, FXO.
Asterisk cuenta con un amplio rango de protocolos TDM que le permiten el manejo y
transmisión de voz sobre interfases tradicionales, soporta la señalización estándar de los
sistemas telefónicos comerciales, tanto americanos como europeos, lo cual le permite co-
www.softwareguru.com.mx
“Asterisk es una aplicación que tiene toda la
funcionalidad de un call manager, y además
tiene la fabulosa cualidad de ser open source”.
nectarse a los sistemas de nueva generación
o, a una infraestructura existente.
Arquitectura
Asterisk está diseñado para brindar una
alta flexibilidad en su funcionalidad. Existen APIs que se diseñaron específicamente, como el núcleo central de un PBX. Este
núcleo es el encargado de administrar las
interconexiones internas, abstrayéndolo
de los protocolos específicos, codecs, e
interfaces de hardware de las aplicaciones
de telefonía.
El núcleo de Asterisk administra las siguientes funciones de forma interna:
•PBX Switching. Esta unidad de switching
conecta de forma transparente las llamadas
que llegan desde cualquier interfase, ya sea
de hardware o software. Es el corazón de Asterisk, y contiene el núcleo de la funcionalidad de PBX conectando las llamadas entre
los usuarios y automatizando tareas.
•Lanzador de Aplicaciones. Lanza las aplicaciones para los servicios como correo de voz, directorio, grabación y reproducción de llamadas.
•Traductor de Codecs. Utiliza los módulos
de codecs para la codificación y decodificación de los formatos de audio estándar de
la industria. Se cuentan con los codecs más
comunes para satisfacer las distintas necesidades que pueden surgir, para encontrar el
balance entre calidad de audio y ancho de
banda de nuestra implementación.
•Scheduler and I/O Manager. Administra
las tareas programadas de bajo nivel y es
el encargado del manejo del sistema, para
el desempeño óptimo bajo cualquier condición de carga.
www.softwareguru.com.mx
Módulos APIs
A través del uso de este sistema de módulos,
el núcleo de Asterisk se despreocupa de detalles como de dónde proviene una llamada,
qué codec utiliza, etcétera.
•API de Canal. El API de canal administra
el tipo de conexión de la llamada que está
llegando al sistema. Esta puede ser una conexión VoIP, ISDN, PRI u otra tecnología. Los
módulos dinámicos se cargan para manejar
las capas de bajo nivel para la detección y
manejo de estas conexiones.
•API de Aplicación. El API de aplicación
permite que se corran varios módulos de
tareas para ejecutar distintas funciones,
como conferencias, directorio, correo de
voz, y cualquier otra tarea que un sistema
PBX podría desempeñar ahora o en el futuro. Estos módulos pueden administrarse
por separado.
•API Traductor de Codec. Este API tiene la
función de cargar los módulos de codecs
para soportar los distintos formatos para
la codificación y decodificación del audio.
Estos pueden ser: GSM, Mu-Law, A-law, e
incluso MP3.
•API de Formato de Archivos. Administra
la lectura y escritura de varios formatos
para el almacenamiento de datos en el sistema de archivos.
Gracias a este manejo de módulos, es posible integrar los sistemas de hardware actuales de telefonía o las nuevas tecnologías de
voz que puedan emerger.
La implementación y puesta a punto de esta
aplicación, podría parecer complicada, pero
la realidad es distinta. Existen varias guías
para llevar acabo una implementación completa de Asterisk, y adquiriendo el hardware
adecuado, se puede implementar como el
equipo de telefonía de cualquier oficina, sin
importar su tamaño o complejidad.
Aunque usted no lo crea, hoy en día existen
varias empresas mexicanas que ya están
utilizando este software como su sistema
de telefonía. Lejos de pensar que su operación se ve comprometida al trabajar con
una aplicación open soruce, resulta que su
comunicación se ve incrementada, al poder
contar con los beneficios de la telefonía IP a
un costo bajo. Esto, sumado con el soporte
y contribución continua de la comunidad del
open source, debería llevar a cuestionarnos
si realmente deseamos continuar operando
con nuestro PBX actual o realizar inversiones fuertes para implementar una solución
de telefonía IP propietaria.
Como siempre, la decisión es del negocio,
y la única forma de comprobar los beneficios de tal aplicación es, evaluándola y
presentando los resultados con un análisis de riesgos. Por ello, los invito a que
instalen Asterisk en su ambiente de desarrollo y vean si cumple las expectativas de
su negocio.
Referencias
• www.asterisk.org
• www.digium.com/en/index.php
• www.voip-info.org/wiki-Asterisk+
installation+tips
ENE-FEB 2007
53
////TECNOLOGÍA
TECNOLOGÍA
/* GADGETS */
D-Link
Wireless Presentation Gateway
Hacer presentaciones desde diversas computadoras, proyectores y monitores sin utilizar cables, es el objetivo primordial del Wireless Presentation Gateway DPG-2100 de D-Link. Este pequeño dispositivo hace
que la comunicación entre equipos sea posible, de tal manera que, si en la sala de juntas se proyectan
varias diapositivas desde diferentes equipos, no será necesario estar conectando cada equipo. Está
basado en el estándar inalámbrico 802.11g, que lo hace compatible con la mayoría de los dispositivos inalámbricos, incluyendo los antiguos 802.11b. Además es capaz de manejar cualquier
formato de archivo, en silencio o con audio. Es posible también acceder a Internet para integrar
en las presentaciones contenido directo de la Web gracias al puerto Ethernet.
Pyramat
s2000 Sound Rocker
Widow PC
SLI Laptop
WidowPC es una compañía norteamericana por Internet, dedicada a la
fabricación de computadoras pensadas en la experiencia de juego y en
los videojugadores. Ellos mismos se denominan, el “Porsche” de las
computadoras; y presentan la nueva generación de desempeño móvil
para juegos de video. Es una de las más rápidas e incluye uno de los
frame rates más veloces en cuanto a plataformas móviles se refiere;
además soporta hasta tres monitores al mismo tiempo y cuenta con tarjeta de video dual NVIDIA 7950 GTX con 1028MB. Entre algunas otras de
sus características destacan: memoria DDR3, procesador AMD Turion
64bit Dual Core, monitor LCD con ClearView de 19” con resolución de
1680X1050, cinco puertos USB 2.0, uno para teclado y video externo,
cuatro para audio, uno PMCIA y S-Video, entre otros. La tecnología integrada en esta computadora portátil, también ofrece alta definición para
explotar al máximo el poder gráfico de los videojuegos, así como para
la reproducción de contenidos digitales.
Acción en directo de los videojuegos, películas o música, es la
mejor forma de definir al s200 Sound Rocker, un sillón equipado con subwoofers PowersubTM de 5.5” que envía intensas vibraciones y sonido nítido, de tal manera que es posible
apreciar desde un disparo hasta la respiración de un personaje. Cuenta a su vez, con altavoces iluminados ARXTM de alto
desempeño y largo alcance que aceleran la experiencia de juego. Está fabricado en tela Poly-strech que además de brindar
confort durante largas horas, es porosa, permitiendo así, la ventilación entre el cuerpo
y el sillón. En los costados se encuentran
entradas para audífonos, controles de
volumen y bajos, así como puertos
RCA multi player. Es compatible con
casi todas las consolas de videojuegos, televisores, reproductores de
video y MP3.
Space Invaders 5-en-1 Plug & Play
Para recordar aquellos tiempos en que jugar videojuegos no requería de pulsar seis botones y
mover el joystick a la vez, y las palabras “combo”, juego en línea, inmersión o gráficos en alta
definición ni siquiera figuraban en el vocabulario, existe esta pequeña curiosidad retro, que de
seguro a muchos les provocará un nudo en la garganta y, a otros, quizá hasta derramar un par
de lágrimas. Tan simple como es, rayando en lo ridículamente hipnótico, Space Invaders se ha
convertido en un icono cultural, y para celebrar su 25 aniversario, qué mejor que una unidad plug
& play con cinco juegos: Space Invaders, Phoenix, Qix, Lunar Rescue y Colony 7. Todo al más puro
estilo arcadia. Se conecta directamente al televisor vía cables AV, y su tamaño compacto, permite
llevarlo a cualquier parte para aprovechar las televisiones que se atraviesen por el camino.
54
ENE-FEB 2007
www.softwareguru.com.mx
INDEX
DIRECTORIO
Anunciante
Páginas
Sitio
AMCIS
Avantare
ExpoComm
e-Quallity
Gartner
Itera
LinuxWorld
Microsoft
Milestone Consulting
Roca Sistemas
SafeNet
Select / Tendencias
Tiburón Software
55
51
45
43
F3
07
49
F2-01, 23
F4
11
13
19
47
www.amcis.org.mx
www.avantare.com
www.expocomm.com.mx
www.e-quallity.net
www.gartner.com/mx/appint
www.itera.com.mx
www.linuxworldexpo.com
www.microsoft.com/mexico
www.milestone.com.mx
www.rocasistemas.com.mx
www.safenet-inc.com
www.select.com.mx
www.tiburonsoft.com
TENEMOS UN ESPACIO
RESERVADO PARA TI
Si deseas anunciarte contáctanos
en el (55) 5239 5502 o en ventas@
softwareguru.com.mx
www.softwareguru.com.mx
ENE-FEB 2007
55
// REFLEXIONES
Programas Correctos
Parte 3. Pensar No es Opcional
Por Marco Antonio Dorantes
Software durable implica diseño continuo
Identificar el verdadero problema a resolver y diseñar el programa atinado, representa el mayor avance en un proyecto de desarrollo, la parte
restante se trata de hacer de manera correcta dicho programa. El problema identificado típicamente continúa co-evolucionando junto con
su solución[1], en otras palabras, la solución tecnológica y el problema
de negocio se influencian mutuamente. Una noción común dice que, el
mayor costo y esfuerzo en la aplicación de software para resolver problemas de negocio, sucede en el desarrollo del mismo, y una vez que
está en producción, es sólo mantenimiento y operación, por lo que las
mentes brillantes sólo se requieren en el desarrollo; en muchos casos
esto sucede al revés, la necesidad de un diseño flexible y adaptable[2]
a situaciones poco previsibles —sin importar cuánto esfuerzo de análisis se haya hecho— ocurre en la etapa de mantenimiento, donde el
negocio de verdad necesita dicha flexibilidad, por lo que en tales casos,
más vale transferir una parte significativa del costo de desarrollo a dicha
etapa de mantenimiento. En otras palabras, la actividad de diseñar[3] se
requiere a lo largo de todo el ciclo de vida del software.
Best practices
Para algunos está claro que, cuando se presenta un best practice, en realidad se está hablando de conocimiento tácito, es decir, conocimiento que
sólo existe en la cabeza de las personas y que llegó ahí por su experiencia
personal, o por observar de primera mano a otro profesional en plana acción; dicho conocimiento es de difícil acceso, y por lo tanto muy valioso. Lo
que no está claro para muchos, es que dicho conocimiento tiene contexto,
y su transmisión efectiva requiere una interacción extensa así como una
amplia confianza entra las personas, y por ende, no es algo que se transmita de forma escrita —por definición deja de ser conocimiento tácito. El
riesgo de tomar como best practice el conocimiento obtenido fácilmente
en publicaciones o seminarios reside en la frase: “no tienes que pensar,
sólo aplica el best practice”—, pues impide lo que precisamente es necesario hacer para adquirir el conocimiento tácito: pensar en contexto.
Adaptación es clave, el mapa no es el terreno
Una vez que tienes experiencia con un buen número de métodos de diseño, sigue el reto de saber cómo y cuándo adaptar un método a una
situación en particular. ¿Qué mantener o qué dejar de lado? ¿Qué agregar? Una manera es ignorar esta complejidad esperando que las cosas
simplemente pasen, pero en tal caso, sería mejor dedicarnos a otra
cosa y dejar esto en manos de alguien que le importe. El panorama de
aplicación de software para resolver problemas de negocio, se observa
cada vez más demandante, y la necesidad de métodos dinámicos que
se adapten al vuelo será cada vez más necesaria. Un balance adecuado de propiedades como las que presenta Alistair Cockburn[4] (Entrega frecuente, comunicación efectiva, mejora reflexiva, etcétera.) puede
ayudar para confeccionar el método de diseño para tu próximo proyecto
de desarrollo. Otra opción es esperar que alguna figura autoritaria y no
practicante, te diga cómo tienes que programar, o simplemente seguir
con la inercia de los proyectos en crisis, donde los integrantes ya saben
que el proyecto va a fracasar y que sólo hay que hacer como que trabajas, aceptando que “la realidad es así”.
Conclusiones
David West nos presenta algo que llama curiosidades, en la introducción de su libro[5] y que reflejan ciertos comportamientos muy diseminados en nuestra industria, que parecieran ser muy sólidos y muy
bien definidos, pero ante la luz de un poco de investigación, resultan
ser sólo malos entendidos. Por ejemplo, ante la pregunta: ¿Cuál es
el siguiente paso después de orientación a objetos?, Martin Fowler
respondió que se necesita entender realmente el paradigma de objetos como primer paso, antes de pensar en lo siguiente, o cómo dice
Anders Hejlsberg[6]: “orientación a objetos antes era como religión y
que apenas ahora está empezando a ser realmente útil para cada vez
más personas”. La respuesta de David Parnas[7] tiene mucho sentido,
cuando responde a la pregunta: ¿Cuáles son las ideas más prometedoras de ingeniería de software en el horizonte?, diciendo que las
ideas más prometedoras no están en el horizonte, sino aquí mismo
y desde ya hace tiempo, solamente que no han sido usadas como se
debe. Ha sido un placer escribir este artículo en sus tres partes. Sus
comentarios son bienvenidos: mdorante@hotmail.com
Referencias
1. Wicked Problems, Righteous Solutions
blogs.msdn.com/marcod/archive/2004/06/12/154131.aspx
2. Unconscious Design Defined
blogs.msdn.com/marcod/archive/2005/04/03/
UnconsciousDesignDefined.aspx
3. The Engineering in Software Development – Trails of Design Mastery
blogs.msdn.com/marcod/archive/2004/06/23/163358.aspx
4. Just-In-Time Methodology Construction
alistair.cockburn.us/crystal/articles/jmc/
justintimemethodologyconstruction.html
5. David West. Object Thinking.
6. Life and Times of Anders Hejlsberg
channel9.msdn.com/Showpost.aspx?postid=159952
7. ACM Special Interest Group on Software Engineering (SIGSOFT) Software Engineering Notes. ACM Fellow Profile: David Lorge Parnas
www.sigsoft.org/SEN/parnas.html
Marco Antonio Dorantes Martínez es un consultor en el diseño y formulación de software desde 1987, oficio que lo llevó a la investigación aplicada en el
campo de los métodos sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto
en foros técnicos como en software, por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com. Publica un diario
electrónico en blogs.msdn.com/marcod
56
ENE-FEB 2007
www.softwareguru.com.mx
Año 03 No. 01
www.softwareguru.com.mx
SOFTWARE GURU CONOCIMIENTO EN PRÁCTICA
Enero-Febrero 2007