SG13 (Enero-Febrero 2007) by Revista Software Guru

• Análisis de ROI • POJOs y Frameworks Ligeros • Evaluación de Arquitecturas

Software Guru CONOCIMIENTO EN PRÁCTICA Año 03 No.01 • Enero-Febrero 2007 • www.softwareguru.com.mx

ESPECIAL

Desarrollo de Software en Universidades [ ENTREVISTAS ]

Desde Creanimax Bill Plympton René Castillo Ernesto Gálvez

Desarrollo de

Videojuegos ¿Por dónde comenzar? México, $65.00

Noticias • Eventos • Fundamentos • UML • Infraestructura • Reflexiones

[ Novedades ] WCF

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Susana Tamayo Asesoría Editorial Edgardo Domínguez Arte y Diseño Dafne Ortega Oscar Sámano Consejo Editorial Francisco Camargo, Ralf Eder, Raúl Trejo, Guillermo Rodríguez, ITESM-CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek; Luis Vinicio León, e-Quallity - ITESO.

Editorial Quizá muchos de ustedes se vean sorprendidos con la portada de esta edición, la número13 de SG, la primera del año que apenas comienza. Y es que para abrir este 2007, decidimos enfocarnos en un tema que está de moda: los videojuegos. Al igual que todos los temas que abordamos, hemos buscado hacerlo desde la perspectiva no de usuarios, sino de creadores. Por otra parte, escoger este tema nos permitió tomarnos algunas libertades no sólo en el diseño, sino también en los contenidos. Consideramos que este número tiene un buen balance de temas y niveles de profundidad. Tenemos desde artículos amigables que van dirigidos al público en general, hasta los muy clavados que son para nuestros fieles gurús. Tal vez por error llegue a haber algunos despistados que tomen esta revista pensando que encontrarán información sobre los últimos juegos y consolas. Al principio se llevarán una desilusión, pero estamos seguros que se les pasará cuando descubran que aquí hay información para aprender a desarrollar sus propios juegos. Además del desarrollo de videojuegos, tenemos un artículo especial que recalca la importancia y necesidad de los centros de desarrollo de software en las universidades. Consideramos que estos centros son vitales para generar los profesionistas de software que necesitamos. Com-

ENE-FEB 2007

plementamos todo esto con las opiniones de nuestros columnistas, que ya son parte fundamental del contenido; echaremos un vistazo por Windows Communication Foundation, que es uno de los pilares de Windows Vista; veremos cómo determinar el ROI de un esfuerzo de mejora de procesos, y también conoceremos sobre los famosos POJOs. Vale la pena hacer un paréntesis para mencionar que durante todo el tiempo que estuvimos haciendo este número, cada que se mencionaba el término POJO, Susana no podía evitar pensar en cierta ave de color amarillo. Mientras editábamos los textos de este número, llegamos a la conclusión de que tienen un dejo de nostalgia, porque la mayoría de los colaboradores que participaron, hacen referencias al pasado, a su juventud. En realidad, queremos llegar tanto a los jóvenes que apenas comienzan como a todos aquellos que crecieron mirando la evolución de un mundo que hoy nos ha rebasado. Equipo Editorial

FE DE ERRATAS: Queremos pedir una disculpa porque en el número anterior Jorge Palacios escribió el reportaje del Cluster FidSoftware y no apareció su crédito; por otra parte, el subtítulo en la columna de Hanna Oktaba debió decir: International Process Research Consortium (IPRC).

Colaboradores Ariel García, Sergio Orozco, Luis Daniel Soto, Jaime Sánchez, Marco A. Dorantes, Jorge Palacios, Joaquín Arellano, Carlos Gutiérrez, Oscar Guillén, Angélica Su, Alfredo Calvo, Ixcoatl Pérez, Omar Gómez, Ana Vázquez, Mario Gutiérrez, Haarón González, Charlie Macías, Emilio Osorio, Consuelo Jiménez, Joel Villagrana. Ilustración de Portada www.tollhaus.com.mx Ventas Claudia Perea Marketing Natalia Sánchez Circulación y Subscripciones Daniel Velázquez Contacto info@softwareguru.com.mx +52 55 5239 5502

SG Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 04-2004-090212091400102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en diciembre de 2006 en Litográfica Roma. Distribuido por Rrecca Comercializadora y Sepomex.

www.softwareguru.com.mx

contenido ene-feb 2007 EN PORTADA

Desarrollo de Videojuegos Nuestro artículo de portada en esta ocasión, abarca desde los primeros pasos hacia la creación de videojuegos hasta un amplio panorama de esta industria y la oportunidad que representa para nuestro país.

Productos LO QUE VIENE 12 IBM Rational SDP, Apache Axis 2, JBoss Seam y Unity3D NOVEDADES 14 Windows Communication Foundation

Especial Centros de Desarrollo de Software en Universidades

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

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

Mejora Continua por Luis Cuellar

Tierra Libre por Emilio Osorio

Tendencias en Software por Luis Daniel Soto

Prácticas MEJORA DE PROCESOS Análisis de ROI

La mejora de procesos requiere una inversión significativa de recursos. Alfredo Calvo y Angélica Su nos explican cómo estimar el ROI.

DISEÑO POJOs y Frameworks Ligeros

Ixcoatl Pérez nos muestra cómo combinar POJOs con frameworks como Spring e Hibernate, para desarrollar aplicaciones empresariales.

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

En Cada Número

Entrevista

Bill Plympton, René Castillo, Ernesto Gálvez

www.softwareguru.com.mx

Noticias y Eventos CLÚSTERS UML Fundamentos INFRAESTRUCTURA REFLEXIONES

04 06 42 50 52 56

ENE-FEB 2007

// NOTICIAS

Oracle Open World Del 22 al 26 de octubre, los más innovadores desarrollos en tecnología, aplicaciones y soluciones desfilaron por el Centro Moscone de San Francisco, California, durante el Oracle OpenWorld 2006. En un imponente ambiente de alrededor de 41 mil participantes de todo el mundo, se llevaron a cabo más de 1,400 sesiones en torno a las principales aplicaciones de Oracle, 400 demos en vivo de desarrolladores, conferencias a cargo de importantes usuarios y ejecutivos de Oracle, y una Expo con más de 300 expositores. Durante el evento, como noticia principal y sorpresa para muchos, Oracle anunció que dará soporte total a estándares abiertos, por medio del programa llamado Unbreakable Linux.

Lanzamiento de Windows Vista El pasado 29 de noviembre se realizó la presentación de Windows Vista y Office 2007, dedicada a los desarrolladores de software y profesionales de TI. Dicho evento se realizó en el World Trade Center de la Ciudad de México, y resaltó por su magnitud y variedad. La gran sorpresa fue que la conferencia de arranque la impartió Jesús Ramírez, Director Técnico de la Selección Sub 17 de futbol, actuales campeones mundiales. Su plática estuvo enfocada en el poder de la mente cuando se aplica de manera correcta, y en la importancia del trabajo en equipo. Posteriormente se llevaron a cabo sesiones para ahondar en los distintos detalles de esta nueva versión, y el nuevo modelo de desarrollo de aplicaciones que introduce.

Toman Protesta los Miembros de la Mesa Directiva de la ANIEI El pasado 12 de diciembre, en las instalaciones de la Rectoría de la UAM, se llevó a cabo la toma de protesta de los miembros de la Mesa Directiva de la Asociación Nacional de Instituciones de Educación en Informática (ANIEI). Para su periodo 2006 - 2008, la Lic. Ma. de Lourdes Sánchez, por segunda ocasión, estará a cargo de la presidencia de esta asociación. La ANIEI ha fungido como pieza fundamental en la vinculación Industria-Academia-Gobierno, ya que entre sus principales objetivos está el ejecutar la estrategia 2 del programa PROSOFT, enfocada en diseñar el modelo paracurricular de Desarrollador de Software, Ingeniero de Software, Arquitecto, y Administrador en Proyectos, así como adecuar los modelos educativos relacionados con la informática, tareas clave para el esperado crecimiento de la industria de software en México.

ENE-FEB 2007

www.softwareguru.com.mx

// EVENTOS

13 al 16 Febrero 2007

27 Febrero al 2 Marzo 2007

Congreso Nacional de Software Libre Facultad de Ingeniería UNAM, Cd. de México Info: www.consol.org.mx Email: consol@consol.org.mx

Expo Comm 2007, Von Conference & Expo, Expo Móvil Centro Banamex, Cd. de México Info: www.expocomm.com.mx Tel: (55) 1087-1650 ext. 1160 Email: marcela@ejkrause.com

27 Febrero 2007

22 al 24 Marzo 2007

Select Centro Banamex, Cd. de México Info: www.select.com.mx Tel: (55) 5256 1426 Email: liliana.garcia@select.com.mx

Centro de Investigación en Matemáticas (CIMAT) Hotel Real de Minas, Guanajuato, Gto. Info: www.cimat.mx/Sitios/seissigma Email: seissigma@cimat.mx

CONSOL 2007

Tendencias 2007

Softtek, Única Empresa Privada que Opera dos Centros CMMI5 y uno CMM5 en América Latina Softtek concluyó con éxito la valoración en CMMI 5 de sus Centros de Entrega de Servicio Near Shore en Aguascalientes y México D. F. Estos se suman al Centro en Monterrey, que fue evaluado CMM 5 en 2004. Blanca Treviño, Presidente y CEO de Softtek comentó: “El contar con una red de Centros certificados en los más altos niveles de CMM, proporciona cuantiosos beneficios a nuestros clientes en función de productividad, eficiencia en costos y certeza de resultados.” Softtek ha sido pionero en la implementación de prácticas de ingeniería de software en América Latina, y en los servicios de Near Shore outsourcing. Hoy en día, la empresa cuenta con 7 Centros, 4 de ellos en México, 2 en Brasil, y uno más en España, a los que se sumará un nuevo Centro en Asia que iniciará operaciones hacia finales de 2007.

IMSS, Primer Organismo de Gobierno en Alcanzar la Evaluación CMMI La Coordinación de Tecnología para la incorporación y Recaudación del Seguro Social (CTIRSS) fue acreditada con el nivel 3 de capacidad y nivel 2 de madurez de CMMI. La CTIRSS, a cargo del Lic. Marco Rojano, quien forma parte del equipo del Lic. Igor Rosette, Director de Innovación y Desarrollo Tecnológico del IMSS, se ha convertido en la primera unidad de gobierno en México y una de las 50 a nivel mundial en obtener dicha evaluación. Esto representa una recompensa al esfuerzo de más de 3 años de trabajo de un área conformada por más 60 personas, quienes además de desarrollar y mantener en operación más de 50 aplicaciones que soportan los procesos de incorporación y recaudación de todo el Instituto, se pusieron como meta el hacer crecer una organización de clase mundial. www.softwareguru.com.mx

Linux World Conference & Expo

III Simposio Metodología Seis Sigma

TI-M, Primera Empresa en el Norte de México en Obtener CMMI Nivel 3 TI-M (anteriormente TI Móvil) fue acreditado bajo el nivel 3 de CMMI. La implementación y evaluación fueron posibles gracias al apoyo de consultores de It Era. El proceso de implementación tuvo una duración total de dos años, y el grupo evaluador fue dirigido por el SCAMPI Lead Appraiser Carlos Galván. TI-M se ha destacado por minimizar el riesgo en el portafolio de proyectos de TI y maximizar el rendimiento de las inversiones de clientes como Ternium-Hylsa, Sigma Alimentos, Ipsos Bimsa, entre otros.

GULEV Congreso Internacional de Software Libre 2006 Del 7 al 9 de diciembre se llevó a cabo la VI edición del GULEV Congreso Internacional de Software Libre, en Cancún, Quintana Roo. Este año se contó con la presencia de algunas de las más importantes figuras del Software Libre como Miguel de Icaza (Novell) quien ha iniciado proyectos como GNOME y Mono, Rasmus Lerdorf creador de PHP uno de los lenguajes de programación más populares en el mundo, Bruce Momjian creador de PostgreSQL un potente gestor de Bases de Datos, Bdale Garbee (HP) y por primera vez en un evento en latinoamerica, Guido Van Rossum, creador del lenguaje Python. El evento fue un éxito, y se anunció que próximamente habrá muy gratas sorpresas alrededor del evento de Software Libre con mayor tradición en México. ENE-FEB 2007

// REPORTAJE

/* CLÚSTERS */

Teraloc

De Morelos para Todo México Por Jorge Palacios

Teraloc es una integradora de empresas del área de Tecnología de Información, que está basada en la ciudad de Cuernavaca, Morelos y opera desde 2003. Principalmente se enfoca a desarrollar y comercializar productos de sus asociados para la gestión publica, apoyándose en diferentes herramientas y distintas metodologías en las que se trabaja la administración de proyectos, ITIL, PSP/TSP.

Teraloc cuenta con 6 socios, que son: •Synerware - Especializada en el software para agencias automotrices. •Morelos Web - Dedicada al desarrollo y hosting de paginas web para el Estado de Morelos. •Victec - Enfocados al desarrollo de aplicaciones de referenciación geográfica. •AE Sistemas - Desarrolla aplicaciones administrativas dando servicios a la medida de las necesidades del cliente. •Pineda y Asociados especializados en metodologías para BPM. •AFRM procesos - que se dedica al modelado de procesos. La unión de estas seis empresas, da como resultado, Teraloc, que como ya explicamos, es una integradora de empresas de TI en el estado de Morelos. Estas forman parte de la Asociación de la Industria del Software en Morelos, que es la AISAC. Teraloc surge con el objetivo de crear un corredor tecnológico en esta zona, estableciéndolo como la integradora y la Asociación de Intelsoft.

¿Por qué Teraloc? El vocablo Teraloc proviene de la combinación del prefijo Tera, que se refiere a cantidad 1x1012, como se entiende en Megabytes, Gigabytes y Terabytes, y Loc, que se refiere a las siglas utilizadas para referirse a líneas de código (lines of code). Este nombre se debe a que el enfoque inicial estaba orientado a la maquila de desarrollo de software. Sin embargo, la experiencia ha hecho ver a Teraloc, que es mejor enfocarse en segmentos de mayor valor, y por eso ha decidido enfocarse en la gestión y automatización de procesos de negocio (BPM), y metodologías de administración de proyectos y desarrollo de software. Como ya mencionamos, Teraloc nació hace cuatro años, al parejo del programa ProSoft. Desde un inicio han contado con el apoyo de dicho programa, y han aprovechado los recursos provenientes de este fondo para dirigirlos principalmente al área de capacitación. De hecho, Teraloc fue la primera compañía del estado de Morelos en firmar un convenio con Prosoft, siendo la primera entidad para el desarrollo del impulso del software.

Pero las habilidades del personal no son todo. También se necesitan procesos maduros y repetibles, y clientes interesados en adquirir tus productos y servicios. Fue por eso que desde un inicio, Teraloc definió un plan de desarrollo estratégico, que además de la capacitación, consideraba otros aspectos como la definición de procesos, y la generación de demanda. Los resultados de tales esfuerzos han sido, sin duda positivos, dando como resultado que la oferta de valor de Teraloc sea más competitiva en términos de calidad y precio. Adicionalmente, Teraloc provee soluciones para la comunidad, tales como apertura de empleos y soluciones a nivel gubernamental.

Mercado meta Teraloc tiene bien definido cual es su mercado meta, el cual está compuesto de: •Empresas medianas y grandes que necesiten redefinir y/o automatizar sus procesos internos y externos a través de diversas tecnologías de información para dar un soporte adecuado en la toma de decisiones. •Micro y pequeña empresa agrupada. •Gobierno en sus 3 niveles.

Principales logros Entre los logros más recientes de Teraloc y sus empresas asociadas, podemos resaltar los siguientes: •Selección de Syner IP para el programa de aceleración Techba en Austin, Texas. •Creación de la cátedra AISAC en el ITESM Campus Ciudad de México y Santa Fe. •Definición del Modelo APTI de TeraLOC para la administración de proyectos de TI y su adopción en la AISAC. •Plataforma e-learning para capacitación a distancia vía web. •Integración de IT Learning en el consejo de educación a distancia de la Secretaría de Economía. Para mayor información, visita www.teraloc.com.

La primera etapa en el desarrollo de Teraloc, estuvo enfocada en la generación y formación de recursos humanos. Teraloc desde el principio se ha manejado con un enfoque académico en la formación de gente, generando confianza a través de cursos de capacitación donde reciben certificaciones conjuntas. De acuerdo con la gente de Teraloc, esto ha sido la base para establecer lazos de comunicación y, que la integradora siga funcionando y dando grandes resultados.

ENE-FEB 2007

www.softwareguru.com.mx

// COLUMNA

/*TEJIENDO NUESTRA RED*/

Lo Que Pasó en Luxemburgo Avances de MoProSoft en el WG24

La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fundadora de la AMCIS. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

n esta ocasión voy a contarles sobre la segunda participación de la Delegación Mexicana en una reunión del ISO/IEC JTC1 SC7 WG24, cuyo nombre es “Software Life Cycle Profiles and Guidelines for use in Very Small Enterprises (VSE)”. Ya en el número de julio-agosto 2006, platicamos sobre la primera participación de la Delegación en la ciudad de Bangkok, donde nuestra norma mexicana basada en MoProSoft y EvalProSoft fue presentada y se seleccionó, de entre varios documentos similares de otros países como base para los trabajos del grupo. En esa primera reunión, la Delegación Mexicana se comprometió a realizar la traducción de MoProSoft al inglés; realizado en un grupo de trabajo que integra el NYCE (el organismo que emitió la norma), y que se entregó a través de la Dirección General de Normas, al responsable del WG24. La Delegación en esta ocasión estuvo integrada por Francisco López Lira, Ana Vázquez y yo, que somos miembros de la AMCIS y hemos trabajado en diversos proyectos relacionados con la norma. El objetivo fue incluir en los productos del WG24 la mayor cantidad de elementos de MoProSoft. La reunión se llevó a cabo en Luxemburgo del 2 al 6 de octubre, y asistieron delegados de Bélgica, Luxemburgo, Finlandia, Canadá, Irlanda, Estados Unidos, Tailandia, Sudáfrica y Australia, siendo ésta, la primera participación de los dos últimos. El objetivo de dicha sesión fue definir el conjunto de actividades que las VSE implementarán en su primer ciclo de mejora, y que en adelante, llamaremos “primer perfil”. Las actividades realizadas fueron las siguientes: •Presentación de las cuatro partes de la norma MoProSoft. •Selección de los procesos de MoProSoft que integrarán el primer perfil. •Selección de las actividades de estos procesos que integrarán el primer perfil.

ENE-FEB 2007

Después de hacer un análisis de los objetivos de cada uno de los procesos, así como los costos y beneficios asociados, los procesos seleccionados fueron los que se encuentran en la categoría de Operación: Administración de Proyectos Específicos (APE) y, Desarrollo y Mantenimiento de Software (DMS). Los participantes se dividieron en dos grupos para analizar las actividades de cada uno de estos procesos, y seleccionar las que consideraban indispensables para el primer perfil. Nuestro papel consistió principalmente, en explicarles el “porqué” de algunos elementos que tiene el modelo y su relación con la práctica que conocemos. Posteriormente, se realizó una discusión conjunta de ambos grupos para generar consenso. Cabe aclarar que no contaban con el “acordeón”, de la versión “coloreada” por niveles de capacidades. En general, las actividades seleccionadas del proceso de Administración de Proyectos Específicos fueron las que corresponden al nivel de capacidad 1, y de Desarrollo y Mantenimiento de Software de los niveles 1 y 2. Dicho de otra forma, del proceso APE se eligió la planeación, registro y control de los principales parámetros de administración de proyectos como costo, tiempo y riesgo, mientras que del DMS se escogieron las actividades de Especificación de Requerimientos, Análisis y Diseño, Construcción, Integración y Pruebas, con sus respectivas verificaciones y validaciones. En adición, se incluyeron algunas actividades para controlar los cambios y las versiones de los productos, subsanando así la ausencia del proceso de Conocimiento de la Organización en este primer perfil. ¿Nada nuevo? En realidad no, ya que estas buenas prácticas están contenidas en otros estándares como el ISO/IEC 12207, además de ser conocidas por buena parte de la industria. Lo que sí pretende aportar el WG24,

son herramientas de diversos tipos para ayudar en la implementación de estas prácticas en las VSE, como son la secuencia de actividades, roles, descripciones de productos, formatos, etcétera. La próxima reunión será en mayo de 2007, en San Petersburgo. Para entonces se espera que el delegado de Finlandia, Timo Varkoi, experto en el estándar ISO/IEC 12207, tenga el mapeo de MoProSoft hacia esa norma, que este primer perfil haya sido revisado o probado en los países de origen de los delegados, y que los documentos del grupo tengan un número ISO/IEC asignado. El trabajo va para largo. Ya nos dimos cuenta que con dos reuniones de trabajo al año no se puede avanzar mucho. El objetivo es generar una secuencia de 3 a 4 perfiles, cada vez más amplios, no necesariamente correspondientes a niveles de capacidades o de madurez, que sirvan de guía a las empresas. El perfil final incluirá a MoProSoft completo. Y de Luxemburgo... lo que les podemos contar es que es un país con historia milenaria. Su número de habitantes no rebasa a la delegación más pequeña del DF, no tiene fronteras; es por supuesto muy limpio, y tiene la parte antigua con castillos y callejones como de cuento de hadas. Sin embargo, es un país fundador de la Unión Europea, un país que hace competencia a Suiza en el área bancaria y, que a la vez, está preocupado por apoyar e innovar a sus pequeñas empresas. Nuestros anfitriones fueron del Centre de Recherche Public Henri Tudor, el cual desde hace veinte años se dedica al apoyo de las PyMES en el uso de las Tecnologías de Información para su beneficio. Otra vez nos da envidia, ¿verdad? Mejor aprendamos de otros y agreguemos nuestros granitos de arena. Porque lo que podemos hacer, también puede servir de ejemplo a los demás. — Hanna Oktaba y Ana Vázquez www.softwareguru.com.mx

// COLUMNA

/*MEJORA CONTINUA*/

Procesos y Variabilidad

La Diferencia entre Productos y Servicios Luis R. Cuellar es Director de Calidad a nivel mundial de Softtek Information Services. Luis es reconocido por la American Society for Quality (ASQ) como Certified Quality Manager, Certified Software Engineer, y Six Sigma Black Belt. En los últimos cinco años ha estado a cargo de la definición e implantación de la estrategia para CMMI5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

ltimamente he tenido que viajar a diferentes lugares, lo que me ha dado algo de tiempo para leer. En la Harvard Business Review de noviembre 2006, encontré un artículo sumamente interesante, titulado: “Breaking the Tradeoff of Efficiency and Services”. El artículo, básicamente habla sobre el hecho de que una de las grandes diferencias entre las compañías de productos y las de servicio, radica en que en una organización de servicios, el cliente constantemente irrumpe en la operación, a través de un comportamiento impredecible, pidiendo servicios en tiempos no apropiados, una gran cantidad de actividades adicionales, o cambiando continuamente de opinión. Esto genera grandes variaciones en el proceso, y hace mucho más complicada la operación orientada a servicios, que la enfocada a producto. En un servicio, conforme aumenta la variabilidad, también aumenta el costo. Por ejemplo, si el cliente cambia con frecuencia de decisión, en cuanto a si quiere su sistema con una funcionalidad específica o no, el costo de la aplicación se eleva, y se genera trabajo que finalmente no se utilizará. Para poder resolver esta problemática, el autor del artículo que leí, plantea la necesidad de definir el tipo de interrupción que genera el cliente, y tomar la decisión entre: a) Manejar la variabilidad en forma controlada. Por ejemplo, los procesos de Starbucks están diseñados para ofrecer un gran número de opciones, y aun así, controlarlas dentro del mismo proceso. b) Reducir la variabilidad. Por ejemplo, un restaurante maneja tipos de cocina y menús para reducir las posibilidades de variación dentro de las elecciones a seguir.

Máquinas y personas Tal vez lo que más me llamó la atención del artículo, fueron las implicaciones que esta diferencia entre productos y servicios tiene en el área de sistemas. Todos sabemos que desarrollar sistemas es, tanto un producto (el sistema en cuestión) como un servicio (análisis de la problemática, diseño de la solución, etcétera). Esta dualidad hace que el desarrollo de sistemas sea una labor sumamente compleja y llena de decisiones, y el gran problema que nos trae es que lo que a un cliente dejó sumamente maravillado, a otro simplemente no le trae ningún valor, por lo que es difícil hacerlo repetible. Por desgracia, muchas de las teorías de Ingeniería de Software y modelos de Calidad, se basan en modelos de manufactura, en donde el cliente genera una variabilidad mínima. Esto nos lleva a una amplia diferenciación entre dos extremos de pensamiento: por un lado están los que ven la calidad como una lista de proceso, plantillas, y reglas inquebrantables que todo proyecto debe seguir para minimizar la variabilidad. Por otro lado, están los que piensan que no tienen sentido los modelos de calidad, pues por más procesos que se tengan, siempre existirán miles de decisiones que se

ENE-FEB 2007

toman en su momento, y lo mejor es tener gente inteligente que pueda resolver de forma autónoma todos los problemas que se le presenten. El proceso que se siga, será a discreción de dichos individuos. La estrategia de calidad inteligente, es precisamente la que se mueve en medio de estos dos mundos, la que da una serie de reglas, prácticas técnicas y lineamientos. Se asegura que éstos se sigan de acuerdo a como se planeó al principio del proyecto, y tiene apoyo constante del resto de la organización para asegurarse de lograr un buen balance entre flexibilidad y variabilidad.

Ni muy muy ni tan tan Veamos de nuevo el desarrollo de software como un servicio. Los procesos de calidad tienen dos funciones primordiales: 1) Lograr generar un producto sin defectos y bajo un presupuesto predeterminado 2) Reducir el costo de manera constante al capitalizar el conocimiento, para que el siguiente producto se haga de forma más rápida. En otras palabras, estamos buscando complacer al usuario lo más eficientemente posible, por ende, con la menor variación posible. Así, todo proyecto debe iniciar preguntándole al cliente cuáles son sus requerimientos no funcionales más importantes y por qué. Con esta información, podemos crear una serie de métricas que nos ayuden a ver si estamos cumpliendo con lo que un cliente en particular considera calidad. Algunos clientes tienen muy claro que las métricas más importantes de su proyecto son la entrega a tiempo, sin defectos y bajo el presupuesto acordado. Sin embargo, tenemos muchos otros con ideas diferentes, hay algunos que no les preocupan esas cosas; buscan una compañía con la que se puedan entender, por lo que para ellos, lo más importante es la flexibilidad en la forma de trabajo, y una gran comunicación entre las personas del proyecto. Mientras que a otros, lo que les interesa es que su gente se quede con el conocimiento necesario, aunque cueste más caro. Sin importar cuáles son los requisitos, es muy importante conocerlos, medirlos, y en base a ellos, establecer en dónde se debe guiar al cliente y en dónde seguirlo.

A final de cuentas Bajo ningún motivo, un proceso substituye a tener gente capaz de resolver y entender las necesidades del cliente. Por lo tanto, la idea de que exista un proceso, es buscar cómo disminuir, en la medida posible, la mayoría de las variaciones en el proyecto, para así lograr resultados más eficientes, y al mismo tiempo tener a nuestros clientes siempre contentos, sin importar lo que estén buscando. —Luis Cuellar www.softwareguru.com.mx

// PUBLIREPORTAJE

eDeveloper V10 de Magic Software Enterprises es el nuevo paso evolutivo de una herramienta de programación que por más de dos décadas, ha estado entregando tecnología innovadora para los desarrolladores de aplicaciones que se enfocan en minimizar los costos, ajustándose a los estándares que prevalecen en la industria.

uchos de los conceptos actualmente aceptados como parte esencial para la administración de todo el ciclo de desarrollo, han sido la parte central de la productividad de eDeveloper a través de toda su historia. Estos conceptos incluyen: repositorios para abarcar las descripciones de una aplicación completa, Reglas de Negocio para obtener los mayores niveles de abstracción, Desarrollo Declarativo por medio de metadatos para reducir la codificación de manera drástica. Todo esto se logra sin definir una sola línea de código, ya que todas la reglas de negocio están interconstruidas en el motor autómata, que es el núcleo central de la tecnología Magic. Esto nos lleva a ser un Lenguaje visual 4GL y, a ser considerados como una herramienta RAD+D, donde la última D, es la facilidad de poner en Ejecución (Deployment) nuestros desarrollos. Aunado a esto, tenemos la posibilidad de que las aplicaciones desarrolladas con eDeveloper sean rápidamente escalables, facilitando la implementación de nuevas versiones de sus sistemas. También tenemos la capacidad de que sus desarrollos corran en distintas plataformas, como UNIX, Linux o Windows, y con conexiones a las bases de datos líderes en la industria, incluida la capacidad de explotar datos de sistemas AS/400. Tenemos un rápido Retorno de la Inversión hecha con eDeveloper, ya que las ventajas que se le presentan al programador, le permiten incrementar su eficiencia. Las mayores ventajas que se otorgan son el uso de un paradigma de desarrollo uniforme, tanto para aplicaciones C/S o para Web; una independencia de la base de datos a utilizar, permitiendo que el desarrollador se olvide de las tareas mundanas de conexión a las distintas bases de datos que pudieran utilizarse en su organización; la interoperabilidad con las distintas tecnologías emergentes, como el uso de XML, ejecución de servicios de mensajería MSMQ, la interacción con plataformas J2EE y el uso de Web Services. Con estas características de conexión tan diversas, tenemos la capacidad de generar aplicaciones compuestas, sin que esto disminuya la velocidad de desarrollo.

Lo que nos permite ser compatibles con las Arquitecturas Orientadas a Servicios (SOA), y a su vez, ser una herramienta para el Desarrollo de Aplicaciones Orientadas a Servicios (SODA), pero siempre contemplando los estándares existentes en la industria; como en el caso, por poner un ejemplo, de nuestra conexión a Systinet, que es un aplicativo estándar para la comunicación, tanto de consumo como de proveedor de Web Services. Nuestros desarrollos se guardan en documentos XML, pero sin que el desarrollador tenga que escribir una sola línea XML. eDeveloper es tan compatible con XML, que puede ocupar un documento XML, y editarlo como si se tratase de una tabla de una base de datos. El entorno de desarrollo, conocido como Editor de Tareas, conjunta todas las características necesarias para el desarrollo de la lógica, así como la presentación de un programa o tarea. La edición de las formas que se dispondrán al usuario final, podrán tener la mejor presentación, siendo compatibles con los estilos gráficos de Windows XP, para el caso de aplicaciones C/S, o compatibles con los estilos diseñados por el editor de páginas HTML de su elección, para el caso de aplicaciones Web. El programador podrá trabajar de la misma forma en C/S como en Web, basados en un mismo paradigma de desarrollo. Todo está basado en una tecnología que conocemos como Browser Client, el cual, pondrá a nuestra disposición, la facilidad de crear aplicaciones para Internet o Intranet, pero dándole al usuario final, la apariencia de que trabaja en C/S. Un concepto de una aplicación para cliente ligero basado en un navegador. El motor autómata permite ejecutar nuestras aplicaciones ya sea corriendo dentro del módulo de ejecución de aplicaciones, como en el caso de aplicaciones Stand-Alone o C/S, o corriendo como servicios, para el caso de Servidores de Procesos o Servidores de Aplicaciones Web. Y con la capacidad de portabilidad a distintas plataformas, esto nos ofrece un espectro de posibilidades mayor. Esto, y mucho más, es el eDeveloper V10. Mayor información en www.rocasistemas.com.mx

// PRODUCTOS

/* LO QUE VIENE*/

Rational Software Delivery Platform 7.0 Desarrollo Global de Aplicaciones SOA

IBM lanzó la versión 7 de su línea de herramientas de desarrollo de software, Rational Software Delivery Platform (SDP) que es un conjunto de herramientas para desarrollar software, basadas en Eclipse, y complementada con procesos que engloban mejores prácticas, como el Rational Unified Process. Esta versión está principalmente orientada a la construcción y mantenimiento de aplicaciones orientadas a servicios. Otro aspecto importante, es que atiende las características y necesidades del desarrollo de software moderno y global, donde los equipos de desarrollo están dispersos geográficamente, por lo que las herramientas de desarrollo deben soportar y facilitar esta forma de trabajo. Algunos de los productos específicos incluidos como parte de esta nueva versión están: •IBM Rational Application Developer – Un IDE completo para diseñar, desarrollar, depurar e instalar aplicaciones SOA y J2EE en ambientes empresariales. •IBM Rational Software Modeler – Un modelador visual basado en UML 2.1, para que los arquitectos, analistas y diseñadores plasmen y comuniquen los requerimientos y diseño de los sistemas a construir. •IBM Rational Functional Tester – Una herramienta de pruebas avanzada que provee pruebas automatizadas funcionales y de regresión. Más información en www-306.ibm.com/software/rational

Apache Axis2

JBoss Seam 1.1

Aplicaciones Web con Funcionalidad Compleja, pero Desarrollo Sencillo Seam es el framework de JBoss para desarrollar aplicaciones Web 2.0. Dicho framework integra tecnologías populares como AJAX, Java Server Faces, EJB3, Java portlets y workflow, bajo un modelo unificado. Seam facilita el desarrollo de aplicaciones web ricas y basadas en estados (stateful), a través del manejo sencillo de objetos con estado, que residen en el servidor, que interactúan con componentes AJAX del lado del cliente. La versión 1.1 de Seam se liberó recientemente, y entre sus nuevas capacidades están: •Modelo de componentes basado en POJOs, que elimina la dependencia a EJBs para manejar estado. •Nuevo framework de persistencia basado en Java Persistente API e Hibernate. •Integración con ICEfaces y Ajax4jsf para generar componentes GUI de nueva generación. •Soporte de conversaciones atómicas, las cuales son requeridas por el modelo de operación de las aplicaciones AJAX. Mayor información en www.jboss.com/products/seam

Web Services Open Source de 3ra Generación

Axis2 es un motor de web services desarrollado por la Apache Software Foundation, y por lo tanto, open source. Axis2 se encuentra actualmente en su versión 1.1, la cual fue recientemente liberada y recibida con gran entusiasmo por la comunidad. De acuerdo con los expertos, hoy en día estamos en la tercera generación de middleware para web services, y Axis2 forma parte de ésta. Mientras que las dos primeras generaciones se enfocaron en demostrar que los web services “eran posibles”, la tercera generación se enfoca en hacerlos eficientes y confiables. Es decir, algo que vaya más allá de los prototipos, y que sea una alternativa real para sistemas de misión crítica. Apache Axis2 fue diseñado y construido desde cero, a partir de las lecciones aprendidas con Apache Axis, el cual puede ser considerado un middleware de web services de 2da generación. Axis2 es mucho más eficiente, escalable y modular que su antecesor. Además, es altamente extensible a través de módulos opcionales para soportar especificaciones avanzadas de web services como son WS-Security, WS-Trust, WS-Reliable Messaging, o WS-Eventing. Más información en ws.apache.org/axis2

ENE-FEB 2007

Unity 1.6

Desarrollo de Juegos 3D Multiplataforma Unity es una herramienta para desarrollar juegos de 3D, que se pueden ejecutar en un navegador web, o standalone. Con Unity se puede generar gráficas de gran detalle, a una gran velocidad. Vale la pena notar ue, Unity utiliza Mono como máquina virtual para la ejecución de scripts multiplataforma. Unity es utilizado por diversos estudios desarrolladores de juegos, y recibió el segundo lugar en la categoría “Mejor uso de las gráficas de Mac OS X”, durante el pasado Developer Conference de Apple. En el sitio web de Unity (unity3d.com) se puede descargar una versión de evaluación, y también se puede echar un vistazo a la galería de cosas hechas con dicha herramienta. Quedarás impresionado por el detalle y velocidad de las gráficas que se ejecutan en tu navegador.

www.softwareguru.com.mx

// PRODUCTOS

/* NOVEDADES*/

Windows Communication Foundation Un Framework para Desarrollar Aplicaciones Distribuidas Por Haarón González

ivimos en un mundo cada día más conectado. Las organizaciones se han enrolado en la era de Internet, ofreciendo servicios electrónicos que les permiten integrar o exponer su información interna, hacia clientes u otros procesos empresariales externos. Esta conectividad, combinada con la necesidad de integrar sistemas heterogéneos, ha influenciado el establecimiento de un nuevo paradigma: las arquitecturas orientadas a servicios (SOA), de las cuales hemos oído tanto en los últimos meses. A pesar de que ya existían múltiples tecnologías para construir este tipo de sistemas, como lo son CORBA y DCOM, en definitiva los servicios web basados en XML fueron un paso importante para descubrir y asimilar el verdadero potencial del concepto de software como servicio, o software que se conecta con software, abriendo una nueva gama de posibilidades para construir aplicaciones distribuidas, debido a la adopción de estándares abiertos para conectar personas, sistemas y dispositivos. Múltiples proveedores de plataformas tecnológicas ya soportan en sus productos el uso de web services y sus estándares para permitirnos integrar sistemas, aunque éstos utilicen diferentes plataformas operativas. Sin embargo, las capacidades de integración a través de servicios web no son del todo ricas, de alguna manera están limitadas a cierto tipo de escenarios. En otras palabras, los servicios web se quedan cortos en funcionalidad. Por ejemplo, hacer trabajar tecnologías J2EE con .NET es factible, pero complicado a la vez, requiere de consideraciones técnicas adicionales para reforzar la seguridad, compartir la identidad de usuario, soportar transacciones distribuidas. Los retos que se tienen en la actualidad para hacer realidad la visión de orientación a servicios son: •¿Cómo podemos asegurarnos de que las conexiones entre los servicios sean confiables, y se repongan a fallos en la comunicación? •¿Cómo establecer todo un mecanismo de seguridad integral para el intercambio de mensajes entre servicios? •¿Cómo crear aplicaciones que expandan sus fronteras de confianza y participen en procesos transaccionales locales y remotos? •¿Qué modelo de programación debo utilizar para construir servicios? •¿Cómo puedo hacer que una aplicación esté orientada a servicios y pueda beneficiarse de este estilo de arquitectura? Para resolver estas necesidades, se ha creado la tecnología Windows Communication Foundation (WCF).

Windows Communication Foundation Es uno de los pilares del .NET Framework 3.0. Básicamente provee un subsistema de programación para la construcción de aplicaciones distribuidas orientadas a servicios. WCF permite el desarrollo de ser-

vicios seguros, confiables y transaccionales que interoperan ya sea con plataformas Microsoft u otras; soportando coexistencia con anteriores tecnologías para aprovechar las inversiones existentes. Ofrece mecanismos de implementación mucho más sofisticados que los que actualmente utilizamos para distribuir servicios y conectar sistemas. WCF combina y extiende las tecnologías actuales para construir sistemas distribuidos bajo plataforma Microsoft, hablamos de .NET Enterprise Services (COM+), MSMQ, .NET Framework Remoting, Web Service Enhancement (WSE), ASP.NET Web Services (ASMX) y System.Messaging, con la intención de proveer un solo marco de trabajo o unificado. Como ya comenté, WCF es parte del .NET Framework 3.0, lo que significa que es parte integral e interna de Windows Vista, pero que también estará disponible en otros sistemas operativos que soporten el .NET Framework 3.0, como Windows XP SP2 y Windows Server 2003 SP1. Adicionalmente, existen proyectos basados en Mono, para llevar soporte de WCF a plataforma Unix/Linux.

Objetivos de Diseño WCF hace posible lo anterior gracias a los siguientes objetivos de diseño: •Soportar internamente un gran conjunto de protocolos para servicios web: las tecnologías actuales para web services proveen soporte para un tipo de interoperabilidad muy básica entre aplicaciones. Por ejemplo, estas tecnologías carecen de la habilidad de lograr interoperabilidad garantizando una seguridad integral y comunicación confiable. WCF soporta interoperabilidad segura, confiable y transaccional, a través de soporte interno para las especificaciones WS-*. •Diseño orientado a servicios: los principios del desarrollo orientado a servicios han permitido hacer frente al reto de construir software que se adapta con rapidez a las necesidades del negocio. WCF es el primer modelo de programación construido desde cero para facilitar implícitamente el desarrollo de aplicaciones orientadas a servicios. •Modelo de programación unificado: WCF provee una API diseñada para el desarrollo de sistemas conectados, lo cual trae mejoras en productividad al desarrollar este tipo de sistemas.

Fundamentos de WCF La figura 1 ilustra el flujo de un servicio que utiliza WCF. Los EndPoint son la unidad principal de exposición de funcionalidad en un servicio, un servicio puede albergar múltiples EndPoint cada uno con su propia configuración. Los EndPoints pueden ser configurados de manera programática (en código) o declarativa (en configuración XML) y son prácticamente nuestros canales de conversación con las aplicaciones cliente o con otros consumidores de nuestros servicios, ya que

Haarón González trabaja para DirectApps, una empresa de Sacramento, CA dedicada a construir soluciones web para automatizar flujos de trabajo, servicios de infraestructura y staffing. Haarón es Licenciado en Informática egresado del Instituto Tecnológico de Mexicali, y cuenta con las certificaciones MCP, MCAD y MCT, además de ser reconocido como Microsoft MVP en la categorÌa ASP.NET, y ser orador regional de INETA (International .NET Association).

ENE-FEB 2007

www.softwareguru.com.mx

definen en donde, cómo y qué se intercambia. Los EndPoints están compuestos por: • Address define: donde exponer un servicio, en otras palabras, una dirección en la red en donde reside un servicio. • Binding define: cómo exponer un servicio, o qué protocolos de transporte (TCP, HTTP), codificación (texto, binario, MTOM) y requerimientos de seguridad (SSL, WS-Security) se utilizarán en la conversación. • Contract define: qué exponer en un servicio, es decir, qué estructuras (datos) y operaciones (métodos) se pueden intercambiar durante una conversación entre servicios.

Un ejemplo sencillo

Una vez definido nuestro contrato, lo implementamos en la clase CalculoService, que es donde realmente existirá la funcionalidad de nuestro servicio. using System.ServiceModel; namespace BasicWCFDemo.Server { [ServiceBehavior(Name = “CalculoService”)] public class CalculoService : ICalculoService { public int Suma(int x, int y) { return x + y; } public int Resta(int x, int y) { return x - y; } public int Multiplicacion(int x, int y) { return x * y; } } }

El siguiente paso es especificar el hospedaje de nuestro servicio, y eso lo hacemos a través de la clase ServiceHost. Con ServiceHost podemos hacer que cualquier aplicación pueda convertirse en un huésped de algún servicio, eliminando dependencias a otros productos del servidor. Por ejemplo, el siguiente código hace que nuestra aplicación de consola sea un huésped de servicio. using System.ServiceModel; Figura 1. Flujo de un servicio con WCF.

Para construir servicios WCF requerimos hacer referencia a System. ServiceModel incluido en .NET Framework 3.0. Primeramente hay que definir el contrato, ya que es muy importante especificar las reglas para lograr una conversación. En WCF existen los atributos DataContract y OperationContract. Los DataContract nos permiten calificar código para que sean tomadas como las estructuras de datos que vamos a utilizar para intercambiar mensajes. Los OperationContract nos permiten calificar código para que sea tomado como los métodos o puntos de entrada que pueden invocarse durante el intercambio de mensajes. Veamos el código para definir un contrato: using System.ServiceModel; namespace BasicWCFDemo.Server { [ServiceContract(Namespace = “http://DemoWCFService.ServiceContracts/2006/11”, Name = “ICalculoService”)] public interface ICalculoService { [OperationContract(Action = “Suma”, IsOneWay = false)] int Suma(int x, int y); [OperationContract(Action = “Resta”, IsOneWay = false)] int Resta(int x, int y); [OperationContract(Action = “Multiplicacion”, IsOneWay = false)] int Multiplicacion(int x, int y); } }

www.softwareguru.com.mx

namespace BasicWCFDemo.Server { class Program { static void Main(string[] args) { Uri direccionUrl = new Uri(“http://localhost:8080/BasicWCFDemoServer”); ServiceHost servicioHost = new ServiceHost(typeof(CalculoService), direccionUrl); servicioHost.AddServiceEndpoint(typeof(ICalculoService), new BasicHttpBinding(), direccionUrl); servicioHost.Open(); Console.WriteLine(“Servicio escuchando...”); Console.ReadKey(); servicioHost.Close(); } } }

Si observamos detenidamente el código, encontraremos que se ha especificado la dirección (address) donde reside nuestro servicio en la red, el canal (binding) utilizado para intercambiar mensajes (BasicHttpBinding) y el contrato usado por el servicio. Aquí es donde sucede la magia, ya que es donde podemos configurar nuestro servicio basado en los tres conceptos más importantes: Address, Binding y Contract.

Conclusión WCF se puede usar para conectar sistemas que se ejecutan en contextos locales, Intranet, Extranet e Internet. WCF provee un marco de referencia unificado y con capacidades avanzadas para el desarrollo de aplicaciones distribuidas. ENE-FEB 2007

// ESPECIAL

¿Centros de Desarrollo de Software en las Universidades? Una Realidad aún sin Explotar Por Joaquín Arellano

de una carrera de Ingeniería ¿paraEldeegresado Software, está realmente preparado afrontar como se debe, los retos que

demanda el mercado laboral?, lamentablemente, en la mayoría de los casos, el alumno promedio sólo obtiene los conocimientos teóricos y prácticos que le enseñan en las aulas, y que a pesar de que son buenos, no son del todo suficientes. ¿Cuál puede ser una de las causas? Hoy en día, no sólo es necesario dominar algún lenguaje de programación orientado a objetos –pensando que es la única opción para un problema–, sino también, poder codificar en el clásico notepad o en un editor básico, saber que existen técnicas de producción de sistemas; aprender de memoria el modelo de cascada o espiral, u otro, saber de la existencia de UML, pero no saberla aplicar; conocer y desarrollar en una sola base de datos, y en general, conceptos básicos del mundo de IT; se requiere ampliar así como profundizar en dichos conocimientos y en muchos más, no por soberbia, sino porque el mercado lo exige, demanda profesionistas mejor preparados en áreas de conocimientos más recientes, cada vez más usadas. Por otra parte, para incrementar su competitividad, el egresado necesita tener un background más amplio de lo que los planes de estudios actuales ofrecen. Esto, debido a que el mercado laboral es muy exigente, competitivo,

y no sólo requiere profesionistas que sepan conceptos y fundamentos básicos de Information Technology (IT, por sus siglas en inglés); sino que también se requiere que estén familiarizados con: •IDEs: como Java Studio Creator 2, Visual Studio 2003/2005, Eclipse, NetBeans, Zend Studio, etcétera. •No sólo dominar un lenguaje de programación (orientado a objetos, estructurado, procedural, etcétera), sino que además, sepan usar de forma básica otros lenguajes (si no dominarlo, saber qué alcance tiene cada uno y cuáles son sus ventajas sobre otros lenguajes) en caso que sea necesario moverse a un nuevo lenguaje. •Cómo interactúan diferentes lenguajes con diferentes proveedores de bases de datos (Oracle, SQL Server, MySQL, Informix, PostgreSQL, etcétera). •La ya tan mencionada Web 2.0. •Modelos arquitectónicos como MVC (Model View Controller), o SOA (Service Oriented Architecture). •Poder entender adecuadamente y llevar a la práctica (en escala) conceptos de ingeniería de software, pasando por modelado de objetos, calidad en el software, PSP, TSP, ITIL y, ¿por qué no?, CMM/CMMI y varios más. •Creación de Software confiable, seguro, adaptable, administrable, entre otros. •Facilidad de adaptarse a cambios, tiempos y tecnologías.

Joaquín Alonso Arellano Ramírez, se ha desempeñado como desarrollador, implementador y administrador de sistemas, coautor del artículo “Confiabilidad del Software: desarrollando productos confiables”. Sus intereses en el área de sistemas incluyen, sistemas en plataforma WEB y Técnicas de Producción de Sistemas. Trabaja en el departamento de desarrollo de sistemas escolares del ITESM Campus Monterrey y forma parte del equipo que implementa el modelo CMMi en el mismo instituto.

ENE-FEB 2007

www.softwareguru.com.mx

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

¿Dónde puede el alumno aprender esto?, dónde más, sino en su misma universidad, ¿de qué forma?, promoviendo centros de desarrollo de software en los que el alumno pueda, de forma voluntaria, involucrarse y profundizar en conceptos como los antes mencionados, mientras desarrolla proyectos reales, que no necesariamente tienen que ser grandes (en complejidad y tamaño) para que el alumno pueda usar los conceptos anteriores, sino a través de proyectos planeados y estructurados, todo, al mismo tiempo que cursa su carrera. Esto ayuda a que el alumno mientras estudia una carrera de Ingeniería de Software, tenga la posibilidad de aplicar todos los conocimientos que adquiere a lo largo de sus estudios, más una gran parte, de los que ya hemos mencionado, en proyectos reales. Muchos de los conceptos, si no es que la gran mayoría, se pueden obtener mediante iniciativas, como por ejemplo:

•Acercamiento con empresas de software que aplican CMM/CMMI, ITIL, PSP, TSP; conceptos de ingeniería de software y herramientas tecnológicas actuales que requieren de los egresados cierto grado de conocimiento. •Una gran gama de sitios en Internet en donde se puede obtener material de alta calidad de los conceptos y tecnologías ya mencionados, y de muchos más, que quizá se me puedan estar pasando. •Acercamiento con gobiernos Estatal y Federal, para incentivar dichos centros en la educación pública y privada.

Estructura propuesta Profundizando un poco en cómo se podrían estructurar dichos centros, considero tres bloques esenciales, como se muestra en la siguiente figura.

•Software gratis. Algunos de ellos se pueden obtener bajo algún tipo de licenciamiento, y en ciertos casos, existen cursos, también gratuitos, que ofrecen las empresas, para capacitarse en el uso de dicha tecnología. •Programas de certificaciones gratuitos, como los que ofrece Microsoft con su Academia Latinoamericana de Management (ITIL), Desarrollador Cinco estrellas 2005, por mencionar uno. •Evaluación de software, que muchas empresas ofrecen, como Flex 2 de Adobe (recién liberado) y las versiones constantes de los productos de Sun, IBM, Zend, ActiveGrid, etcétera. •Convenios como los que algunas universidades tienen con empresas como Microsoft, Macromedia (ahora Adobe), Oracle, Sun, en donde el alumno puede tener acceso a versiones gratuitas de software, o como las versiones educativas que ponen a disposición un gran número de empresas, como Zend Technology. Estructura en 3 Bloques Esenciales.

www.softwareguru.com.mx

ENE-FEB 2007

// ESPECIAL

“De la curiosidad nace el interés, y es por medio de centros de desarrollo de software que el alumno puede despertar su inquietud por conocer más, de lo que los planes de estudio suelen cubrir”.

Zona operativa y de control La integrarían personas que formen parte de las academias de IT de las mismas universidades, y alumnos; es de academias de IT forme parte de esta zona, es para lograr un vínculo entre los salones de clase y los centros de desarrollo de software; mientras que la de los alumnos, es fortalecer los aspectos administrativos y de control de proyectos de software en ellos, y no sólo la parte técnica (el desarrollo del software como tal).

Zona de desarrollo de SW Estaría conformada 100% por los alumnos que hayan obtenido un nivel de conocimientos adecuado, que les permita explotarlo en dichos proyectos. El nivel de conocimiento puede ser delimitado mediante varias formas: de algún semestre en adelante, número de materias cursadas, conocimientos técnicos, promedios, etcétera.

Zona de soporte y apoyo: En esta zona se encontrarían profesionistas de IT externos, empresas públicas y privadas, gobierno y demás personas e instituciones que puedan aportar sus conocimientos para el beneficio de los centros. Las empresas públicas, privadas y gobierno serían los “patrocinadores” de proyectos específicos, aportando SW licenciado para fines educativos, programas de capacitación, charlas, orientación y soporte de las metodologías que usan, por mencionar algunos. La forma puede ser variada, no necesariamente tiene que ser presencial; y los profesionistas de IT aportarían los conocimientos que han adquirido a lo largo de su carrera, permitiendo entre otras cosas, alentar a los estudiantes a seguir creciendo en el mundo de las IT’s y de igual forma, dando soporte a proyectos que les interesen. Como puntos finales es necesario recalcar, que el nivel de conocimientos que un alumno pueda llegar a tener, aprender, manejar y conocer, de los conceptos aquí presentados, dependerá en gran parte, de su propia inquietud, complementada por los consejos y apoyo que reciba de todas las personas que formen parte de los centros, así como de los proyectos manejados. De la curiosidad nace el interés, y es por medio de centros de desarrollo

ENE-FEB 2007

de software que el alumno puede despertar su inquietud por conocer más de lo que los planes de estudio suelen cubrir. Esto con el fin último, de presentar egresados al mercado laboral, con la confianza, el respaldo técnico y conocimientos para enfrentar los retos laborales que el mundo de IT necesita. Sin duda se requiere de inversiones económicas, instalaciones, tiempo, esfuerzo y personal, pero no tienen que ser necesariamente exigentes, es posible hacer uso de mucho de lo que las instalaciones de las universidades tienen, para dar soporte a centros de esta clase y los resultados compensarían la inversión. No es necesario destacar los beneficios que los alumnos principalmente, las empresas públicas y privadas, instituciones educativas y el gobierno podrían obtener, porque son obvios. “El objetivo no sólo es beneficiar al alumno sino también a todas las partes que se vean involucradas en proyectos de este tipo. Las formas de cristalizar los centros son variadas. Se propone una estructura operacional básica de cómo se podrían administrar los centros, pero el hecho es que necesitan realizarse”, como bien lo menciona el Dr. Carlos Montes de Oca en la edición mayo-junio 2006 de la revista Software Guru, y agregaría algo que sin duda muchos compartirán conmigo: que si México quiere competir internacionalmente como país, en el desarrollo de software de calidad, es necesario que los alumnos y egresados estén a la par sobre lo que día con día surge en este mundo cambiante de las IT’s, siendo la propuesta aquí presentada, un medio por el cual se puede lograr.

NOTA El propósito de mencionar el software y las empresas aquí citadas, es con el fin de divulgar el gran esfuerzo hecho, en términos generales, por empresas de TI para dar a conocer a la comunidad los productos, tecnologías y metodologías que ofrecen y promueven bajo diferentes esquemas de licenciamiento.

www.softwareguru.com.mx

// ENTREVISTA

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

Bill Plympton

Software Guru estuvo presente, y tuvimos la oportunidad de platicar con tres interesantes personajes, cada uno con su muy particular estilo y espacio en el universo de la animación 3D y el desarrollo de videojuegos. Se trata de Bill Plympton, con más de veinte años de experiencia, creador de cortos animados como “Guard Dog”; Ernesto Gálvez, CEO y socio fundador de Immersion Games, y René Castillo, animador en stop motion, creador de “Poncho Balón” y de la película animada “Hasta los Huesos”. A continuación lo que compartieron con nosotros.

ENE-FEB 2007

“Sobreviviendo como animador independiente” Nos llamó la atención el título de tu ponencia, ¿qué es lo que compartes con los asistentes? Creo que ahora es un momento muy especial, parece ser que hay mucho interés en la animación. Es la segunda “época dorada” en animación. Y creo que es posible convertirse en un animador independiente y hacer dinero. Me gusta compartir con la gente mi propia experiencia, cómo he sobrevivido haciendo pequeños filmes, comerciales y largometrajes. Me gusta revelar el secreto de mi éxito con las personas, decirles cómo hacer las cosas y al mismo tiempo, mostrar un poco de mi nuevo trabajo. ¿Podrías compartir con nosotros el secreto de tu éxito? Me parece que es muy importante que el filme sea divertido, creo que a la gente le gusta reírse con la animación, por lo tanto, debe ser divertido. También creo que debe ser corto, alrededor de cinco minutos, y deber ser barato, es decir, no invertir cientos y cientos de dólares. Si puedes hacerlo, si puedes cumplir con estos tres requisitos, tu filme será exitoso y podrás hacer mucho dinero. Seguro que hay algunos tips para todos aquellos que quieren iniciarse en la animación independiente. Por supuesto. Quizá el más importante es dibujar, hacerlo siempre, nunca dejarlo; tener un cuaderno donde constantemente se anoten ideas, porque ésas, eventualmente se convierten en proyectos. Es vital también, ver muchos

filmes, es importante conocer la animación, la historia de la animación, debes amarla, deber tener pasión por ella , yo lo hago, trabajo doce horas al día haciendo mis filmes, y esa es la clase de pasión que debes tener. ¿Cuál crees que sea el papel de México en el mundo de la animación? Justo de eso platicaba en la mañana con una persona, México tiene una maravillosa tradición de historias y artistas, desde los aztecas y los mayas, hasta las grandes leyendas; y creo que el artista de hoy, ama al contador de historias, ama las artes visuales, y son exactamente los dos ingredientes que se necesitan para convertirse en un éxito. No creo que se necesite mucho dinero, no creo que se necesite mucha tecnología, sólo contar historias interesantes y entretenidas. ¿Ves futuro en los animadores mexicanos? Bueno, René Castillo es una gran estrella, es una gran celebridad. Lo conocí hace alrededor de cinco años en un festival, y me gustan mucho sus filmes. Me parece que ahora, como sabes, los cineastas mexicanos son muy populares, por tanto, creo que México está explotando, en términos de producción cinematográfica. ¿Cuál es el panorama de la industria actualmente? Creo que está creciendo, y eso hace que sea el momento perfecto para la animación. Hay muchísimos mercados, y trabajos ahí, esperando por el talento.

BILL PLYMPTON Nació en Portland, Oregon el 30 de abril de 1946. Sus filmes cortos se han mostrado alrededor de los Estados Unidos, sobre todo durante festivales de animación. Con un peculiar sentido del humor y visión burlona del día a día, que se reflejan en sus “Microtoons” y otros populares cortos para MTV, Plympton se ha hecho famoso con “Guard Dog” que le valió la nominación al Oscar en 2005. Su más reciente producción se titula “Idiots and Angeles”. Para conocer más de cerca su trabajo: www.plymptoons.com

www.softwareguru.com.mx

René Castillo ¿Cuál fue tu primer encuentro con la animación? Desde niño hacía muñequitos de plastilina, era algo que no podía dejar de hacer, tenía dinero y compraba plastilina para crear monitos diferentes, nunca copiaba, y hacía mis historias. Pero a pesar de ese acercamiento, no contemplé jamás la animación como una posibilidad. Y fue hasta los 23 años cuando iba en el coche, en el radio escuché un anuncio que decía: “curso de animación con plastilina”. Me dije: “yo puedo hacer eso”, así es que llamé, me inscribí y al día siguiente ya estaba ahí. ¿Qué opinas de eventos como Creanimax? Cuando empecé a hacer animación, hace quince años, había dos personas a quién preguntarles, y no te decían nada. Por tanto, esto representa un gran crecimiento, relacionado con la tecnología que nos acerca las herramientas; tiene que ver también con el software, que nos permite ahora, hacer cosas de gran calidad y en un tiempo aceptable. Antes, sólo Disney hacía películas, y usaban novecientas personas para hacer un largometraje. Hoy en día, con cincuenta personas lo puedes hacer, y eso es gracias a la tecnología. Hay como un “boom” en todo el mundo, justamente por eso, porque hay un sinfín de plataformas para hacer animación 3D. Hacer stop motion es laborioso. ¿Cuánto tiempo tardas? Normalmente en un segundo de animación me tardo una hora. Si es complicado y a 24 cuadros por segundo, me tardo hasta cinco horas por segundo. Es que tienes que mezclar escultura, actuación y todo. Es un proceso muy artesanal, extremadamente artesanal, de hecho, es la técnica de animación más cara y lenta de todas. Además hay que tomar en cuenta todo el tiempo previo, hay que hacer los personajes, las maquetas, iluminar, todo lleva consigo una preproducción bastante larga.

¿Qué tipo de software utilizas? La verdad es que utilizo softwares diferentes, pero para stop motion, utilizo Adobe Premiere o Final Cut para hacer un animatic, que es algo parecido a una maqueta que te permite ver cómo será tu proyecto. La animación hay que planearla siempre y mucho, sea la técnica que vayas a usar, siempre hay un trabajo de trazo a lápiz, de story board, y luego un sistema de edición no lineal para armar tu maqueta. Después, para animar stop motion, utilizo un software que se llama Frame Thief, que graba cuadro por cuadro, es muy sencillo porque grabas desde tu cámara, mientras ves cómo corre la animación. Todas son herramientas muy buenas que permiten previsualizar el avance de tu animación. Antes no teníamos nada de esto, y era completamente a ciegas, animabas y después tardabas otros dos días editando cuadro por cuadro, era hasta entonces cuando podías ver cómo se veía. Ahora lo puedes ver al instante. También hacemos animación en Flash, por ejemplo, Poncho Balón. Usamos también software de animación 3D, tanto Maya como 3ds Studio Max y claro, software como Photoshop que es básico y Word para escribir, que es el primer paso. Digamos que la computadora es una parte fundamental. ¿Cómo ves la industria de animación en México? En México hay mucho talento, todavía es una materia pendiente, pero puede llegar a ser una gran industria, representa ingresos importantes para Estados Unidos y Canadá, así como para muchos países asiáticos. Yo creo que podemos ser muy buenos maquiladores a un costo relativamente bajo, súper competitivos con imagen, por ejemplo, pero además, podemos generar propiedades, proyectos. Aunque quizá, el principal problema aquí en México, son los animadores. No encontramos animadores, porque no hay, todavía no están listos, la gente está aprendiendo por su cuenta y eso lleva mucho tiempo. Y es que si te preguntas: ¿qué va primero?, es todo, las escuelas, los proyectos, las empresas, todo va de la mano. ¿Alguna vez te ha cruzado por la mente desarrollar videojuegos? Totalmente, por supuesto, con Poncho Balón ya estoy en pláticas con gente de aquí (Creanimax) para hacer un juego. Me parece magnífico que podamos encontrarnos, y veamos en conjunto todas las posibilidades que tenemos. Porque quizá tú quieras desarrollar un videojuego basado en un personaje que nadie conoce, y eso te dificulte darlo a conocer, pero si yo tengo un personaje, que a parte estoy lanzando, y tengo grandes planes para él, de pronto podemos lanzar un juego, es decir, sumamos esfuerzos.

RENÉ CASTILLO Es egresado de la carrera de Comunicación por el ITESO en Guadalajara, Jalisco. Su afición desde pequeño por modelar personajes de plastilina lo llevó a encontrar en la animación stop motion el lugar perfecto para darle rienda suelta a su creatividad. Muestra de su sobresaliente trabajo son los filmes animados “Hasta los Huesos” y “Sin Sostén”. Además de la animación en Flash, “Poncho Balón”. www.ponchobalon.com

www.softwareguru.com.mx

ENE-FEB 2007

// ENTREVISTA

Ernesto Gálvez

¿Cómo surge Immersion Games? Hace cuatro años decidimos fundar nuestra compañía, queríamos hacer videojuegos, pero no teníamos presupuesto para hacerlo ni siquiera para pagar el primer mes de nuestros salarios, así que decidimos explorar otras áreas relacionadas también con gráficos 3D, pero orientadas hacia desarrollo de soluciones de seguridad, de arquitectura, etcétera. Así nos mantuvimos durante mucho tiempo, viviendo de regatearle a los clientes, eso nos cansó, nos aburrió, pero fue lo que nos permitió ir creciendo poco a poco, y entonces decidimos arriesgarlo todo y desarrollar videojuegos.

ENE-FEB 2007

¿Cómo captaron la atención de inversionistas? Porque desarrollar un videojuego requiere capital y proyección para ser exitoso. Se dio la oportunidad de que unos inversionistas metieran su dinero en nuestra compañía, pero nunca se atrevieron, porque siempre nos vieron como un grupo de jóvenes, pensaban que podían perder su dinero fácilmente. Mientras eso sucedía, contactamos con una compañía norteamericana, porque pensábamos que con aquel dinero, compraríamos tecnología de otros para hacer nuestros videojuegos, pero eso nunca sucedió. Un día, producto de nuestra desesperación hablamos con dicha empresa con la propuesta de hacer mejoras en su tecnología, a cambio de su código fuente, y el uso de esa tecnología. Llevamos más de un año y medio cerrando el negocio, pensamos que todo sería de un mes para otro, pero por suerte, al leer las propuestas técnicas de lo que ambos queríamos hacer, aceptaron, y no sólo eso, sino que disminuyeron el valor de la tecnología como en un 70%. Después nos pidieron imágenes de lo que estábamos haciendo, cuando las vieron, nos ofrecieron su tecnología a cambio de regalías cuando el juego estuviera terminado. Luego de un par de semanas trabajando echaron un vistazo a lo que estábamos haciendo, se dieron cuenta que sí cumplíamos lo prometido, así que nos ofrecieron hacer un juego en conjunto, y de ahí arrancamos. ¿Cómo dieron a conocer su trabajo en la industria? En uno de los eventos más importantes de la industria de videojuegos, el GDC (Game Developers Conference), cuando lo hicimos, causamos un gran impacto, e incluso, compañías de talla mundial como Epic Games, dueña de uno de los mejo-

res motores gráficos llamado Unreal Engine 3, al ver nuestro trabajo, decidió que usáramos su tecnología para desarrollar el videojuego. Después conseguimos un publisher que nos financiara, y ahora estamos por terminar nuestros dos primeros juegos: Monster Madness y CellFactor, uno lo terminamos en diciembre, el otro en febrero. ¿Cuál es tu apreciación de Latinoamérica en el mundo del desarrollo de videojuegos? Desde el punto de vista, ya no tanto de lo artístico o técnico, sino desde el punto de vista productivo, y en muchas conferencias he dicho lo mismo, el hecho de que estemos en países en vías de desarrollo, ha provocado que aprendamos a utilizar muy bien los poco recursos con los que contamos. Queremos dar la oportunidad que nunca tuvimos. Sabemos que en Latinoamérica hay muchos entusiastas, hay mucha gente que quiere hacer videojuegos, pero desafortunadamente, dependiendo de dónde quieras competir, los niveles que se necesitan de conocimiento son bastante fuertes, y queremos que la gente se entere de eso, que hay una gran oportunidad, pero que no se puede aprovechar si no has desarrollado el conocimiento suficiente, que por el hecho de que a ti te gusten los videojuegos o tengas una gran visión alrededor del tema o tengas el empuje o el dinero, no significa que seas la persona indicada para hacerlo. El truco está en que armes equipo de gente muy talentosa y que si tú eres programador, y has programado algo para videojuegos, pero sabes que a tu nivel le falta, y terminas encontrándote con otra persona que hace cosas en un fin de semana y todas son geniales, pues hazte a un lado, mantente en el equipo, pero deja que sea él el que lo haga, y lo mismo en la parte artística. Tengo entendido que quieren impulsar la industria en Latinoamérica, platícanos un poco al respecto. Queremos trabajar muy fuerte para desarrollar la industria en Latinoamérica. Hemos encontrado en NAGA (National Gamers Association) un punto de apoyo para crear una serie de programas, que por ejemplo, nos permitan compartir todo el conocimiento que hemos adquirido. Desarrollar programas de capacitación, pero no sólo eso, también hacer que la industria mundial comience a dirigir la mirada hacia nosotros; que nos vean como un mercado interesante.

ERNESTO GÁLVEZ Nacido, radicado en Colombia e ingeniero de profesión, es el CEO y socio fundador de Immersion Games, junto a otras tres personas. Está encargado de la ingeniería de producción que está relacionada con el uso de las máquinas y los procesos para producir cualquier clase de producto. En sus propias palabras: “Siempre he sido conciente de que la universidad lo que hace es darte criterios y volverte una persona racional para solucionar problemas y al final puedes terminar en cualquier área”. www.immersionsoftware.com www.cellfactorgame.com www.monster-madness.com

www.softwareguru.com.mx

s o g e u oj

e d o l l sarro

e d i V

el Por Jo

ana Villagr

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

zar? Empe

ENE-FEB 2007

www.softwareguru.com.mx

Muy rápido me di cuenta de 3 cosas: la primera es que no existía algún libro ni tutorial que enseñe todo lo que se necesita saber; la segunda es que toda la información existente estaba en inglés (y eso no ha cambiado); y la tercera, es que ni siquiera ahí me podría escapar de las matemáticas –la dirección en la que se mueve un objeto, determinar si está dentro del rango de visión de la cámara virtual, determinar si un vehículo chocó contra un edificio; todo eso requiere matemáticas. Desafortunadamente, en México todavía no existe una industria de desarrollo de videojuegos como tal, y es una lástima, porque es una industria de billones de dólares. Ya existen carreras de desarrollo de videojuegos en universidades internacionales, pero en muchas universidades de nuestro país ni siquiera se toma en serio la materia de gráficas por computadora, que es la base de todo. Esto en gran parte se debe a falta de información, muchas personas creen que es lo mismo jugarlos que desarrollarlos. Un juego 2D puede ser fácil, pero uno 3D es algo muy diferente y se necesitan muchas personas trabajando en conjunto para crearlo. No es que una sola persona no pueda, pero se tardaría mucho más tiempo. Un juego comercial tarda entre 1.5 y 3 años para ser desarrollado, con un equipo de 25 personas en promedio. Un juego 3D generalmente tiene programación orientada a objetos, cálculos trigonométricos y de álgebra lineal que se ejecutan durante todo el juego, estructuras de datos especializadas, y también puede existir una red neuronal para el manejo de la inteligencia artificial, así como algo de teoría de autómatas finitos y teoría de grafos aplicada, entre muchas otras cosas. Y aún así, hay maestros de universidades que cuando se les presenta un juego como una

www.softwareguru.com.mx

idea para un proyecto final, solo dicen en tono despectivo “¿otro jueguito?” Tuve la oportunidad de participar en el Festival de Desarrollo de Videojuegos Creanimax 2006, y me di cuenta que por fin se están haciendo esfuerzos para entrarle a esta industria. Me di cuenta de que hay algunas compañías interesadas en desarrollar juegos, pero falta apoyo y habilidades técnicas. También me enteré de un par de universidades en Guadalajara que están incorporando una carrera de animación y arte digital a su oferta académica. Hay muchas personas involucradas ya en el modelado y animación 3D –y son buenos–. Entonces no vamos tan mal, sólo falta ponernos las pilas, organizarnos y darle importancia también a la parte de la programación. Así que el objetivo de este artículo, es tratar de dar una pequeña orientación para aquellos que desean empezar a desarrollar videojuegos y tengan preguntas parecidas a las que tenía yo cuando empecé.

¿Qué se necesita saber para desarrollar videojuegos? Programación. Lo primero que se necesita es saber programar en algún lenguaje orientado a objetos, yo en lo personal uso C++, pero también se puede utilizar C#, Delphi, Java, etcétera. En cuanto a compiladores, no hay gran diferencia, se pueden utilizar el Visual C++ 2005 Express Edition de Microsoft o el C++ de Borland. Game Engines. Los juegos generalmente tienen módulos clave para manejar tareas como mostrar gráficas, manejar recursos, interpretar y ejecutar scripts, reproducir efectos de sonido, manejar la inteligencia artificial, manejar el input del usuario. Estos

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

¿Qué se necesita aprender para desarrollar videojuegos? Esta pregunta no es fácil de contestar, sobre todo porque existen diferentes áreas dentro de la programación de videojuegos: gráficas, redes, inteligencia artificial, sonido, lógica principal. El área en el que está centrado este artículo es en la de gráficas, y para esta área se necesitan aprender básicamente dos cosas: •Teoría de gráficas: involucra aprender las bases de los sistemas de coordenadas 2D

ENE-FEB 2007

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

¿Cómo puedo programar videojuegos para Xbox360, PlayStation 3, GameCube?

y 3D, las bases de los objetos 3D que son representados como modelos poligonales (vértices, normales, caras, etcétera); las báses de la arquitectura gráfica (diferentes tipos de transformaciones y proyecciones); las matemáticas involucradas (vectores, planos, matrices y todas sus operaciones relacionadas). Diferentes modelos de iluminación, mapeado de texturas, entre otras cosas. Es necesario tener estos conocimientos, ya que se aplican a las APIs para programación gráfica existentes y son necesarios para explotar todo su potencial. •Una API para programación de gráficas: que es básicamente una librería que usamos en nuestro código para poder mandar gráficas a la pantalla, sin tener que accesar al hardware directamente (en su lugar, los drivers se encargan de procesar las peticiones hechas por las APIs). Las dos APIs de gráficas más usadas son OpenGL y Direct3D, y dado que los resultados que se pueden obtener con ellas, son, hasta cierto punto similares, la elección de una u otra es cuestión personal.

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

ENE-FEB 2007

¿Qué es OpenGL? OpenGL es una API para el manejo de gráficas exclusivamente, no tiene otro tipo de funciones utilizadas en los juegos. OpenGL es multiplataforma, lo que significa que el mismo código puede correr en Windows, Mac, X Window, con mínimas modificaciones. Esta es una de las ventajas que, puede decirse, tiene con respecto a Direct3D, el cual es exclusivamente para Windows. Dado que OpenGL es multiplataforma, no incluye comandos para manejo de ventanas, porque estos son diferentes en cada caso. Dependiendo de la plataforma, hay métodos para crear una ventana con soporte para OpenGL. Para agilizar o hacer más fácil el manejo de ventanas. Ya existen algunas librerías que se utilizan junto con OpenGL, por ejemplo: SDL y GLUT. OpenGL, a diferencia de DirectX, no se baja como un paquete, de algún sitio de Internet, ya que es implementado por los drivers. Todas las máquinas con Windows 95 o posterior, incluyen los drivers de OpenGL 1.1, aunque la versión más reciente de OpenGL es 2.0 –Windows Vista tendrá los drivers de OpenGL 1.4–. Entonces, la versión de OpenGL que se tenga, depende de dos cosas: la primera es nuestra tarjeta de video –no todas las tarjetas soportan las últimas versiones de OpenGL –, y la segunda, es actualizar los drivers de nuestra tarjeta de video para tener la versión más reciente que soporte la tarjeta. Para utilizar OpenGL, es necesario configurar nuestro compilador para que pueda encontrar

En el caso de Xbox360, para desarrollar un juego se necesita obtener un “Kit de Desarrollo”, que consta de una consola Xbox360 especial para desarrollo, herramientas, SDKs, y documentación. El desarrollo se hace en una PC con Visual Studio o CodeWarrior por ejemplo. Dicha PC está conectada a la consola especial de desarrollo, generalmente por ethernet. Una vez compilado el código, éste se pasa a la consola; la forma de cómo hacerlo, depende de cada sistema. En Xbox, se cuenta con unos plugins en Visual Studio que copian los datos de la PC al disco duro del Xbox, y después el Xbox monta el directorio que se copió, como si fuera el disco duro interno, para empezar a correr el juego.

Para obtener el kit de desarrollo, se necesita ser un desarrollador registrado con Microsoft, y los kits son muy caros. Aunque existe el XNA Game Studio Express, éste, no es suficiente para hacer juegos comerciales, en realidad, es un producto dirigido más para estudiantes y hobbyists. Además, para ser aceptado como desarrollador, se debe seguir un proceso que está sujeto a aceptación por parte de Microsoft. Se puede encontrar más información en: www.xbox.com/en-us/dev/ default.htm Otros fabricantes de consolas piden requisitos adicionales. Por ejemplo, Nintendo pide que se cuente con respaldo financiero de algún distribuidor de juegos internacional. Así que, en general, para desarrollar un videojuego para consolas, se necesita tener una compañía establecida con presupuesto suficiente. Si quieres aprender cómo es el desarrollo para consolas, una muy recomendada para empezar sería Gameboy Advance (GBA), ya que es de las menos complejas. En el sitio www.jharbour.com/gameboy/default.aspx se encuentra gratuitamente el ebook “Programming The Nintendo Game Boy Advance”, que nunca se publicó como libro debido a cuestiones legales. En éste, se encuentra información de cómo ejecutar nuestros prowww.softwareguru.com.mx

Tema

Tìtulo

Autor

Matemáticas/Física

Mathematics for 3d Game Programming and Computer Graphics

Eric Lengyel

OpenGL

OpenGL Programming Guide: OpenGL Architecture The Official Guide to Learning OpenGL Review Board

Beginning OpenGL Game Programming.

Dave Astle y Kevin Hawkins

More OpenGL Game Programming.

Dave Astle

Gráficas 3D

Interactive Computer Graphics: A Top-Down Approach using OpenGL.

Edward Angel

Real-Time Rendering

Tomas Akenine-Moller y Eric Haines

Desarrollo de Juegos Game Programming Gems. (Serie de 6 libros hasta el momento).

Mark DeLoura (Editor)

Core Techniques and Algorithms in Game Programming

Daniel Sanchez-Crespo

Inteligencia Artificial

AI Game Programming Wisdom 3

Steve Rabin

Modelado

Modeling a Character in 3DS Max

Paul Steed

pios juegos de GBA en una PC, usando un emulador, así como información de cómo correrlos en una consola GBAreal.

Referencias en línea Algunos links con mucha información son los siguientes: www.opengl.org – El sitio oficial de OpenGL, tiene documentación y foros de OpenGL para principiantes y avanzados. msdn.microsoft.com/library/en-us/directx9_ c/directx_sdk.asp – Información de DirectX. www.gamedev.net – Un sitio con mucha documentación de desarrollo de juegos en general y foros para los diferentes aspectos del desarrollo. www.gamasutra.com – Un sitio donde se pueden encontrar las más recientes noticias de la industria de los videojuegos, pero también cuenta con algo de información técnica. www.flipcode.com – Un sitio que ya no se mantiene por sus creadores, pero tiene una extensa colección de artículos, todavía en línea, relacionados al desarrollo de videojuegos.

¿Qué libros me pueden servir? La tabla en la parte superior de esta página lista algunos libros que considero buenos y que son útiles, independientemente del nivel de conocimiento de programación de videojuegos que se tenga. Como ya lo había mencionado, hasta el momento, no sé de alwww.softwareguru.com.mx

gun libro que enseñe todo lo relacionado al desarrollo de videojuegos, así que los categoricé en 6 grupos principales, y por razones de espacio, sólo menciono unos cuantos de cada categoría.

¿Qué tarjeta gráfica me puede servir para empezar? El mercado de las tarjetas gráficas es dominado por dos compañías, ATI y NVIDIA. Las dos ofrecen tarjetas gráficas de muy buena calidad y de una gran variedad de precios, dependiendo de la generación de la tarjeta. Muchas veces, al ver las cajas de las tarjetas pueden surgir más preguntas, ya que la información que tienen, puede parecer extraña. Por ejemplo, es importante entender lo que son los Shaders. Shaders: hasta hace algunos años, se decía que las tarjetas gráficas tenían una arquitectura fija (Fixed-Function Pipeline) ya que la información enviada desde la aplicación, siempre pasaba por las mismas operaciones dentro de la tarjeta gráfica. Esto ha cambiado, y actualmente las tarjetas gráficas tienen una arquitectura programable. Una arquitectura programable significa que desde la aplicación, se le puede indicar a la tarjeta gráfica que ejecute ciertos programas pequeños (llamados Shaders) ella misma, liberando al CPU completamente de ejecutar esas funciones. Es por esto que las tarjetas gráficas actuales, cuentan con su propia memoria y procesador, conocido como GPU (Graphics Processing Unit). Muchos de los

efectos visuales avanzados que vemos en los juegos de hoy en día, son implementados por medio de Shaders. Hace algunos años, los Shaders eran escritos en lenguaje ensamblador, por tal razón no eran tan populares. Actualmente la mayoría de los Shaders, son escritos en lenguajes de “alto nivel”, muy parecidos a C, los tres más usados son: GLSL (específico de OpenGL); HLSL (específico de DirectX) y Cg (puede correr ya sea en OpenGL o DirectX). Las tarjetas gráficas con arquitectura programable tienen dos núcleos o procesadores programables, uno se ejecuta a nivel de objetos y otro se ejecuta a nivel de pixeles. Los Shaders que se pueden ejecutar en ellos, se conocen como Vertex Shaders y Pixel Shaders respectivamente (los últimos también se conocen como Fragment Shaders). Las tarjetas gráficas con arquitectura programable, también tienen soporte para la arquitectura fija, y es decisión de la aplicación, utilizar una u otra arquitectura o incluso utilizar las dos. Es por eso que muchas veces, aunque tengamos un procesador avanzado, si no tenemos una tarjeta gráfica con arquitectura programable como lo requieren algunos juegos, no podremos ejecutarlos.

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

Conclusión El tema de desarrollo de videojuegos es muy extenso, pero espero haber respondido las preguntas básicas acerca de cómo empezar. El siguiente artículo tiene información mas específica en cuanto a la estructura de un juego. Si dejé alguna pregunta sin responder, me pueden contactar en joel.villagrana@gmail.com y trataré de responder lo más pronto posible. ENE-FEB 2007

second) ejecuta. Qué tan rápido corre un juego, depende de muchos factores, principalmente aspectos de hardware como procesador, memoria, tarjeta gráfica; aunque también, influyen aspectos de nuestra lógica de programación. Por lo general, en el desarrollo de un juego se intenta tener por lo menos 60fps, para que el movimiento de los objetos sea contínuo. •Una parte de liberación de recursos – Ejecutada al finalizar el juego, aquí se libera la memoria obtenida de manera dinámica en todos los subsistemas del juego.

Conceptos básicos

n u e d o l l o

D 2 o g ue

r r a s De

Definamos algunos conceptos básicos que nos ayudarán a entender el código de nuestro juego 2D:

gra el Villa Por Jo

pto

Conce

ración

nfigu s y Co

esarrollar un juego de video en 2D con OpenGL no es tan complicado como podrías pensar. A través de una serie de artículos, mostraré cómo se desarrolla un juego sencillo, que sirva para dar una idea clara de las funciones y estructura básica de un juego. Por razones de espacio en la revista, en esta primera parte sólo introduciré algunos conceptos básicos y de configuración; y en próximas entregas continuaré con los diferentes aspectos a resolver, en el desarrollo de un juego 2D. Estructura básica de un juego •Una parte de inicialización - Aquí se crea nuestra ventana principal, se cargan todos los archivos que necesita el juego (modelos 3D, imágenes, sonidos) y se crean e inicializan los diferentes subsistemas del juego (gráficas, input del usuario, inteligencia artificial, etcétera).

•Actualización - Por ejemplo la posición de un enemigo, verificar si el usuario ha presionado algun botón, actualizar la posición de un cohete se disparó, verificar si un vehículo ha colisionado contra algún objeto del mundo. •Render – Es la parte más importante, es decir, el mandar todas las gráficas a la pantalla.

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

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

ENE-FEB 2007

Framebuffer. OpenGL cuenta con una colección de búfers donde se almacena información que se presentará en la pantalla. El búfer principal, es el búfer de color, que es un arreglo bidimensional que almacena el color final de los pixeles. También existe el búfer de profundidad (Z-buffer), que almacena la información de profundidad (respecto a la cámara virtual) de cada pixel generado cuando se hacer un render de un objeto, esto sirve para determinar si cada pixel del objeto es visible al hacer la comparación de los pixeles generados contra la información que ya se tiene en el Z-Buffer. En las aplicaciones gráficas se tienen cuando ménos dos framebuffers, uno para mostrar en la pantalla y otro para hacer un render en él, mientras el otro, se muestra en la pantalla. Al terminar de hacer un render en un búfer, se hace un intercambio, el búfer en el que se hizo el render es mostrado en la pantalla, mientras se hace render en el otro. Es necesario usar dos búfers, ya que de lo contrario, tendríamos un efecto visual desagradable al hacer render sobre el búfer en pantalla. Render. Es el proceso de tomar una representación matemática tridimensional de un objeto y presentarlo como una imagen bidimensional en la pantalla. Para este proceso se toma toda la información relacionada al objeto como color, posición y textura. Proyecciones. Las 3 etapas conceptuales de la arquitectura gráfica son: Aplicación, Geometría, y Rasterización. En la etapa de Geometría, se toman los objetos y sus datos asociados y se “proyectan” en la pantalla. Hay dos formas principales de hacerlo: para 2D se usa la proyección ortogonal, en www.softwareguru.com.mx

ésta, la apariencia de los objetos es la misma, independientemente de la distancia desde donde se vean. Para 3D se utiliza la proyección en perspectiva; donde la apariencia de los objetos cambia, dependiendo de la distancia con respecto a la cámara virtual, que es como percibimos los objetos en la vida real. Transformaciones. En un juego, el movimiento de los objetos se realiza por medio de transformaciones. Trasladar un proyectil de una posición a otra, rotar la cámara virtual, hacer más grande un objeto, son ejemplos de transformaciones. Matrices. Para almacenar información acerca del tipo de proyección usada en un juego, e información de las transformaciones y parámetros actuales de la cámara virtual, OpenGL utiliza la Projection Matrix y la ModelView Matrix respectivamente.

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

GL Utility Toolkit (GLUT) GLUT es una librería que simplifica la creación y manejo de ventanas con soporte para OpenGL. En GLUT podemos definir nuestras callback functions, que son las funciones llamadas automáticamente cuando ocurren ciertos eventos como cuando se cambia de tamaño la ventana, cuando se hace clic con el mouse o cuando se recibe input del teclado. GLUT se puede descargar en www.xmission. com/~nate/glut.html, y si quieres configurar Visual Studio para usar GLUT, puedes encontrar una guía para esto en csf11.acs. uwosh.edu/cs371/visualstudio/ El siguiente código es un ejemplo de un esqueleto que inicializa OpenGL y GLUT.

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

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

Geometría. Todos los objetos que vemos en un juego 3D están compuestos por pequeños triángulos, que al ser representados en conjunto, determinan la forma del objeto. Las formas básicas que se mandan a la tarjeta gráfica son cuadrados, triángulos, líneas, y puntos. Cada una de estas primitivas tiene información asociada como vértices, normales, y coordenadas de textura.

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

Texturas. Son básicamente, imágenes que van a ser “pegadas” a nuestra geometría para darle la apariencia final. Una restricción importante para las texturas de un juego, es que su tamaño debe ser potencia de 2, por ejemplo 128x128, 256x256, 512x512 pixeles. Para determinar qué parte de la textura se pegará en cada triángulo de la geometría, se utilizan las coordenadas de textura. Al hacer el render, se deben pasar las coordenadas de textura por cada vértice de la geometría. OpenGL funciona como una máquina de estados, es decir, guarda

}

/* Declaracion de callback functions, etc */ void SG_DisplayFunction(); void SG_KeyboardFunction( unsigned char key, int x, int y ); void SG_SizeFunction( int width, int height ); void SG_MouseFunction( int button, int state, int x, int y ); void InitializeProjection( int width, int height ); void InitializeOpenGL(); /* ... */

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

glClear( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ); //... glFlush(); // Termina los comandos de render pendientes glutSwapBuffers(); // Intercambia el front y back buffer } void SG_SizeFunction( int width, int height ) { InitializeProjection( width, height ); } void SG_KeyboardFunction( unsigned char key, int x, int y ){ /*...*/ } void SG_MouseFunction( int button, int state, int x, int y ){ /*...*/ } int main( int argc, char** argv ) { /* Código de inicialización de GLUT */ glutInitDisplayMode( GLUT_DOUBLE | GLUT_DEPTH | GLUT_RGBA ); glutInitWindowPosition( 0, 0 ); glutInitWindowSize( 800, 600 ); glutInit( &argc, argv ); /* Creación de la ventana */ glutCreateWindow(“Juego 2D – SG 2007”); /* Callback Functions */ // Función llamada cada vez que el usuario cambia // de tamaño la ventana glutReshapeFunc( SG_SizeFunction ); // Función llamada cuando la ventana necesita ser redibujada glutDisplayFunc( SG_DisplayFunction ); // Función llamada cada que nuestra aplicación esta “libre” glutIdleFunc( SG_DisplayFunction ); // Función llamada cada que se recibe input del teclado glutKeyboardFunc( SG_KeyboardFunction ); // Función llamada cada que se recibe input del mouse glutMouseFunc( SG_MouseFunction ); // Inicialización de OpenGL InitializeOpenGL(); // El loop principal de la aplicación glutMainLoop(); return 0; }

Como se puede observar, el uso de GLUT permite simplificar a unas cuantas líneas, un código de inicialización que podría tomar el doble de líneas o más, usando la API de Windows.

glShadeModel( GL_SMOOTH ); // Tipo de shading InitializeProjection( 800, 600 ); // Proyección //... void InitializeProjection( int width, int height ) { glViewport( 0, 0, width, height ); // Viewport glMatrixMode( GL_PROJECTION ); // Proyección glLoadIdentity(); glOrtho( 0, width, 0, height, -10, 10 ); // 2D /* Cambiar para poder procesar las transformaciones de la camara virtual */ glMatrixMode( GL_MODELVIEW ); glLoadIdentity(); } void SG_DisplayFunction() { // Limpia el bufer de color y el Z-buffer

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

Joel Villagrana, egresado de la Universidad de Guadalajara como Ingeniero en Computación, ha estado en contacto con la programación de videojuegos desde hace 4 años cuando estudió una maestría en Ambientes Virtuales en Inglaterra. Actualmente trabaja para IBM, pero en su tiempo libre sigue aprendiendo las nuevas técnicas de gráficas 3D. Participó en el libro “More OpenGL Game Programming”, publicado en 2005. Recientemente participó en Creanimax 2006. La información de estos artículos representa su punto de vista y no necesariamente el de IBM Corporation. joel.villagrana@gmail.com

www.softwareguru.com.mx

ENE-FEB 2007

XNA

a cantaba odos n T e e e d em er lcance ien qufenomenal vdesA b l y a u s era ego ar a do m recuer s. Para mí, asmas, o jug de Ju , o a l i l r o a r a it nd nt Desar la secun las maquindo por los fapequeños. n e a b a más esta o co canz uandohoras jugandara no ser al en pedazos pasar corriendo p e explotaban qu an Pac-M s asteroides truir lo e Por Jaim

Sánch

Con historias así, es que surge la industria de los videojuegos, y precisamente este tipo de juegos simples, pero contagiosos, se conocen actualmente como juegos ocasionales o casual gaming. Lo interesante de dicha tendencia en videojuegos, no es tanto la capacidad de poderlos jugar una y otra vez, sino que además, puedes disfrutarlos en diferentes dispositivos y competir contra diferentes adversarios en línea. En este sentido, el Xbox 360 abrió un mercado muy interesante a través de su Xbox Live, con el que los usuarios pueden descargar de Internet contenidos y juegos. Sin embargo, esto presentó dos problemas principales; el primero es que, para desarrollar juegos para diferentes plataformas (por ejemplo, Xbox y PC), se necesitaban bases de código diferentes e independientes. El segundo problema, es que la capacidad de desarrollar juegos para consolas sólo estaba disponible para las grandes casas desarrolladoras de juegos, utilizando kits de desarrollo caros y con disponibilidad limitada. Esto eliminaba la posibilidad de que un desarrolaldor casual pudiera hacer un juego para Xbox, por ejemplo. Para resolver tales problemas, se creó XNA. XNA es un framework basado en .NET, que facilita el desarrollo de videojuegos y permite usar una misma base de código para tanto plataforma Xbox como Windows.

ENE-FEB 2007

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

Para desarrollar juegos basados en el framework XNA, se utiliza XNA Game Studio, que es un ambiente de desarrollo basado en Visual Studio C#. XNA Game Studio estará disponible en dos versiones: •XNA Game Studio Express. Versión gratuita basada en Visual Studio Express C# dirigida a los desarrolladores casuales o por hobby. Actualmente está disponible como beta, y en cualquier momento se liberará la versión final.

•XNA Game Studio Professional. Dirigido a profesionales que crean juegos para comercializar. Se espera que sea lanzado en el segundo semestre de 2007. Cuando estás desarrollando un videojuego, lo más complejo se encuentra en generar el código, que se va a encargar de operar las controladoras de videos, las interfaces de entrada o controles, los eventos a los que www.softwareguru.com.mx

debe de responder, etcétera. Toda esta lógica, la administra XNA, de tal manera que, es mucho más fácil comenzar a desarrollar tu videojuego usando las interfaces que te provee, además, cuando lo instalas, vienen pre cargadas una serie de plantillas que te permiten comenzar a crear tu juego en menos de 5 minutos.

Lo importante, es que sepas que, generar un videojuego, no es cosa sencilla, ya que tienes que diseñar la historia del juego, todo el arte, las animaciones, objetos en 3D, el audio, y ya una vez que tienes todos estos componentes, comienza lo divertido: integrarlos. Pero no te desanimes, ya verás que con un poco de práctica, pronto estarás desarrollando juegos divertidos, que podrás compartir con tus amigos o incluso, jugarlos en línea.

Capas de XNA Ahora, ya que entendimos qué onda con XNA, vamos a verlo un poco más a detalle. El framework está organizado en 4 capas orientadas a diferentes propósitos: •La capa base del framework XNA es la capa denominada de “Plataforma”, que es donde se maneja toda la lógica de bajo nivel, por ejemplo lo que es Direct 3D, XACT, etcétera. Digamos que es como el cerebro de XNA. •Encima de la capa de plataforma se encuentra la del framework básico, o central. Aquí es donde se procesa la información general del videojuego, es decir, el audio, los procesamientos matemáticos, almacenamiento, etcétera. •Para facilitar el desarrollo de los juegos, se diseñó un conjunto de interfaces que forman la capa denominada, framework extendido. •La última capa es la de juego, que es donde se lleva toda la lógica como tal. Lo interesante es que tú puedes generar componentes que permitan que los demás puedan acceder a tu juego y configurar cómo se desarrolla. Por ejemplo, podrías hacer una interfaz para que pudieran descargar nuevas naves espaciales, o en un ambiente un poco más comercial, podrías vender espacio publicitario en tu videojuego. Imagina que pudieras rentarle a una compañía de refrescos, un espacio para que publiciten sus productos, y al término del periodo, venderle ese mismo espacio a una compañía de automóviles, y lo único que cambiaría en tu juego, es la manera en la que se consume dicho componente. Sería genial, ¿no?

Figura 2. Interfaz de desarrollo de Game Studio Express de XNA.

Figura 3. Plantilla de desarrollo Space War.

Conclusión

Para dar inicio

Figura 4. Juego en ejecución.

Ya que conoces cómo está diseñada a gran escala la arquitectura de XNA, muy seguramente tu siguiente pregunta sería: ¿Cómo lo empiezo a utilizar?

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

Lo primero que tienes que hacer es descargar Visual Studio Express C#. Lo puedes encontrar en el sitio msdn.microsoft.com/ vstudio/express/visualcsharp. Una vez que instales C# Express necesitas descargar el

Una vez que instalaste los programas, estarás listo para comenzar a desarrollar tu juego. Te recomiendo que para comenzar te bases en alguna de las plantillas de videojuegos que ya vienen instaladas, esto te va a permitir entender cómo está estructurado el videojuego.

Desarrollar un videojuego involucra tomar en cuenta muchos aspectos. Afortunadamente, XNA elimina algo de esa complejidad y es una excelente opción para desarrollar juegos tanto para Xbox como Windows. Lo mejor de todo es que XNA Game Studio Express es gratis, así que si eres un desarrollador de software y conoces algo de C#, anda ya, y desarrolla tus primeros juegos.

Jaime Sánchez Beltrán, con más de 10 años de experiencia en la industria de Tecnologías de Información, actualmente se desempeña como evangelista para empresas de software en Microsoft, entre sus labores se encuentra la divulgación tecnológica, y generación de programas que impulsen el ecosistema de TI. Ha participado como conferencista nacional e internacional, empujando la innovación en TI. Anteriormente trabajó para Microsoft en Texas, soportando las cuentas Premiere de América Latina.

www.softwareguru.com.mx

ENE-FEB 2007

a i c n e g i l e t In

l a i c fi i t r A lo ión a do c a c i l a Ap s Delg

Por Dr.

e Vide

os d s Jueg

Carlo

a Inteligencia Artificial (IA) en los juegos de video, ha cobrado auge en los últimos años. Dado que las imágenes desplegadas por las consolas de la siguiente generación (Wii, PlayStation 3 y Xbox 360) cada vez se acercan más a la realidad, ahora, el reto radica en hacer que estas imágenes cobren “vida” y realicen comportamiento que el jugador perciba como inteligente. Esto es, que el comportamiento sea tan creíble como las imágenes desplegadas. Para cumplir este gran reto, los videojuegos están utilizando cada vez, con mayor frecuencia, técnicas de Inteligencia Artificial avanzadas, como lo son Redes Neuronales, Algoritmos Genéticos, y Planeación, y ya no sólo técnicas que se han usado tradicionalmente, como las Máquinas de Estado Finito (FSM) para simular el comportamiento de los personajes, y el Algoritmo A* para encontrar rutas. El presente artículo se divide en dos partes: la primera es un vistazo a lo que es la IA más interesante en los juegos de video actuales, y la segunda, es un ejemplo de IA reactiva para un juego que estamos desarrollando en Nibbo Studios. Juegos cuya IA vale la pena notar Estos son algunos de los juegos que consideo vale la pena destacar por su uso de IA: 1. Creatures, un juego de vida artificial creado por Steve Grand para Cyberlife en el Reino Unido. En este juego, cada una de las criaturas (Norns) tiene diferentes genes. Los Norns se aparean entre sí para dar vida a nuevas criaturas, que van evolucionando su DNA y adquiriendo algunos rasgos de generaciones anteriores. El cerebro de las criaturas es simulado por una red neuronal sencilla. Steve Grand incluso, se ha auto proclamado un dios digital, ya que según él, ha creado “vida” dentro de una computadora. 2. Black and White de Peter Molyneaux de Lionhead Studios, donde se puede entrenar a las bestias que dependen del dios (el juga-

ENE-FEB 2007

dor). Esto se realiza por medio de la técnica de IA conocida como aprendizaje reforzado, donde se premia a la criatura si realiza la acción que le pedimos (por medio de un caricia en el lomo) o se castiga si no hace lo que se pide (a través de un latigazo).

con estos objetivos. Esto acarrea el beneficio de que las acciones y los objetivos están “desacopladas”, por lo que es más sencillo expandir el sistema de IA de manera eficaz.

3. F.E.A.R. (First Encounter Assault Recon), IA por Jeff Orkin de Monolith Productions. Cuenta con la Inteligencia Artificial más interesante, ya que se utilizan técnicas como el uso de un planeador para complementar a otras que se han utilizado con mayor frecuencia en la IA de los juegos de video, como son las maquina de estado finito (FSM) y el algoritmo A*. Lo interesante de utilizar el planeador, es que solamente es necesario especificar cuál es el conjunto de objetivos que persigue el personaje y cuáles son las acciones que puede realizar para cumplir

Ahora daré un ejemplo de la IA del videojuego mexicano Überpong, desarrollado por Nibbo Studios (www.nibbo.net) en la ciudad de Aguascalientes. Überpong actualmente se encuentra en pruebas beta, y pronto saldrá al mercado. Este videojuego ha ganado dos premios a nivel nacional, incluyendo el mejor videojuego en PC desarrollado por una empresa mexicana en el concurso del capítulo mexicano de la IGDA (International Game Developers Association) en noviembre del 2006. Überpong es un videojuego que combina los géneros de deportes y de acción para traer el clásico

Ejemplo: Überpong desarrollado por Nibbo Studios

www.softwareguru.com.mx

Figura 1. Contestación del enemigo (paddle derecho) en el nivel de la tierra.

Figura 2. Enemigo (paddle derecho) recibiendo la pelota en el nivel del hielo.

juego de Pong al siglo XXI. Para lograrlo, se dotó de algoritmos de física computacional, detección de colisiones y de Inteligencia Artificial que a continuación se describe: La Inteligencia Artificial de los enemigos de Überpong se divide en 4 dimensiones, una para definir cómo el control (paddle) del enemigo se aproxima a la pelota, y las otras 3, para definir la personalidad del enemigo. El sistema de IA está influenciado en los estudios doctorales de un servidor. En este tipo de IA, por medio de reglas sencillas se simula comportamiento que parece ser más complejo. Sistemas similares de IA se han utilizado para simular animales artificiales, y también para guiar robots en ambientes complejos y cambiantes. Para definir cómo se aproxima el paddle del enemigo a la pelota, se definieron un conjunto de parámetros que se especifican en el archivo XML de la IA. Entre éstos se encuentran: 1. Qué método utilizará para aproximarse a

la pelota (siguiéndola o prediciendo a cada instante dónde llegará la pelota). 2. Parámetros para definir un sistema primitivo de visión. 3. Velocidad máxima del paddle. 4. Aceleración máxima del paddle. 5. Porcentaje de decaimiento de la velocidad del paddle. Para definir la personalidad del enemigo, se crearon los perfiles de personalidad, estos están dados en 3 dimensiones: •La primera dimensión define si el enemigo será agresivo, precavido, o miedoso; esto es, si tratará de acelerar la pelota, no hará nada o si tratará de desacelerar la pelota. •La segunda dimensión define si el enemigo es arriesgado o no; esto es, si tratará de aplicar efecto o no a la pelota. •La tercera dimensión define si el enemigo es impulsivo o calculador; esto es, qué estrategia utilizará para aplicarle los ítems al jugador: si es impulsivo, los aplicará en cuanto los tenga disponibles y si es calculador, los aplicará cuando ocasione más daño al jugador, por ejemplo, vol-

tear la pantalla cuando la pelota esté cerca del jugador, le dará menos tiempo de reaccionar. El juego se puede ver en acción en las figuras 1 y 2 (que se muestran en la esquina superior izquierda).

Conclusión La Inteligencia Artificial es sin duda, un campo con mucho potencial, que tiene grandes áreas de oportunidad en los juegos de video. Espero que con este breve artículo les haya dado una idea del tipo de consideraciones que se deben tener en IA para videojuegos, y también espero, haber despertado su curiosidad para que conozcan más sobre esta fascinante área.

El Dr. Carlos Delgado Mata es socio fundador de Nibbo Studios, y ha estado encargado de la Inteligencia Artificial y Física Computacional del más reciente proyecto. Además, es profesor investigador en el campus académico de la Universidad Panamericana, Universidad Bonaterra. Es autor de mas de 30 artículos en el área de Agentes y Entornos Virtuales Inteligentes. Es fundador y co-chair de la conferencia internacional especializada en el área IVEVA (Intelligent Virtual Environments and Virtual Agents).

www.softwareguru.com.mx

ENE-FEB 2007

a i r t s u d In

uillén

scar G

g. O Por In

s cia instan ías e Todo a d r e e m c i pr an pañ al Alc gos, enn en las comambién s e o u j g o e e Ju vid nsa s. T llo de ria de riente y, pie ros crecimo o Francia. t o s r u r d a n s De no o terra e la i nosot abla d iajan al leja muchos de nidos, Ingla el nuestro. h e s uandoas mentes v on los que Estados U íamos sería nuestr los juegos cpaíses comos que pensar sy en paí niponamos pensar n el último podríaiertamente, e Pero c

Aunque desde hace cerca de diez años han existido intentos de desarrollo de juegos de video en México, aún muy poca gente conoce la existencia de aquellas compañías que luchan por un sueño común: desarrollar juegos, con propiedad intelectual propia, “Hechos en México”. Desgraciadamente, los primeros proyectos no cautivaron al público de la manera que sus creadores hubieran querido. Sin embargo, a medida que pasan los años, cada vez más gente creativa se dispone a embarcarse en tan aventurada tarea, y en conocer los errores del pasado, que han servido de lección para muchas compañías que están comenzando.

Antecedentes y lecciones aprendidas Los factores que ocasionaron que los proyectos pioneros fracasaran, son varios, y se necesitaría hablar, en particular de cada una de las empresas involucradas, para buscar-encontrar qué fue lo que hizo falta. Sin embargo, a manera general podemos englobar los más importantes y de los cuales, se trata un poco a continuación. Originalidad. Al no tener una clara visión del mercado se suele pasar por alto varios factores externos que pueden hacer que un producto no se venda como se tiene planeado. Si a cualquier desarrollador de juegos se le pregunta qué piensa de su creación, lo más seguro es que la

ENE-FEB 2007

defienda a capa y espada. Por lo mismo, muchas veces estas personas suelen no estudiar el mercado para conocer a su competencia y el tema que se elige para el juego a desarrollar se escoge simplemente basándose en el gusto personal de quienes lo van a crear. Debido a esto, podemos ver que algunos de los primeros juegos mexicanos fueron muy similares a juegos reconocidos mundialmente. Esto provocó que el consumidor, al tener que elegir entre dos juegos similares, uno desarrollado por un estudio reconocido, y otro por un grupo de personas que apenas comienzan y del cual no se sabe mucho, obviamente se inclinará por el primero. Piratería. La piratería es otro factor que incidió y sigue causando molestias a los desarrolladores en nuestro país. Se estima que más del 80% de los videojuegos que se venden en México son adquiridos en el mercado informal. Este vicio, que las autoridades han dejado pasar, origina que las personas consideren normal comprar un juego por veinte pesos o menos, en el mercado de la esquina, sin ponerse a pensar en todo el esfuerzo que hay detrás, y por el cual el producto comprado en una tienda legítima, tiene un precio mucho más elevado. Es risible entonces, ver que haya gente que luego de conseguir de manera ilegal videojuegos desarrollados en México, se pregunte por qué la compañía que lo desarrolló ya no continuó sacando más proyectos.

conoce e t n e g oca ellas “Muy pencia de aquchan por la exist ñías que lu compaño común: , con un sueollar juegos ual desarrdad intelectMéxico”. propie, hechos en propia Malinchismo. El malinchismo mexicano es otro factor importante que no podemos dejar fuera de la ecuación. Pongamos por ejemplo el juego Mythic Blades desarrollado por la compañía Vermillion Games de Querétaro. Cuando Vermillion mostró las primeras versiones de su producto en los foros especializados mexicanos, lo único que recibió fue críticas. Miguel Pineda, socio fundador de Vermillion Games, una vez comentó que los comentarios más viscerales hacia el juego fueron por parte de los propios paisanos. Esto casi los llevó a abandonar el proyecto. Sin embargo, al mostrar su juego en páginas de Internet y foros extranjeros, la aceptación fue tal que terminaron el juego y éste fue comercializado en varios países por una distribuidora norteamericana, recibiendo grandes alabanzas por el arte gráfico del mismo.

Esfuerzos recientes de promoción Eventos como Creanimax 2006, que se realizó el pasado mes de octubre en Guadalajara, Jalisco; donde se dieron cita varias de las más importantes personalidades en materia de Animación y Videojuegos no sólo nacional sino internacional, y los concursos organizados por el capítulo en México de la IGDA (International Game Developers Association) junto con Oelli, la empresa organizadora del Electronic Game Show, y la Secretaría de Economía, son puntos importantes de exposición de la creatividad de www.softwareguru.com.mx

los jóvenes mexicanos. En los concursos de ambos eventos se premiaron proyectos realizados por estudiantes, profesionistas y empresas, basándose en diferentes factores como el gameplay del juego, el arte y música, pero sobre todo, la originalidad de los mismos. Cabe mencionar que entre los premios otorgados en el concurso de la IGDA, se dio a los mejores proyectos la oportunidad de viajar a San Francisco el próximo año, para asistir al Game Developers Conference, donde podrán exhibir sus proyectos en un pabellón que pretende acercar a los desarrolladores nacionales con los del resto del mundo. Esperemos que estos apoyos continúen y que las empresas nacionales sepan sacar el máximo provecho de los mismos, y que la industria de videojuegos en nuestro país dé el gran paso y dé a conocer al mundo la creatividad con la que contamos.

Algunas empresas mexicanas A continuación, una breve reseña de algunas empresas representativas de esta naciente industria de videojuegos en México. Artefacto Estudio. Es una compañía que trabaja en una amplia gama de proyectos que van desde aplicaciones web, hasta creación de imagen corporativa y desarrollo de videojuegos. Su proyecto “Xtreme Drive” los hizo merecedores del tercer lugar en el concurso más reciente de desarrollo de videojuegos de la IGDA. AztecTech Games. Parte del Instituto Aztec Tech, el cual es considerado como la primera escuela de desarrollo de videojuegos en Latinoamérica. Sacó al mercado dos de los primeros juegos para PC de creación mexicana: “World Masters”y “Hellcopters”, en los que se trabajó cerca de seis años y que, desgraciadamente no lograron capturar la atención del público mexicano. Digital Moon Studios. Compañía originaria del estado de México que se dedica a la realización de proyectos a manera de outsourcing. Poco se conoce acerca de los juegos en los que han participado, debido a los contratos de confidencialidad que se requieren para conseguir este tipo de proyectos. Dimtv. Empresa dedicada a la creación de juegos publicitarios. Han logrado concretar negocios con empresas nacionales e internacionales a las cuales les han desarrollado juegos basados en su marca o producto.

Idle Hands Games. Enfocados en la creación de juegos para dispositivos móviles, esta empresa del D.F. cuenta ya con siete juegos en su haber; que se basan en ideas simples, pero entretenidas y se venden por medio de descargas directas al celular. Entre sus juegos más populares se encuentra “Ruta 666”, en el que el usuario toma el papel de un chofer de autobús, que intenta realizar su trabajo en el caos vial de la ciudad de México. Nibbo Studios. Empresa de Aguascalientes que ha desarrollado diferentes proyectos como los kioscos con pantalla táctil, presentados en la Feria de San Marcos 2006 en el stand del Gobierno Estatal; un juego didáctico para la enseñanza del teclado de la computadora de nombre “Mecapumble” y el juego en 2D que aún se encuentra en desarrollo, llamado “Überpong”. Este último logró conseguir el segundo lugar en el concurso de desarrollo de juegos durante Creanimax 2006 y el primer lugar en la categoría profesional en el concurso organizado por la IGDA. Nusof Studios. Ganadores del segundo lugar de la categoría profesional del concurso de la IGDA. Su proyecto más sobresaliente “Biops 2” es un juego tridimensional de armas en primera persona (first person shooter), con buenos gráficos y un nivel adecuado de emoción y dificultad. Radical Studios. Sacaron al mercado un juego “multi-jugador masivo en línea” (MMOG por sus siglas en inglés), en el cual se permitía jugar en tiempo real contra enemigos programados y personas que estuvieran en línea en el mismo momento que se estuviera jugando. La idea de esta compañía era seguir mejorando el juego de manera continua, cobrando mensualidades a los suscriptores para permitirles tener acceso al juego. Desgraciadamente, la empresa no pudo soportar los costos de operación y cerró operaciones al poco tiempo de haber comenzado. Ranflosoft. Sorprendió a muchos con su juego de peleas basado en personajes políticos y del folclor mexicano. Aún y cuando la calidad gráfica y el gameplay del juego dejaban mucho que desear, “Kombate Mexicano” siempre lograba sacar una sonrisa en las personas que lo probaron por primera vez. Snake & Eagle Studios. Esta compañía, asociada con la casa editorial Linaje, desarrolló el proyecto “Antrophos”, que consistía en un có-

mic futurista que daba oportunidad al lector de terminar cada uno de los capítulos, viviéndolo en un juego adjunto en forma de CD con cada tomo. El principal problema que enfrentó este proyecto, fue no haber considerado los largos tiempos que toma desarrollar un videojuego, ya que la idea original era que, tanto el juego como el cómic, salieran mensualmente. Se lanzaron al mercado dos tomos y se desarrolló una versión especial del juego en formato de Arcadia, mismos que se pueden adquirir todavía, a través de la página de Internet de la casa editorial. Xibalba Studios. Con base en Monterrey, esta compañía está formada por egresados de Digipen, una de las más prestigiosas escuelas de desarrollo de videojuegos. Hasta la fecha, sólo han mostrado una demo tecnológica de su motor de juegos, pero se sabe que trabajan en un proyecto basado en el juego maya de la pelota, que llevará el nombre de “Underworld Tournament”, y que se espera salga para el Xbox Live. Vermillion Games. Compañía formada por los hermanos Pineda de Querétaro. Su juego “Mythic Blades”, es considerado por muchos, el mejor juego de video desarrollado en México hasta la fecha. La calidad que han logrado imprimir en el arte gráfico y la programación, hizo que distribuidores internacionales de videojuegos se fijaran en él, y se esté vendiendo ya en diversos lugares del mundo.

Conclusión A pesar de los retos y dificultades que enfrenta esta industria en nuestro país, las esperanzas de que siga creciendo son muchas, ya que existe gente que cree firmemente que México puede dejar de ser un país consumidor y convertirse en un país creador de propiedad intelectual y juegos de calidad. Si quieres conocer más sobre desarrollo de videojuegos en nuestro país, te recomiendo que entres al sitio del capítulo en México del IGDA, disponible en http://mexico.vjuegos.org/

Ing. Oscar Miguel Guillén Hernández. Ingeniero en Electrónica y Sistemas Digitales por la Universidad Panamericana campus Bonaterra de la ciudad de Aguascalientes. Socio fundador y Director Creativo de la empresa de tecnologías de entretenimiento Tecnochtitlán S.A. de C.V. de la cual se desprende la marca de juegos de video Nibbo Studios. Creador de los personajes de los juegos Mecapumble y Überpong. Co-coordinador de los proyectos creados por la empresa y encargado del área artística de la misma.

www.softwareguru.com.mx

ENE-FEB 2007

/* MEJORA DE PROCESOS */

// PRÁCTICAS

Análisis del ROI

Una Herramienta para Justificar la Mejora de Procesos Por Angélica Su y Alfredo Calvo

ucho se ha cuestionado si la mejora de procesos de software basada en CMMI, realmente trae beneficios tangibles para las compañías de nuestro país. Las empresas que quieren comenzar a implementar un esfuerzo de esta naturaleza, se cuestionan cómo poder justificar los recursos que van a invertir para ello, y si se aprovecharán de manera adecuada. Aunque para muchas de estas empresas, la obtención de un nivel de madurez sigue siendo el principal móvil para implementar CMMI. La realidad muestra que, tales iniciativas, logran un éxito significativo cuando son vistas como un objetivo de negocio, que traerá consigo beneficios económicos y que resolverá problemáticas relevantes en la organización. Las preguntas que típicamente surgen al plantear un programa de mejora son: ¿cuánto nos va a costar?, ¿qué beneficios vamos a obtener?, ¿cómo justifico el gasto ante el Consejo?, ¿existe información de resultados obtenidos por empresas similares en México?

de utilidad del 35%? O quizá destinarlo a mejorar la infraestructura de cómputo. A fin de cuentas, la implementación de un programa de mejora de procesos de software compite por recursos humanos y económicos limitados. Actualmente, las compañías utilizan el ROI para evaluar los proyectos de inversión que tienen en puerta. Sin embargo, para un programa de mejora basado en CMMI, la complejidad de este análisis radica en obtener la información suficiente y confiable para calcularlo correctamente.

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

Para poder generar un adecuado entendimiento de implicaciones y beneficios asociados con un programa de mejora, el análisis del Retorno de Inversión o ROI (Return of Investment) es una herramienta de utilidad, que permite apoyar la justificación de la inversión en términos tangibles para los tomadores de decisiones en la organización. El ROI es un concepto sencillo de comprender y aplicar. Supongamos el caso de una empresa que enfrenta la decisión de si invertir o no, en un programa de mejora. El análisis del ROI significa evaluar si la inversión es rentable, comparada con otros proyectos u opciones de inversión disponibles, es decir, ¿por qué no mejor invertir este dinero en el banco a taza del 8%?, o ¿por qué no invertirlo como capital de trabajo en proyectos para buscar un margen

1. Determinar el alcance de la iniciativa de mejora A fin de acotar el alcance del programa de mejora, la organización debe decidir: •La representación del modelo que utilizará (escalonada o continua). •Las áreas de proceso a implementar. •El nivel de madurez objetivo. •Las áreas involucradas (una división, toda la organización, todos los tipos de proyecto, o sólo aquellos que pertenezcan a una u otra tecnología, etcétera).

2. Estimar el esfuerzo y los costos asociados Como en cualquier proyecto, es necesario identificar los recursos que se requerirán para poder implementar el programa de mejora. Los principales rubros a considerar son: •Capacitación. •Esfuerzo para la definición, despliegue y soporte del proceso. •Herramientas. •Consultoría especializada. •Evaluaciones formales. Es importante contemplar los costos asociados, no sólo para la implementación del programa, sino también para mantenerlo operando, aun después de haber alcanzado un nivel de madurez.

3. Dimensionar los beneficios

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

Un programa de mejora debe estar gobernado por los objetivos de mejora definidos por el negocio. La experiencia después de innumerables sesiones de trabajo con directores de empresas de TI para identificar los objetivos de negocio, nos arroja que los cinco principales son: •Mejorar la utilidad de los proyectos. •Cumplir dentro del tiempo y costo estimado. •Mejorar la satisfacción del cliente.

Alfredo Calvo es Consultor Sr. de IT ERA en CMMI, Planeación Estratégica y Balanced Scorecard. Alfredo es CMM CBA-IPI Lead Assessor e Instructor de PSP y TSP autorizado por el SEI, así como Premio Nacional de Tecnología 2000. Ha sido desarrollador, líder de proyecto, gerente y director de TI para diversas empresas y cuenta con amplia experiencia brindando servicios de consultoría en mejora de procesos. Angélica Su es Gerente de Línea de Negocio de CMMI en IT ERA. Cuenta con más de 12 años de experiencia en el ámbito de mejora de procesos, ha participado en diversos proyectos de implementación de modelos como CMMI, MoProSoft, RUP, ITIL para diversas compañías. Participó como editora en MoProSoft y EvalProSoft, las cuales actualmente forman parte de norma mexicana de software.

ENE-FEB 2007

www.softwareguru.com.mx

El análisis del ROI es una herramienta de utilidad, que permite apoyar la justificación de la inversión en términos tangibles. •Mejorar la calidad del producto. •Mejorar la productividad del equipo. El punto más complicado para realizar un adecuado análisis del ROI, es el dimensionamiento y la cuantificación de los beneficios que se obtendrán con CMMI, debido sobre todo, a la carencia de información; la buena noticia es que ahora existen resultados cuantitativos publicados que pueden servir como base para este análisis. En la tabla 1, se pueden observar los resultados del uso de CMMI publicados por el SEI, con datos relevantes como: la disminución del costo en un 20%, aumento en calidad en un 50%, aumento en precisión del calendario del 37%, aumento en productividad del 62% y un ROI medio de 4.7 a 1. Categoría de Rendimiento Número Desempeño medio de datos

Desempeño Desempeño Inferior mayor

Costo

20%

87%

Calendario

37%

90%

Productividad

62%

255%

Calidad

50%

132%

Satisfacción del Cliente

14%

-4%

55%

Retorno de Inversión

4.7 : 1

2:1

27%

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

•Ti-M. Evaluada en diciembre del 2006 como CMMI Nivel 3, con información de uso de sus procesos en más de 15 proyectos. Sus estimaciones de esfuerzo tienen variaciones respecto a la realidad, de menos del 10% (de -8% a +5%), lo cual habla de la madurez y confiabilidad de su operación. • Dextra Technologies. Empresa trabajando con procesos CMMI Nivel 3, actualmente presenta datos recopilados durante 2 años, que reflejan un efectivo control en la densidad de defectos en sus proyectos. Esto le ha permitido mejorar el empleo de sus recursos, disminuyendo el retrabajo en actividades de calidad. • Mexware Consulting. Comenzó a implementar su programa de mejora de procesos en 2005 y actualmente implementa proyectos con procesos de Nivel CMMI3. Sus resultados a la fecha para 20 proyectos ejecutados reflejan una desviación promedio de esfuerzo y tiempo del 5% • A nivel gubernamental, está el caso de la Coordinación de Tecnología para la Incorporación y Recaudación del IMSS, que en octubre de 2006 obtuvo el Nivel 3 de capacidad de CMMI. Dentro de los resultados actualmente reportados, presenta proyectos con desviación promedio del 6.3%, un índice de apego a procesos definidos del 98.1% y un ROI de 3.5 a 1.

edu/cmmi/results.html.

Estos datos pueden ser tomados “como referencia”, con las debidas reservas, ya que cada empresa es diferente, y los criterios para captar, calcular y presentar dicha información no necesariamente podrían ser aplicables a su empresa. Las empresas que han aportado datos al SEI son empresas del tamaño de Boeing, Lookheed Martin, GM, Siemens, etcétera; y para la empresa promedio en nuestro país genera inquietud, sobre si estos datos les son aplicables o no. La mala noticia aquí, es que actualmente no existe un registro similar para las empresas mexicanas, pues son aún pocas las que han implementado con éxito el CMMI, y menos todavía, las que cuentan con información histórica confiable. A continuación, se presentan datos de empresas mexicanas con las cuales hemos trabajado en la empresa It Era. www.softwareguru.com.mx

Algunos de los ejemplos típicos que se presentan como metas de mejora pueden ser: •Disminuir el retrabajo por corrección a defectos en un X% •Disminuir el retrabajo por mala especificación de requerimientos en un X% •Acotar la desviación en esfuerzo y tiempo a un X% •Aumentar la rentabilidad en un X% En la tabla 2 se presenta un ejemplo para estimar los beneficios en una empresa con 60 desarrolladores, tomando como base un aumento en productividad del 10%.

4. Calcular el ROI El cálculo del ROI, se realiza dividiendo la estimación de los beneficios estimados entre los costos asociados con el programa. Siguiendo el ejemplo anterior, si consideramos una inversión de 75 mil dólares, un

Desarrolladores

260

Días laborales

Horas x día

124,800

Horas hombre al año

$ 30.00

Tarifa promedio (USD)

$ 3,744,000

Ingresos estimados anuales (USD)

$ 374,400

Ahorros estimados por aumento en productividad del 10% por año (USD)

Tabla 2. Ejemplo de beneficios estimados.

beneficio esperado de 374 mil dólares al año tenemos: ROI = 374,400 / 75,000 = 4.99

5. Presentación de resultados Comunicar a la organización el análisis realizado, los objetivos de negocio, las metas de mejora y los beneficios esperados, es importante para generar el compromiso y patrocinio de todos los participantes que pueden apoyar a que el programa de mejora tenga éxito.

Principales consideraciones •Se requiere acceso a información relevante y sensible. •Calcular los beneficios no es una tarea trivial. •Falta de consistencia en la medición del ROI. •Las organizaciones no tienen datos de su situación actual.

Conclusión El análisis del ROI es una herramienta de suma utilidad para evaluar la conveniencia de un programa de mejora. Se requiere contemplar los costos asociados con la implementación y el mantenimiento del programa de mejora. Es indispensable establecer objetivos de negocio cuantificables que guíen y gobiernen el programa de mejora. Los beneficios económicos se determinan en b ase a estos objetivos de negocio.

ENE-FEB 2007

// PRÁCTICAS

/* DISEÑO */

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

uienes han desarrollado aplicaciones empresariales usando la especificación 2 de EJB (Enterprise Java Beans), conocen el excesivo tiempo que se consume en el ciclo Editar-Compilar-Debugear. Incluso, posiblemente se han vuelto expertos en pasatiempos como Sudoku, u otra actividad que haga más llevadera la espera en este ciclo. Es cierto que algunas veces la utilización de tal tecnología es la mejor decisión que podemos tomar, sin embargo, también existen muchos proyectos donde su uso no es él más recomendado, e incluso hace el desarrollo más lento y tedioso, afectando la productividad del equipo de desarrollo.

Un típico diseño basado en Arquitectura EJB 2 Veamos un ejemplo simple de tipos de cambios, donde se nos solicita el servicio de Captura de Operaciones de compra-venta de dólares hacia otras instituciones bancarias. La figura 1 muestra cómo podría diseñarse este servicio con un Session EJB. El acceso hacia los objetos de datos (Data Access Object - DAO) es a través de un EJB llamado CapturaService, donde cualquier validación y/o proceso de lógica de negocio es ejecutada. Por ejemplo, si la institución bancaria existe, o si la cantidad que se desea cambiar está dentro de los límites aceptables.

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

El resultado es un objeto de datos llamado CapturaResultDTO con el resultado de la operación. Los métodos que acceden la base de datos están encapsulados en DAOs, los cuales pueden ser implementados con JDBC o algún otro mecanismo de persistencia. Este diseño aparenta estar bastante bien, pero esconde varios problemas que describo a continuación.

Problemas frecuentes en EJBs Framework pesado y complejo. EJB 2 es un framework muy completo, que resuelve requerimientos comunes en las aplicaciones empresariales, tales como el manejo de transacciones distribuidas, seguridad y persistencia. Esto trae varias ventajas, pero también lo convierte en un modelo muy pesado y complejo. Poca productividad. La arquitectura EJB 2 nació con el propósito de facilitar el desarrollo de aplicaciones empresariales, y ciertamente nos evita la necesidad de codificar procesos estructurales de bajo nivel, pero esa ayuda se paga con altísimos costos de tiempo. Hacer cualquier modificación a un EJB, requiere además de editar y compilar, instalar cada componente EJB en el Servidor de Aplicaciones, configurar los archivos XML, levantar el Servidor de Aplicaciones para que se tomen los cambios, y buscar soluciones a problemas generados por los mismos EJBs.

No fomenta la Orientación a Objetos Mucha gente piensa que por el hecho de escribir código en un lenguaje que soporte OO, ya están desarrollando con objetos y todo el paradigma que éste conlleva. Sin embargo, lo anterior no es una estrategia basada en tecnología, sino en la organización del código. La cultura de la programación orientada a componentes de EJB 2, no fomenta la orientación a objetos, ya que los session y message-driven beans son estructuras monolíticas y clases muy pesadas. Por otro lado, los Entity Beans que son creados para representar entidades de negocio, tienen muchas limitaciones que los hacen difíciles para implementar un modelo de objetos. Como resultado, es difícil desarrollar un verdadero estilo Orientado a Objetos sobre la plataforma J2EE. Este tipo de desarrollos es lo que Martin Fowler llama “anemia domain model”, y parecido a la falta de vitalidad en la sangre anémica, los modelos de objeto anémicos únicamente modelan superficialmente el problema, ya que contienen clases que implementan poco, o nada de comportamientos.

Desarrollando con POJOs y Frameworks ligeros Antes de la especificación EJB 3, muchos desarrolladores desilusionados con EJB buscaron alternativas, y encontraron que los POJO son una de esas, convincente a EJBs. Un POJO (Plain Old Java Object) es simplemente un objeto de Java que no implementa ninguna interfase especial. Su nombre fue creado por Fowler, Rebbecca Parsons y Josh MacKenzie para darle a los objetos regulares de Java un nombre de sonido divertido. Los POJOs por sí solos, no son suficientes para crear una aplicación empresarial completa, ya que carecen de los servicios que brinda un contenedor de EJB. Por eso, la solución es complementarlos con el uso de Frameworks Ligeros como Spring e Hibernate, que reemplazan algunas de las partes pesadas de la

Ixcoatl Pérez es Consultor TI especializado en sector financiero, con experiencia desarrollando sistemas empresariales para diferentes industrias en USA y México. Es experto en análisis y diseño orientado a objetos, desarrollo web, RUP y arquitectura J2EE. Ixcoatl cuenta con las certificaciones Sun Certified Java Developer, Sun Certified Web Component Developer y Sun Certified Business Component Developer.

ENE-FEB 2007

www.softwareguru.com.mx

plataforma J2EE. Hibernate y Spring tienen características importantes, el no ser intrusivas, es una de ellas. Proveen transacciones y persistencia sin requerir que las clases implementen ninguna interfase en especial (por ello siguen siendo POJOs). La aplicación es ensamblada con contenedores ligeros que implementen Dependecy Injection en lugar de usar la búsqueda de componentes con JNDI. Estos frameworks solucionan diferentes necesidades a lo largo de un desarrollo empresarial. Los beneficios son mayores cuando se combinan adecuadamente con patrones de diseño y mejores prácticas de desarrollo. Por ejemplo, el patrón de Modelo de Domino nos brinda todo el beneficio del Desarrollo OO, ya que las reglas de negocios son la base de la implementación, al tiempo que los objetos de dominio ignoran que serán persistidos, ya que, transparentemente son mapeados hacia la Base de Datos relacional. Un framework de persistencia como Hibernate nos brinda una solución ORM (Object-Relational Mapping), y si se requiere mapear POJOs hacia sentencias SQL, iBATIS, nos brinda una solución bastante conveniente para ejecutar sentencias SQL. Con un el uso de interfaces se evita acoplar un modelo de dominio hacia un framework de persistencia específico, lo que nos da mayor flexibilidad e incluso es posible probar el modelo de domino sin un esquema de Base de Datos. El desarrollo con POJOs también nos brinda un beneficio extra, ya que el Desarrollo Orientado-a-Pruebas (Test Driven Development - TDD) es bastante simple y compatible con los POJOs, al no depender de un servidor de aplicaciones. Tal vez la principal razón para usar Session Beans, es la capacidad de tener transacciones administradas por el contenedor (ContainerManaged Transaction - CMT). Esto permite que el contenedor EJB automáticamente comience una transacción cuando un método es invocado, haciendo el commit cuando termina exitosamente, o el rollback en caso de no ser así. Ahora bien, si optamos por la opción de POJOS y frameworks ligeros, el framework de Spring nos provee una solución equivalente a CMT para POJOs, además de tener un rango amplio de características que lo hacen muy fácil de usar. Cuando un método POJO es llamado, Spring automáticamente comenzará una transacción y hará el commit o rollback correspondiente. Aquí lo interesante es que Spring puede administrar las transacciones usando el framework de persistencia, el administrador de transacciones de JDBC, o el Java Transaction API (JTA), según sea deseado. Esto es tan simple como definir un POJO como un Spring Bean, con unas cuantas líneas de XML similar al deployment descriptor de EJB, y con eso tenemos un POJO que es transaccional. La aplicación obtiene un SpringBean llamando a la fábrica de SpringBean con el nombre y tipo esperado. Tan simple como: BeanFactory factory = new XMLBeanFactory(new FileInputSteam(“capturaFacade.xml”)) ;

Debido al alto nivel de configuracion de Spring, la fábrica de SpringBean puede ser configurada para regresar un proxy en lugar del objeto original. Este proxy, también conocido como interceptor, es un objeto que finge ser el objeto original, pero que puede ejecutar código adicional antes y después de la invocación del objeto original, y por tanto sirve para muchos propósitos, como administrar transacciones, seguridad o conexiones a la base de datos. CapturaFaçade puede ser envuelto en un interceptor, el cual administra las transacciones con algún administrador de transacciones propio del framework de persistencia que estemos usando.

Diseño basado en POJOs Revisemos por último el diseño del servicio de Captura de Operaciones de compra-venta de dólares, pero ahora con POJOs. Este diseño tiene más componentes que el basado en EJB, y puede parecer más complejo, pero su diseño es más modular y mucho más fácil de probar y extender. Aun cuando son más clases, cada una tiene un pequeño número de responsabilidades fáciles de entender y bien definidas. Se agregó un nuevo modulo CantidadPolicy, donde aplicamos políticas de filtro que tengan que ver con la cantidad que se compra o vende. Esto es más que nada, un ejemplo de lo fácil que se puede agregar nueva funcionalidad, es decir, un objeto con responsabilidad simple y específica.

Figura 2. Diseño del servicio usando POJOs.

Usamos interfaces para simplificar el desarrollo orientado a pruebas, ya que es posible reemplazar la implementación del repositorio Hibernate por algún otro framework de persistencia, sin modificar el código.

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

Nota: Utilizamos un Façade con la intención de desacoplar las responsabilidades de un CapturaService y la capa de presentación. www.softwareguru.com.mx

En resumen, los frameworks ligeros como Spring e Hibernate nos permiten usar POJOs, con todas sus conveniencias; y tener los mismos beneficios de usar EJB Session Beans, sin tener sus complicaciones. ENE-FEB 2007

// PRÁCTICAS

/* ARQUITECTURA */

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

no de los factores que determina el éxito o fracaso de un sistema de software, es su arquitectura. Con esto nos referimos a la estructura o conjunto de estructuras del sistema, las cuales están compuestas de elementos de software, propiedades externas visibles de estos elementos y las relaciones entre sí [1].

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

El diseñar debidamente una arquitectura de software, garantiza que el sistema de software cumpla con uno o varios atributos de calidad. Por ejemplo, que sea fácil de usar, confiable o seguro. Sin embargo, si la arquitectura no se diseña de forma apropiada, el sistema de software resultante no logrará sus objetivos [2]. De nada sirve un sistema de software que no cumple con los tiempos de respuesta requeridos por el cliente, o que es complejo de modificar, difícil de usar o vulnerable a ataques.

Primeros inicios

Por lo regular, se conoce hasta el final del desarrollo del sistema de software, si éste cumplió o no con los atributos de calidad que se especificaron en los requerimientos no funcionales. Dicho conocimiento tardío, implica tomar demasiados riesgos innecesarios, un ejemplo es, descubrir fallas en el sistema de software debido a que en la fase de diseño no se eligió apropiadamente una arquitectura. Para reducir tales riesgos y, como una buena práctica de ingeniería, es recomendable llevar acabo evaluaciones a la arquitectura. La finalidad de este artículo es dar a conocer un panorama general sobre evaluaciones a arquitecturas de software. En él, presento el propósito de evaluar, conceptos sobre atributos de calidad, primeros intentos de evaluación, momentos en los que se pueden realizar evaluaciones, clasificación de las técnicas de evaluación, planeación de evaluaciones, y beneficios que se obtienen al evaluar una arquitectura.

Porqué es necesario evaluar una arquitectura de software El propósito de realizar evaluaciones a la arquitectura, es para analizar e identificar riesgos potenciales en su estructura y sus propiedades, que puedan afectar al sistema de software resultante, verificar que los requerimientos no funcionales estén presentes en la arquitectura, así como determinar en qué grado se satisfacen los atributos de calidad. Cabe señalar que los requerimientos no funcionales, también son conocidos como atributos de calidad. De acuerdo al estándar IEEE 610.12-1990 [3], un atributo de calidad es una característica que afecta la calidad de un elemento. En esta definición, el término “característica” se refiere a aspectos no funcionales, mientras que el término “elemento” se refiere a un componente o sistema. Los atributos de calidad se clasifican en dos grupos [4]: operacionales y de desarrollo. Los atributos operacionales son las cualidades

Los primeros esfuerzos en realizar evaluaciones a arquitecturas de software utilizando un proceso estructurado y definido, fueron descritos en un trabajo seminal hecho por Parnas y Weiss [5] en 1985. En él se propone utilizar revisiones de diseño activas, que consisten en detectar errores e inconsistencias, por ejemplo aquellos que no fueron detectados en la fase de requerimientos. Este proceso consiste en elaborar una serie de cuestionarios cuidadosamente escritos, de tal manera que el revisor no pueda responderlos de una manera pasiva, es decir, con un “Sí” o un “No”. Cada cuestionario se diseña para encontrar diferentes tipos de errores, por lo que cada uno, evalúa aspectos específicos del diseño. Estos, a su vez, junto con la documentación del diseño, se entregan para su evaluación a un grupo de revisores expertos en uno o varios aspectos específicos del diseño. En promedio, la duración de dichas revisiones se lleva de uno a dos días, dependiendo de la complejidad del diseño, así como del número de revisores.

¿Cuándo es recomendable evaluar? La evaluación a la arquitectura puede efectuarse en varios momentos, dependiendo de la etapa de construcción en que se encuentre. La evaluación clásica se efectúa una vez que la arquitectura se ha terminado y aún no se implementa. La evaluación temprana se lleva acabo una, o varias veces durante la etapa de construcción de la arquitectura, mientras que la evaluación tardía, se realiza cuando la arquitectura existe y la implantación se ha completado. Clements, Kazman y Klein [6] proponen dos reglas de oro para determinar el momento de efectuar la evaluación: 1. Realizar una evaluación cuando el equipo de desarrollo inicia a tomar decisiones que afectan directamente a la arquitectura; y... 2. Cuando el costo de no tomar estas decisiones podría pesar más, que el costo de realizar una evaluación.

Técnicas de evaluación Existen varias técnicas para evaluar arquitecturas de software, que se clasifican en cualitativas y cuantitativas. Dentro de las técnicas de evaluación cualitativas se pueden utilizar: escenarios, cuestionarios o listas de verificación. Por otro lado, en las técnicas de evaluación cuantitativas se pueden emplear: métricas, simulaciones, prototipos, experimentos o modelos matemáticos; en la figura 1 se muestran de manera gráfica estas técnicas.

Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas. Actualmente es profesor de la Universidad de Guadalajara, es miembro de la Association for Computing Machinery ACM y del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org

ENE-FEB 2007

www.softwareguru.com.mx

Realizar una evaluación no planeada, representa retrasos en los tiempos de entrega, así como un incremento en los costos del proyecto. La mayoría de los métodos de evaluación utilizan escenarios, que son secuencias específicas de pasos que involucran el uso o la modificación del sistema. Por lo regular, las técnicas de evaluación cualitativas son usadas cuando la arquitectura se encuentra en construcción, mientras que las técnicas de evaluación cuantitativas, se usan cuando la arquitectura ya ha sido implantada. Por ejemplo, es posible hacer uso de modelos matemáticos tales como teoría de colas, para medir el desempeño de un conjunto de componentes EJB en una aplicación J2EE [7].

por los resultados obtenidos de la evaluación, ya que puede decidir continuar o no con el proyecto, dependiendo de los resultados. Un ejemplo de este caso es el siguiente, tras haber efectuado una evaluación temprana, se determinó que no es posible implantar la arquitectura con la infraestructura disponible, ya que esta no cumplirá con los tiempos de respuesta requeridos por el cliente.

Resultado de la evaluación Una vez que se ha efectuado la evaluación, se debe elaborar un reporte. Que debe presentarse como un documento preliminar, con la finalidad de que se corrija por las personas que participaron en la evaluación. El contenido del reporte responde a dos tipos de preguntas [6]: •¿Se ha diseñado la arquitectura mas apropiada para el sistema? •¿Cuál de las arquitecturas propuestas es la más apropiada para el sistema a construir? Además de responder estas preguntas, el reporte también indica el grado en que se cumplieron los atributos de calidad.

Conclusiones En esta primera parte presentamos un panorama general sobre las evaluaciones a las arquitecturas de software. Entre los puntos más importantes destacaron: el propósito de evaluar, los momentos y los tipos de técnicas de evaluación, así como los resultados que se obtienen de ésta. En la próxima ocasión, expondremos de manera detallada, algunos de los métodos de evaluación a arquitecturas de software más usados en la actualidad. Figura 1. Clasificación de las técnicas de evaluación.

Planear o no la evaluación Las evaluaciones pueden ser planeadas o no planeadas. Una evaluación planeada es aquella que ha sido contemplada dentro del ciclo de vida de desarrollo, por lo que es parte de las actividades del proyecto. Son varios los beneficios que se obtienen de realizar evaluaciones, algunos de estos son descubrir defectos e inconsistencias en la fase de diseño, asegurar que se cumplan los atributos de calidad, así como reducir los costos del proyecto. Comúnmente una evaluación no planeada, se presenta cuando la arquitectura de software contiene varios defectos que han sido detectados en etapas tardías del desarrollo, por ende, realizar una evaluación no planeada, representa retrasos en los tiempos de entrega, así como un incremento en los costos del proyecto. Es recomendable que en el proyecto se contemple realizar una o varias evaluaciones a la arquitectura.

¿Quiénes participan en la evaluación? Generalmente las evaluaciones a la arquitectura se hacen por los miembros del equipo de desarrollo, tales como el arquitecto, diseñador y administrador del proyecto. Sin embargo, puede haber excepciones en las que se contrate a un grupo de personas especialistas para realizar la evaluación. El cliente también se interesa www.softwareguru.com.mx

Referencias 1. Len Bass, Paul Clements & Rick Kazman. “Software Architecture in Practice”. SEI Series In Software Engineering. Segunda edición. Addison Wesley, 2003. 2. Anthony Finkelstein & John Dowell. “A Comedy of Errors: The London Ambulance Service Case Study”. Proceedings of 8th International Workshop on Software Specification and Design (IWSSD-8), Schloss Velen; Alemania, Marzo 1996. 3. “Standard Glossary of Software Engineering Terminology.”, Institute of Electrical and Electronics Engineers (IEEE), 1990. 4. Jan Bosch & Peter Molin. “Software Architecture Design: Evaluation and Transformation”. Proceedings of IEEE Engineering of Computer Based Systems Symposium (ECBS ‘99) 1999. 5. David L. Parnas & David M. Weiss. “Active Design Reviews: Principles and Practices”. Proceedings of 18th International Conference on Software Engineering 1985. 6. Paul Clements, Rick Kazman & Mark Klein. “Evaluating Software Architectures”. SEI Series in Software Engineering. Addison Wesley, 2002. 7. Yan Liu & Ian Gorton. “Performance Prediction of J2EE Applications Using Messaging Protocols.” International SIGSOFT Symposium on Component-based Software Engineering (CBSE). Mayo 2005.

ENE-FEB 2007

// UML

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

Imagina tu casa con un televisor de plasma de 50 pulgadas, un refrigerador que te envía mensajes cuando la leche o el huevo están por terminarse; una estufa con parrilla electrónica que se apaga sola; una sala de piel que da masajes y autoregula su temperatura; dos líneas telefónicas con teléfonos inalámbricos de 5.8 Ghz de largo alcance y una cama king size automática con masajes; todo esto para que lo disfrutes tú, tus padres y tus cinco hermanitos. De fantasía, ¿cierto? Contenido en una maravillosa casa duplex de interés social de 70 metros cuadrados. ¡Espera! ¿Maravillosa casa duplex para todo esto? Hablemos de incongruencias. No parece ser el lugar más apropiado para tener esas comodidades, ¿cierto?

Soñar no cuesta, no planear sí Antes de decidir comprar los anteriores componentes, tienes que asegurarte que van a caber o, funcionar en tu casa. Y si no caben, y tienes el presupuesto, tendrás que mudarte a otra casa más apropiada. Bueno, pues eso mismo sucede con el desarrollo de software. Antes de decidir desarrollar una aplicación con ciertos requerimientos, tienes que asegurarte que cuentas con la infraestructura apropiada para ponerlos a funcionar sin problema. Si no cuentas con ella, tendrás que decidir cuál será el equipo y ambiente adecuados (computadoras, servidores, sistemas operativos, etcétera) para instalar y hacer funcionar tu aplicación. Por supuesto, restringiéndote al presupuesto disponible para tal fin. Antes de llenar tu casa con todo tipo de muebles y componentes, de seguro visualizarás si

tu casa tiene espacio dónde colocarlos. Si eres suficientemente precavido evaluarás si la instalación eléctrica o hidráulica es la apropiada para que funcionen correctamente. Si eres un diseñador de interiores o un arquitecto, bosquejarás algún plano para asegurarte de estar tomando la decisión correcta. Así mismo ocurre en el caso del software, antes de desarrollar un conjunto de componentes que formarán una aplicación, pensarás si el equipo e infraestructura con la que cuentas es apropiada para dicho sistema. Antes de desarrollar el software, e incluso antes de comprometerte con tu cliente a desarrollarlo, tendrás que asegurarte de identificar si se cuenta con el equipo apropiado o con el presupuesto para adquirirlo y así poder hacer funcionar correctamente la aplicación.

Proponer o Restringir Al inicio del proyecto, en lo que podemos llamar fase de Inicio o Concepción (“Inception”) en el caso del Proceso Unificado, tendrás que desarrollar un primer diagrama de distribución para identificar las restricciones físicas de hardware en el proyecto (el equipo e instalaciones con las que cuenta el cliente para el proyecto), o en su defecto, documentar el hardware propuesto, en el cual se tendrá que invertir para hacer funcionar el software. En la fase posterior, la de Elaboración, este diagrama tendrá que ser refinado para dejar especificadas las decisiones tomadas con respecto a esta perspectiva del sistema. El diagrama de distribución es el artefacto de UML que nos permite representar los elementos físicos de un sistema; lo que mu-

cha gente conoce tradicionalmente como la arquitectura física. En este puedes visualizar las computadoras (clientes, servidores, PDAs), elementos adicionales de hardware (impresoras, ruteadores) y las conexiones (la red). Incluso puedes indicar qué sistema operativo corre en una computadora o en cuál de las computadoras pondrás a correr ciertos componentes de tu aplicación. Los componentes de software realizan la dinámica de un sistema; representan agregaciones de clases. Son los moldes de fabricación que construyen a los objetos que colaboran en tiempo de ejecución para llevar acabo lo que especifican los requerimientos. Estos componentes tienen que ser colocados en el hardware para que los podamos usar. Entender la manera, lugares y necesidades que los alojarán es un factor importante en la definición del dominio de la solución.

Elementos del Diagrama de Distribución Nodo. Representa un recurso de cómputo que puede alojar artefactos y que se puede interconectar con otros nodos para describir topologías de redes. Dispositivo. Representa un recurso físico de cómputo que posee capacidad de procesamiento; se representa igual que un nodo. Entorno. Ejecutable. Representa un recurso lógico de cómputo dentro del cual se alojan manifestaciones de componentes de cierto tipo.

Charlie Macías es arquitecto de software y consultor senior en UML de Milestone Consulting. Sergio Orozco es director general, consultor e instructor senior de Milestone Consulting (UML Value Added Training Center), empresa especializada en capacitación práctica y consultoría en UML, CMMI y orientación a objetos. Milestone Consulting es la primer empresa mexicana miembro de la OMG Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting (UML Value Added Training Center), empresa especializada en capacitación práctica y consultoría en UML, CMMI y orientación a objetos. Milestone Consulting es la primer empresa mexicana miembro de la OMG. info@milestone.com.mx www.milestone.com.mx

ENE-FEB 2007

www.softwareguru.com.mx

“Por más extraño que parezca, ni las clases ni los componentes se ejecutan en el hardware, ya que estos tipos de elementos carecen de manifestación en el mundo físico”. Rutas de Comunicación. Asociación que se modela sólo entre objetivos de distribución (nodos, dispositivos o entornos ejecutables) indicando que estos pueden intercambiar mensajes y señales. Componente. Representa unidades autocontenidas de software que realizan a las clases, o a cualquier elemento empacable Artefacto. Representa la manifestación de un componente en el mundo físico.

Un artefacto es una pieza de información física que usa o produce un proceso de desarrollo de software, una distribución o el funcionamiento de un sistema. Ejemplos de artefactos, son los archivos que distribuimos en el hardware, como los archivos JAR, WAR, EAR, EXE y DLL. En la siguiente figura podemos observar la relación que existe entre el concepto tradicional de componente y el artefacto donde se manifiesta.

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

Ambientando la Casa Los componentes necesitan de un ambiente donde se ejecutarán. Si deseas dejar gráficamente documentada esta información. El ambiente de ejecución se puede representar de manera similar a los nodos, es decir, en forma de cubo. Sólo que dicho ambiente se aloja dentro de un dispositivo, como se puede ver en la ilustración.

Figura 1. Dos recursos de cómputo con capacidad de procesamiento conectados y alojando artefactos.

Un artefacto no es una Ilusión Un concepto que para muchos resulta difícil de entender, es el artefacto. Especialmente por su relación con el concepto de componente. El nivel de abstracción es diferente en ambos casos, aunque podemos referirnos en cierta situación, a elementos muy similares. Por más extraño que parezca, ni las clases ni los componentes se ejecutan en el hardware, ya que estos tipos de elementos carecen de manifestación en el mundo físico. Para lograr la manifestación de las clases y componentes necesitamos un artefacto. www.softwareguru.com.mx

Figura 3. Artefacto que se ejecuta en un ambiente de ejecución dentro de un dispositivo.

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

// COLUMNA

/*TENDECIAS EN SW*/

Office Business Applications (OBA) y Line of Business Integration (LOBi) El Próximo Patrón Estratégico Luis Daniel Soto es director de Evangelización en nuevas tecnologías en Microsoft México. Entre sus funciones actuales están la de administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Es jurado del “Gran Orden del Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de TI. Ganó el primer lugar en el concurso nacional para software de exportación en 1989. blogs.msdn.com/luisdans

n la columna anterior hablé sobre Software as a Service (SaaS), el cual puede ser denominado como un patrón estratégico, tal vez el de mayor proyección e importancia hacia el resto de ésta década. Otros patrones estratégicos que existen actualmente en el mercado son: •Win32 – la mayoría de aplicaciones actuales para Microsoft Windows. •Dispositivos – teléfonos, portátiles, conectados a tv, embebido. •Empresarial – cliente-servidor, 3 capas. •Videojuegos – escritorio, consola, portátil, teléfonos.

Office System 2007 como plataforma de desarrollo

En esta ocasión, me referiré al que consideramos en Microsoft, el segundo patrón estratégico en importancia para el futuro: Office Oriented Applications. Las Office Business Applications (OBA) son una nueva categoría de aplicaciones de negocio, que permite utilizar aplicaciones de negocio (line of business systems) desde Microsoft Office.

En particular, es interesante la plataforma del servidor, que incluye una gran cantidad de nuevas tecnologías, entre las que destacan: •Colaboración: Blog y Wiki, RSS, Web Services API. •Administración de contenido: Extensible Type System, Records Repository API, Web Management API, Information Rights API, Document Converter. •Inteligencia de negocios: Excel Services Web API, Excel Services Calculation Engine, Filter Web Parts, Data Connection Library. •Procesos de negocio y formas: Pluggable SSO, Infopath Services. •Búsqueda empresarial: Web Services Search API, Business Data Catalog, iFilters. •Portal: Web Parts Framework, User Profile API, Audience Targeting API.

Imagina que tienes una capa de datos (backend), y una capa de lógica e integración con procesos de negocio (que residen en “lineof-business applications”, tales como ERPs, CRMs y SCMs), pero te falta tu capa de presentación. En lugar de desarrollar una aplicación web, un cliente windows, o utilizar el front-end de un CRM específico, puedes utilizar aplicaciones de Microsoft Office como tu capa de presentación y dejar que los usuarios interactúen con los procesos de negocio, a través de programas como Outlook que ya conocen bien, y que de todos modos, tienen abiertos durante todo el día. El siguiente diagrama ilustra a grandes rasgos la arquitectura de este nuevo tipo de aplicaciones.

Office 2007 será el gran habilitador de este tipo de aplicaciones. Los objetivos principales de esta versión son: 1. Mayor productividad en lo que cada herramienta ofrece. 2. Transformarse en un cliente de tres áreas poco desarrolladas en las empresas: a) Comunicaciones unificadas y colaboración; b) Administración de contenido empresarial; c) Inteligencia de negocios. 3. Convertirse finalmente en una plataforma de desarrollo auténtica.

Es importante señalar que estos servicios descansan en los nuevos “Windows SharePoint Services 3.0” (WSS 3.0) que se ofrecen gratuitamente para usuarios de Windows Server 2003 y Small Business Server. La infraestructura que ofrece WSS 3.0 incluye: flujos de trabajo, meta datos, búsqueda, auditoría, ayuda personalizada y otros servicios.

Conclusión OBA permitirá “abrir el retorno de inversión de toda la tecnología empresarial”. Consiste en aprovechar la plataforma existente al máximo. Algunos ejemplos: Panorama (BI en Sharepoint), Oracle Siebel (CRM desde Outlook), Hummingbird (Administración de documentos desde Word), Fractal Edge (Visualización desde Excel) y Mind Manager (Mapas mentales con Open XML), son algunos ejemplos concretos. Microsoft trabaja ya en “Office 14”, y la principal inversión a futuro será precisamente la categoría denominada LOBi (Line of Business integration). Evalúenlo con sus usuarios, y decidan ustedes mismos. —Luis Daniel Soto

Referencias Figura 1. Arquitectura de aplicaciones orientadas a Office.

ENE-FEB 2007

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

// COLUMNA

/* CÁTEDRA Y MÁS */

Realidad Virtual

Estimulando la Imaginación

El Dr. Mario Arturo Gutiérrez Alonso es profesor asistente del Departamento de Computación y Sistemas de Información de la Escuela de Ingeniería y Arquitectura del ITESM Campus Toluca. Sus áreas de interés son la Realidad Virtual, Animación 3D y la Inteligencia Artificial aplicadas al desarrollo de interfaces multimodales y simulación.

l término Realidad Virtual engloba una gran cantidad de ideas filosóficas, aplicaciones y áreas de investigación, todas ellas con un tema en común: “crear la sensación de estar ahí”, en un lugar que no existe o que en un momento dado es imposible alcanzar. No está muy claro quién fue el primero en acuñar el término; se mencionan autores como Damien Broderick, escritor australiano autor de “The Judas Mandala” (1982), y Jaron Lanier, investigador norteamericano fundador de VPL Research, una compañía que desarrollaba productos y aplicaciones de Realidad Virtual. Uno de los primeros ejemplos de sistemas de Realidad Virtual es el “Sensorama”, de Morton Heilig, desarrollado en 1962; un dispositivo mecánico que proyectaba una película de cine cuya reproducción era relativamente interactiva, e incluía la estimulación de múltiples sentidos: visión, sonido, olfato y tacto. El sistema simulaba un paseo en bicicleta donde además de audio y video, se liberaban diferentes aromas, dependiendo del lugar a visualizar en ese momento. Se trataba de una verdadera interfase multimodal o sistema multimedia, desarrollada antes que las computadoras digitales tuvieran posibilidades concretas de simular entornos virtuales. Cuando se habla de Realidad Virtual, tal vez las imágenes que vienen a la mente son las inspiradas por películas como “The Lawnmower Man” o más recientemente “The Matrix”. Estas y otras producciones cinematográficas, presentan un estado de la tecnología que aún no se ha alcanzado, y estimulan la imaginación al mostrar la posibilidad de crear simulaciones que sean indistinguibles o mucho más atrac-

ENE-FEB 2007

tivas que la misma realidad. Lo cierto es, que estamos aún lejos de tener simuladores que confundan la mente del usuario a tal grado, que ya no sea posible distinguir lo real de lo sintético. Simular realidades alternativas y entornos virtuales, implica una gran cantidad de áreas de conocimiento. La idea principal es que el camino hacia una simulación de la realidad, pasa por la estimulación simultánea y coherente de todos nuestros sentidos: vista, oído, olfato, tacto y gusto. La mayor parte de la investigación y el desarrollo se han enfocado en la vista y el oído. El primer prototipo de visualización de inmersión total, que utilizó tecnología digital fue el Head Mounted Display (HMD), desarrollado por Ivan Sutherland y Bob Sproull del XEROX PARC en 1962. El HMD de Sutherland y Sproull, fue uno de los primeros intentos por presentar al usuario una interfase en la que la interacción imitara la forma en que nos desenvolvemos en la vida real: las imágenes presentadas en una pantalla situada frente a los ojos, se actualizan dependiendo de los movimientos de la cabeza, como si el usuario estuviera “dentro” del entorno artificial. La tecnología del HMD ha evolucionado mucho en cuanto a la calidad de las imágenes, pero nunca ha tenido mucha aceptación, debido a que el dispositivo es muy incómodo (ver cybersickness). Recientemente, los sistemas de visualización han adoptado el uso de proyectores, y entre los dispositivos más sofisticados, se encuentran los CAVE (Cave Automatic Virtual Environment), seis o más pantallas de proyección que forman un área en la que, el usuario puede colocarse y verse

rodeado de imágenes sintéticas proyectadas en estéreo –simulando profundidad– con la ayuda de lentes polarizados especiales. La calidad de las imágenes sintéticas, ha mejorado mucho con los desarrollos del hardware especializado para la síntesis de gráficas en 3D. Hoy en día una PC con tarjeta de gráficos profesional, tiene poder de cómputo suficiente para visualizar escenas animadas complejas de gran realismo. Para tener una idea más clara, una aplicación 3D actual, es capaz de animar una escena urbana (parques y edificios), con alrededor de 35 mil personajes con comportamiento interactivo e independiente de alta calidad visual, a más de 30 cuadros por segundo (calidad de cine) para más información: http://vrlab.epfl.ch (VRlab-EPFL Suiza). En cuanto al audio, las tecnologías actuales permiten la reproducción de sonido envolvente de alta calidad, y podemos decir que en buena medida, este reto ha sido superado. El resto de los sentidos presentan problemas mucho más complejos de atacar, siendo el olfato y el gusto los menos estudiados. Sin embargo, existen trabajos de investigación relevantes que tratan de resolver el problema de la producción y liberación controlada de diversos tipos de aromas. Así mismo, hay prototipos como el “food simulator” que trata de imitar el masticar y saborear alimentos –un tipo particular de interfase háptica– (ver los trabajos de H. Iwata, Universidad de Tsukuba, Japón). Considerando el trabajo de investigación y los productos ya existentes en el mercado, el tacto es el tercer sentido humano más estudiado. Las interfaces hápticas (haptic www.softwareguru.com.mx

Las interfaces hápticas son dispositivos electromecánicos –robots–, que permiten simular la sensación de tocar objetos con las manos y otras partes del cuerpo.

interfaces) son dispositivos electromecánicos –robots–, que permiten simular la sensación de tocar objetos con las manos y otras partes del cuerpo, como el torso. Las interfases hápticas más comunes son los sistemas tipo PHANTOM. Estos dispositivos son brazos mecánicos con una especie de pluma o estilete, la cual, al ser manipulada por el usuario, permite simular la resistencia de diferentes materiales; como si tocáramos con una pluma, superficies con distinta textura y resistencia: metales, rocas, esponjas, etcétera. Otros dispositivos hápticos comerciales, son los producidos por la compañía Immersion Co. tales como la “Haptic Workstation”: un exoesqueleto que produce retroalimentación de fuerza en las muñecas y los dedos de ambas manos. Al combinar estas interfases con un sistema de sonido envolvente y un HMD, o un sistema CAVE, se pueden obtener entornos virtuales interactivos, muy útiles para realizar estudios de ergonomía en cabinas de todo tipo de vehículos; simulaciones de intervenciones quirúrgicas; terapias de inmersión total para el tratamiento de fobias (fobia social, aracnofobia, claustrofobia) y juegos de video, entre otros. Son muchos los retos de investigación a superar, antes de tener un sistema de Realidad Virtual en verdad convincente y accesible al público. En su mayoría, los prototipos actuales son desarrollados por universidades y empresas que le apuestan a las tecnologías emergentes. Sin embargo, poco a poco los frutos de la investigación se van filtrando en aplicaciones comerciales, y hoy en día tenemos efectos visuales de gran realismo en el cine y en juegos de video. Estos últimos son lo más cercano al triángulo ideal de la Realidad Virtual, pues son la integración de tres componenwww.softwareguru.com.mx

tes principales: interacción, inmersión y tiempo real. Una de las áreas de investigación más vanguardistas, en cuanto al componente interactivo se refiere, son las llamadas “brain interfaces”, trabajos pioneros encaminados a utilizar las señales eléctricas producidas por el cerebro y capturadas mediante electrodos, como medio de comunicación del usuario con la computadora. Los avances actuales permiten un control con cierta precisión del cursor de un mouse y la ejecución de acciones simples como abrir o cerrar una aplicación. Quizás el fin último será llegar a un sistema como el de “The Matrix”, en el que la simulación interactiva se realice estimulando directamente el cerebro, pero afortunada o desafortunadamente, aún estamos muy lejos de ello. La experiencia demuestra que, no se requiere de dispositivos muy complejos para lograr una inmersión total del usuario, y hacerle olvidar el mundo que lo rodea en favor de una realidad alternativa. Una pantalla de computadora o televisión con imágenes y sonido bien diseñados, son capaces de mantener la atención del usuario y aislarlo del mundo exterior por horas y hasta días, como todo buen aficionado a los videojuegos podrá constatar. En todo caso, a los interesados en incursionar en el fascinante mundo de la Realidad Virtual, les recomiendo documentarse en temas de gráficas por computadora, aprender a programar aplicaciones en OpenGL y/o Direct3D (DirectX) y revisar la abundante literatura científica sobre interacción humano-computadora, entornos virtuales y Realidad Virtual en general. —Por Mario Gutiérrez ENE-FEB 2007

// COLUMNA

/*TIERRA LIBRE*/

SimpleJ

Regresando la Diversión al Desarrollo de Software Emilio Osorio colabora actualmente como Consultor Asociado para Sun Microsystems México. Ha trabajado en desarrollos basados en Java desde 1996 y actualmente se dedica a ayudar a equipos de desarrollo a aprovechar las ventajas del Software Libre y los métodos ágiles en sus organizaciones. Ferviente entusiasta de la aplicación social de la tecnología, a ultimas fechas esta involucrado con Organizaciones de la Sociedad Civil. Emilio estaré encantado de recibir sus comentarios y quejas en http://tecnonirvana.org/ y en oemilio@tecnonirvana.org

éxico no escapa a la crisis mundial de déficit de profesionistas con capacidades reales de programación. El desarrollo de software atrae cada vez a menos jóvenes, y muchos de estos cambian de carrera antes de graduarse. No es extraño encontrar en las universidades, generaciones de carreras orientadas al desarrollo de software, con menos de 10 alumnos. Mucho se ha hablado de las causas de esta crisis, algunos culpan a la falta de profesionalismo y experiencia real de los maestros, otros, al mal ejemplo que damos los que somos parte de esta industria: nuestras jornadas de trabajo, niveles de estrés y costumbres geeks no son muy atractivas para jóvenes de 18 años que sólo se quieren divertir. Hace un par de años, Gerardo Horvilleur, mejor conocido como “El Mago”, se preguntaba si parte del problema no sería la creciente complejidad de los entornos de desarrollo de software. Si tienes más de 35 años, aceptarás que la forma de empezar a programar actual –no importa si profesas la religión de .Net, Java o algún culto menor– no se compara en nada con las “micros”, gloriosas máquinas como las Commodore, Apple o Tandys que llenaron nuestra adolescencia de disfrutes computacionales. Recordarás el ansia de esperar el siguiente Compute Gazzete o Ahoy! en el Sanborns, para copiar los programas de BASIC, sazonados con alguna otra rutina de ensamblador de 6510 en glorioso código hexadecimal. Este tipo de cosas te iniciaron en la programación y gracias a ellas decidiste que querías hacerlo por el resto de tus días. Los chavos de hoy, no tienen estas maravillosas opciones. No conozco mucho el caso de .Net, pero en el de Java al menos, creo que bajar Glassfish, Netbeans, y demás cosas “básicas” para programar, no llama tanto la atención de un adolescente como jugar el videojuego de moda y convertirse en consumidores, más que en creadores. Con las micros, si querías un juego, casi tenías que hacerlo. Ahí es donde Mago cree que está el problema: “los jóvenes ya no eligen estudiar programación, simplemente porque no es tan divertido y sencillo como lo era en esos tiempos”. Afortunadamente, Gerardo no se quedó con las manos cruzadas, y desarrolló Simple J, una novedosa apuesta a despertar la curiosidad de los chavos, creado con la intención muy noble de regresar la programación a su origen esencial: diversión. SimpleJ recrea un entorno de desarrollo virtual en Java, que permite crear juegos de video y compartirlos con el mundo. Simple J simula una computadora simplificada, para que sea más sencillo aprender a programar y evitar distracciones en detalles irrelevantes. La decisión de enfocarse en videojuegos me parece genial, es algo que los chavos conocen bien y les llama la atención. Sin darse cuenta, estarán aprendiendo a programar.

ENE-FEB 2007

No se necesita ser un experto para comenzar con SimpleJ. En el sitio de SimpleJ (www.simplej.com) está disponible un tutorial enfocado a quienes no saben absolutamente nada de programación, y los guía durante los primero pasos de la programación. Se comienza con cosas sencillas, y va aumentando la complejidad poco a poco, como si el programador fuera “pasando de nivel”, de tal forma que hacer un juego, se convierte en sí mismo, en un juego. Una parte muy importante de la escena de programación de hace 20 años, eran los grupos de usuarios donde los adolescentes nos presumíamos unos a otros lo que habíamos aprendido: scrolls de letras, música sintetizada, campos de estrellas que giraban, justo como en la “Guerra de las Galaxias”. Este componente es esencial en el desarrollo de buenos programadores, ya que normalmente vienen en múltiplos, y aprenden juntos, ya sea colaborando o compitiendo. SimpleJ promueve esto, a través de un applet que permite publicar los juegos desarrollados dentro de una página web para presumirlos al mundo. Así que, espero pronto encontrar muchos blogs de chavos mostrándole al mundo sus creaciones. Adicionalmente, SimpleJ cuenta con una comunidad donde por medio de foros, se pueden hacer preguntas, o ponerse de acuerdo con alguien más para hacer un videojuego. Mago personalmente contesta todas las dudas que puede, pero la comunidad es principalmente soportada por alumnos de todo tipo de instituciones académicas, desde universitarios del ITAM, hasta estudiantes del bachiller Juan de Dios Bátiz del IPN. Estas son escuelas visionarias, que han entendido el potencial de dicha herramienta en el proceso educativo. Espero que pronto se unan muchas más instituciones académicas a este esfuerzo. Finalmente, una de las partes más importantes de este desarrollo –además de que es 100% mexicano–, es su modelo de negocios. SimpleJ es software libre, licenciado con GPL y completamente abierto. Mago ha decidido concentrar sus esfuerzos para hacer sustentable este proyecto a través de la venta de un libro que tiene disponible para aprender a programar juegos de video con SimpleJ. Si tienen algún hijo o familiar adolescente y con intereses tecnológicos, no dejen pasar la oportunidad de pasar un buen rato con ellos recordando viejos tiempos, y ayudando a que la industria de software en México tenga los mejores programadores. Una felicitación desde aquí, al talento y entusiasmo de Gerardo (mago@simplej.com), sin duda, un ejemplo a seguir en el software libre mexicano. — Emilio Osorio www.softwareguru.com.mx

// FUNDAMENTOS

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

Cuando estamos inmiscuidos en el área de la enseñanza, muchas veces repetimos patrones, y terminamos enseñando de la misma forma en que nos dictaban clase nuestros maestros. Usted, que ya ha aprendido a programar, ¿recuerda sus inicios? Remontémonos a aquella clase de Pascal, Cobol, Fortran, Basic o C. Como podrá recordar, lo que se hacía era básicamente analizar a detalle los resultados, o bien, proporcionar los datos necesarios para generarlos. Posteriormente, se realizaba el diagrama de flujo, lo cual implicaba diseñar la solución, y antes de pasar a construirlo, se verificaba a través de una prueba, que eso realmente estaba correcto. Todos aprendimos, pero, ¿será esta la manera más efectiva de enseñar? Tomemos unos minutos de nuestro tiempo para considerar ciertos aspectos de la enseñanza. Para poder analizar un problema, encontrar rápidamente una solución y construirla, se requiere del desarrollo de ciertas habilidades. Esto se da a través de un adecuado proceso de enseñanza-aprendizaje. Sin embargo, los cimientos deben definirse desde un primer contacto con algún curso de programación. Por lo general, hay un trabajo previo con problemas razonados donde están involucradas diferentes variables y con aplicaciones prácticas; esto ayudará a que ese primer encuentro se convierta en un reto atractivo.

Para que un estudiante pueda llegar a construir programas sin importar el lenguaje de programación, es muy importante el desarrollo de la lógica. El objetivo no es enseñarle instrucciones como, “imprimir”, “leer”, etcétera. –Cualquiera puede aprenderse líneas de texto y su significado–, sino que debemos enfocarnos en enseñarles cuándo y cómo usarlas, cuándo y cómo combinarlas, incluso mejorar la solución usando otras instrucciones. El alumno necesita entender a detalle el significado de cada tema y complementar esto con su práctica y aplicación, al mismo tiempo que utiliza un lenguaje de programación. Muchas veces, para los alumnos resulta difícil entender significados como, ciclos, condicionales, métodos, archivos, arreglos, y más aún si esto se combina con la teoría de objetos y cómo pueden ser aplicados. Así pues, surge en el estudiante la típica pregunta: “¿y para qué me sirve esto que me están explicando?” No hay que olvidar que, cuando el lenguaje de programación es sencillo, esas instrucciones que se aprenden rápidamente se pueden memorizar; pero quizás esto sólo serviría cuando la persona ya tiene un camino recorrido en cuanto a la lógica de programación, de otra forma no lograremos un aprendizaje significativo. Uno de los puntos que debemos observar con atención, es que siempre se debe tener una estrategia de enseñanza donde se mantenga una relación directa entre aquello que se está enseñando, y la vida real; de prefe-

rencia algo que los estudiantes ya hayan experimentado previamente. Por ejemplo, cuál es el proceso que tiene una tienda de autoservicio cuando la cajera pasa el producto por un lector de código de barras, o qué sucede cuando ellos entran a un sitio en Internet para comprar un libro, o bien, qué pasa en un restaurante de comida rápida cuando solicitan algún tipo de alimento. A través de estos ejemplos, entenderán el significado y la aplicación de aquello que se está explicando y así, despertaremos el interés por resolver cierto tipo de problemas. No será lo mismo si el primer bloque de problemas a resolver que enfrenta alguien que está aprendiendo a programar, son series de Ulam, Fibonnaci, funciones exponenciales, logarítmicas, números primos, o generar las raíces de una ecuación cuadrática. Como educadores, debemos despertar el interés de nuestros estudiantes; de nosotros depende captar y conservar la atención para lograr un nivel de aprendizaje satisfactorio. Muchas veces esto se logra cuando nos enfocamos al desarrollo de juegos, donde ellos tengan la capacidad de cumplir con las especificaciones que se les indicó, y que además, puedan aplicar su maravillosa creatividad, que puedo asegurar que nos dejará asombrados. Como instructores, siempre hay que considerar el tipo de público que en ese momento tengamos en frente. Además, nos ayuda mucho si mostramos los temas de la manera más gráfica posible, sobre todo cuando se trata de temas abstractos como archivos, arreglos y métodos. Podemos

Ing. Ma. del Consuelo Jiménez Fernández es profesor asociado del departamento de Ciencias Computacionales en la Universidad de Monterrey. Ha recibido en más de diez ocasiones el primer lugar en el concurso de investigación vinculada a la docencia de la UDEM, y también ha recibido el premio a la calidad docente. Sus áreas de especialidad son: Metodologías para el Desarrollo de Software, Lenguajes de Programación, y Administración de Proyectos. Actualmente, es una de las evaluadoras en las propuestas de proyectos para la incubadora en UDEM. cjimenez@udem.edu.mx

ENE-FEB 2007

www.softwareguru.com.mx

“El desarrollo de juegos nos ayuda a despertar el interés de nuestros estudiantes, para lograr así un nivel de aprendizaje satisfactorio”. apoyarnos en paquetes que permiten simular o animar la teoría relacionada a estos temas, y que tienen ejemplos representativos y claros. Otro aspecto importante que convendría considerar en la enseñanza de la programación, es que cuando no existen bases firmes en el área matemática, se le dificulta más al alumno captar rápidamente operaciones tan simples como, cálculo de porcentajes, promedios, frecuencias, divisores, etcétera; todos ellos son conceptos que se enseñan desde la primaria, pero que por no llevarlos a la práctica suelen olvidarlos fácilmente. Es recomendable tener diseñado un curso en un ambiente en línea, más para estos casos, de tal forma que la persona que requiera un refuerzo pueda acceder a manera de autoestudio a aquellos módulos que le ayuden a repasar o entender esos conceptos. ¿No cree usted que los cursos enfocados a desarrollar la lógica de programación, deberían ser parte esencial de los programas académicos desde la primaria? Si nuestro objetivo es enseñar a programar, y vemos que existen áreas de oportunidad para ello, sería preciso hacer un análisis al grupo de personas que recibimos a través de algún instrumento diagnóstico, así podremos definir estrategias y estilos adecuados de enseñanza-aprendizaje. El diseño de nuestras estrategias nos ayudará a lograr nuestra principal meta: “pensar de forma lógica”, para luego programar utilizando un lenguaje de programación. En realidad, son muchos los elementos que en un primer curso, los estudiantes de programación tienen que aprender y dominar: la lógica, el lenguaje para programar donde la sintaxis puede ser simple o compleja; los estándares, el desarrollo de la www.softwareguru.com.mx

documentación y el entorno de desarrollo. Si logramos que tengan estas bases bien cimentadas, entonces de ahí, se desprenderán la correcta definición y relación que tengamos entre los estilos de enseñanza y aprendizaje. Todos los que nos dedicamos a la enseñanza de la programación, fuimos inspirados por algún buen maestro, y nuestro deber ahora, es transmitir lo mejor posible esta pasión por lo que hacemos, tomando lo mejor de nuestros instructores, y añadiendo lo que hemos aprendido en el camino. ¿No le gustaría a usted, que cada uno de sus estudiantes por lo menos, conservara una actitud positiva ante lo aprendido? El balón está de nuestro lado.

Algunos puntos clave para tomar en cuenta: •Analice a su público o grupo. •Defina sus estrategias de enseñanza y aprendizaje, considere los estilos. •Apóyese de elementos gráficos, animaciones o simulaciones. •Tenga como apoyo su curso en línea y retroinforme de manera constante. •Cree un banco copioso de ejercicios, material de contenido y exámenes. •Sea sencillo en su explicación. •Cambie siempre la actitud de su grupo cuando ésta sea negativa. •Utilice problemas que permitan a la persona establecer una relación con lo real. •Practique para poder aplicar lo aprendido. •Y por favor, si tiene dudas al manejar un tema, pida a sus alumnos tiempo para investigarlo, y explíquelo cuando se sienta seguro. Ellos se lo agradecerán.

SEP-OCT 2006

// INFRAESTRUCTURA

Asterisk

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

Durante el año pasado tuvimos la oportunidad de publicar varios artículos relacionados con tecnologías de VoIP (voz sobre IP), ToIP (telefonía IP), protocolos y aplicaciones basados en SIP (Session Iniciation Protocol). Toda esta tecnología se integra para poder brindarnos comunicaciones punto a punto de voz, datos y video. En esta ocasión, vamos a conjuntar todos estos conceptos en una aplicación open source, que está siendo adoptada significativamente y merece nuestra atención en este número. Para aquellos que no están familiarizados con el mundo de la telefonía y desconocen las características de un PBX (Private Branch Exchange), por favor continúen leyendo. Para quienes cuentan con amplia experiencia en este tema, si así lo desean, pueden ir directamente a la explicación de Asterisk (www.asterisk.org).

¿Qué es un PBX? Un PBX en la jerga de TI, es lo que conocemos terrenalmente como un conmutador de teléfonos. Sin embargo, hay que hacer la distinción del alcance de funcionalidad que tiene este equipo. El PBX usualmente está compuesto por tarjetas de circuitos electrónicos, semejantes a un motherboard, que se insertan en gabinetes. Con este hardware, además de la funcionalidad de telefonía interna, tenemos servicios de correo de voz, transferencia de llamadas, conferencias, enrutamientos, configuraciones de call center, identificador de llamadas, códigos de seguridad, tarificación, etcétera. Por lo general, algunos servicios como por ejemplo, el correo de voz, viene asociado a una tarjeta en el gabinete. Típicamente, dichos equipos trabajan con troncales analógicas o digitales, con conexión directa a las centrales de fibra óptica o cobre de los proveedores telefónicos. En algunos casos es posible trabajar con líneas directas comerciales, pero esto sucede por lo regular en implementaciones pequeñas, donde quizás no sea necesario el uso de un PBX, dado los costos que implica tenerlo, que provienen de mantenimiento de hardware y software de las tarjetas,

ENE-FEB 2007

servicios de programación o capacitación para hacerlo con personal interno, contratos de 7x24 en caso de fallas, dada la criticidad del servicio, etcétera. La tecnología de ToIP, trajo la evolución de estos equipos PBX en los hoy llamados call managers. Un call manager es simplemente un servidor que, a través de software provee la misma funcionalidad de un PBX, sin necesidad de adquirir y mantener las costosas tarjetas y gabinetes de los PBX. A través de la implementación de ToIP, los costos de operación y mantenimiento del equipo de telefonía se reducen de forma dramática, dado que ofrecen la misma funcionalidad a precios más bajos con mayor redundancia, y una mejor oferta de soluciones, dado que se incorpora el video en tiempo real y los beneficios del mundo IP. Aunque un call manager es más eficiente en términos de costos que un PBX, también requiere de una inversión considerable de capital para su implementación. O cuando menos, así lo era antes de que el open source llegara al mundo de la telefonía IP. Aquí es donde entra Asterisk.

¿Qué es Asterisk? Asterisk es una aplicación que tiene toda la funcionalidad de un call manager, y por ende, las de un PBX, corre bajo plataforma Linux BSD o Mac OSX, y además tiene la fabulosa cualidad de ser open source. Antes de continuar, deseo resaltar la magnitud del párrafo anterior con un ejemplo: una

solución de ToIP o de un PBX con la funcionalidad antes mencionada, significa una inversión que va desde 50 hasta 100 mil dólares, en una implementación pequeña. No puedo ser más explicito en el impacto que podría tener Asterisk en nuestra empresa. El software fue escrito originalmente por Mark Spencer de Digium Inc. y constantemente el código se está enriquecido por la comunidad open source de todo el mundo. A la fecha, se continúan realizando pruebas, desarrollo de parches y extensiones que han impulsado fuertemente al desarrollo y adopción de dicha aplicación El programa no requiere de hardware adicional para soportar VoIP, y existe una buena variedad de dispositivos para que Asterisk pueda interconectarse con equipo tanto digital como analógico. La mayor parte de estos dispositivos provienen de Digium, que es la marca que patrocina a Asterisk. Se cuenta con hardware para poder conectar la aplicación a troncales E1 y T1 para conexiones PRI (Primary Rate Interface) que son las interfaces más comunes usadas por las empresas con un alto volumen de llamadas. Para las pequeñas y medianas empresas, se cuentan con dispositivos para la conexión de líneas tradicionales, que pueden usarse a través de módulos con puertos FXS, FXO. Asterisk cuenta con un amplio rango de protocolos TDM que le permiten el manejo y transmisión de voz sobre interfases tradicionales, soporta la señalización estándar de los sistemas telefónicos comerciales, tanto americanos como europeos, lo cual le permite co-

www.softwareguru.com.mx

“Asterisk es una aplicación que tiene toda la funcionalidad de un call manager, y además tiene la fabulosa cualidad de ser open source”.

nectarse a los sistemas de nueva generación o, a una infraestructura existente.

Arquitectura Asterisk está diseñado para brindar una alta flexibilidad en su funcionalidad. Existen APIs que se diseñaron específicamente, como el núcleo central de un PBX. Este núcleo es el encargado de administrar las interconexiones internas, abstrayéndolo de los protocolos específicos, codecs, e interfaces de hardware de las aplicaciones de telefonía. El núcleo de Asterisk administra las siguientes funciones de forma interna: •PBX Switching. Esta unidad de switching conecta de forma transparente las llamadas que llegan desde cualquier interfase, ya sea de hardware o software. Es el corazón de Asterisk, y contiene el núcleo de la funcionalidad de PBX conectando las llamadas entre los usuarios y automatizando tareas. •Lanzador de Aplicaciones. Lanza las aplicaciones para los servicios como correo de voz, directorio, grabación y reproducción de llamadas. •Traductor de Codecs. Utiliza los módulos de codecs para la codificación y decodificación de los formatos de audio estándar de la industria. Se cuentan con los codecs más comunes para satisfacer las distintas necesidades que pueden surgir, para encontrar el balance entre calidad de audio y ancho de banda de nuestra implementación. •Scheduler and I/O Manager. Administra las tareas programadas de bajo nivel y es el encargado del manejo del sistema, para el desempeño óptimo bajo cualquier condición de carga.

www.softwareguru.com.mx

Módulos APIs A través del uso de este sistema de módulos, el núcleo de Asterisk se despreocupa de detalles como de dónde proviene una llamada, qué codec utiliza, etcétera. •API de Canal. El API de canal administra el tipo de conexión de la llamada que está llegando al sistema. Esta puede ser una conexión VoIP, ISDN, PRI u otra tecnología. Los módulos dinámicos se cargan para manejar las capas de bajo nivel para la detección y manejo de estas conexiones. •API de Aplicación. El API de aplicación permite que se corran varios módulos de tareas para ejecutar distintas funciones, como conferencias, directorio, correo de voz, y cualquier otra tarea que un sistema PBX podría desempeñar ahora o en el futuro. Estos módulos pueden administrarse por separado. •API Traductor de Codec. Este API tiene la función de cargar los módulos de codecs para soportar los distintos formatos para la codificación y decodificación del audio. Estos pueden ser: GSM, Mu-Law, A-law, e incluso MP3. •API de Formato de Archivos. Administra la lectura y escritura de varios formatos para el almacenamiento de datos en el sistema de archivos. Gracias a este manejo de módulos, es posible integrar los sistemas de hardware actuales de telefonía o las nuevas tecnologías de voz que puedan emerger. La implementación y puesta a punto de esta aplicación, podría parecer complicada, pero

la realidad es distinta. Existen varias guías para llevar acabo una implementación completa de Asterisk, y adquiriendo el hardware adecuado, se puede implementar como el equipo de telefonía de cualquier oficina, sin importar su tamaño o complejidad. Aunque usted no lo crea, hoy en día existen varias empresas mexicanas que ya están utilizando este software como su sistema de telefonía. Lejos de pensar que su operación se ve comprometida al trabajar con una aplicación open soruce, resulta que su comunicación se ve incrementada, al poder contar con los beneficios de la telefonía IP a un costo bajo. Esto, sumado con el soporte y contribución continua de la comunidad del open source, debería llevar a cuestionarnos si realmente deseamos continuar operando con nuestro PBX actual o realizar inversiones fuertes para implementar una solución de telefonía IP propietaria. Como siempre, la decisión es del negocio, y la única forma de comprobar los beneficios de tal aplicación es, evaluándola y presentando los resultados con un análisis de riesgos. Por ello, los invito a que instalen Asterisk en su ambiente de desarrollo y vean si cumple las expectativas de su negocio.

Referencias • www.asterisk.org • www.digium.com/en/index.php • www.voip-info.org/wiki-Asterisk+ installation+tips

ENE-FEB 2007

////TECNOLOGÍA TECNOLOGÍA

/* GADGETS */

D-Link

Wireless Presentation Gateway Hacer presentaciones desde diversas computadoras, proyectores y monitores sin utilizar cables, es el objetivo primordial del Wireless Presentation Gateway DPG-2100 de D-Link. Este pequeño dispositivo hace que la comunicación entre equipos sea posible, de tal manera que, si en la sala de juntas se proyectan varias diapositivas desde diferentes equipos, no será necesario estar conectando cada equipo. Está basado en el estándar inalámbrico 802.11g, que lo hace compatible con la mayoría de los dispositivos inalámbricos, incluyendo los antiguos 802.11b. Además es capaz de manejar cualquier formato de archivo, en silencio o con audio. Es posible también acceder a Internet para integrar en las presentaciones contenido directo de la Web gracias al puerto Ethernet.

Pyramat

s2000 Sound Rocker

Widow PC

SLI Laptop WidowPC es una compañía norteamericana por Internet, dedicada a la fabricación de computadoras pensadas en la experiencia de juego y en los videojugadores. Ellos mismos se denominan, el “Porsche” de las computadoras; y presentan la nueva generación de desempeño móvil para juegos de video. Es una de las más rápidas e incluye uno de los frame rates más veloces en cuanto a plataformas móviles se refiere; además soporta hasta tres monitores al mismo tiempo y cuenta con tarjeta de video dual NVIDIA 7950 GTX con 1028MB. Entre algunas otras de sus características destacan: memoria DDR3, procesador AMD Turion 64bit Dual Core, monitor LCD con ClearView de 19” con resolución de 1680X1050, cinco puertos USB 2.0, uno para teclado y video externo, cuatro para audio, uno PMCIA y S-Video, entre otros. La tecnología integrada en esta computadora portátil, también ofrece alta definición para explotar al máximo el poder gráfico de los videojuegos, así como para la reproducción de contenidos digitales.

Acción en directo de los videojuegos, películas o música, es la mejor forma de definir al s200 Sound Rocker, un sillón equipado con subwoofers PowersubTM de 5.5” que envía intensas vibraciones y sonido nítido, de tal manera que es posible apreciar desde un disparo hasta la respiración de un personaje. Cuenta a su vez, con altavoces iluminados ARXTM de alto desempeño y largo alcance que aceleran la experiencia de juego. Está fabricado en tela Poly-strech que además de brindar confort durante largas horas, es porosa, permitiendo así, la ventilación entre el cuerpo y el sillón. En los costados se encuentran entradas para audífonos, controles de volumen y bajos, así como puertos RCA multi player. Es compatible con casi todas las consolas de videojuegos, televisores, reproductores de video y MP3.

Space Invaders 5-en-1 Plug & Play Para recordar aquellos tiempos en que jugar videojuegos no requería de pulsar seis botones y mover el joystick a la vez, y las palabras “combo”, juego en línea, inmersión o gráficos en alta definición ni siquiera figuraban en el vocabulario, existe esta pequeña curiosidad retro, que de seguro a muchos les provocará un nudo en la garganta y, a otros, quizá hasta derramar un par de lágrimas. Tan simple como es, rayando en lo ridículamente hipnótico, Space Invaders se ha convertido en un icono cultural, y para celebrar su 25 aniversario, qué mejor que una unidad plug & play con cinco juegos: Space Invaders, Phoenix, Qix, Lunar Rescue y Colony 7. Todo al más puro estilo arcadia. Se conecta directamente al televisor vía cables AV, y su tamaño compacto, permite llevarlo a cualquier parte para aprovechar las televisiones que se atraviesen por el camino.

ENE-FEB 2007

www.softwareguru.com.mx

INDEX

DIRECTORIO

Anunciante

Pรกginas

Sitio

AMCIS Avantare ExpoComm e-Quallity Gartner Itera LinuxWorld Microsoft Milestone Consulting Roca Sistemas SafeNet Select / Tendencias Tiburรณn Software

55 51 45 43 F3 07 49 F2-01, 23 F4 11 13 19 47

www.amcis.org.mx www.avantare.com www.expocomm.com.mx www.e-quallity.net www.gartner.com/mx/appint www.itera.com.mx www.linuxworldexpo.com www.microsoft.com/mexico www.milestone.com.mx www.rocasistemas.com.mx www.safenet-inc.com www.select.com.mx www.tiburonsoft.com

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

www.softwareguru.com.mx

ENE-FEB 2007

// REFLEXIONES

Programas Correctos Parte 3. Pensar No es Opcional Por Marco Antonio Dorantes

Software durable implica diseño continuo Identificar el verdadero problema a resolver y diseñar el programa atinado, representa el mayor avance en un proyecto de desarrollo, la parte restante se trata de hacer de manera correcta dicho programa. El problema identificado típicamente continúa co-evolucionando junto con su solución[1], en otras palabras, la solución tecnológica y el problema de negocio se influencian mutuamente. Una noción común dice que, el mayor costo y esfuerzo en la aplicación de software para resolver problemas de negocio, sucede en el desarrollo del mismo, y una vez que está en producción, es sólo mantenimiento y operación, por lo que las mentes brillantes sólo se requieren en el desarrollo; en muchos casos esto sucede al revés, la necesidad de un diseño flexible y adaptable[2] a situaciones poco previsibles —sin importar cuánto esfuerzo de análisis se haya hecho— ocurre en la etapa de mantenimiento, donde el negocio de verdad necesita dicha flexibilidad, por lo que en tales casos, más vale transferir una parte significativa del costo de desarrollo a dicha etapa de mantenimiento. En otras palabras, la actividad de diseñar[3] se requiere a lo largo de todo el ciclo de vida del software.

Best practices Para algunos está claro que, cuando se presenta un best practice, en realidad se está hablando de conocimiento tácito, es decir, conocimiento que sólo existe en la cabeza de las personas y que llegó ahí por su experiencia personal, o por observar de primera mano a otro profesional en plana acción; dicho conocimiento es de difícil acceso, y por lo tanto muy valioso. Lo que no está claro para muchos, es que dicho conocimiento tiene contexto, y su transmisión efectiva requiere una interacción extensa así como una amplia confianza entra las personas, y por ende, no es algo que se transmita de forma escrita —por definición deja de ser conocimiento tácito. El riesgo de tomar como best practice el conocimiento obtenido fácilmente en publicaciones o seminarios reside en la frase: “no tienes que pensar, sólo aplica el best practice”—, pues impide lo que precisamente es necesario hacer para adquirir el conocimiento tácito: pensar en contexto.

Adaptación es clave, el mapa no es el terreno Una vez que tienes experiencia con un buen número de métodos de diseño, sigue el reto de saber cómo y cuándo adaptar un método a una situación en particular. ¿Qué mantener o qué dejar de lado? ¿Qué agregar? Una manera es ignorar esta complejidad esperando que las cosas simplemente pasen, pero en tal caso, sería mejor dedicarnos a otra cosa y dejar esto en manos de alguien que le importe. El panorama de aplicación de software para resolver problemas de negocio, se observa cada vez más demandante, y la necesidad de métodos dinámicos que se adapten al vuelo será cada vez más necesaria. Un balance adecuado de propiedades como las que presenta Alistair Cockburn[4] (Entrega frecuente, comunicación efectiva, mejora reflexiva, etcétera.) puede

ayudar para confeccionar el método de diseño para tu próximo proyecto de desarrollo. Otra opción es esperar que alguna figura autoritaria y no practicante, te diga cómo tienes que programar, o simplemente seguir con la inercia de los proyectos en crisis, donde los integrantes ya saben que el proyecto va a fracasar y que sólo hay que hacer como que trabajas, aceptando que “la realidad es así”.

Conclusiones David West nos presenta algo que llama curiosidades, en la introducción de su libro[5] y que reflejan ciertos comportamientos muy diseminados en nuestra industria, que parecieran ser muy sólidos y muy bien definidos, pero ante la luz de un poco de investigación, resultan ser sólo malos entendidos. Por ejemplo, ante la pregunta: ¿Cuál es el siguiente paso después de orientación a objetos?, Martin Fowler respondió que se necesita entender realmente el paradigma de objetos como primer paso, antes de pensar en lo siguiente, o cómo dice Anders Hejlsberg[6]: “orientación a objetos antes era como religión y que apenas ahora está empezando a ser realmente útil para cada vez más personas”. La respuesta de David Parnas[7] tiene mucho sentido, cuando responde a la pregunta: ¿Cuáles son las ideas más prometedoras de ingeniería de software en el horizonte?, diciendo que las ideas más prometedoras no están en el horizonte, sino aquí mismo y desde ya hace tiempo, solamente que no han sido usadas como se debe. Ha sido un placer escribir este artículo en sus tres partes. Sus comentarios son bienvenidos: mdorante@hotmail.com

Referencias 1. Wicked Problems, Righteous Solutions blogs.msdn.com/marcod/archive/2004/06/12/154131.aspx 2. Unconscious Design Defined blogs.msdn.com/marcod/archive/2005/04/03/ UnconsciousDesignDefined.aspx 3. The Engineering in Software Development – Trails of Design Mastery blogs.msdn.com/marcod/archive/2004/06/23/163358.aspx 4. Just-In-Time Methodology Construction alistair.cockburn.us/crystal/articles/jmc/ justintimemethodologyconstruction.html 5. David West. Object Thinking. 6. Life and Times of Anders Hejlsberg channel9.msdn.com/Showpost.aspx?postid=159952 7. ACM Special Interest Group on Software Engineering (SIGSOFT) Software Engineering Notes. ACM Fellow Profile: David Lorge Parnas www.sigsoft.org/SEN/parnas.html

Marco Antonio Dorantes Martínez es un consultor en el diseño y formulación de software desde 1987, oficio que lo llevó a la investigación aplicada en el campo de los métodos sistemáticos para diseño de software. Ha realizado diversas contribuciones públicas en la comunidad mundial de programación, tanto en foros técnicos como en software, por ejemplo AutoTest for .Net y CppUnit for C++Builder disponibles desde www.xprogramming.com. Publica un diario electrónico en blogs.msdn.com/marcod

ENE-FEB 2007

www.softwareguru.com.mx

Aﾃｱo 03 No. 01

www.softwareguru.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Enero-Febrero 2007