SG13 (Enero-Febrero 2007)

Software Guru CONOCIMIENTO EN PRÁCTICA

www

.sof

twar

egur

u.co

m.m

x

Año 03 No.01 • Enero-Febrero 2007 • www.softwareguru.com.mx

[ Novedades ]WCFNoticias • Eventos • Fundamentos • UML • Infraestructura • Reflexiones

• Análisis de ROI

• POJOs y Frameworks Ligeros

• Evaluación de Arquitecturas

Desarrollo de

Videojuegos

[ ENTREVISTAS ]Desde CreanimaxBill PlymptonRené CastilloErnesto Gálvez

ESPECIALDesarrollo de Software en Universidades

México, $65.00

¿Por dónde comenzar?

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

Coordinación EditorialSusana Tamayo

Asesoría EditorialEdgardo Domínguez

Arte y DiseñoDafne 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.

ColaboradoresAriel 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 Portadawww.tollhaus.com.mx

Ventas Claudia Perea

Marketing Natalia Sánchez

Circulación y Subscripciones Daniel Velázquez

[email protected]

+52 55 5239 5502

SG Software Guru es una publicación bimestral ed-itada 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 necesari-amente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-2004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Reg-istro Postal: PP15-5106. Se imprimió en diciembre de 2006 en Litográfica Roma. Distribuido por Rrecca Com-ercializadora y Sepomex.

directorio

Quizá muchos de ustedes se vean sor-prendidos 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 perspec-tiva no de usuarios, sino de creadores. Por otra parte, escoger este tema nos permi-tió tomarnos algunas libertades no sólo en el diseño, sino también en los conte-nidos. 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 en-contrará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 desarro-llar 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 univer-sidades. Consideramos que estos centros son vitales para generar los profesionis-tas de software que necesitamos. Com-

plementamos todo esto con las opiniones de nuestros columnistas, que ya son par-te fundamental del contenido; echaremos un vistazo por Windows Communication Foundation, que es uno de los pilares de Windows Vista; veremos cómo determi-nar 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 ma-yorí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).

Editorial

// CONTENIDO

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

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba y Ana Váquez

Mejora Continua 10por Luis Cuellar

Tendencias en Software 44por Luis Daniel Soto

Cátedra y Más 46por Mario Gutiérrez

Tierra Libre 48por Emilio Osorio

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.

contenido ene-feb 2007

// CONTENIDO

En Cada Número

NOTICIAS y EVENTOS 04CLÚSTERS 06UML 42FUNDAMENTOS 50INFRAESTRUCTURA 52REFLEXIONES 56

Productos

LO QUE VIENE 12IBM Rational SDP, Apache Axis 2, JBoss Seam y Unity3D

NOVEDADES 14Windows Communication Foundation

Especial

Centros de Desarrollo de Software en Universidades 16

Prácticas

MEJORA DE PROCESOS 36Análisis de ROILa 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 38POJOs y Frameworks LigerosIxcoatl Pérez nos muestra cómo combinar POJOs con frameworks como Spring e Hibernate, para desarrollar aplicaciones empresariales.

ARQUITECTURA 40Evaluación de Arquitectura de SoftwareOmar Gómez nos enseña a evaluar arquitecturas para determinar si cumplen con los requerimientos.

EntrevistaBill Plympton, René Castillo, Ernesto Gálvez20

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

24


Lanzamiento de Windows Vista

El pasado 29 de noviembre se realizó la presentación de Win-dows 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.

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 partici-pantes de todo el mundo, se llevaron a cabo más de 1,400 sesiones en torno a las principales aplicaciones de Ora-cle, 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.

// NOTICIAS

Toman Protesta los Miembros de la Mesa Directiva de la ANIEI

El pasado 12 de diciembre, en las instalaciones de la Rec-torí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 en-tre 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.

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

13 al 16 Febrero 2007CONSOL 2007Congreso Nacional de Software LibreFacultad de Ingeniería UNAM, Cd. de MéxicoInfo: www.consol.org.mxEmail: [email protected]

27 Febrero 2007Tendencias 2007SelectCentro Banamex, Cd. de MéxicoInfo: www.select.com.mx Tel: (55) 5256 1426Email: [email protected]

27 Febrero al 2 Marzo 2007Linux World Conference & ExpoExpo Comm 2007, Von Conference & Expo, Expo Móvil Centro Banamex, Cd. de MéxicoInfo: www.expocomm.com.mx Tel: (55) 1087-1650 ext. 1160Email: [email protected]

22 al 24 Marzo 2007III Simposio Metodología Seis SigmaCentro de Investigación en Matemáticas (CIMAT) Hotel Real de Minas, Guanajuato, Gto.Info: www.cimat.mx/Sitios/seissigma Email: [email protected]

Softtek, Única Empresa Privada que Opera dos Centros CMMI5 y uno CMM5 en América LatinaSofttek 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 soft-ware 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 Recau-dació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 equi-po 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 ob-tener 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 man-tener en operación más de 50 aplicaciones que soportan los procesos de incorporación y recaudación de todo el Institu-to, se pusieron como meta el hacer crecer una organización de clase mundial.

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 inver-siones 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 progra-mació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.

// EVENTOS

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 servi-cios 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 es-tado de Morelos. Estas forman parte de la Asociación de la Industria del Software en Morelos, que es la AISAC. Teraloc surge con el obje-tivo 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, Giga-bytes 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.

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 for-mación de gente, generando confianza a través de cursos de ca-pacitació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.

Pero las habilidades del personal no son todo. También se necesitan pro-cesos maduros y repetibles, y clientes interesados en adquirir tus produc-tos 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, dan-do como resultado que la oferta de valor de Teraloc sea más competi-tiva 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 metaTeraloc tiene bien definido cual es su mercado meta, el cual está compuesto de:•Empresas medianas y grandes que necesiten redefinir y/o automa-tizar sus procesos internos y externos a través de diversas tecno-logí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 logrosEntre 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.


/* CLÚSTERS */

TeralocDe Morelos para Todo MéxicoPor 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.

// REPORTAJE


En 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, plati-camos sobre la primera participación de la Delegación en la ciudad de Bangkok, donde nuestra norma mexicana basada en MoPro-Soft y EvalProSoft fue presentada y se selec-cionó, de entre varios documentos similares de otros países como base para los trabajos del grupo. En esa primera reunión, la Delega-ció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 inte-grada por Francisco López Lira, Ana Vázquez y yo, que somos miembros de la AMCIS y hemos trabajado en diversos proyectos rela-cionados con la norma. El objetivo fue incluir en los productos del WG24 la mayor canti-dad 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, Es-tados Unidos, Tailandia, Sudáfrica y Austra-lia, siendo ésta, la primera participación de los dos últimos.

El objetivo de dicha sesión fue definir el con-junto de actividades que las VSE implemen-tarán en su primer ciclo de mejora, y que en adelante, llamaremos “primer perfil”. Las ac-tividades 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 pro-cesos que integrarán el primer perfil.

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 gru-pos para analizar las actividades de cada uno de estos procesos, y seleccionar las que consideraban indispensables para el primer perfil. Nuestro papel consistió principalmen-te, en explicarles el “porqué” de algunos ele-mentos 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 Espe-cí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 es-cogieron las actividades de Especificación de Requerimientos, Análisis y Diseño, Construc-ción, Integración y Pruebas, con sus respecti-vas verificaciones y validaciones.

En adición, se incluyeron algunas activida-des para controlar los cambios y las ver-siones 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 in-dustria. Lo que sí pretende aportar el WG24,

son herramientas de diversos tipos para ayudar en la implementación de estas prác-ticas en las VSE, como son la secuencia de actividades, roles, descripciones de produc-tos, formatos, etcétera.

La próxima reunión será en mayo de 2007, en San Petersburgo. Para entonces se espe-ra que el delegado de Finlandia, Timo Varkoi, experto en el estándar ISO/IEC 12207, ten-ga el mapeo de MoProSoft hacia esa norma, que este primer perfil haya sido revisado o probado en los países de origen de los dele-gados, y que los documentos del grupo ten-gan 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 ge-nerar una secuencia de 3 a 4 perfiles, cada vez más amplios, no necesariamente corres-pondientes 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 In-formación para su beneficio.

Otra vez nos da envidia, ¿verdad? Mejor aprendamos de otros y agreguemos nues-tros granitos de arena. Porque lo que pode-mos hacer, también puede servir de ejem-plo a los demás.

— Hanna Oktaba y Ana Vázquez

Lo Que Pasó en LuxemburgoAvances 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, Tecnolo-gí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.

// COLUMNA /*TEJIENDO NUESTRA RED*/// COLUMNA


Ú ltimamente he tenido que viajar a diferentes lugares, lo que me ha dado algo de tiempo para leer. En la Harvard Business Re-

view de noviembre 2006, encontré un artículo sumamente interesan-te, 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 gran-des variaciones en el proceso, y hace mucho más complicada la opera-ció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 fi-nalmente 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 pro-cesos 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 personasTal vez lo que más me llamó la atención del artículo, fueron las implica-ciones que esta diferencia entre productos y servicios tiene en el área de sistemas. Todos sabemos que desarrollar sistemas es, tanto un produc-to (el sistema en cuestión) como un servicio (análisis de la problemáti-ca, 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ó suma-mente 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 pen-samiento: 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

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 mue-ve 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 tanVeamos 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 predeterminado2) Reducir el costo de manera constante al capitalizar el conocimien-to, 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 consi-dera 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 conocimien-to necesario, aunque cueste más caro. Sin importar cuáles son los re-quisitos, 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 cuentasBajo 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 clien-tes siempre contentos, sin importar lo que estén buscando.

—Luis Cuellar

Procesos y VariabilidadLa Diferencia entre Productos y Servicios

/*MEJORA CONTINUA*/// COLUMNA

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.

eDeveloper V10 de Magic Software Enterprises es el nuevo paso evoluti-vo 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.

Muchos 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 eDe-veloper a través de toda su historia.

Estos conceptos incluyen: repositorios para abarcar las des-cripciones de una aplicación completa, Reglas de Negocio para obtener los mayores niveles de abstracción, Desarrollo Decla-rativo 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 au-tó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 de-sarrolladas con eDeveloper sean rápidamente escalables, facilitan-do 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 co-nexiones 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 eDevelo-per, 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 intero-perabilidad 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 dis-minuya la velocidad de desarrollo.

Lo que nos permite ser compatibles con las Arquitecturas Orien-tadas 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, con-junta 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, po-drán tener la mejor presentación, siendo compatibles con los es-tilos 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 aplica-ciones 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

// PUBLIREPORTAJE

Apache Axis2Web Services Open Source de 3ra Generación

Axis2 es un motor de web services desarrollado por la Apache Soft-ware 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 ge-neració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 genera-ció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


Rational Software Delivery Platform 7.0Desarrollo Global de Aplicaciones SOA

IBM lanzó la versión 7 de su línea de herramientas de desarrollo de software, Ra-tional Software Delivery Platform (SDP) que es un conjunto de herramientas para desarrollar software, basadas en Eclipse, y complementada con procesos que en-globan 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 requeri-mientos 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

JBoss Seam 1.1Aplicaciones Web con Funcionalidad Compleja, pero Desarrollo Sencillo

Seam es el framework de JBoss para desarrollar aplica-ciones 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 ba-sadas 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 eli-mina 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 com-ponentes 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

Unity 1.6Desarrollo 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 desarrollado-res de juegos, y recibió el segundo lugar en la catego-rí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 herramien-ta. Quedarás impresionado por el detalle y velocidad de las gráficas que se ejecutan en tu navegador.

/* LO QUE VIENE*/// PRODUCTOS

Vivimos en un mundo cada día más conectado. Las organizacio-nes se han enrolado en la era de Internet, ofreciendo servicios

electrónicos que les permiten integrar o exponer su información in-terna, hacia clientes u otros procesos empresariales externos. Esta conectividad, combinada con la necesidad de integrar sistemas he-terogéneos, ha influenciado el establecimiento de un nuevo para-digma: 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 posibilida-des 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 in-tegrar sistemas, aunque éstos utilicen diferentes plataformas operati-vas. 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 cor-tos 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 servi-cios 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 FoundationEs 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 ante-riores 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 siste-mas distribuidos bajo plataforma Microsoft, hablamos de .NET Enterpri-se Services (COM+), MSMQ, .NET Framework Remoting, Web Service En-hancement (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 sopor-ten 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ñoWCF hace posible lo anterior gracias a los siguientes objetivos de diseño:•Soportar internamente un gran conjunto de protocolos para servi-cios web: las tecnologías actuales para web services proveen sopor-te para un tipo de interoperabilidad muy básica entre aplicaciones. Por ejemplo, estas tecnologías carecen de la habilidad de lograr in-teroperabilidad garantizando una seguridad integral y comunicación confiable. WCF soporta interoperabilidad segura, confiable y transac-cional, 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 WCFLa 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 pro-pia 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 aplicacio-nes cliente o con otros consumidores de nuestros servicios, ya que

Windows Communication FoundationUn Framework para Desarrollar Aplicaciones DistribuidasPor Haarón González

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).


/* NOVEDADES*/// PRODUCTOS


/* NOVEDADES*/

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 trans-porte (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é estructu-ras (datos) y operaciones (métodos) se pueden intercambiar durante una conversación entre servicios.

Un ejemplo sencillo

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 califi-car 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); }}

Una vez definido nuestro contrato, lo implementamos en la clase CalculoService, que es donde realmente existirá la funcionalidad de nuestro servicio.


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 po-demos hacer que cualquier aplicación pueda convertirse en un hués-ped de algún servicio, eliminando dependencias a otros productos del servidor. Por ejemplo, el siguiente código hace que nuestra apli-cación de consola sea un huésped de servicio.


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 es-pecificado la dirección (address) donde reside nuestro servicio en la red, el canal (binding) utilizado para intercambiar mensajes (BasicHttpBin-ding) 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ónWCF se puede usar para conectar sistemas que se ejecutan en con-textos locales, Intranet, Extranet e Internet. WCF provee un marco de referencia unificado y con capacidades avanzadas para el desarrollo de aplicaciones distribuidas.

Figura 1. Flujo de un servicio con WCF.


// ESPECIAL

¿El egresado de una carrera de Ingeniería de Software, está realmente preparado

para afrontar como se debe, los retos que demanda el mercado laboral?, lamentable-mente, en la mayoría de los casos, el alum-no 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 necesa-rio dominar algún lenguaje de programación orientado a objetos –pensando que es la úni-ca 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 memo-ria el modelo de cascada o espiral, u otro, sa-ber de la existencia de UML, pero no saberla aplicar; conocer y desarrollar en una sola base de datos, y en general, conceptos bási-cos 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 es-té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 (orien-tado 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 len-guajes) 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, MyS-QL, Informix, PostgreSQL, etcétera).

•La ya tan mencionada Web 2.0.

•Modelos arquitectónicos como MVC (Model View Con-troller), o SOA (Service Oriented Architecture).

•Poder entender adecuadamente y llevar a la práctica (en escala) conceptos de ingeniería de software, pasan-do 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, ad-ministrable, entre otros.

•Facilidad de adaptarse a cambios, tiempos y tecnologías.

¿Centros de Desarrollode Software en las Universidades?

Una Realidad aún sin ExplotarPor Joaquín Arellano

Joaquín Alonso Arellano Ramírez, se ha desempeñado como desarrollador, implementador y administrador de sistemas, coautor del artículo “Confiabilidad del Soft-ware: 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.


¿Centros de Desarrollode Software en las Universidades?

¿Dónde puede el alumno aprender esto?, dónde más, sino en su misma universidad, ¿de qué forma?, promo-viendo centros de desarrollo de software en los que el alumno pueda, de forma voluntaria, involucrarse y pro-fundizar en conceptos como los antes mencionados, mientras desarrolla proyectos reales, que no necesaria-mente 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 Ingenie-rí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:

•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 em-presas, 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 ofre-cen, como Flex 2 de Adobe (recién liberado) y las ver-siones constantes de los productos de Sun, IBM, Zend, ActiveGrid, etcétera.

•Convenios como los que algunas universidades tie-nen 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.

•Acercamiento con empresas de software que aplican CMM/CMMI, ITIL, PSP, TSP; conceptos de ingeniería de software y herramientas tecnológicas actuales que re-quieren 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 tecno-logías ya mencionados, y de muchos más, que quizá se me puedan estar pasando.•Acercamiento con gobiernos Estatal y Federal, para in-centivar dichos centros en la educación pública y privada.

Estructura propuestaProfundizando un poco en cómo se podrían estructurar di-chos centros, considero tres bloques esenciales, como se muestra en la siguiente figura.

Estructura en 3 Bloques Esenciales.

“El egresado necesita tener un background más amplio de lo que los planes de estudios

actuales ofrecen”.


// ESPECIAL

Zona operativa y de controlLa integrarían personas que formen parte de las acade-mias 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 de-sarrollo 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 SWEstaría conformada 100% por los alumnos que hayan obtenido un nivel de conocimientos adecuado, que les permita explotarlo en dichos proyectos. El nivel de cono-cimiento puede ser delimitado mediante varias formas: de algún semestre en adelante, número de materias cur-sadas, conocimientos técnicos, promedios, etcétera.

Zona de soporte y apoyo:En esta zona se encontrarían profesionistas de IT exter-nos, empresas públicas y privadas, gobierno y demás personas e instituciones que puedan aportar sus cono-cimientos para el beneficio de los centros. Las empresas públicas, privadas y gobierno serían los “patrocinado-res” de proyectos específicos, aportando SW licencia-do 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 varia-da, 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 en-tre otras cosas, alentar a los estudiantes a seguir cre-ciendo 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í pre-sentados, dependerá en gran parte, de su propia inquie-tud, 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

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, insta-laciones, tiempo, esfuerzo y personal, pero no tienen que ser necesariamente exigentes, es posible hacer uso de mucho de lo que las instalaciones de las uni-versidades 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 alum-nos 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 in-volucradas en proyectos de este tipo. Las formas de cris-talizar los centros son variadas. Se propone una estruc-tura 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 con-migo: que si México quiere competir internacionalmente como país, en el desarrollo de software de calidad, es ne-cesario 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.

NOTAEl propósito de mencionar el software y las em-presas 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 comuni-dad los productos, tecnologías y metodologías que ofrecen y promueven bajo diferentes esque-mas de licenciamiento.

“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”.


// ENTREVISTA

Bill

Plym

pton

El pasado mes de octubre en la ciudad de Guadalajara, Jalisco, se realizó el primer Festival Nacional de Animación y Videojue-gos, Creanimax 2006, donde se dieron lugar profesionistas y entusiastas del medio, para compartir conocimientos, secre-tos, y conocer un poco más de cerca lo que se está haciendo tanto en México como en otras partes del mundo.

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.

“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 con-vertirse 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 diver-tido, 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 fil-me 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 cons-tantemente 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 ne-cesite mucho dinero, no creo que se necesite mucha tecnolo-gía, sólo contar historias interesantes y entretenidas.

¿Ves futuro en los animadores mexicanos?Bueno, René Castillo es una gran estrella, es una gran cele-bridad. Lo conocí hace alrededor de cinco años en un fes-tival, 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 PLYMPTONNació 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 “Micro-toons” 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


RENÉ CASTILLOEs egresado de la carrera de Comunicación por el ITESO en Guadalajara, Jalisco. Su afi-ción desde pequeño por modelar personajes de plastilina lo llevó a encontrar en la ani-mació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

¿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 per-sonas 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 ma-quetas, iluminar, todo lleva consigo una preproducción bastante larga.

¿Qué tipo de software utilizas?La verdad es que utilizo softwares diferentes, pero para stop mo-tion, 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 anima-ción. Todas son herramientas muy buenas que permiten previsua-lizar 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 im-portantes 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 anima-dores. 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 es-cuelas, 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 mag-ní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 di-ficulte 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


¿Cómo surge Immersion Games?Hace cuatro años decidimos fundar nuestra compañía,

queríamos hacer videojuegos, pero no teníamos pre-supuesto para hacerlo ni siquiera para pagar el pri-mer mes de nuestros salarios, así que decidimos ex-plorar otras áreas relacionadas también con gráficos

3D, pero orientadas hacia desarrollo de soluciones de seguridad, de arquitectura, etcétera. Así nos mantuvi-mos 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.

¿Cómo captaron la atención de inversionistas? Porque desarrollar un videojuego requiere capital y proyec-

ción para ser exitoso. Se dio la oportunidad de que unos inversionistas me-tieran 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ácilmen-te. Mientras eso sucedía, contactamos con una compañía norteamericana, porque pensábamos que con aquel dine-ro, 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 se-ría de un mes para otro, pero por suerte, al leer las propues-tas 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 vi-deojuegos, 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 fi-nanciara, 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 con-ferencias 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 desafortunada-mente, 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 vi-sió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 videojue-gos, pero sabes que a tu nivel le falta, y terminas encontrán-dote 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 indus-tria en Latinoamérica. Hemos encontrado en NAGA (Na-tional 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 diri-gir la mirada hacia nosotros; que nos vean como un mer-cado interesante.

ERNESTO GÁLVEZNacido, 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 pro-ducció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.comEr

nest

o Gá

lvez

// ENTREVISTA


Desarrollo de

Videojuegos¿Por Dónde Empezar?

Por Joel Villagrana

Desde niño siempre me han gustado los videojuegos, y siempre había

tenido curiosidad de cómo es el proceso para crear uno. Finalmente,

hace 6 años, decidí que era tiempo de aprender a desarrollarlos; después de

idealizar por unos minutos un videojuego perfecto como primer proyecto,

tuve que volver a la realidad: “¿Y por dónde empiezo?” Entonces comencé

a buscar información en Internet, que en aquel entonces era muy escasa;

parecía que mis dudas aumentaban en lugar de disminuir: “¿Qué lenguaje

de programación se utiliza?, ¿se usa algún compilador en especial?, ¿qué

estructura tiene un juego?, ¿qué necesito aprender?, ¿cómo se hacen los jue-

gos para las consolas?” Eran algunas de las muchas preguntas que tenía.


Muy rápido me di cuenta de 3 cosas: la pri-mera es que no existía algún libro ni tutorial que enseñe todo lo que se necesita saber; la segunda es que toda la información existen-te estaba en inglés (y eso no ha cambiado); y la tercera, es que ni siquiera ahí me podría escapar de las matemáticas –la dirección en la que se mueve un objeto, determinar si está dentro del rango de visión de la cámara vir-tual, determinar si un vehículo chocó contra un edificio; todo eso requiere matemáticas.

Desafortunadamente, en México todavía no existe una industria de desarrollo de video-juegos como tal, y es una lástima, porque es una industria de billones de dólares. Ya exis-ten carreras de desarrollo de videojuegos en universidades internacionales, pero en mu-chas universidades de nuestro país ni siquie-ra se toma en serio la materia de gráficas por computadora, que es la base de todo.

Esto en gran parte se debe a falta de infor-mación, muchas personas creen que es lo mismo jugarlos que desarrollarlos. Un juego 2D puede ser fácil, pero uno 3D es algo muy diferente y se necesitan muchas personas trabajando en conjunto para crearlo. No es que una sola persona no pueda, pero se tar-daría mucho más tiempo. Un juego comer-cial tarda entre 1.5 y 3 años para ser desa-rrollado, con un equipo de 25 personas en promedio. Un juego 3D generalmente tiene programación orientada a objetos, cálculos trigonométricos y de álgebra lineal que se ejecutan durante todo el juego, estructuras de datos especializadas, y también puede existir una red neuronal para el manejo de la inteligencia artificial, así como algo de teoría de autómatas finitos y teoría de gra-fos aplicada, entre muchas otras cosas. Y aún así, hay maestros de universidades que cuando se les presenta un juego como una

idea para un proyecto final, solo dicen en tono despectivo “¿otro jueguito?”

Tuve la oportunidad de participar en el Festi-val de Desarrollo de Videojuegos Creanimax 2006, y me di cuenta que por fin se están haciendo esfuerzos para entrarle a esta in-dustria. Me di cuenta de que hay algunas compañías interesadas en desarrollar jue-gos, pero falta apoyo y habilidades técnicas. También me enteré de un par de universida-des en Guadalajara que están incorporando una carrera de animación y arte digital a su oferta académica. Hay muchas personas in-volucradas ya en el modelado y animación 3D –y son buenos–. Entonces no vamos tan mal, sólo falta ponernos las pilas, organizar-nos y darle importancia también a la parte de la programación.

Así que el objetivo de este artículo, es tra-tar de dar una pequeña orientación para aquellos que desean empezar a desarrollar videojuegos y tengan preguntas parecidas a las que tenía yo cuando empecé.

¿Qué se necesita saber para desarrollar videojuegos?Programación. Lo primero que se necesita es saber programar en algún lenguaje orienta-do a objetos, yo en lo personal uso C++, pero también se puede utilizar C#, Delphi, Java, etcétera. En cuanto a compiladores, no hay gran diferencia, se pueden utilizar el Visual C++ 2005 Express Edition de Microsoft o el C++ de Borland.

Game Engines. Los juegos generalmente tienen módulos clave para manejar tareas como mostrar gráficas, manejar recursos, interpretar y ejecutar scripts, reproducir efectos de sonido, manejar la inteligencia artificial, manejar el input del usuario. Estos

módulos clave, junto con otros, forman de manera colectiva lo que se llama un Game Engine, un producto que ofrece todas estas características, y hay quienes las usan para ahorrarse algo de trabajo al programar. De hecho, los estudios dedicados a los vide-ojuegos, utilizan Game Engines comerciales o desarrolladas por ellos mismos. Utilizar un Game Engine cuando se está iniciando en la programación de videojuegos, podría ser una limitante hasta cierto punto, porque primero se tendría que estudiar la documentación de ésta para saber utilizarla y si no se tienen los fundamentos teóricos suficientes, cuando se quiera modificar una parte del engine para adaptarla al juego deseado, será mucho más difícil. Existe una gran variedad de engines, desde algunas gratuitas y/o, open source como Irrlicht, hasta otras comerciales como el Unreal Engine 3, cuyo licenciamiento pue-de rebasar los cien mil dólares.

Matemáticas. Es deseable tener cono-cimientos generales de álgebra lineal y trigonometría, sobre todo para el área de programación de gráficas. Si no se tie-nen estos conocimientos, se tendrán que aprender al mismo tiempo que se hace con la teoría y programación de gráficas.

¿Qué se necesita aprender para desarrollar videojuegos?Esta pregunta no es fácil de contestar, so-bre todo porque existen diferentes áreas dentro de la programación de videojue-gos: gráficas, redes, inteligencia artificial, sonido, lógica principal. El área en el que está centrado este artículo es en la de gráficas, y para esta área se nece-sitan aprender básicamente dos cosas:

•Teoría de gráficas: involucra aprender las bases de los sistemas de coordenadas 2D

Desde niño siempre me han gustado los videojuegos, y siempre había

tenido curiosidad de cómo es el proceso para crear uno. Finalmente,

hace 6 años, decidí que era tiempo de aprender a desarrollarlos; después de

idealizar por unos minutos un videojuego perfecto como primer proyecto,

tuve que volver a la realidad: “¿Y por dónde empiezo?” Entonces comencé

a buscar información en Internet, que en aquel entonces era muy escasa;

parecía que mis dudas aumentaban en lugar de disminuir: “¿Qué lenguaje

de programación se utiliza?, ¿se usa algún compilador en especial?, ¿qué

estructura tiene un juego?, ¿qué necesito aprender?, ¿cómo se hacen los jue-

gos para las consolas?” Eran algunas de las muchas preguntas que tenía.

y 3D, las bases de los objetos 3D que son representados como modelos poligonales (vértices, normales, caras, etcétera); las báses de la arquitectura gráfica (diferentes tipos de transformaciones y proyecciones); las matemáticas involucradas (vectores, planos, matrices y todas sus operaciones relacionadas). Diferentes modelos de ilumi-nación, mapeado de texturas, entre otras co-sas. Es necesario tener estos conocimientos, ya que se aplican a las APIs para programa-ción gráfica existentes y son necesarios para explotar todo su potencial.

•Una API para programación de gráficas: que es básicamente una librería que usamos en nuestro código para poder mandar gráficas a la pantalla, sin tener que accesar al hardware directamente (en su lugar, los drivers se en-cargan de procesar las peticiones hechas por las APIs). Las dos APIs de gráficas más usa-das son OpenGL y Direct3D, y dado que los resultados que se pueden obtener con ellas, son, hasta cierto punto similares, la elección de una u otra es cuestión personal.

¿Qué es DirectX?DirectX es una serie de APIs de Microsoft para manejo de gráficas, input del usuario, soni-do, video, y funciones de redes que se pue-den usar en aplicaciones de multimedia en general, no solamente juegos. En versiones anteriores de DirectX, las gráficas 2D y 3D se manejaban con las APIs DirectDraw y Di-rect3D, respectivamente. A partir de DirectX 8, éstas se fusionaron en DirectX Graphics, pero es mejor conocida como Direct3D.

¿Qué es OpenGL?OpenGL es una API para el manejo de grá-ficas exclusivamente, no tiene otro tipo de funciones utilizadas en los juegos. OpenGL es multiplataforma, lo que significa que el mismo código puede correr en Windows, Mac, X Window, con mínimas modificacio-nes. Esta es una de las ventajas que, puede decirse, tiene con respecto a Direct3D, el cual es exclusivamente para Windows.

Dado que OpenGL es multiplataforma, no inclu-ye comandos para manejo de ventanas, porque estos son diferentes en cada caso. Dependien-do de la plataforma, hay métodos para crear una ventana con soporte para OpenGL. Para agilizar o hacer más fácil el manejo de ventanas. Ya existen algunas librerías que se utilizan junto con OpenGL, por ejemplo: SDL y GLUT.

OpenGL, a diferencia de DirectX, no se baja como un paquete, de algún sitio de Internet, ya que es implementado por los drivers. To-das las máquinas con Windows 95 o posterior, incluyen los drivers de OpenGL 1.1, aunque la versión más reciente de OpenGL es 2.0 –Win-dows Vista tendrá los drivers de OpenGL 1.4–. Entonces, la versión de OpenGL que se tenga, depende de dos cosas: la primera es nuestra tarjeta de video –no todas las tarjetas sopor-tan las últimas versiones de OpenGL –, y la segunda, es actualizar los drivers de nuestra tarjeta de video para tener la versión más re-ciente que soporte la tarjeta.

Para utilizar OpenGL, es necesario configurar nuestro compilador para que pueda encontrar

la libreria (OpenGL32.lib) y los archivos de encabezado (gl.h, glu.h, glaux.h) de OpenGL. Así mismo, necesitamos incluir los archivos de encabezado en los archivos de código fuente donde se usen funciones de OpenGL.

¿Cómo puedo programar videojuegos para Xbox360, PlayStation 3, GameCube?En el caso de Xbox360, para desa-rrollar un juego se necesita obtener un “Kit de Desarrollo”, que consta de una consola Xbox360 especial para desarrollo, herramientas, SDKs, y do-cumentación. El desarrollo se hace en una PC con Visual Studio o Co-deWarrior por ejemplo. Dicha PC está conectada a la consola especial de de-sarrollo, generalmente por ethernet. Una vez compilado el código, éste se pasa a la consola; la forma de cómo hacerlo, depende de cada sistema. En Xbox, se cuenta con unos plugins en Visual Studio que copian los datos de la PC al disco duro del Xbox, y después el Xbox monta el directorio que se co-pió, como si fuera el disco duro inter-no, para empezar a correr el juego.

Para obtener el kit de desarrollo, se nece-sita ser un desarrollador registrado con Microsoft, y los kits son muy caros. Aun-que existe el XNA Game Studio Express, éste, no es suficiente para hacer juegos comerciales, en realidad, es un producto dirigido más para estudiantes y hobbyists. Además, para ser aceptado como desarro-llador, se debe seguir un proceso que está sujeto a aceptación por parte de Microsoft. Se puede encontrar más información en:www.xbox.com/en-us/dev/ default.htm

Otros fabricantes de consolas piden requisitos adicionales. Por ejemplo, Nintendo pide que se cuente con respaldo financiero de algún distribuidor de juegos internacional. Así que, en general, para desarrollar un videojuego para consolas, se necesita tener una compañía establecida con presupuesto suficiente.

Si quieres aprender cómo es el desarrollo para consolas, una muy recomendada para empezar sería Gameboy Advance (GBA), ya que es de las menos complejas. En el sitio www.jharbour.com/gameboy/default.aspx se encuentra gratuitamente el ebook “Pro-gramming The Nintendo Game Boy Advan-ce”, que nunca se publicó como libro debido a cuestiones legales. En éste, se encuentra información de cómo ejecutar nuestros pro-


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íneaAlgunos 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 docu-mentación de desarrollo de juegos en general y foros para los diferentes aspectos del desarro-llo.

www.gamasutra.com – Un sitio donde se pue-den 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 man-tiene por sus creadores, pero tiene una extensa colección de artículos, todavía en línea, relacio-nados 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 al-

gun libro que enseñe todo lo relacionado al desarrollo de videojuegos, así que los cate-goricé 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 domina-do por dos compañías, ATI y NVIDIA. Las dos ofrecen tarjetas gráficas de muy buena calidad y de una gran variedad de precios, dependien-do de la generación de la tarjeta. Muchas ve-ces, al ver las cajas de las tarjetas pueden sur-gir 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 arqui-tectura 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 cambia-do, 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, li-berando 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 implementa-dos por medio de Shaders.

Hace algunos años, los Shaders eran escri-tos en lenguaje ensamblador, por tal razón no eran tan populares. Actualmente la mayo-ría de los Shaders, son escritos en lenguajes de “alto nivel”, muy parecidos a C, los tres más usados son: GLSL (específico de Open-GL); HLSL (específico de DirectX) y Cg (pue-de correr ya sea en OpenGL o DirectX).

Las tarjetas gráficas con arquitectura pro-gramable tienen dos núcleos o procesadores programables, uno se ejecuta a nivel de ob-jetos y otro se ejecuta a nivel de pixeles. Los Shaders que se pueden ejecutar en ellos, se conocen como Vertex Shaders y Pixel Sha-ders respectivamente (los últimos también se conocen como Fragment Shaders).

Las tarjetas gráficas con arquitectura pro-gramable, también tienen soporte para la ar-quitectura fija, y es decisión de la aplicación, utilizar una u otra arquitectura o incluso uti-lizar las dos. Es por eso que muchas veces, aunque tengamos un procesador avanzado, si no tenemos una tarjeta gráfica con arqui-tectura programable como lo requieren algu-nos juegos, no podremos ejecutarlos.

Tips generales•Es más fácil empezar por 2D, y algunas co-sas de 2D se aplican a 3D también.•Es más sencillo aprender OpenGL que Di-rectX (en mi opinión).•Jugar muchos juegos. Es la mejor manera de sacar ideas para juegos nuevos.•Ayudar a otros. También se aprende mucho cuando se enseña.•Tratar de hacer un clon de algún juego 2D sencillo (Tetris, Pong) y después mejorarlo.•Para un juego 3D, es más rápido desarro-llarlo en equipo.

Tema Tìtulo Autor

Matemáticas/Física Mathematicsfor3dGame EricLengyel ProgrammingandComputerGraphics

OpenGL OpenGLProgrammingGuide: OpenGLArchitecture TheOfficialGuidetoLearningOpenGL ReviewBoard

BeginningOpenGLGameProgramming. DaveAstley KevinHawkins

MoreOpenGLGameProgramming. DaveAstle

Gráficas3D InteractiveComputerGraphics: EdwardAngel ATop-DownApproachusingOpenGL.

Real-TimeRendering TomasAkenine-Moller yEricHaines

DesarrollodeJuegos GameProgrammingGems. MarkDeLoura (Seriede6libroshastaelmomento). (Editor)

CoreTechniquesandAlgorithmsin DanielSanchez-Crespo GameProgramming

InteligenciaArtificial AIGameProgrammingWisdom3 SteveRabin

Modelado ModelingaCharacterin3DSMax PaulSteed


ConclusiónEl tema de desarrollo de videojuegos es muy extenso, pero espero haber respondido las preguntas básicas acerca de cómo empezar. El siguiente artículo tiene información mas espe-cífica en cuanto a la estructura de un juego. Si dejé alguna pregunta sin responder, me pueden contactar en [email protected] y trataré de responder lo más pronto posible.

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 inicia-lizan los diferentes subsistemas del juego (gráficas, input del usuario, inteligencia ar-tificial, etcétera).

•Un ciclo principal - Este ciclo principal eje-cuta la lógica del juego una y otra vez, hasta que el usuario sale del juego. La lógica bási-ca dentro de este ciclo es:

•Actualización - Por ejemplo la posición de un enemigo, verificar si el usuario ha presionado algun botón, actualizar la po-sició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.

Este ciclo se ejecuta muchas veces por se-gundo, y cada ejecución se conoce como Fra-me. Una medida del rendimiento de nuestro juego, es indicar cuantos FPS (frames-per-

second) ejecuta. Qué tan rápido corre un juego, depende de muchos factores, princi-palmente aspectos de hardware como proce-sador, memoria, tarjeta gráfica; aunque tam-bié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 – Eje-cutada al finalizar el juego, aquí se libera la memoria obtenida de manera dinámica en todos los subsistemas del juego.

Conceptos básicosDefinamos algunos conceptos básicos que nos ayudarán a entender el código de nues-tro juego 2D:

Framebuffer. OpenGL cuenta con una co-lección de búfers donde se almacena infor-mació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 almace-na 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 cuan-do ménos dos framebuffers, uno para mos-trar en la pantalla y otro para hacer un ren-der 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 repre-sentación matemática tridimensional de un objeto y presentarlo como una imagen bidi-mensional 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 da-tos asociados y se “proyectan” en la panta-lla. Hay dos formas principales de hacerlo: para 2D se usa la proyección ortogonal, en


Desarrollar un juego de video en 2D con OpenGL no es tan complica-do 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.

Desarrollo de un

Juego 2DConceptos y Configuración

Por Joel Villagrana

ésta, la apariencia de los objetos es la mis-ma, independientemente de la distancia desde donde se vean. Para 3D se utiliza la proyección en perspectiva; donde la apa-riencia de los objetos cambia, dependiendo de la distancia con respecto a la cámara vir-tual, que es como percibimos los objetos en la vida real.

Transformaciones. En un juego, el movi-miento de los objetos se realiza por medio de transformaciones. Trasladar un proyectil de una posición a otra, rotar la cámara vir-tual, hacer más grande un objeto, son ejem-plos de transformaciones.

Matrices. Para almacenar información acer-ca del tipo de proyección usada en un jue-go, e información de las transformaciones y parámetros actuales de la cámara virtual, OpenGL utiliza la Projection Matrix y la Mo-delView Matrix respectivamente.

Viewport. Podemos definir un área dentro de una ventana, a la cual va a afectar nues-tro render. Generalmente, el viewport tiene el mismo tamaño de la ventana, pero si qui-siéramos hacer una aplicación que muestre nuestros objetos desde varias perspectivas (como lo hace 3dsmax por ejemplo) tendría-mos que definir diferentes viewports dentro de nuestra ventana.

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 tarje-ta gráfica son cuadrados, triángulos, líneas, y puntos. Cada una de estas primitivas tiene información asociada como vértices, norma-les, y coordenadas de textura.

Texturas. Son básicamente, imágenes que van a ser “pegadas” a nuestra geometría para darle la apariencia final. Una restric-ción importante para las texturas de un jue-go, 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érti-ce de la geometría. OpenGL funciona como una máquina de estados, es decir, guarda

la información actual de las propiedades de los objetos hasta que se le indican nue-vas propiedades.

GL Utility Toolkit (GLUT)GLUT es una librería que simplifica la creación y manejo de ventanas con soporte para Open-GL. En GLUT podemos definir nuestras call-back functions, que son las funciones llama-das 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 configu-rar 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 es-queleto que inicializa OpenGL y GLUT.

#include <stdio.h>#include <stdlib.h>#include <GL/glut.h> // funciones de GLUT y OpenGL

/* 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();/* ... */

void InitializeOpenGL(){ // Color que se utilizará cuando se limpie la pantalla (RGBA) glClearColor( 0.0f, 0.4f, 0.9f, 1.0f );

// Parámetros para el uso del Z-buffer glClearDepth( 1.0f ); glEnable( GL_DEPTH_TEST ); glDepthFunc( GL_LEQUAL );

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

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 to-mar el doble de líneas o más, usando la API de Windows.

Joel Villagrana, egresado de la Universidad de Guadalajara como Ingeniero en Computación, ha estado en contacto con la programación de videojuegos des-de 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. [email protected]


ConclusiónEn esta primera parte, revisamos los conceptos básicos para arrancar con el desarrollo de nuestro juego. En entre-gas posteriores veremos cómo crear el mundo gráfico de nuestro juego, mo-ver los objetos, detectar colisiones, reproducir sonidos, y muchos otros aspectos involucrados en el desarrollo de un juego. ¡Hasta entonces!

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 po-derlos 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 presen-tó dos problemas principales; el primero es que, para desarrollar juegos para diferentes platafor-mas (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 desarrollado-ras de juegos, utilizando kits de desarrollo caros y con disponibilidad limitada. Esto eliminaba la posibilidad de que un desarrolaldor casual pu-diera 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 permi-te usar una misma base de código para tanto plataforma Xbox como Windows.

Para desarrollar juegos basados en el fra-mework 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 comer-cializar. Se espera que sea lanzado en el se-gundo 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

Figura 1. Aquí se ilustran las capas que componen el XNA Framework.

Cuando estaba en la secundaria, recuerdo muy bien que me encantaba

pasar horas jugando con las maquinitas. Para mí, era fenomenal ver a

Pac-Man corriendo para no ser alcanzado por los fantasmas, o jugar a des-

truir los asteroides que explotaban en pedazos más pequeños.XNADesarrollo de Juegos al Alcance de Todos

Por Jaime Sánchez


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 me-nos de 5 minutos.

Capas de XNAAhora, ya que entendimos qué onda con XNA, vamos a verlo un poco más a detalle. El frame-work 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 encuen-tra la del framework básico, o central. Aquí es donde se procesa la información general del videojuego, es decir, el audio, los procesamien-tos 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 publicita-rio en tu videojuego. Imagina que pudieras rentarle a una compañía de refrescos, un es-pacio 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 mane-ra en la que se consume dicho componente. Sería genial, ¿no?

Para dar inicioYa que conoces cómo está diseñada a gran escala la arquitectura de XNA, muy segura-mente tu siguiente pregunta sería: ¿Cómo lo empiezo a utilizar?

Lo primero que tienes que hacer es descar-gar 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

Game Studio Express de XNA, desde el sitio msdn.microsoft.com/directx/xna/gse.

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 enten-der cómo está estructurado el videojuego.

Lo importante, es que sepas que, generar un videojuego, no es cosa sencilla, ya que tie-nes 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: inte-grarlos. Pero no te desanimes, ya verás que con un poco de práctica, pronto estarás de-sarrollando juegos divertidos, que podrás compartir con tus amigos o incluso, jugarlos en línea.

ConclusiónDesarrollar un videojuego involucra tomar en cuenta muchos aspectos. Afortunadamente, XNA elimina algo de esa complejidad y es una excelente op-ció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.

Figura 2. Interfaz de desarrollo de Game Studio

Express de XNA.

Figura 3. Plantilla de desarrollo Space War.

Figura 4. Juego en ejecución.

Cuando estaba en la secundaria, recuerdo muy bien que me encantaba

pasar horas jugando con las maquinitas. Para mí, era fenomenal ver a

Pac-Man corriendo para no ser alcanzado por los fantasmas, o jugar a des-

truir los asteroides que explotaban en pedazos más pequeños.XNADesarrollo de Juegos al Alcance de Todos

Por Jaime Sánchez


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.


La Inteligencia Artificial (IA) en los juegos de video, ha cobrado auge en los últimos años. Dado que las imáge-nes desplegadas por las consolas de la siguiente generación (Wii, PlayStation 3 y Xbox 360) cada vez se acer-

can 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 des-plegadas. 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 notarEstos son algunos de los juegos que consideo vale la pena destacar por su uso de IA:

1. Creatures, un juego de vida artificial crea-do por Steve Grand para Cyberlife en el Reino Unido. En este juego, cada una de las criatu-ras (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 si-mulado por una red neuronal sencilla. Steve Grand incluso, se ha auto proclamado un dios digital, ya que según él, ha creado “vida” den-tro 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-

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 ac-ció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).

3. F.E.A.R. (First Encounter Assault Recon), IA por Jeff Orkin de Monolith Productions. Cuenta con la Inteligencia Artificial más in-teresante, ya que se utilizan técnicas como el uso de un planeador para complementar a otras que se han utilizado con mayor fre-cuencia 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

con estos objetivos. Esto acarrea el benefi-cio 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.

Ejemplo: Überpong desarrollado por Nibbo StudiosAhora daré un ejemplo de la IA del videojue-go mexicano Überpong, desarrollado por Ni-bbo 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 pre-mios a nivel nacional, incluyendo el mejor vi-deojuego en PC desarrollado por una empresa mexicana en el concurso del capítulo mexicano de la IGDA (International Game Developers As-sociation) en noviembre del 2006. Überpong es un videojuego que combina los géneros de deportes y de acción para traer el clásico

Inteligencia

Artificial

Aplicación a los Juegos de Video

Por Dr. Carlos Delgado


juego de Pong al siglo XXI. Para lograrlo, se dotó de algoritmos de física computacional, detección de colisiones y de Inteligencia Ar-tificial 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 con-junto de parámetros que se especifican en el archivo XML de la IA. Entre éstos se en-cuentran: 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 primi-tivo 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 apli-car 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 dis-ponibles 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).

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.

ConclusiónLa 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 conside-raciones que se deben tener en IA para videojuegos, y también espe-ro, haber despertado su curiosidad para que conozcan más sobre esta fascinante área.

Inteligencia

Artificial

Aplicación a los Juegos de Video

Por Dr. Carlos Delgado

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).

Aunque desde hace cerca de diez años han exis-tido intentos de desarrollo de juegos de video en México, aún muy poca gente conoce la exis-tencia de aquellas compañías que luchan por un sueño común: desarrollar juegos, con pro-piedad intelectual propia, “Hechos en México”.

Desgraciadamente, los primeros proyectos no cautivaron al público de la manera que sus crea-dores hubieran querido. Sin embargo, a medida que pasan los años, cada vez más gente creati-va 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 empre-sas 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

defienda a capa y espada. Por lo mismo, mu-chas 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 jue-gos reconocidos mundialmente. Esto provocó que el consumidor, al tener que elegir entre dos juegos similares, uno desarrollado por un estu-dio 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 inci-dió y sigue causando molestias a los desa-rrolladores en nuestro país. Se estima que más del 80% de los videojuegos que se ven-den en México son adquiridos en el mercado informal. Este vicio, que las autoridades han dejado pasar, origina que las personas con-sideren 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 pre-gunte por qué la compañía que lo desarrolló ya no continuó sacando más proyectos.

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 Ver-million 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 comen-tó 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 In-ternet y foros extranjeros, la aceptación fue tal que terminaron el juego y éste fue comercializa-do en varios países por una distribuidora norte-americana, recibiendo grandes alabanzas por el arte gráfico del mismo.

Esfuerzos recientes de promociónEventos como Creanimax 2006, que se reali-zó 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


Cuando se habla de la industria de videojuegos, en primera instancia

nuestras mentes viajan al lejano oriente y, piensan en las compañías

niponas y los juegos con los que muchos de nosotros crecimos. También

podríamos pensar en países como Estados Unidos, Inglaterra o Francia.

Pero ciertamente, en el último país que pensaríamos sería el nuestro.La IndustriaDesarrollo de Juegos al Alcance de Todos

Por Ing. Oscar Guillé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”.

los jóvenes mexicanos. En los concursos de am-bos eventos se premiaron proyectos realizados por estudiantes, profesionistas y empresas, basándose en diferentes factores como el ga-meplay del juego, el arte y música, pero sobre todo, la originalidad de los mismos.

Cabe mencionar que entre los premios otorga-dos en el concurso de la IGDA, se dio a los me-jores 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 apo-yos 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 mexicanasA continuación, una breve reseña de algunas empresas representativas de esta naciente in-dustria de videojuegos en México.

Artefacto Estudio. Es una compañía que trabaja en una amplia gama de proyectos que van des-de 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 cap-turar 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 par-ticipado, debido a los contratos de confidencia-lidad que se requieren para conseguir este tipo de proyectos.

Dimtv. Empresa dedicada a la creación de jue-gos publicitarios. Han logrado concretar nego-cios con empresas nacionales e internacionales a las cuales les han desarrollado juegos basa-dos en su marca o producto.

Idle Hands Games. Enfocados en la creación de juegos para dispositivos móviles, esta em-presa 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 des-cargas 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 auto-bú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, presen-tados en la Feria de San Marcos 2006 en el stand del Gobierno Estatal; un juego didácti-co para la enseñanza del teclado de la compu-tadora de nombre “Mecapumble” y el juego en 2D que aún se encuentra en desarrollo, llamado “Überpong”. Este último logró con-seguir el segundo lugar en el concurso de de-sarrollo 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 per-sona (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ó opera-ciones 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áfi-ca y el gameplay del juego dejaban mucho que desear, “Kombate Mexicano” siempre lograba sacar una sonrisa en las personas que lo proba-ron por primera vez.

Snake & Eagle Studios. Esta compañía, aso-ciada 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, mis-mos 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 Digi-pen, una de las más prestigiosas escuelas de desarrollo de videojuegos. Hasta la fecha, sólo han mostrado una demo tecnológica de su mo-tor de juegos, pero se sabe que trabajan en un proyecto basado en el juego maya de la pelota, que llevará el nombre de “Underworld Tourna-ment”, 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éxi-co hasta la fecha. La calidad que han logrado imprimir en el arte gráfico y la programación, hizo que distribuidores internacionales de vi-deojuegos se fijaran en él, y se esté vendien-do ya en diversos lugares del mundo.

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.


Cuando se habla de la industria de videojuegos, en primera instancia

nuestras mentes viajan al lejano oriente y, piensan en las compañías

niponas y los juegos con los que muchos de nosotros crecimos. También

podríamos pensar en países como Estados Unidos, Inglaterra o Francia.

Pero ciertamente, en el último país que pensaríamos sería el nuestro.La IndustriaDesarrollo de Juegos al Alcance de Todos

Por Ing. Oscar Guillé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”.

ConclusiónA 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 con-vertirse en un país creador de propie-dad intelectual y juegos de calidad. Si quieres conocer más sobre desarrollo de videojuegos en nuestro país, te re-comiendo que entres al sitio del capí-tulo en México del IGDA, disponible en http://mexico.vjuegos.org/


Mucho 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 ob-tención de un nivel de madurez sigue siendo el principal móvil para implementar CMMI. La rea-lidad muestra que, tales iniciativas, logran un éxito significativo cuando son vistas como un objetivo de negocio, que traerá consigo benefi-cios económicos y que resolverá problemáticas relevantes en la organización.

Las preguntas que típicamente surgen al plan-tear un programa de mejora son: ¿cuánto nos va a costar?, ¿qué beneficios vamos a obte-ner?, ¿cómo justifico el gasto ante el Consejo?, ¿existe información de resultados obtenidos por empresas similares en México?

Para poder generar un adecuado entendimien-to 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 apo-yar 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 empre-sa 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

de utilidad del 35%? O quizá destinarlo a me-jorar 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 pro-grama de mejora basado en CMMI, la com-plejidad de este análisis radica en obtener la información suficiente y confiable para calcularlo correctamente.

Análisis del Retorno de InversiónEl proceso para analizar el ROI de un programa de mejora se ilustra en la siguiente figura, y se describe a continuación:

1. Determinar el alcance de la iniciativa de mejoraA fin de acotar el alcance del programa de me-jora, 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 so-porte del proceso.•Herramientas. •Consultoría especializada. •Evaluaciones formales.

Es importante contemplar los costos asocia-dos, no sólo para la implementación del pro-grama, sino también para mantenerlo operan-do, aun después de haber alcanzado un nivel de madurez.

3. Dimensionar los beneficiosUn programa de mejora debe estar goberna-do por los objetivos de mejora definidos por el negocio. La experiencia después de innu-merables sesiones de trabajo con directores de empresas de TI para identificar los obje-tivos 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.

/* MEJORA DE PROCESOS */

Análisis del ROIUna Herramienta para Justificar la Mejora de ProcesosPor Angélica Su y Alfredo Calvo

// PRÁCTICAS

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.

Figura 1. Procedimiento para el análisis del ROI.

•Mejorar la calidad del producto. •Mejorar la productividad del equipo.

El punto más complicado para realizar un ade-cuado análisis del ROI, es el dimensionamiento y la cuantificación de los beneficios que se ob-tendrán con CMMI, debido sobre todo, a la ca-rencia de información; la buena noticia es que ahora existen resultados cuantitativos publi-cados 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.

Estos datos pueden ser tomados “como re-ferencia”, con las debidas reservas, ya que cada empresa es diferente, y los criterios para captar, calcular y presentar dicha infor-mación no necesariamente podrían ser apli-cables 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 em-presa promedio en nuestro país genera inquie-tud, 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 his-tórica confiable. A continuación, se presentan datos de empresas mexicanas con las cuales hemos trabajado en la empresa It Era.

•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 estima-ciones de esfuerzo tienen variaciones respec-to a la realidad, de menos del 10% (de -8% a +5%), lo cual habla de la madurez y confiabili-dad de su operación.• Dextra Technologies. Empresa trabajando con procesos CMMI Nivel 3, actualmente pre-senta 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, disminu-yendo el retrabajo en actividades de calidad.• Mexware Consulting. Comenzó a imple-mentar su programa de mejora de procesos en 2005 y actualmente implementa proyec-tos con procesos de Nivel CMMI3. Sus re-sultados a la fecha para 20 proyectos ejecu-tados reflejan una desviación promedio de esfuerzo y tiempo del 5% • A nivel gubernamental, está el caso de la Co-ordinació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 reporta-dos, presenta proyectos con desviación pro-medio del 6.3%, un índice de apego a procesos definidos del 98.1% y un ROI de 3.5 a 1.

Algunos de los ejemplos típicos que se pre-sentan como metas de mejora pueden ser:•Disminuir el retrabajo por corrección a defectos en un X%•Disminuir el retrabajo por mala especifi-cació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 ROIEl cálculo del ROI, se realiza dividiendo la estimación de los beneficios estimados en-tre los costos asociados con el programa. Siguiendo el ejemplo anterior, si conside-ramos una inversión de 75 mil dólares, un

beneficio esperado de 374 mil dólares al año tenemos:

ROI = 374,400 / 75,000 = 4.99

5. Presentación de resultadosComunicar a la organización el análisis realiza-do, los objetivos de negocio, las metas de me-jora 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ónEl análisis del ROI es una herra-mienta de suma utilidad para evaluar la conveniencia de un pro-grama de mejora. Se requiere con-templar los costos asociados con la implementación y el manteni-miento del programa de mejora. Es indispensable establecer objeti-vos de negocio cuantificables que guíen y gobiernen el programa de mejora. Los beneficios económi-cos se determinan en b ase a estos objetivos de negocio.


El análisis del ROI es una herramienta de utilidad, que

permite apoyar la justificación de la inversión en términos tangibles.

Categoría de Desempeño

Rendimiento medio

Número de datos

Desempeño Inferior

Desempeño mayor

Costo 20% 21 3% 87%

Calendario 37% 19 2% 90%

Productividad 62% 17 9% 255%

Calidad 50% 20 7% 132%

Satisfaccióndel Cliente

14% 6 -4% 55%

Retorno deInversión

4.7 : 1 16 2 : 1 27%

Tabla 1. Resultados publicados por el SEI. www.sei.cmu.

edu/cmmi/results.html.

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 estimadosanuales (USD)

$ 374,400 Ahorros estimados por aumento en productividad del 10% por año (USD)

Tabla 2. Ejemplo de beneficios estimados.


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

Quienes han desarrollado aplicaciones em-presariales usando la especificación 2 de

EJB (Enterprise Java Beans), conocen el excesivo tiempo que se consume en el ciclo Editar-Com-pilar-Debugear. Incluso, posiblemente se han vuelto expertos en pasatiempos como Sudoku, u otra actividad que haga más llevadera la es-pera en este ciclo. Es cierto que algunas veces la utilización de tal tecnología es la mejor deci-sió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 enArquitectura EJB 2Veamos un ejemplo simple de tipos de cam-bios, 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 Ac-cess Object - DAO) es a través de un EJB llama-do 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á den-tro de los límites aceptables.

El resultado es un objeto de datos llamado CapturaResultDTO con el resultado de la ope-ració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 va-rios problemas que describo a continuación.

Problemas frecuentes en EJBsFramework pesado y complejo. EJB 2 es un framework muy completo, que resuelve reque-rimientos comunes en las aplicaciones empre-sariales, tales como el manejo de transaccio-nes 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 na-ció 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. Ha-cer cualquier modificación a un EJB, requiere además de editar y compilar, instalar cada componente EJB en el Servidor de Aplicacio-nes, 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 ObjetosMucha gente piensa que por el hecho de escri-bir código en un lenguaje que soporte OO, ya están desarrollando con objetos y todo el para-digma que éste conlleva. Sin embargo, lo ante-rior 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 crea-dos 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 verda-dero estilo Orientado a Objetos sobre la plata-forma 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 úni-camente modelan superficialmente el proble-ma, ya que contienen clases que implementan poco, o nada de comportamientos.

Desarrollando con POJOs y Frameworks ligerosAntes de la especificación EJB 3, muchos desarrolladores desilusionados con EJB bus-caron alternativas, y encontraron que los POJO son una de esas, convincente a EJBs. Un POJO (Plain Old Java Object) es simple-mente 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 reem-plazan 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.

POJOs y Frameworks Ligeros: Simplificando el Desarrollo Por Ixcoatl Pérez

Figura 1. Diseño de Captura de Operaciones con EJB 2.

/* DISEÑO */

plataforma J2EE. Hibernate y Spring tienen características importan-tes, el no ser intrusivas, es una de ellas. Proveen transacciones y per-sistencia 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 combi-nan 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 mapea-dos hacia la Base de Datos relacional. Un framework de persistencia como Hibernate nos brinda una solución ORM (Object-Relational Ma-pping), y si se requiere mapear POJOs hacia sentencias SQL, iBATIS, nos brinda una solución bastante conveniente para ejecutar senten-cias 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 (Container-Managed 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 ro-llback 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 in-teresante 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 cuan-tas 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”)) ;

CapturaFacade cF = (CapturaFacade) factory.getBean(“CapturaFacade”, CapturaFacade.class);

Nota: Utilizamos un Façade con la intención de desacoplar las res-ponsabilidades de un CapturaService y la capa de presentación.

Debido al alto nivel de configuracion de Spring, la fábrica de Spring-Bean 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 ori-ginal, y por tanto sirve para muchos propósitos, como administrar transacciones, seguridad o conexiones a la base de datos. Captura-Faç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 POJOsRevisemos por último el diseño del servicio de Captura de Operacio-nes 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.

En resumen, los frameworks ligeros como Spring e Hibernate nos permi-ten usar POJOs, con todas sus conveniencias; y tener los mismos benefi-cios de usar EJB Session Beans, sin tener sus complicaciones.


/* ARQUITECTURA */


Uno de los factores que determina el éxito o fracaso de un siste-ma 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 visi-bles de estos elementos y las relaciones entre sí [1].

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 ar-quitectura no se diseña de forma apropiada, el sistema de software resul-tante 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.

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 conoci-miento 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 so-bre 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 softwareEl propósito de realizar evaluaciones a la arquitectura, es para anali-zar e identificar riesgos potenciales en su estructura y sus propieda-des, que puedan afectar al sistema de software resultante, verificar que los requerimientos no funcionales estén presentes en la arqui-tectura, así como determinar en qué grado se satisfacen los atribu-tos de calidad. Cabe señalar que los requerimientos no funcionales, también son conocidos como atributos de calidad. De acuerdo al es-tándar IEEE 610.12-1990 [3], un atributo de calidad es una caracterís-tica que afecta la calidad de un elemento. En esta definición, el tér-mino “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]: operaciona-les y de desarrollo. Los atributos operacionales son las cualidades

del sistema que están en operación, por ejemplo: rendimiento, con-fiabilidad, disponibilidad, tolerancia a fallas. En cambio, los atribu-tos de desarrollo son las cualidades del sistema que son relevantes desde una perspectiva del desarrollo de software, por ejemplo: faci-lidad de modificación, facilidad de re-utilización, flexibilidad.

Primeros iniciosLos primeros esfuerzos en realizar evaluaciones a arquitecturas de soft-ware 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 cues-tionarios 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 erro-res, 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 evalua-ció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 implanta-ció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ónExisten 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, prototi-pos, experimentos o modelos matemáticos; en la figura 1 se mues-tran de manera gráfica estas técnicas.

Evaluando la Arquitectura de Software Parte 1. Panorama GeneralPor Omar Gómez

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 [email protected]

// PRÁCTICAS


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 arqui-tectura ya ha sido implantada. Por ejemplo, es posible hacer uso de mo-delos 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].

Planear o no la evaluaciónLas evaluaciones pueden ser planeadas o no planeadas. Una eva-luación planeada es aquella que ha sido contemplada dentro del ciclo de vida de desarrollo, por lo que es parte de las activida-des 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, di-señador y administrador del proyecto. Sin embargo, puede haber excepciones en las que se contrate a un grupo de personas espe-cialistas para realizar la evaluación. El cliente también se interesa

por los resultados obtenidos de la evaluación, ya que puede deci-dir 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 cum-plirá con los tiempos de respuesta requeridos por el cliente.

Resultado de la evaluaciónUna vez que se ha efectuado la evaluación, se debe elaborar un repor-te. Que debe presentarse como un documento preliminar, con la fina-lidad de que se corrija por las personas que participaron en la evalua-ció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.

ConclusionesEn 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.

Realizar una evaluación no planeada, representa retrasos en los tiempos de entrega, así como un incremento en los

costos del proyecto.

Referencias1. 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 Lon-don 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 Archi-tectures”. 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.

Figura 1. Clasificación de las técnicas de evaluación.


Brindándole un Hogar al Software:DIAGRAMAS DE DISTRIBUCIÓNPor Charlie Macías y Sergio Orozco

Imagina tu casa con un televisor de plas-ma 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 tempe-ratura; 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 pa-rece ser el lugar más apropiado para tener esas comodidades, ¿cierto?

Soñar no cuesta, no planear síAntes de decidir comprar los anteriores com-ponentes, 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 desa-rrollo de software. Antes de decidir desarro-llar una aplicación con ciertos requerimien-tos, 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, ser-vidores, 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 mue-bles y componentes, de seguro visualizarás si

tu casa tiene espacio dónde colocarlos. Si eres suficientemente precavido evaluarás si la ins-talación eléctrica o hidráulica es la apropiada para que funcionen correctamente. Si eres un diseñador de interiores o un arquitecto, bos-quejará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 compo-nentes que formarán una aplicación, pensa-rás si el equipo e infraestructura con la que cuentas es apropiada para dicho sistema. An-tes de desarrollar el software, e incluso antes de comprometerte con tu cliente a desarro-llarlo, 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 RestringirAl inicio del proyecto, en lo que podemos lla-mar fase de Inicio o Concepción (“Inception”) en el caso del Proceso Unificado, tendrás que desarrollar un primer diagrama de distribu-ción para identificar las restricciones físicas de hardware en el proyecto (el equipo e ins-talaciones 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 artefac-to 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 visuali-zar 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 agre-gaciones de clases. Son los moldes de fa-bricació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óm-puto 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.

// UML

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 miem-bro de la OMG. [email protected] www.milestone.com.mx


Un artefacto no es una IlusiónUn concepto que para muchos resulta difícil de entender, es el artefacto. Especialmente por su relación con el concepto de componente. El ni-vel 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.

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 com-ponente y el artefacto donde se manifiesta.

Ambientando la CasaLos componentes necesitan de un ambiente donde se ejecutarán. Si deseas dejar gráfi-camente 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 pue-de ver en la ilustración.

Así que antes de decidir llenarte de comodi-dades, asegúrate de contar con el espacio y las características necesarias en tu casa. An-tes de invertir en la compra o desarrollo de un software, asegúrate que tendrá un hogar apropiado donde hospedarse.

“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 men-sajes y señales.

Componente. Representa unidades autocontenidas de software que realizan a las clases, o a cualquier elemento empacable

Artefacto. Representa la manifes-tación de un componente en el mundo físico.

Figura 1. Dos recursos de cómputo con capacidad

de procesamiento conectados y alojando artefactos.

Figura 2. Relación entre el artefacto y el componente

manifestado.

Figura 3. Artefacto que se ejecuta en un ambiente de

ejecución dentro de un dispositivo.


En 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.

En esta ocasión, me referiré al que consideramos en Microsoft, el se-gundo 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 aplicacio-nes de negocio (line of business systems) desde Microsoft Office.

Imagina que tienes una capa de datos (backend), y una capa de ló-gica e integración con procesos de negocio (que residen en “line-of-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 pre-sentació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 System 2007 como plataforma de desarrolloOffice 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) Adminis-tración de contenido empresarial; c) Inteligencia de negocios.3. Convertirse finalmente en una plataforma de desarrollo auténtica.

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.

Es importante señalar que estos servicios descansan en los nuevos “Windows SharePoint Services 3.0” (WSS 3.0) que se ofrecen gratuita-mente 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ónOBA permitirá “abrir el retorno de inversión de toda la tecnología em-presarial”. 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 (Ma-pas 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 in-tegration). Evalúenlo con sus usuarios, y decidan ustedes mismos.

—Luis Daniel Soto

Referencias•Arquitectura OBA: msdn.microsoft.com/architecture/office •Desarrollo OBA: msdn.microsoft.com/office•WSS 3.0: www.microsoft.com/technet/windowsserver/sharepoint

Office Business Applications (OBA) y Line of Business Integration (LOBi)El Próximo Patrón Estratégico

/*TENDECIAS EN SW*/// COLUMNA

Luis Daniel Soto es director de Evangelización en nuevas tecnologías en Microsoft México. Entre sus funciones actuales están la de adminis-tració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

Figura 1. Arquitectura de aplicaciones orientadas a Office.

El término Realidad Virtual engloba una gran cantidad de ideas filosófi-

cas, 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érmi-no; se mencionan autores como Damien Broderick, escritor australiano autor de “The Judas Mandala” (1982), y Jaron La-nier, investigador norteamericano funda-dor 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 re-lativamente interactiva, e incluía la estimu-lación de múltiples sentidos: visión, soni-do, 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 in-terfase 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 alcanza-do, y estimulan la imaginación al mostrar la posibilidad de crear simulaciones que sean indistinguibles o mucho más atrac-

tivas que la misma realidad. Lo cierto es, que estamos aún lejos de tener simulado-res 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 simul-tánea y coherente de todos nuestros sen-tidos: vista, oído, olfato, tacto y gusto. La mayor parte de la investigación y el desa-rrollo se han enfocado en la vista y el oído. El primer prototipo de visualización de in-mersión total, que utilizó tecnología digital fue el Head Mounted Display (HMD), desa-rrollado 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 inte-racción imitara la forma en que nos des-envolvemos en la vida real: las imágenes presentadas en una pantalla situada fren-te 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 evolu-cionado 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 visualiza-ció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 panta-llas de proyección que forman un área en la que, el usuario puede colocarse y verse

rodeado de imágenes sintéticas proyec-tadas en estéreo –simulando profundi-dad– 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 profe-sional, tiene poder de cómputo suficiente para visualizar escenas animadas com-plejas 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 inte-ractivo 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 actua-les 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 pro-blemas mucho más complejos de atacar, siendo el olfato y el gusto los menos es-tudiados. 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 imi-tar 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


Realidad VirtualEstimulando la Imaginación

/* CÁTEDRA Y MÁS */// COLUMNA

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.


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 dispositi-vos son brazos mecánicos con una especie de pluma o estilete, la cual, al ser manipu-lada por el usuario, permite simular la re-sistencia de diferentes materiales; como si tocáramos con una pluma, superficies con distinta textura y resistencia: metales, ro-cas, 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 ma-nos. Al combinar estas interfases con un sistema de sonido envolvente y un HMD, o un sistema CAVE, se pueden obtener entor-nos 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 in-mersió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 comercia-les, 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 componen-

tes principales: interacción, inmersión y tiempo real. Una de las áreas de investi-gación más vanguardistas, en cuanto al componente interactivo se refiere, son las llamadas “brain interfaces”, trabajos pioneros encaminados a utilizar las seña-les 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 reali-ce estimulando directamente el cerebro, pero afortunada o desafortunadamente, aún estamos muy lejos de ello.

La experiencia demuestra que, no se re-quiere 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 ca-paces 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 in-cursionar en el fascinante mundo de la Realidad Virtual, les recomiendo docu-mentarse en temas de gráficas por compu-tadora, aprender a programar aplicaciones en OpenGL y/o Direct3D (DirectX) y revisar la abundante literatura científica sobre in-teracción humano-computadora, entornos virtuales y Realidad Virtual en general.

—Por Mario Gutiérrez

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.


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, gene-raciones 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 pro-gramar actual –no importa si profesas la religión de .Net, Java o al-gú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 conoz-co 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 de-sarrolló Simple J, una novedosa apuesta a despertar la curiosidad de los chavos, creado con la intención muy noble de regresar la progra-mación a su origen esencial: diversión. SimpleJ recrea un entorno de desarrollo virtual en Java, que permite crear juegos de video y compar-tirlos 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 aten-ción. Sin darse cuenta, estarán aprendiendo a programar.

No se necesita ser un experto para comenzar con SimpleJ. En el sitio de SimpleJ (www.simplej.com) está disponible un tutorial enfoca-do 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 normalmen-te 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 acuer-do con alguien más para hacer un videojuego. Mago personal-mente contesta todas las dudas que puede, pero la comunidad es principalmente soportada por alumnos de todo tipo de institucio-nes académicas, desde universitarios del ITAM, hasta estudian-tes 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 desa-rrollo –además de que es 100% mexicano–, es su modelo de negocios. SimpleJ es software libre, licenciado con GPL y com-pletamente 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ógi-cos, 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 ([email protected]), sin duda, un ejemplo a seguir en el software libre mexicano.

— Emilio Osorio

SimpleJRegresando la Diversión al Desarrollo de Software

/*TIERRA LIBRE*/// COLUMNA

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 [email protected]

Cuando estamos inmiscuidos en el área de la enseñanza, muchas veces repetimos patrones, y ter-minamos enseñando de la mis-ma forma en que nos dictaban clase nuestros maestros. Usted, que ya ha aprendido a progra-mar, ¿recuerda sus inicios?

Remontémonos a aquella clase de Pascal, Cobol, Fortran, Basic o C. Como podrá re-cordar, lo que se hacía era básicamente analizar a detalle los resultados, o bien, proporcionar los datos necesarios para ge-nerarlos. Posteriormente, se realizaba el diagrama de flujo, lo cual implicaba diseñar la solución, y antes de pasar a construir-lo, 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 habilida-des. Esto se da a través de un adecuado proceso de enseñanza-aprendizaje. Sin em-bargo, los cimientos deben definirse desde un primer contacto con algún curso de pro-gramació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 len-guaje de programación, es muy importan-te el desarrollo de la lógica. El objetivo no es enseñarle instrucciones como, “impri-mir”, “leer”, etcétera. –Cualquiera puede aprenderse líneas de texto y su significa-do–, sino que debemos enfocarnos en en-señarles cuándo y cómo usarlas, cuándo y cómo combinarlas, incluso mejorar la solu-ció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 instruc-ciones que se aprenden rápidamente se pueden memorizar; pero quizás esto sólo serviría cuando la persona ya tiene un ca-mino recorrido en cuanto a la lógica de pro-gramació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 man-tenga una relación directa entre aquello que se está enseñando, y la vida real; de prefe-

rencia algo que los estudiantes ya hayan ex-perimentado previamente. Por ejemplo, cuál es el proceso que tiene una tienda de auto-servicio cuando la cajera pasa el producto por un lector de código de barras, o qué su-cede cuando ellos entran a un sitio en Inter-net 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á expli-cando 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 expo-nenciales, logarítmicas, números primos, o generar las raíces de una ecuación cua-drática. Como educadores, debemos des-pertar el interés de nuestros estudiantes; de nosotros depende captar y conservar la atención para lograr un nivel de aprendiza-je satisfactorio. Muchas veces esto se lo-gra 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 ase-gurar que nos dejará asombrados.

Como instructores, siempre hay que con-siderar el tipo de público que en ese mo-mento 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


Enseñar a Programar es Mucho MásQue Sólo Enseñar un Lenguaje de Programación Por Consuelo Jiménez

// FUNDAMENTOS

Ing. Ma. del Consuelo Jiménez Fernández es profesor asociado del departamento de Ciencias Computacionales en la Universidad de Monterrey. Ha recibi-do 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. Actual-mente, es una de las evaluadoras en las propuestas de proyectos para la incubadora en UDEM. [email protected]

43SEP-OCT 2006www.softwareguru.com.mx

apoyarnos en paquetes que permiten si-mular o animar la teoría relacionada a estos temas, y que tienen ejemplos repre-sentativos y claros.

Otro aspecto importante que convendría considerar en la enseñanza de la progra-mación, es que cuando no existen bases firmes en el área matemática, se le difi-culta más al alumno captar rápidamente operaciones tan simples como, cálculo de porcentajes, promedios, frecuencias, divisores, etcétera; todos ellos son con-ceptos que se enseñan desde la primaria, pero que por no llevarlos a la práctica suelen olvidarlos fácilmente. Es recomen-dable tener diseñado un curso en un am-biente en línea, más para estos casos, de tal forma que la persona que requiera un refuerzo pueda acceder a manera de au-toestudio a aquellos módulos que le ayu-den 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 progra-mas 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í po-dremos definir estrategias y estilos adecua-dos 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 domi-nar: la lógica, el lenguaje para programar donde la sintaxis puede ser simple o com-pleja; los estándares, el desarrollo de la

documentación y el entorno de desarrollo. Si logramos que tengan estas bases bien cimentadas, entonces de ahí, se despren-derá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ñan-za 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ñadien-do 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 mane-jar un tema, pida a sus alumnos tiempo para investigarlo, y explíque-lo cuando se sienta seguro. Ellos se lo agradecerán.

“El desarrollo de juegos nos ayuda a despertar el interés de nuestros

estudiantes, para lograr así un nivel de aprendizaje satisfactorio”.

Para aquellos que no están familiarizados con el mundo de la telefonía y desconocen las características de un PBX (Private Bran-ch Exchange), por favor continúen leyendo. Para quienes cuentan con amplia experien-cia 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 cono-cemos 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 hard-ware, además de la funcionalidad de tele-fonía interna, tenemos servicios de correo de voz, transferencia de llamadas, confe-rencias, 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 co-nexión directa a las centrales de fibra ópti-ca o cobre de los proveedores telefónicos. En algunos casos es posible trabajar con lí-neas directas comerciales, pero esto suce-de por lo regular en implementaciones pe-queñas, donde quizás no sea necesario el uso de un PBX, dado los costos que impli-ca tenerlo, que provienen de mantenimien-to de hardware y software de las tarjetas,

servicios de programación o capacitación para hacerlo con personal interno, contra-tos de 7x24 en caso de fallas, dada la criti-cidad 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 nece-sidad 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 fun-cionalidad a precios más bajos con mayor redundancia, y una mejor oferta de solucio-nes, dado que se incorpora el video en tiem-po 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 sour-ce 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 fa-bulosa cualidad de ser open source.

Antes de continuar, deseo resaltar la magni-tud del párrafo anterior con un ejemplo: una

solución de ToIP o de un PBX con la funciona-lidad antes mencionada, significa una inver-sió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 constante-mente 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 adop-ción de dicha aplicación

El programa no requiere de hardware adicio-nal para soportar VoIP, y existe una buena variedad de dispositivos para que Asterisk pueda interconectarse con equipo tanto di-gital como analógico. La mayor parte de es-tos dispositivos provienen de Digium, que es la marca que patrocina a Asterisk. Se cuenta con hardware para poder conectar la aplica-ción a troncales E1 y T1 para conexiones PRI (Primary Rate Interface) que son las interfa-ces 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 pro-tocolos TDM que le permiten el manejo y transmisión de voz sobre interfases tradicio-nales, soporta la señalización estándar de los sistemas telefónicos comerciales, tanto ame-ricanos como europeos, lo cual le permite co-


Durante el año pasado tuvimos la oportunidad de publicar varios artículos relacionados con tec-nologí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 comuni-caciones 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.

AsteriskDemasiado Bueno y Aun Así, es Cierto Por Ariel García

// INFRAESTRUCTURA


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. Exis-ten APIs que se diseñaron específicamen-te, 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 siguien-tes 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 As-terisk, y contiene el núcleo de la funcionali-dad de PBX conectando las llamadas entre los usuarios y automatizando tareas.•Lanzador de Aplicaciones. Lanza las aplicacio-nes para los servicios como correo de voz, direc-torio, grabación y reproducción de llamadas. •Traductor de Codecs. Utiliza los módulos de codecs para la codificación y decodifica-ción de los formatos de audio estándar de la industria. Se cuentan con los codecs más comunes para satisfacer las distintas nece-sidades 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 condi-ción de carga.

Módulos APIsA través del uso de este sistema de módulos, el núcleo de Asterisk se despreocupa de de-talles 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 co-nexió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 futu-ro. 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 sis-tema de archivos.

Gracias a este manejo de módulos, es posi-ble integrar los sistemas de hardware actua-les 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 com-pleta 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 ope-ració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 inversio-nes 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 bene-ficios 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 desa-rrollo 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

“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”.


/* GADGETS */// TECNOLOGÍA

D-Link

Wireless Presentation GatewayHacer presentaciones desde diversas computadoras, proyectores y monitores sin utilizar cables, es el ob-jetivo 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 dispo-sitivos 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.

Space Invaders 5-en-1 Plug & PlayPara 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.

// TECNOLOGÍA

Widow PC

SLI LaptopWidowPC 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 tar-jeta 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 inte-grada 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.

Pyramat

s2000 Sound Rocker 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 equi-pado con subwoofers PowersubTM de 5.5” que envía inten-sas vibraciones y sonido nítido, de tal manera que es posible apreciar desde un disparo hasta la respiración de un persona-je. Cuenta a su vez, con altavoces iluminados ARXTM de alto desempeño y largo alcance que aceleran la experiencia de jue-go. Está fabricado en tela Poly-strech que además de brindar

confort durante largas horas, es porosa, per-mitiendo 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 videojue-

gos, televisores, reproductores de video y MP3.

INDEX

Anunciante Páginas Sitio

AMCIS 55 www.amcis.org.mxAvantare 51 www.avantare.comExpoComm 45 www.expocomm.com.mxe-Quallity 43 www.e-quallity.netGartner F3 www.gartner.com/mx/appintItera 07 www.itera.com.mxLinuxWorld 49 www.linuxworldexpo.comMicrosoft F2-01, 23 www.microsoft.com/mexicoMilestone Consulting F4 www.milestone.com.mxRoca Sistemas 11 www.rocasistemas.com.mxSafeNet 13 www.safenet-inc.comSelect / Tendencias 19 www.select.com.mxTiburón Software 47 www.tiburonsoft.com

TENEMOS UN ESPACIO RESERVADO PARA TISi deseas anunciarte contáctanosen el (55) 5239 5502 o en [email protected]

DIRECTORIO

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

Software durable implica diseño continuoIdentificar el verdadero problema a resolver y diseñar el programa ati-nado, representa el mayor avance en un proyecto de desarrollo, la parte restante se trata de hacer de manera correcta dicho programa. El pro-blema 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 pro-blemas 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 practicesPara algunos está claro que, cuando se presenta un best practice, en rea-lidad 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 ac-ció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 trans-mita 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 nece-sario hacer para adquirir el conocimiento tácito: pensar en contexto.

Adaptación es clave, el mapa no es el terrenoUna vez que tienes experiencia con un buen número de métodos de di-señ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é agre-gar? 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 adecua-do de propiedades como las que presenta Alistair Cockburn[4] (Entre-ga 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 traba-jas, aceptando que “la realidad es así”.

ConclusionesDavid West nos presenta algo que llama curiosidades, en la introduc-ción de su libro[5] y que reflejan ciertos comportamientos muy dise-minados 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 ob-jetos 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 prome-tedoras 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: [email protected]


Programas CorrectosParte 3. Pensar No es OpcionalPor Marco Antonio Dorantes

Referencias1. Wicked Problems, Righteous Solutionsblogs.msdn.com/marcod/archive/2004/06/12/154131.aspx2. Unconscious Design Definedblogs.msdn.com/marcod/archive/2005/04/03/UnconsciousDesignDefined.aspx3. The Engineering in Software Development – Trails of Design Masteryblogs.msdn.com/marcod/archive/2004/06/23/163358.aspx4. Just-In-Time Methodology Constructionalistair.cockburn.us/crystal/articles/jmc/justintimemethodologyconstruction.html5. David West. Object Thinking. 6. Life and Times of Anders Hejlsbergchannel9.msdn.com/Showpost.aspx?postid=1599527. ACM Special Interest Group on Software Engineering (SIGSOFT) Soft-ware Engineering Notes. ACM Fellow Profile: David Lorge Parnaswww.sigsoft.org/SEN/parnas.html

// REFLEXIONES

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

www

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

Ener

o-Fe

brer

o 20

07

[ Novedades ]WCFNoticias • Eventos • Fundamentos • UML • Infraestructura • Reflexiones

Año

03

No.

01

Documents

SG13 (Enero-Febrero 2007)