Sg-200704

• Mejora de Procesos • Mantenimiento • Diseño orientado a objetos [ ENTREVISTA ]

Scott Ambler Software Guru CONOCIMIENTO EN PRÁCTICA Año 03 No. 4 • Julio-Agosto 2007 •

México, $65.00

La Evolución de Ágil

www.sg.com.mx

WEB 2.0 El poder de la colaboración

Noticias • Eventos • Fundamentos • UML • Infraestructura • Biblioteca • Gadgets

[ Tutorial ]

Apache Lucene

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Arte y Diseño David Gutiérrez 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

Colaboradores Oscar Cortés, Miguel Ángel Morán, Aldo Hernández, Alexis Castañares, Edgar Parada, Carlos “Fofo” Ordoñez, Rocío García Ocaña, José M. Esquivel, Aquiles Santana, Juan M. Hernández, Luis Daniel Soto, Sergio Orozco, Ariel García, Emilio Osorio, Jorge Palacios, Susana Tamayo.

Sabemos que cuando les llegue esta revista probablemente ya vayan a estar hartos de oír sobre Web 2.0 y estén listos para ahorcar a la próxima persona que se quiera hacer el interesante sacando a colación este término. Definitivamente es algo que ha sido sobreexplotado, y sinceramente nos disculpamos por contribuir a ello. Es solo que consideramos que realmente es algo notable, y por lo tanto no lo podíamos dejar pasar sin atender. Hemos hecho un gran esfuerzo por proveer artículos serios y objetivos que los ayuden a formar una opinión propia e informada sobre esta tendencia. Para nosotros, lo verdaderamente notable de Web 2.0 no es la tecnología, sino la participación. Esto es lo que realmente agrega valor y le da su sabor. Es por ello que los invitamos a participar para generar la creatividad de este número, y estamos muy satisfechos con los resultados. La verdad es que no cualquier revista puede darse el lujo de darle tan solo un par de días a sus lectores para que envíen fotografías personales, y obtener tan

02

JUL-AGO 2007

buena respuesta. Muchas gracias. Esperamos que les haya gustado el resultado, y que logren encontrarse por ahí. Esta edición de SG es una de las más densas que hemos hecho, en términos de contenido técnico. Esperamos que sea de su satisfacción. Ya saben que con gusto recibimos cualquier retroalimentación en [email protected] Cada vez está más cerca SG ’07. Estamos muy emocionados de volver a verlos y sentir esa energía. Sabemos que ustedes también están muy interesados en poder asistir para aprender y compartir experiencias con sus colegas. Les garantizamos que estamos haciendo todo para que esta edición salga todavía mejor que el año pasado. La visión sigue siendo la misma: tener en México un congreso de clase mundial para profesionistas de software. — Equipo Editorial

Fotografía Lectores SG Ventas Claudia Perea Natalia Sánchez Marketing y RP Dafne Vidal Circulación y Subscripciones Daniel Velázquez Administración Araceli Torres Contacto [email protected] +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. Queda 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-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en julio de 2007 en Litográfica Roma. Distribuido por Rrecca Comercializadora y Sepomex.

www.sg.com.mx

contenido jul-ago 2007

18

EN PORTADA WEB 2.0

A través de una variedad de artículos definimos qué es el Web 2.0, qué características tienen las aplicaciones de este tipo, y cómo es que se desarrollan.

Productos LO QUE VIENE 10 Tecnologías RIA, Visual Studio 2008, JBoss Seam 2.0, Spring Batch TUTORIAL Desarrollo de código seguro con Visual Studio

Columnas

Prácticas

Tejiendo Nuestra Red por Hanna Oktaba

06

Tendencias en Software por Luis Daniel Soto

43

Mejora Continua por Luis Cuellar

08

Tierra Libre por Emilio Osorio

46

Cátedra y Más por Raul Trejo

30

04

INFRAESTRUCTURA

50

Fundamentos

48

BIBLIOTECA

56

Scott Ambler La Evolución de Ágil

www.sg.com.mx

32

José M. Esquivel hace un repazo sobre la importancia del mantenimiento de software, y algunas mejores prácticas de esta disciplina.

Finalizamos este caso de estudio, donde aprendimos a aplicar la técnica de análisis de puntos función a un caso real.

Noticias y Eventos

Entrevista

MANTENIMIENTO Mantenimiento de Software

ADMINISTRACIÓN DE PROYECTOS 34 Análisis de Puntos Función, parte 3

En Cada Número

14

12

MEJORA DE PROCESOS 37 Las 7 Claves de la Mejora de Procesos Rocío García comparte con nosotros algunos tips y recomendaciones clave para la mejora de procesos en las organizaciones de software.

DISEÑO El Mariachi Orientado a Objetos

40

Carlos Ordoñez adopta un enfoque divertido para explicar un tema bastante complicado: la incorporación de patrones para hacer más flexible y robusto un diseño orientado a objetos.

JUL-AGO 2007

03

// NOTICIAS

SUN Tech Days 2007 La gira mundial Sun Tech Days 2007 realizó su visita correspondiente a la ciudad de México del pasado 16 a 18 de mayo. Este tour visitó 15 ciudades en todo el mundo, y es una excelente noticia que se hayan incluido 3 ciudades de América Latina: Buenos Aires, Sao Paulo, y Ciudad de México. Algo que le dio mucha fuerza al evento de Ciudad de México es que se realizó apenas unos días después del JavaOne 2007, y las presentaciones ya incluían mucho de lo que se vio en dicho evento, así que los asistentes tuvieron oportunidad de estar en contacto con lo último de lo último en cuanto a tecnologías como Java, Solaris y NetBeans. Los archivos de las presentaciones se pueden descargar en: http://suntechdays.com.mx/downloads/

IBM Strategic Innovation Forum Los pasados 29 y 30 de mayo, IBM llevó a cabo el Strategic Innovation Forum, uno de los eventos más importantes de IBM en el 2007, donde acudieron clientes de diferentes industrias en busca de propuestas que les apoyen a mejorar sus procesos y estrategias de negocio. Se revisaron temas como la optimización de la infraestructura, el poder de la información, gobernabilidad, manejo de riesgos, y la flexibilidad en los negocios. Eduardo Gutiérrez, Director de la división de software en México, nos comentó que el siguiente paso de IBM es convertirse en la empresa de software más importante. Por lo que estaremos recibiendo noticias de IBM en el segmento de software.

Directores TI 2007 Los días 13 al 15 de junio, hospedada en la Universidad Veracruzana, se llevó a cabo la XVI Reunión Nacional de Directores de Escuelas y Facultades de Informática y Computación, que organiza la Asociación Nacional de Instituciones de Educación en Tecnologías de la Información – ANIEI. Durante la reunión se realizaron mesas de trabajo que revisaron temas como: modelos curriculares, vinculación academia-industria-gobierno, y siguientes metas para la estrategia 2 de PROSOFT, entre otros. Como problemas prioritarios se identificó la baja en las matrículas de las carreras de TI, la enorme brecha entre la oferta y la demanda de capital humano; problemas que ya en la actualidad, impiden el desarrollo de la industria de software en México. Ya los Directores de las carreras de TI se encuentran trabajando al respecto, pero es necesario que todos los involucrados pongamos nuestro granito de arena. Para mayor información visita: www.aniei.org.mx

04

JUL-AGO 2007

www.sg.com.mx

// EVENTOS

16 al 18 de Julio 2007

23 de Agosto 2007

Guadalajara, Jalisco Info: www.ciisa.gda.itesm.mx e-mail: [email protected]

Ciclo de conferencias, PMI Capítulo México y REPs Cd. de México Info: www.pmichapters-mexico.org/mexico e-mail: [email protected]

Estrategia para una PMO y Equipos Virtuales

CIISA 2007

25 y 26 de Julio 2007

Mexico and the Knowledge Society Strategic IT Training Cycle, Cutter Consortium 25 de Julio - Hotel Camino Real, Monterrey, N.L. 26 de Julio - Hotel JW Marriott, Cd. de México Info: www.cutter.com.mx/ciclo2007 Tel: +52 (81) 2282 6266 y +52 (55) 5336 0418 e-mail: [email protected]

27 y 28 de Agosto 2007

IDC 3a. Cumbre de Gobierno y Tecnología Centro Banamex, Cd. de México Info: www.idc-eventos.com e-mail: [email protected] 30 y 31 de Agosto 2007

26 de Julio 2007

Agile Project Management: Innovation in Action

Ciclo de conferencias, PMI Capítulo México y REPs Cd. de México Info: www.pmichapters-mexico.org/mexico e-mail: [email protected]

Strategic IT Training Cycle, Cutter Consortium 30 de Agosto - Hotel Camino Real, Monterrey, N.L. 31 de Agosto - Hotel JW Marriott, Cd. de México Info: www.cutter.com.mx/ciclo2007 Tel: +52 (81) 2282 6266 y +52 (55) 5336 0418 e-mail: [email protected]

AMITI elige nuevo Consejo Directivo

Gartner Outsourcing Summit

El pasado mes de mayo, los socios de la AMITI eligieron por votación a los integrantes del nuevo Consejo Directivo que ha de conducir los trabajos de esta asociación en el periodo 2007 - 2009. Varios de los consejeros fueron ratificados, lo que asegura continuidad en las iniciativas de la asociación. Por su parte, el actual Presidente Rafael Funes, Director General de DynaWare, ha sido un actor incansable en pro del fortalecimiento de la industria. AMITI continuará trabajando para hacer más competitivos a todos los actores económicos y sociales del país, a través del uso y aprovechamiento de las TIs.

El pasado 27 de junio, Gartner presentó la tercera edición del Outsourcing Summit, tocando como tema principal el aprovechamiento de los activos y servicios de TI, para lograr mejores resultados del negocio. Los analistas de Gartner presentaron temas relacionados con: multisourcing, evaluación y selección de proveedores, servicios tercerizados de TI y Business Process Outsourcing, entre otros. Al término del evento, los asistentes lograron obtener una visión clara de las áreas del “Outsourcing”, con una perspectiva de todas las opciones, riesgos y oportunidades disponibles.

El Director de Proyectos y el Analista de Negocios

Congreso ANADIC 2007

Empresas recientemente evaluadas en CMMI y MoProSoft: Empresa Computación XXI Praxis Medisist ST Novutek Mexware EISEI *Ahora ESI Center

www.sg.com.mx

Evaluación MoProSoft 1 – nov 2006 CMMI 4 – ene 2007 CMMI 2 – feb 2007 CMMI 2 - feb 2007 CMMI 3 – may 2007 CMMI 3 – jun 2007 CMMI 2 – jul 2007

Apoyado por: SIE Center* América XXI SIE Center* SIE Center* Itera Itera Innevo

Con sede en Cancún, Quintana Roo, se llevó a cabo del 27 al 30 de junio el 7º Congreso Nacional de la ANADIC, en el cual participaron mayoristas y distribuidores de TI de toda la República. En el evento liderado por Francisco Wilson, Presidente de la Asociación,  se reunieron  los representantes de las diferentes empresas que forman parte de ANADIC y ANADICSoft, además de diversos gobernadores y diputados. El evento estuvo lleno de distintas actividades como: foros, reuniones de trabajo, presentaciones de productos, talleres, capacitación y certificaciones.

JUL-AGO 2007

05

// COLUMNA // COLUMNA

/*TEJIENDO NUESTRA RED*/

Lo que Pasó en Moscú El Tercer Capítulo de WG4

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.

D

el 21 al 25 de mayo de 2007 Moscú fue la sede de la sesión plenaria del comité ISO/IEC JTC1 SC7 dedicado a la generación de normas para el área de Ingeniería de Software y de Sistemas. Los lectores de SG ya saben que en este comité se creó un grupo de trabajo WG24, para generar una norma de Software Life Cycle Profiles and Guidelines for use in Very Small Enterprises (VSE). También saben que hace un año en Bangkok, este grupo decidió tomar la norma mexicana basada en MoProSoft y EvalProSoft, como punto de partida para los trabajos del grupo. En el número de noviembre-diciembre 2006 de SG, les relatamos lo que pasó en la segunda participación de la Delegación Mexicana en octubre pasado en la ciudad de Luxemburgo, la que terminó en la selección de un subconjunto de procesos de la categoría de Operación de MoProSoft como candidatos a ser la primera guía de implementación de procesos identificado como Perfil 1. En Moscú, Ana Vázquez y yo, formamos la Delegación que representó a México. La sesión plenaria del lunes 21 de mayo empezó con la presentación de alrededor de 140 delegados que vinieron de varios países para participar en 13 grupos de trabajo. Uno de los grupos más importantes es el WG7 (Development of Standards and Technical Reports on Life Cycle Management), que tiene a su cargo la actualización de la norma 12207 (Software Life Cycle Processes), y el otro es el WG10 (Development of Standards and Guidelines Covering Methods, Practices and Application of Process Assessment), que tiene a su cargo la actualización de la norma 15504 (Process Assessment). Las Delegaciones más numerosas, de entre 10 y 20 personas, provenían de países angloparlantes (Estados Unidos, Canadá, Gran Bretaña, Australia) y de los asiáticos (Japón y Corea). Los demás tuvieron representaciones más modestas. Nos sorprendió que de la India llegara una sola persona; y que la Delegación China la formaran solamente dos mujeres jóvenes, al igual que la Delegación Mexicana (restando lo de joven en mi caso). De los países latinoamericanos no hubo ninguna otra representación, pero, afortunadamente, España tuvo tres enviados con quienes formamos una spanish connection que, por su alegría, atraía en espacios de ocio a otros participantes para tomar clases de español gratis.

06

JUL-AGO 2007

Después de las formalidades de la inauguración, nos dirigimos a los lugares de trabajo asignados a cada grupo. El grupo WG24 contaba, en su gran mayoría, con los mismos asistentes que en Luxemburgo: los delegados de Bélgica, Luxemburgo, Finlandia, Canadá (dos personas), Estados Unidos, Tailandia (dos personas) y Australia. También se incorporó un asistente de Japón y algunos otros, como el de la India, que venían ocasionalmente para enterarse de lo que pasaba en nuestro grupo. El resumen de los resultados de trabajo de una semana del WG24 en Moscú es el siguiente: • La futura norma ya tiene su número: 29110 (apréndanselo por favor, porque a mi me va a costar trabajo). • Contará con cinco partes: o La primera describirá el contexto y las características de empresas pequeñas de desarrollo de software a nivel mundial y las razones por las cuales ameritan una atención especial de ISO. o La segunda explicará el concepto de perfil y su taxonomía. o La tercera describirá el perfil, que es el conjunto de requisitos de otros estándares que se tomaron como base para crearlo. o La cuarta se dedicará al modelo de evaluación de perfiles, y o La quinta va a contener la guía para implementar el Perfil 1 basado en nuestro modelo de procesos y en paquetes de implementación aportados por otros miembros del grupo. El trabajo de nuestro grupo estuvo enfocado en obtener resultados, pasamos de una etapa de propuestas a otra de decisiones concretas, lo que permitirá que en octubre, al término de la siguiente reunión, el WG24 entregue el primer Working Draft de los cinco documentos. Se estima que todas estas partes se convertirán en norma en 2010. No se sorprendan, ¡son los tiempos ISO! En México podemos aprovechar que ya tenemos este perfil y unos cuantos más, es decir: el MoProSoft completo, como norma nacional. Por otra parte, nos dimos cuenta de lo importante que sería tener representantes en otros grupos de trabajo del SC7, para estar dónde “se cuecen la habas” y poder transmitirlo rápidamente a nuestra industria. En Moscú, también entendimos y reconocimos la visión y la aportación personal de Arnoldo Díaz de Certum, que con sus re-

www.sg.com.mx

cursos y, a nombre de México, participó a mitad de los años 90 en la definición de la norma 15504. Arnoldo tuvo el valor de demostrar que México no sólo es un país “consumidor” de estándares, sino que también puede ser “aportador” de ideas. Como parte de su participación organizó una reunión del comité en Acapulco, que todavía es recordada con gusto por algunos de los delegados. Desafortunadamente cuando Arnoldo se retiró, la participación de nuestro país perdió continuidad y durante muchos años no tuvo representación en el comité. A diferencia de otros países que tienen políticas y recursos destinados para este tipo de actividades, México todavía no cuenta con esquemas similares. Generarlos es un reto que debemos tomar.

con los delegados de otros países fue un elemento muy importante de promoción para México. Sobre todo, en los primeros días, cuando mis clases de ruso de primaria y secundaria en Polonia dieron por fin sus frutos para facilitarme la lectura y el entendimiento de los letreros en el metro, y los menús en los restaurantes, lo que aumentó la popularidad de nuestra Delegación. También la belleza mexicana de Anita tuvo su impacto entre algunos delegados de tierras frías. —Hanna Oktaba

Para finalizar, les dejo alunas reflexiones de tipo turístico: Moscú, “la ciudad de calles anchas”, como la define Jorge Volpi en su muy recomendable novela “No será la Tierra”, es una ciudad grande, con 3 millones de carros y el tráfico poco envidiable de la Ciudad de México. La Plaza Roja tiene una belleza especial, el metro es el mejor medio de transporte y el vodka es el tequila de allá, nada más que se consume en mayores cantidades y a todas horas. La convivencia

www.sg.com.mx

JUL-AGO 2007

// COLUMNA // COLUMNA

/*MEJORA CONTINUA*/

Personas y Procesos ¿Donde Está el Problema? 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.

Hace algunas semanas me encontraba dando una asesoría cuando una de las personas preguntó lo siguiente: “dado que un proceso es una secuencia de actividades, y dado que toda mi gente ejecuta actividades y todos ellos utilizan alguna herramienta como SAP, PeopleSoft o similar, que los obligan a seguir una secuencia, entonces: ¿no sería la mía, una organización orientada a procesos? ¿Qué es lo que diferencía a una organización orientada a procesos de otra que no lo está?”. Una pregunta interesante. A fin de cuentas, todos ejecutamos secuencias de actividades, lo cual, es la base de todo proceso. ¿Pero exactamente qué hace que una organización se clasifique como orientada a procesos?

Las personas y los problemas Antes que nada, la primera pregunta es: ¿para que moverse a una organización orientada a procesos? Todos hemos escuchado que en las organizaciones de software, la gente es el activo más preciado. Para brindar un servicio de excelencia, se requiere gente experimentada, comprometida, y orientada al servicio. Lo importante es la gente, los procesos no son nada sin ella. Por eso, si vamos a lograr un servicio de calidad, la organización debe estar enfocada a la gente, y no a los procesos. Dicho lo anterior, también debemos estar conscientes de que los procesos aumentan la productividad y eficacia de la gente. Una organización de clase mundial está formada por tres componentes básicos representados en la figura 1:

Figura 1. Los tres componentes de las organizaciones de clase mundial

Los tres vértices: personas, herramientas y procesos, están interrelacionados y forman un todo. Es un hecho que los procesos no existen sin la gente, pero la gente sin procesos no puede lograr un servicio consistente.

La felicidad esta en la moderación El servicio orientado a procesos implica que existe un balance entre: 1. La gente que asegura la calidad y flexibilidad del servicio, en base a su conocimiento y habilidades. 2. La tecnología que apoya a los individuos con información requerida en forma rápida, concisa y oportuna para lograr los objetivos de calidad, productividad y excelencia. 3. El proceso que entreteje todo esto en una serie de actividades y ser-

08

JUL-AGO 2007

vicios coherentes con la finalidad de sumar el trabajo de cada individuo en un todo a gran escala, apoyando a asegurar la consistencia y productividad del servicio.

Detectando la madurez Cuando se tiene algo de experiencia trabajando en áreas de calidad, es relativamente fácil detectar la madurez de una organización con tan solo unos minutos de diálogo con los empleados. Una organización poco madura está principalmente basada en la habilidad adquirida de las personas asignadas. Esto quiere decir que no importa lo que pase, cualquier eventualidad no planeada o no definida es atribuible a la persona que tenía como responsabilidad ejecutar correctamente esa actividad; lo que nos lleva a dos efectos secundarios: • Como parte de la naturaleza humana, cuando se echa la culpa de un problema de la organización a una persona, ésta inmediatamente busca otros culpables que tomen por lo menos parte de la responsabilidad (el cliente, la gente que se me asignó, el área encargada de la infraestructura, etcétera). Esto hace parecer que todo lo que pasa en proyectos depende de tantas variables fuera de nuestro control, que resulta imposible o al menos poco práctico prevenirlas. • Y el otro efecto tiene que ver con que la única forma de prevenir que vuelva a suceder es llamarle la atención a la persona o asignar a alguien más, ya que la otra persona demostró no ser capaz de resolver lo que se le asignó. Normalmente, en una organización de este tipo la conversación que se escucha tiene que ver con establecer culpables, deslindar responsabilidades y criticar el trabajo de otros. En una organización orientada a procesos, el individuo es en parte responsable del problema, pero una gran parte del análisis se enfoca en detectar errores en el diseño o ejecución de un proceso. Si la persona no ejecutó lo que debería ejecutar, se le llama la atención, pero el análisis real viene al revisar cómo falló el proceso de entrenamiento que no le dio las habilidades necesarias, porqué el proceso no detectó la falla antes de que se hiciera un problema. Las posibilidades de mejora son infinitas. Esto crea otro efecto secundario: ya que la culpa no es del individuo, en lugar de enfocarnos en, ¿cómo cambiamos a la persona?, nos juntamos todos a buscar donde falló el proceso. La cultura se vuelve de cooperación. Ya no son todos juzgando mi trabajo, somos todos nosotros tratando de prevenir que vuelva a suceder. Si quieres saber si una organización está orientada a personas o a procesos, simplemente espera que algo salga mal y observa si la conversación se enfoca en culpar a las personas o en reparar los procesos. Se puede predecir fácilmente el nivel de madurez de una organización simplemente midiendo el grado de cooperación que existe entre los individuos, al encontrarse con un problema. —Luis R. Cuellar www.sg.com.mx

www.sg.com.mx

JUL-AGO 2007

// PRODUCTOS

/* LO QUE VIENE*/

Flex, Silverlight y JavaFX

Visual Studio 2008

A pesar de todo el ruido que ha habido en el escenario de tecnologías RIA en los últimos años, realmente no ha habido una competencia interna fuerte. Los principales jugadores habían sido Ajax y Flex, siendo ambos tan diferentes en su estructura y comportamiento, que estaban más cerca de complementarse que de competir. Sin embargo, esto cambió a principios de mayo, cuando Microsoft lanzó Silverlight, un plugin para ejecutar aplicaciones enriquecidas y multimedia, lo cual compite directamente con Flash/Flex. Todavía un par de semanas después Sun Microsystems se agregó a la competencia dando a conocer JavaFX, una tecnología para desarrollar y ejecutar clientes enriquecidos tanto para desktops como dispositivos móviles. Es así que podemos declarar oficialmente iniciada la guerra de los RIA.

La próxima versión de Visual Studio, que anteriormente era conocida por el nombre clave “Orcas” ya se aproxima a su última etapa antes del lanzamiento. Actualmente está disponible como Beta 1, y se espera un Beta 2 este verano, para estar lanzando el producto final antes de que termine el año.

La guerra de las RIA

Uno de los primeros acontecimientos notables al respecto, es que Miguel de Icaza ya se apuró a desarrollar una implementación de Silverlight basada en Mono, que lleva el nombre de Moonlight. Por otro lado, JavaFX se está moviendo un poco más lento, ya que hasta el momento Sun solo ha liberado dos productos específicos: JavaFX Script, que es el lenguaje de scripting para desarrollar aplicaiones, y JavaFX Mobile, el ambiente de ejecución para dispositivos móviles. Sun ha indicado que le restan varios productos por liberar dentro de la familia de JavaFX, pero no ha dado detalles sobre cuales son, y cuando saldrán. También ha anunciado que JavaFX será eventualmente liberado como software libre bajo licencia GPL, sin embargo no ha dado fecha para esto. En SG estaremos al pendiente de lo que suceda en esta arena, y estaremos publicando artículos relacionados con las diferentes tecnologías para que puedan conocerlas más a fondo.

JBoss Seam 2.0

Ambiente de desarrollo para .NET 3.0

Entre las características más esperadas de esta versión está el soporte a la versión 3.0 del .NET Framework, incluyendo C# 3.0 y LINQ (Language Integrated Query), lo cual tendrá un fuerte impacto en la forma en que se desarrollan aplicaciones .NET. Otra característica importante es que Visual Studio Tools for Office –el componente para extender las aplicaciones de Office– ya estará integrado dentro de Visual Studio 2008. Asimismo, Visual Studio Tools for Office –el componente para extender aplicaciones de Office– ya vendrá incluido como parte de Visual Studio. Más información en msdn2.microsoft.com/en-us/vstudio

Spring Batch

Framework para trabajos Batch

Como sabemos, recurrir a procesos batch es una solución muy común en las empresas para procesar grandes cantidades de datos. La falta de una arquitectura estándar para procesos batch no le deja a las organizaciones otra opción más que desarrollar soluciones in-house, haciendo un desarrollo diferente cada vez que se encuentran con esta necesidad. El objetivo de Spring Batch es cambiar esto, ya que es un framework para facilitar la creación y administración de procesos batch.

Uniendo Web 2.0 con Java EE Tan solo tres meses después de liberarse la versión 1.2.1 de Seam, ya tenemos disponible un beta de la versión 2.0. Como ya hemos comentado anteriormente, Seam es un framework Java para desarrollar aplicaciones Web de nueva generación que unifica e integra tecnologías como Ajax, Java Server Faces, EJBs, Java Portlets y capacidades de BPM. Gavin King, desarrollador en jefe de Seam, nos comentó que entre las principales características de esta versión están: • Soporte a Groovy • Soporte a Google Web Toolkit • Integración de búsqueda con Hibernate • Soporte para JSF 1.2 •Soporte para transacciones independientes de JTA Más información en www.jboss.com/products/seam

10

JUL-AGO 2007

Spring Batch fue creado por Interface21 en colaboración con Accenture, quien aportó su experiencia y ejemplos acumulados en décadas de desarrollar procesos batch para sus clientes. La mejor noticia es que Spring Batch es open source, de tal forma que cualquiera puede descargarlo, utilizarlo, y extenderlo o personalizarlo a sus necesidades específicas. Hablar sobre procesos batch no es algo muy sexy, y por lo tanto este producto no ha recibido mucha atención por parte de los medios. Sin embargo, nosotros entendemos la importancia y utilidad de un framework, así que les recomendamos echarle un ojo, puede ser de gran ayuda en su próximo proyecto. Más información en: www.springframework.org/spring-batch www.sg.com.mx

www.sg.com.mx

JUL-AGO 2007

// PRODUCTOS

/* TUTORIAL*/

Apache Lucene y Solr Búsqueda sencilla y poderosa Por Pedro Galván

¿

Alguna vez han considerado que es irónico de que la funcionalidad más importante y útil del web es la búsqueda, no existe una solución común para agregar capacidad de búsqueda a las aplicaciones web? La mayoría de las aplicaciones simplemente utiliza la funcionalidad básica que provee el motor de base de datos que estén utilizando. Aquellas aplicaciones que requieren un sistema de búsqueda más complejo y flexible típicamente deben recurrir a productos comerciales, o desarrollar una solución desde cero. Afortunadamente esto ya no será necesario, ya que el proyecto Apache Lucene nos brinda una solución de búsqueda sofisticada y flexible que provee capacidades que compiten con las de los productos comerciales. Lucene es un motor de búsqueda de alto desempeño escrito en Java. Está diseñado y desarrollado de tal forma que se pueda utilizar en prácticamente cualquier aplicación que requiera búsqueda de texto completo, especialmente aplicaciones multiplataforma. En esencia, Lucene es una librería que puede ser invocada desde aplicaciones Java para realizar búsquedas. Pero si lo que queremos es una funcionalidad de mayor nivel, y donde no necesariamente tengamos que usar Java, podemos recurrir a Solr. Solr es un servidor de búsqueda basado en Lucene, que provee funcionalidad de más alto nivel, como: • APIs para XML/HTTP y JSON • Resaltar resultados • Cache • Replicación Dedicaré el resto de este artículo a explicar como instalar y utilizar una solución de búsqueda utilizando Solr.

1. Instalación de Solr Para ejecutar Solr requerimos tener instalado un JDK 1.5 o posterior. Teniendo instalado nuestro JDK, simplemente descargamos la versión más reciente

12

JUL-AGO 2007

de Solr de http://mirror.x10.com/mirror/ apache/lucene/solr/ y extraemos el contenido en nuestra computadora. Solr se puede ejecutar en cualquier contenedor de Servlets como Tomcat o Jetty. Por simplicidad, para este ejemplo utilizaremos una versión de Jetty que viene incluida en el directorio de ejemplos de Solr. Para arrancar Solr simplemente entramos al directorio examples y ejecutamos el comando: java -jar start.jar Esto inicia una instancia de Jetty en el puerto 8983 de nuestra máquina, así que si todo salió bien, debemos poder entrar a http://localhost:8983/solr/admin/ y ver el panel de administración de Solr.

2. Definiendo la estructura de la información Ya tenemos andando nuestro servidor Solr. Sin embargo, no tenemos datos, por lo que cualquier búsqueda que hagamos regresa 0 resultados. Para agregar datos a Solr primero debemos definir la estructura de la información que indexaremos y almacenaremos para búsqueda. Al igual que la mayoría de las aplicaciones en Java, la configuración de Solr se guarda en archivos XML. El esquema XML que contiene la definición de la estructura de datos para indexar y almacenar está en el archivo solr/conf/schema.xml. En schema.xml se definen los campos que tendrán nuestros elementos de información. Para cada campo se puede especificar si se debe indexar (para que se pueda utilizar en búsquedas) y si se puede almacenar (para que se pueda obtener la información localmente). Si la información a buscar está almacenada en una base de datos, puedes indicar a Lucene que indexe los campos, pero que no los almacene. A fin de cuentas, mientras almacene la llave primaria de cada elemento, el documento se puede reconstruir directamente desde la base de datos. Esto reduce fuertemente los requerimientos de almacenamiento de Lucene, y evita duplicar datos.

La sección es donde se listan los diferentes elementos tipo , es decir, los campos de información. Cada tiene un nombre que se utiliza como referencia al agregar documentos o realizar búsquedas, y un que identifica el tipo de datos. Los tipos de datos son declarados utilizando elementos . Los tipos de datos estándar en la configuración de ejemplo (text, boolean, sint, slong, sfloat, sdouble) son suficientes para la mayoría de las aplicaciones. El siguiente listado muestra el contenido de los campos definidos para un ejemplo de un catálogo de productos:

Las búsquedas enviadas a Lucene utilizan un solo campo, el cual se especifica utilizando el elemento <defaultSearchField>. Dado que el objetivo en la mayoría de los casos es buscar en base a los valores de múltiples campos, lo que se hace es crear un campo adicional que sirva de sombrilla para contener el valor de todos los campos que queremos que sean incluidos en la búsqueda. El valor de los campos originales se copia utilizando el elemento . Un esquema de configuración de Solr puede contener un número ilimitado de declaraciones . Lo que hacen es indicarle a Solr que copie los datos de un campo especificado por el atributo “source” a otro campo especificado por el atributo “dest”. El siguiente listado muestra un ejemplo de cómo definiríamos un campo múltiple para el catálogo de productos. Definimos un campo llamado “texto” que es el que utilizaremos para buscar, y que contendrá los valores de nombre, fabricante y características.

www.sg.com.mx



3. Agregando documentos a indexar La forma de alimentar datos a Lucene es a través de documentos XML que contienen instrucciones de indexado para agregar, borrar o actualizar documentos. El siguiente listado muestra un ejemplo del XML a través del cual agregaríamos un nuevo elemento de información. Vean que los campos de información consisten con los que definimos en schema.xml. <doc> 3007WFP Dell Widescreen UltraSharp 3007WFP Dell, Inc. 30” TFT active matrix LCD, 2560 x 1600, .25mm dot pitch, 700:1 contrast 401.6 5199

El directorio exampledocs contiene ejemplos de instrucciones que Solr puede recibir, así como una utilería en Java (post.jar) para alimentar instrucciones a Lucene desde la línea de comandos.

4. Realizando búsquedas Las búsquedas se realizan a través de peticiones por HTTP GET en el url /solr/select del servidor donde estés ejecutando Solr. El query de búsqueda se pasa a través del parámetro “q”. Es posible agregar parámetros adicionales para controlar la información que se obtiene. Un url con un query sencillo se vería de la siguiente forma: http://localhost:8983/solr/select?q=monitor Solr regresa los resultados en forma de XML, así que es posible manipularlos como queramos. Incluso podemos utilizar Solr directamente utilizando un objeto XMLHttpRequest y manipular los resultados con Javascript.

Conclusión En este artículo apenas echamos un pequeño vistazo a Lucene y Solr. Estas tecnologías son muy flexibles y nos proveen una amplia gama de posibilidades. De hecho, a quienes les interese hacer un ejercicio más sofisticado les recomendamos buscar en Internet los tutoriales que enseñan como utilizar Solr en conjunto con el API de Digg para poder realizar búsquedas de los contenidos de Digg usando Solr. Ahora que conocen estas tecnologías, esperamos que las tengan en cuenta la próxima vez que requieran incorporar funcionalidad de búsqueda en sus aplicaciones.

Referencias: • lucene.apache.org • lucene.apache.org/solr

www.sg.com.mx

JUL-AGO 2007

Scott Ambler La Evolución de Ágil

Scott W. Ambler dirige la práctica de Desarrollo Ágil en IBM. Es considerado como uno de los principales “agilistas” en el mundo, y ha creado varias metodologías entre las que destacan Agile Modeling (AM), Agile Data (AD), Agile Unified Process (AUP), y Enterprise Unified Process (EUP). Scott será uno de los conferencistas magistrales en SG ’07, así que aprovechamos la oportunidad para publicar esta pequeña entrevista donde nos comparte su perspectiva sobre Ágil y otros temas que tratará durante SG ’07.

¿Cómo describirías el estátus actual de Ágil? Hace unos años, Ágil era visto como un movimiento, una revolución. Sin embargo, creo que actualmente Ágil ya es parte de la “corriente principal” (mainstream) de los métodos de software. Justamente en marzo de este año realicé una encuesta sobre el grado de adopción de ágil, y de las 781 personas que contestaron, el 69% contestó que su organización aplica técnicas derivadas de Ágil. Esto no quiere decir que todo mundo ya esté usando algo como XP como su proceso default, pero si nos indica que la mayoría ya está usando (o considerando usar) una o más técnicas de Ágil. ¿Cuáles consideras que son los principales retos de Ágil en los próximos años? Creo que el principal reto para Ágil al corto plazo es demostrar que es escalable a proyectos grandes. Precisamente el trabajo que hago con IBM consiste en ayudar a clientes a aplicar técnicas ágiles en proyectos grandes y complejos donde se tienen muchas restricciones de regulación, y el equipo de desarrollo es grande, distribuido geográficamente, y formado por distintos proveedores. Estas organizaciones están interesadas en adoptar Ágil, precisamente porque están interesadas en maximizar su eficiencia. En www.ibm.com/rational/agile tenemos varios documentos y videos al respecto. ¿Crees que Ágil evoluciona? ¿Cómo? Sin duda, las metodologías ágiles están evolucionando. Por ejemplo, en los últimos años yo he hecho varios ajustes a Agile Modeling; Kent Beck liberó la segunda versión de su libro “Extreme Programming Explained”, donde presenta cambios significativos a la versión original de XP; Enterprise Scrum justo acaba de salir, y básicamente es una extensión de Scrum que toma ideas del Rational Unified Process (RUP). También está el Open Unified Process (OpenUP), que es un método ágil open source que está disponible en www.eclipse.org/epf. Así que en el espacio de las metodologías, claramente hay una evolución y actualización. Por otro lado, es interesante ver que el Manifiesto Ágil parece resistir la prueba del tiempo. Los valores y principios en que se basa no han sufrido cambios, y parecen no necesitarlos. Sin embargo, también está el trabajo del Agile Project Leadership Network (APLN), www.apln.org, el cual en cierta forma puede ser considerado una extensión al Manifiesto Ágil. Al parecer, la gestión de datos (Data Management) también está siendo impactada por Ágil, ¿podrías explicarnos algo sobre esto? Introducir agilidad al mundo de la gestión de datos es una tarea ciertamente complicada. Desafortunadamente, la gestión de datos se mantenido relativamente estática en cuanto a métodos y procesos, y muchos de los profesionistas de esa comunidad se siguen aferrando a concepciones erróneas sobre como funciona el desarrollo de software en realidad. Por ejemplo, muchos DBAs creen que es difícil evolucionar o refactorizar un esquema de base de datos existente. Esto es algo que Pramod Sadalage y yo demostramos que se puede hacer fácilmente a través de las técnicas documentadas en nuestro libro “Refactoring Databases”. Sin embargo,

14

JUL-AGO 2007

los DBAs que no comprenden esto se enfocan en hacer demasiado modelado muy temprano en el ciclo de vida, lo cual en el libro “Agile Database Techniques” demuestro que es una forma de trabajo altamente ineficiente. El Data Warehouse Institute estima que tan solo en Estados Unidos, los problemas de calidad de datos generan un costo de $600 mil millones de dólares anualmente. A pesar de esto, la comunidad de profesionistas de datos ofrece muy pocas recomendaciones prácticas sobre lo que se puede hacer para resolver esto. En resumen, creo que hay problemas serios en la gestión de datos, sin embargo la mayoría de los profesionistas se aferran a los métodos que generaron estos problemas en primer lugar. Afortunadamente, la comunidad Ágil está involucrándose y desarrollando alternativas para resolver estos problemas. Yo he escrito varios artículos al respecto que están disponibles en www.agiledata.org y que pueden ser de gran ayuda para los profesionistas de datos. ¿Es cierto que un desarrollador de un equipo que utiliza Ágil necesita mayor habilidad y experiencia que en el desarrollo tradicional, o simplemente es cuestión de una mentalidad diferente? El aspecto fundamental es la mentalidad. Los desarrolladores ágiles buscan colaborar estrechamente con otros, aprender de cada uno, y desarrollar nuevas habilidades. También tienen un fuerte enfoque a la calidad, típicamente utilizando una estrategia “test-first” (probar primero). El hecho es que ser un desarrollador ágil requiere mayor disciplina que uno tradicional, así que tal vez no sea para todos. Últimamente has escrito sobre “lean development governance”, ¿de qué se trata esto? La gobernabilidad tradicional se enfoca en estrategias de comando y control, que buscan administrar y dirigir a los equipos de proyecto de forma explícita. Aunque ésta es una estrategia válida en algunas situaciones, en la mayoría de los casos es semejante a arrear gatos –se aplica un gran esfuerzo pero se obtienen pocos resultados. En cambio, “lean governance” se enfoca en estrategias de colaboración que buscan habilitar y motivar a los miembros del equipo implícitamente. Por ejemplo, la forma tradicional de hacer que un equipo siga lineamientos de programación es definirlos y luego realizar inspecciones formales para asegurar que se estén siguiendo. En cambio, lo que se haría en un enfoque “lean”, sería escribir los lineamientos en colaboración con los programadores, explicando la importancia de que todos los sigan, y luego proporcionando herramientas que faciliten la adopción y seguimiento de los lineamientos. El enfoque “lean” es semejante a guiar gatos, si tomas un pedazo de pescado, ellos te seguirán a donde vayas. ¿Consideras que el desarrollo dirigido por modelos (MDD) alguna vez será el común denominador de cómo desarrollar software? Eso depende de qué entiendas por MDD. La versión Ágil de MDD ha sido el común denominador desde hace años, ya que es muy común que los desarrolladores ágiles usen herramientas sencillas como pizarrones y rotafolios para modelar. Lo que no es tan común es el enfoque que promuewww.sg.com.mx

// ENTREVISTA ven los profesionistas de modelado, donde todo se debe hacer en una herramienta CASE. En teoría, esta estrategia es muy buena. Sin embargo, en la práctica muy pocas organizaciones tienen suficiente gente con las habilidades necesarias para lograr esto. Las organizaciones que llegan a tener buenos modeladores, con buenas herramientas, logran muy buenos resultados. Sin embargo, este es un porcentaje pequeño de todas las organizaciones de software, y dudo que eso cambie en el futuro cercano. ¿Qué opinas sobre la programación orientada a aspectos (AOP)? Creo que AOP es una solución muy interesante que todavía está buscando un problema que resolver, y no veo que eso vaya a cambiar.

www.sg.com.mx

¿Qué está sucediendo en cuanto al Eclipse Process Framework (EPF)? Este es un proyecto muy interesante. El EPF composer permite que las personas puedan definir, personalizar y publicar procesos de software, e incluirlos en la herramienta de desarrollo Eclipse. Hay mucho material disponible, incluyendo el OpenUP y la definición de Extreme Programming para EPF. Últimamente no he estado muy involucrado en este proyecto, pero espero poder hacerlo pronto, para agregar más material sobre modelado de datos ágil. ¿Algunas palabras para nuestros lectores? Estoy muy entusiasmado de visitar México. Nos vemos en SG ’07.

JUL-AGO 2007

15

Creando una Personalidad “Web Tú” Sé parte de ella

A

finales de 2006, la revista Time anunciaba a la persona del año y terminaba con la incertidumbre. Para sorpresa de muchos, esta vez no se trataba de un pacifista o líder político o moral. La publicación nos decía: “la persona del año eres tú”, o de manera plural: “ustedes”. Para algunos, esto parecía una broma, sobre todo porque la portada incluía una imitación de espejo, invitando al lector a verse en ella. Pero no, no era una broma. Y entonces, ¿que habíamos hecho para recibir este honor? 2006 marcó el año en que los usuarios de Internet pasaron de ser pasivos a activos. Es decir, no sólo fueron receptores de información, sino que también fueron autores de contenido. Y no es que los usuarios no quisieran participar anteriormente, sino que la Web no lo permitía, porque originalmente no estaba pensada de esa forma. Pero desde su inicio, la Web ha ido evolucionando cada vez más del modo lectura, al modo lectura-escritura desde la perspectiva del usuario común y corriente. Dicho movimiento no bastó por si solo para ser una novedad, sino que fue la masiva participación de los cibernautas. El concepto conformado por lo sistemas y prácticas alrededor de estos ingredientes una Web en modo de lectura-escritura y gente usándola es lo que lo que hoy llamamos Web 2.0. Web 2.0 es considerado un concepto, y no una tecnología. Su construcción está basada en infraestructura y len-

16

JUL-AGO 2007

Por Oscar Cortés Santos

guajes existentes. Lo que es nuevo son las herramientas o aplicaciones construidas con dichos lenguajes. Estas herramientas tienen algo en mente, algo que ha empezado a tener resonancia en el mundo Web 2.0: “Inteligencia Colectiva”. Es decir, brindan un mecanismo para que los usuarios no sólo puedan comunicarse con el creador del sitio, sino entre todos ellos. Y muchas veces, sólo entre ellos. Juntos crean y mejoran conceptos y procesos. Es un principio de Web 2.0: “nadie de nosotros puede saber todo, pero cada uno de nosotros sabe algo”. Así, si juntamos nuestras habilidades y conocimientos individuales, podemos hacer algo nuevo y mejor. Un sitio Web 2.0 puede ser reconocido porque permite la interacción con su audiencia, y deja huella de dicha interacción en forma de nuevo contenido. Un sitio que no permite tal colaboración no está usando el concepto Web 2.0. La comunicación debe circular en ambos sentidos y quedar asentada para que la vean, juzguen y actualicen otros usuarios. Pero reformulemos la pregunta original: ¿a quiénes se está reconociendo como usuarios de Web 2.0? Bueno, aunque cualquiera puede beneficiarse del conocimiento disponible, no todos los usuarios han participado de la misma manera. Por ejemplo: un blog puede ser visitado y habitualmente leído por muchas personas, pero no todas participan con sus comentarios. Este tipo de usuarios contribuyen al tráfico, y muchas veces distribuyendo las historias que leen enviándolas por correo electrónico. Pero su participación es más bien de espectadores. www.sg.com.mx

www.sg.com.mx

JUL-AGO 2007

17

Por otro lado, existen usuarios con una personalidad muy definida: aquellos que son prolíficos creando nuevo contenido. Estoy hablando de los que tienen sus propios blogs, contribuyen en Wikis, suben podcasts, videos o fotografías a la red; tienen su propia página en MySpace o Facebook; su perfil profesional en LinkedIn; y participan activamente en foros, redes y grupos de interés. Esta personalidad es lo que yo llamo una personalidad “Web Tú”. Sí lo sé, aquí he jugado un poco con la etiqueta, abusando de su coincidencia con la pronunciación en inglés de Web 2.0 (web two). Pero creo que al final, este tipo de usuario deja un rastro digital y crea una personalidad Web 2.0. Crear este tipo de personalidad puede ayudarnos a aprender más y volvernos más productivos, ya que nos motiva a estar en contacto constante con los temas que nos interesan, y aprender de lo que otros están creando. Además podemos tomar ventaja del escenario para darnos a conocer globalmente. El principio básico es una cultura de participación, de compartir nuestro conocimiento o experiencia. Las maneras de convertirse en un usuario Web 2.0 son variadas. Aquí las más comunes: Compartiendo opinión. Qué mejor manera de hacerlo que creando un blog. Hay varios servicios que te permiten crear uno propio, tales como Blogger o WordPress. Lo más fácil de un blog es activarlo, sin embargo muchos blogs han decaído en ser sólo repetidores de noticias. Aunque un blog puede usarse para temas casuales, también es una oportunidad para desarrollarse como una autoridad. Mi recomendación es siempre ofrecer un análisis u opinión acerca de lo que se esté hablando. Hay que recordar que se trata de participar en la comunidad agregando valor al contenido y de promover una conversación. Del mismo modo se debe estar abierto para recibir y aceptar comentarios tanto positivos, como negativos. Y sobre todo, no lo abandonen si están interesados en la reputación de dicho blog. Compartiendo creatividad. Con cada vez más dispositivos portátiles que permiten tomar imágenes digitales y video en cualquier rincón, es más probable que podamos captar

esos momentos únicos que expresan parte de nuestra creatividad, y compartirlos a través de sitios como YouTube o Brightcove para video, y Flickr o Photobucket para imágenes. En este campo, ya empezamos a ver herramientas que nos permiten mezclar videos, música e imágenes directamente en los sitios. Dándonos la oportunidad de crear no sólo nuevo contenido en forma de texto, sino también como multimedia. A su vez, es ya muy común el uso de tags para clasificar el contenido que se suba a estos sitios. Permitiendo así que el contenido pertenezca a diferentes categorías al mismo tiempo, agilizando futuras búsquedas. Conectándose con otros. Tal vez el concepto de redes sociales es el más visible en el mundo Web 2.0. El punto de partida es tener intereses similares a los de otros y unirse a comunidades con el mismo interés. Sitios como MySpace, Facebook o LinkedIn recolectan datos para relacionar individuos o comunidades enteras. Esta gente se conecta basada en sus intereses o pasatiempos, ubicación, profesión o afiliación escolar. Compartiendo experiencia. Al mismo tiempo que se puede aprender del contenido creado por otros usuarios, se puede compartir el conocimiento que nosotros tenemos de alguna tecnología o cualquier otro tema. Los medios más conocidos son las Wikis, la más popular: Wikipedia. Regularmente los proyectos de software libre utilizan Wikis para facilitar la colaboración, ya que en la mayoría de los casos los diferentes desarrolladores están distribuidos en todo el mundo. Una Wiki permite a un grupo de personas actualizar la misma página Web manteniendo una historia de actualizaciones. Otro recurso son los foros especializados, que brindan una gran oportunidad para demostrar conocimiento respondiendo a preguntas y dando ejemplos. Mantenerse informado de nuevo contenido. La mayoría de los sitios modernos difunden su contenido hacia otros sitios o lectores usando RSS (Really Simple Syndication). Para recolectar todo este nuevo contenido sin tener que visitar sitio por sitio, se puede usar un agregador de noticias que consuma dichos feeds de RSS.

Web 2.0 en el mundo empresarial El concepto de Web 2.0 se puede aprovechar por las empresas en al menos dos maneras que ayudan a generar ventaja competitiva: > Para entender las comunidades donde sus productos y servicios son introducidos. > Para mejorar la administración de conocimiento e incrementar productividad. El principio de Inteligencia Colectiva se vuelve entonces relevante para las empresas. Al ofrecer una comunicación con los clientes para saber qué piensan de sus productos, una compañía puede seguir mejorando sus productos. Tomemos por ejemplo: Amazon, que vende infinidad de productos de terceros. Amazon permite hacer críticas de los productos y éstas quedan disponibles para futuros compradores. Las empresas pueden subscribirse a las mencionadas críticas usando RSS y así enterarse de cómo está siendo recibido su producto. Herramientas Web 2.0 tales como Blogs y Wikis en combinación con redes sociales, se pueden usar internamente para identificar expertos dentro de la empresa. Normalmente serán los más activos participantes dentro del ecosistema. Además pueden servir para tener una comunicación más clara y promover una cultura de participación. Existen otros componentes Web 2.0 utilizados por las empresas: mashups, que tienen que ver con colaboración con socios de negocios externos y con interoperabilidad entre aplicaciones. Los mashups explotan los datos que se proveen a través de RSS, WebServices y APIs ofrecidas por entidades externas, y los mezclan en una sola interfaz, que regularmente es sofisticada. Por ejemplo: se puede leer la lista de casas en venta de alguna fuente y presentar su localización usando Google Maps. Los mashups típicamente son presentados usando interfaces visuales ricas, denominadas RIAs (Rich Internet Applications). Las RIAs permiten crear aplicaciones con elementos visuales sofisticados e interactivos que brindan al usuario una mejor experiencia de lo que se puede conseguir con HTML por sí solo. Actualmente la tecnología que más se utiliza para hacer RIAs es Ajax, seguido de Adobe Flex.

Oscar Cortés Santos. Maestría en Ciencias en TI, McCallum Graduate School of Business en Bentley College, Boston, USA. Oscar cuenta con más de diez años de experiencia desarrollando aplicaciones para el mundo empresarial, tanto en Cliente/Servidor como Web, y es un entusiasta de tecnologías Web 2.0 y su convergencia con los negocios. Trabaja como Software Engineer para Brightcove  en Boston, desarrollando aplicaciones RIA con Flex.

18

JUL-AGO 2007

www.sg.com.mx

Conclusión

Nuestra presencia en Web 2.0 puede ser tan extensa o compacta como se quiera, y ser usada de manera personal o a nivel empresarial. Las oportunidades en el ecosistema Web 2.0 son inmensas, no sólo de entretenimiento o aprendizaje, sino también de negocios. El contenido existente en Web 2.0 se puede utilizar de incontables maneras, sólo limitadas a la imaginación. Sin embargo, hay que entender a las comunidades existentes en Web 2.0 para poder tomar ventaja de ello. La mejor manera creo yo, es perteneciendo, es desarrollando una personalidad Web Tú. <<

www.sg.com.mx

JUL-AGO 2007

19

Mashups Qué Son y Qué No Son Por Aldo Hernández

M

ashup es una palabra que ¿Qué no es un mashup? proviene de un término mu- Antes de continuar, debemos aclarar dos sical en inglés, que significa concepciones erróneas que tienden a existir la creación de una nueva relacionadas con los mashups. La primera es canción a partir de la mezcla o pedazos que un mashup no es un portal. Sin embarde otras canciones. Desde este concepto se go, un portal puede complementarse por un basa el mashup de software. La Wikipe- mashup y viceversa. dia lo define como “una aplicación o sitio web que combina contenido de una o más La segunda aclaración es que un mashup fuentes dentro de una nueva experiencia tampoco es una aplicación compuesta (comde usuario o manejo de información”. posite application). El término composite

de las empresas crece exponencialmente. Se necesita usar esa información para manipularla de manera rápida y sencilla. > La información se encuentra distribuida en diferentes fuentes de información. > Integración dinámica temporal a fuentes de información. > Integración realizada por el usuario y no necesariamente por el área de sistemas. > Acceso rápido a la información significa mayor competitividad y productividad.

Los mashups son un producto de la Web 2.0 donde el usuario es el centro de todo. Va de la mano con conceptos como colaboración y distribución de la información.

Clasificación de mashups

Las características que podemos encontrar actualmente en el Web 2.0 son: > Hecho por el usuario para él mismo. > Capacidad dinámica de integración de información con otras fuentes. > Integración concurrente limitada. > Utilización de servicios Web públicos. > Orientado al consumidor.

Sin embargo, conforme el Web 2.0 comienza a ser adoptado en las empresas, empezamos a ver su evolución, que llevará a las siguientes características en el futuro: > Hecho por el usuario para él y compartirlo con más usuarios. > Capacidad dinámica de compartir e integrar de la misma manera con otras fuentes. > Utilización tanto de servicios Web públicos, así como servicios internos. > Orientado hacia la empresa, sus clientes y aliados de negocio.

application se utiliza para referirse a aplicaciones que en lugar de ser desarrolladas desde cero, son “ensambladas” a partir de servicios disponibles en una arquitectura SOA. Este concepto puede parecer muy similar al de un mashup, sin embargo hay una diferencia crucial: las composite applications parten de un enfoque centrado en TI, mientras que los mashups parten de un enfoque centrado en el usuario. Bajo el modelo de las composite applications, el usuario final sigue dependiendo del departamento de TI para crear una aplicación (aunque ésta solamente se vaya a ensamblar, no a crear). En cambio, con los mashups el objetivo es que sean los usuarios quienes puedan crear (o ensamblar) sus aplicaciones.

¿Por qué mashups? Las grandes tendencias de desarrollo de software son la reutilización e integración. La mayor parte de los presupuestos de TI para los próximos años estarán asignados al mantenimiento y explotación de los sistemas existentes. La funcionalidad de los mashups se justifica en base a los siguientes puntos: > La información disponible en Web y al interior

Un mashup puede dividirse en dos tipos: > Orientado hacia el navegador (browser). Está más enfocado en la mezcla o composición de información con imágenes del lado del navegador, principalmente usando JavaScript como lenguaje de programación para lograrlo. Un ejemplo clásico de este tipo de mashups es aquél en que se usa el servicio de Google Maps, con otro servicio, por ejemplo: de precios de casas que muestre en una sola pantalla el precio y la ubicación donde se encuentra una casa en venta. > Orientado hacia el servidor (mashup empresarial). En éste, la integración y manipulación de la información suceden en ambos lados: servidor y navegador. Su uso principal es interactuar con información de diferentes sistemas para generar vistas necesarias para la toma de decisiones. Este tipo de mashup es capaz de interactuar con data centers para generar valor .

Funcionalidades del mashup empresarial Estas son algunas de las acciones más comunes que se pueden realizar con un mashup empresarial:

Aldo Hernández Murguía es parte del equipo de JackBe en México. Aldo es Ingeniero en Cibernética y Sistemas Computacionales por la Universidad La Salle, México. Cuenta con más de nueve años de experiencia en TI, y está certificado como Java Developer y Architect. JackBe ofrece soluciones para aplicaciones de negocios basadas en SOA y servicios Web que resultan en aplicaciones interactivas basadas en browser que buscan optimizar las actividades diarias de las organizaciones.

20

JUL-AGO 2007

www.sg.com.mx

> Filtrar información: en ocasiones un servicio regresa información necesaria para construir una vista y por lo mismo es requerido aplicar un filtro para trabajar con la información necesaria. > Conjuntar y unir diversos tipos de servicios de información: con esto nos referimos a la virtualización de los servicios para abstraer la complejidad de consultar o ejecutar operaciones en diversas fuentes de información, como pueden ser base de datos, WSDLs, RSS, etcétera. > Analizar información resultante de servicios: tener la capacidad para aplicar funciones estadísticas como matemáticas, a los resultados de los servicios invocados. (Vgr. Tomar la información de un servicio que nos da precios de acciones y al resultado de la ejecución de ese servicio poder aplicar una función matemática que nos da el precio máximo de esa acción durante un tiempo determinado). > Transformar información: soportar tanto estructuras diferentes de información así como formatos diversos. > Soporte gráfico de información: presentar al usuario final la información a través de tablas, calendarios, gráficos, etcétera. > Orquestación de servicios: un mashup puede crearse a partir de la ejecución secuencial o en paralelo de varios servicios para la generación de la vista final. Un ejemplo: generar un mashup de la situación financiera de una persona. Por lo mismo necesitamos conectarnos al banco con un servicio “Y” que nos da la información básica de ésta, como sus cuentas y de qué tipo son. Con dicha información, se hace una consulta para conocer cuál es su calificación en el buró de crédito y de ahí generar una vista final.

Arquitectura de un mashup empresarial Ya definidas las cualidades y funcionalidades de un mashup empresarial, veamos la arquitectura de sus componentes, para así, entender cómo se integran la funcionalidad y los servicios antes mencionados. La figura 1 muestra el ejemplo de una arquitectura para mashups. En este caso, utilizamos como referencia la plataforma Presto de JackBe. ( Ver Figura 1 ) En este diagrama se puede ver que el mashup empresarial debe ser capaz de conectarse a cualquier fuente de información (base de datos, servicios Web, objetos Java o .Net) a través del concepto “virtualización de servicios”. De esta forma, las diferentes fuentes de información hacen la base de una estructura fuerte para poder integrar, orquestar, mezclar, transformar y visualizar nuevos servicios.

Caso de uso de un mashup Usemos ahora un ejemplo específico para www.sg.com.mx

Integración dirigida por los usuarios

PRESTO DASH (AMBIENTE DE EJECUCIÓN)

Acceso a servicios, colaboración & mashups

Enterprise Ajax Framework

RDBMS

Envío de datos dirigido por eventos

RSS REST

POJO

Comunicación Definición de fuentes de datos

GEO

Enterprise Ajax Framework

PRESTO STUDIO (AMBIENTE DE DESARROLLO)

WSDL

RIAs construidas por desarrolladores

PRESTO EDGE (SERVIDOR DE MASHUPS)

.NET WSRP

Figura 1. Arquitectura para mashups Presto

entender cómo es que podríamos resolver un problema de negocio a través de un mashup. Imaginemos que cierto banco requiere que a través de su website de eBanking personal se pueda realizar la venta cruzada de diferentes productos. Un caso particular es el de un producto financiero hipotecario, donde para poder otorgarlo se requiere como entrada el historial crediticio y hábitos de consumo del cliente prospecto. Estos servicios provienen de diferentes fuentes y son de varios tipos: el historial crediticio es de tipo WebService y los hábitos de consumo nos llegan como RSS. Para resolverlo necesitamos virtualizar estos tipos de servicios, es decir, generar una manera estándar de invocarlos sin importar de qué tipo sean. Esta virtualización puede ser representada a través de un XML como el siguiente: <Servicios> <Servicio nombre=”BuroDeCredito” tipo=”WebService”> <parámetro tipo=”string” nombre=”numeroDeTarjetaCredito” /> <Servicio nombre=”HabitosConsumo” tipo=”RSS”> <parámetro tipo=”string” nombre=”numeroDeTarjetaCredito” />

Así se esconde la complejidad que involucra tener varias fuentes de información; y se tiene una manera estándar de ejecutar y trabajar con sus respuestas. Una vez virtualizados los servicios, se requiere generar un lenguaje que pueda definirse a través de un mark up language capaz de des-

cribir la manera en que lo servicios pueden interactuar, filtrarse, orquestarse, integrarse; es decir, las operaciones básicas de un mashup empresarial. Al tenerlo definido, a partir de este lenguaje se podrá reutilizar o compartir entre varias aplicaciones dando como resultado un servicio de tipo mashup. Este nuevo servicio nos arrojará la respuesta de si el usuario puede obtener el crédito hipotecario y así ofrecerlo al cliente en tiempo real. Bajo este modelo, a través de herramientas visuales para crear los mashups, ésta tarea de definición puede ya estar en manos del área de marketing, logrando así: • Menor dependencia del área de sistemas para generar este tipo de promociones. • Mejores tiempos de reacción al mercado. • Reducción de costos de creación y mantenimiento de campañas. • Estandarización para crear nuevos servicios.

Conclusión

Los mashups son parte funda-

mental de la denominada Web 2.0, cuyo mayor beneficio será obtenido por las organizaciones a través del uso de lo que hemos explicado aquí como mashups empresariales. Este nuevo tipo de aplicaciones están provocando un cambio que traerá a su vez una nueva generación de aplicaciones empresariales centradas en los usuarios. <<

Referencias • blogs.jackbe.com

JUL-AGO 2007

21

Prácticas Arquitectónicas en Aplicaciones Web 2.0 Consideraciones que no puedes olvidar Por Alexis Castañares

L

a forma de publicación y con- Y entonces, ¿qué consideraciones debo tener sumo de información en la en cuenta al desarrollar aplicaciones de este web de hoy en día ha sufrido tipo? Precisamente ese es el objetivo de este un cambio fundamental. El artículo, explicar desde el punto de vista aradvenimiento de un paradigma mu- quitectónico las principales consideraciones cho más proactivo en el uso de la web que debemos tener para el desarrollo de las por parte de los usuarios –que publi- aplicaciones de esta nueva generación. Cocan su propio contenido en forma de mencemos entonces. blogs, wikis, videos, fotografías– ha provocado que anualmente se esté ge- Enfoque en la Experiencia de Usuario nerando un volumen de información Los ejemplos más exitosos que podemos en(estimado en 1.5 exabytes tan sólo contrar en el desarrollo de sitios y aplicaciones para este año) que es mayor al que se de la web 2.0 han sido aquellos que implemenha producido en los últimos 5000 años taron una experiencia integrada y altamente de la historia humana. funcional de uso. La alta cohesión en la interEste nuevo paradigma ha dado pie a una interacción mucho más profunda entre los usuarios de la Internet, que han dejado atrás el rol exclusivo de observadores y han comenzado a colaborar, discutir, formar comunidades e incluso amasar sitios ya existentes, en nuevas aplicaciones o experiencias personalizadas usando mashups. El contar con un medio como la Internet para intercambiar información correlacionada y catalogada a escala humana supera la capacidad de cualquier individuo e incluso cualquier organización para generar conocimiento, y se convierte en un proceso de inteligencia colectiva o “sabiduría de las masas”, como lo denomina Michael Platt en su artículo “Web 2.0 in the Enterprise”. Organizaciones de todos tamaños y en todas las industrias han comenzado a investigar el poder de éstas tendencias para la generación de nuevas oportunidades de crecimiento, satisfacción en sus clientes, economías de escala basadas en la web, mercadotecnia viral, comunidades en línea y sistemas de distribución.

faz de usuario y el uso de tecnologías como Ajax, que permiten proveer interactividad en el browser similar a la ofrecida por las aplicaciones de escritorio, han sido factores clave para fomentar la adopción masiva de aplicaciones como YouTube o MySpace, pues permiten reducir la curva de aprendizaje del usuario y por lo tanto incrementar la productividad y lealtad del mismo hacia la aplicación.

Actualmente, los desarrolladores tienen al alcance diversas tecnologías para crear aplicaciones enriquecidas (RIAs). Silverlight, por ejemplo, es un plugin multiplataforma para el desarrollo de RIAs que utiliza lenguajes avanzados como JavaScript, C# ó VB e incorpora las funcionalidades de acceso a datos y comunicación del framework de .NET con un sistema de entrega de video, habilitando el desarrollo de aplicaciones dinámicas multimedia. Los diferentes frameworks para el desarrollo de aplicaciones AJAX como Google Web Toolkit, ASP.NET Ajax, Prototype, DWR o Dojo son otro ejemplo de las opciones que

ofrecen las tecnologías más recientes para la creación de este tipo de aplicaciones. En el pasado, muchas organizaciones han dejado a un lado la experiencia de usuario en el desarrollo de sus activos en la web en aras de buscar la ubicuidad de las aplicaciones, entendiendo ésta como la posibilidad de contar con ellas en múltiples dispositivos y en la mayor audiencia posible. Hoy en día los proveedores tecnológicos y las comunidades de desarrolladores están dando prioridad a estas funcionalidades, pues la web 2.0 nos ha demostrado que, con la nueva realidad de accesos de banda ancha y usuarios altamente demandantes, es precisamente la experiencia de usuario el componente principal para que éstas aplicaciones tengan la capacidad de generar los altos volúmenes de lealtad, crecimiento y oportunidades de negocio que las organizaciones están buscando.

Modelo de Programación 2.0 Una de las premisas del concepto web 2.0 acuñado por Tim O’Reilly en 2005 es la necesidad de contar con modelos ligeros de programación que permitan que las aplicaciones sean interconectadas para la creación de funcionalidad personalizada. Las aplicaciones web 2.0 son inherentemente ensamblables y para ello es necesario que su arquitectura considere la utilización de estándares tanto en el manejo de datos como en la comunicación, así como un esquema que separe la funcionalidad en módulos que puedan ser reutilizables. Las aplicaciones que sigan estos modelos en su desarrollo estarán mejor preparadas para exponer puntos de conexión que puedan ser usados para la creación de mashups.

Alexis Castañares es Asesor Especialista en Arquitectura de Infraestructura en Microsoft México, donde está a cargo de la estrategia web.  Alexis cuenta con 15 años de experiencia en Tecnologías de Información, y ha dirigido un gran número de proyectos Internet de gran escala para diversas organizaciones como el Grupo MVS Comunicaciones y la Organización Mundial de Comercio. Es egresado de Ingeniería en Cibernética por la Universidad La Salle.

22

JUL-AGO 2007

www.sg.com.mx

Como ya se menciona en otros artículos de esta edición, mashup es el término utilizado para denominar la creación de nuevas aplicaciones en la capa de usuario reutilizando aplicaciones web ya existentes. Recientemente han surgido iniciativas de proveedores tecnológicos para crear editores de este tipo de aplicaciones como Yahoo! Pipes ó Microsoft Popfly. A pesar de que las herramientas y tecnologías de exposición de información disponibles a la fecha tienen aún un largo camino por recorrer para ofrecer escenarios ideales de composición de aplicaciones, los mashups prometen eventualmente ser capaces de reducir los largos tiempos de desarrollo de aplicaciones y los costosos procesos organizacionales para su adopción, habilitando a los usuarios finales para crear sus propias aplicaciones con base en sus muy particulares necesidades. La programación del Web 2.0 se basa en el principio arquitectónico de Transferencia Representativa de Estado ó REST por sus siglas en inglés (Representational State Transfer). La programación “RESTful”, como es comúnmente denominada, se refiere a la separación de tareas en recursos y a la utilización de los mismos por medio de mensajes transmitidos sin almacenamiento de estado utilizando protocolos de comunicación estándares y generalmente transparentes a los firewalls, como HTTP. Finalmente, la aplicación debe concebirse desde sus inicios bajo el paradigma de “lecturaescritura” para promover la interactividad con sus usuarios, así como de “colaboración” para fomentar esta interactividad entre los propios usuarios, aprovechando así la inteligencia colectiva y el potencial de generación de comunidad que describíamos al inicio.

Estrategia para la Distribución de Aplicativos El modelo aplicativo de la web 2.0 ha potencializado los logros del modelo de Software como

Servicio (SaaS). La distribución de software como servicio puede habilitar a las organizaciones a generar economías de escala en sus aplicaciones, particularmente si se utiliza el patrón arquitectónico de Múltiples Inquilinos (Multi-Tenancy) en una instancia del aplicativo. El beneficio que puede obtener la organización al utilizar este modelo proviene del mejor aprovechamiento que puede hacer de sus recursos de infraestructura y del esfuerzo de desarrollo si en el proceso de ingeniería de software se consideran estrategias que permitan crear aplicaciones que atiendan múltiples clientes en instancias de ejecución compartidas. Empresas como salesforce.com han sido exitosas en la utilización de este paradigma amasando grandes volúmenes de usuarios en sus aplicaciones y habilitando el “Long-Tail”, nombre coloquial acuñado en 2004 por Chris Anderson en un artículo de la revista Wired, quien argumenta que los productos con bajos volúmenes de venta pueden en conjunto igualar o superar las ventas de los productos estrella de una organización si se logra tener un canal de distribución lo suficientemente grande. La figura 1 ilustra en rojo el potencial de ganancias que una organización podría tener por la venta de un producto a un mercado naturalmente reducido por el alto costo. En contraposición el color naranja representa las ganancias incrementales que podría obtener la organización vendiendo el mismo producto a un precio menor pero a un mercado potencial mucho mayor. Las ganancias netas por la venta del producto serían mayores si la “Cola” de la gráfica logra ser lo suficientemente larga. En el pasado la generación de economías de escala alrededor de este concepto estaba limitada por la capacidad de distribución y atención que la organización

podía brindar en un mercado tradicional. La Internet ha venido a habilitar este tipo de escenarios puesto que una aplicación con una arquitectura adecuada puede distribuirse vía la web a un mercado potencial de millones de usuarios, superando evidentemente casi cualquier modelo de ingresos por venta de productos de alto costo a mercados reducidos. Recientemente, el concepto de SaaS está evolucionando e incorporando estrategias de distribución como la de S+S (Software + Servicios) en donde se combina la entrega de servicios por medio de la nube, con la riqueza en experiencia de usuario que pueden proveer las aplicaciones de escritorio conectadas a estos servicios. De igual forma, las empresas de desarrollo han comenzado a explorar el uso de Plataformas de Distribución de Software o SDPs (Software Delivery Platforms) para encapsular en un sistema subyacente servicios comúnmente requeridos por los aplicativos –como subsistemas de facturación, análisis estadístico, almacenamiento de datos– permitiendo así a las organizaciones focalizarse en la estructuración de las funcionalidades más específicas del dominio de la aplicación a desarrollar. Los trabajos realizados por Gianpaolo Carraro sobre estos temas pueden ser de gran utilidad para nuestro lector en el entendimiento y utilización de estas estrategias.

Figura 1. The Long Tail

Conclusión

Haciendo un análisis somero de la arquitectura de ac-

tivos altamente exitosos en la web 2.0, visualizamos la presencia recurrente de modelos, estrategias, patrones y paradigmas arquitectónicos orientados a sacar provecho de los nuevos horizontes que la “sabiduría de las masas” ha creado. La utilización de los modelos planteados por el advenimiento de la web 2.0 encierra un alto potencial de negocio así como de soporte a poderosos medios de acercamiento con los clientes internos o externos de las organizaciones por medio de sus activos en Internet.

www.sg.com.mx

Las consideraciones arquitectónicas aquí presentadas pueden servir como premisas iniciales en la planeación y diseño de una solución web 2.0. Con la vista puesta en el futuro inmediato, la organización deberá incluir en su estrategia muchas otras, como la multiplicidad de dispositivos de entrega ó los ciclos continuos de mejora en los aplicativos. En incrementos exponenciales estos modelos van evolucionando y siendo reemplazados por nuevas ideas que habilitan el potencial y desencadenan el crecimiento de la máquina más compleja creada por el hombre: El World Wide Web. <<

JUL-AGO 2007

23

Frameworks Habilitadores de AJAX ¿Cuál Elegir?

D

esde el año 2005 cuando Jesse James Garrett acuñó el acrónimo AJAX (Asynchronous Javascript and XML), las tecnologías relacionadas se han esparcido de una manera francamente vertiginosa.

Ajax es una técnica de programación donde se explotan tecnologías ya existentes como Javascript y XML, para mejorar considerablemente la interacción entre un usuario y una página Web. Esto se logra mediante la transmisión y recepción de información (postback) desde el cliente al servidor en segundo plano, evitando los molestos pantallazos que implica el envío de datos, la admisión de los mismos y la regeneración de la página Web por parte del browser. El uso adecuado de este modelo trae como consecuencia un aumento considerable de la usabilidad, velocidad y tiempo de respuesta de un sitio Web.

Por Miguel Ángel Morán acceso Web de Outlook (OWA) . Este objeto se encarga de establecer un canal de comunicación independiente del browser para enviar y recibir datos, y así evitar que el usuario se percate de lo que está sucediendo tras bambalinas. Ya que la información está siendo procesada en background. Dado que este objeto es programable en Javascript, es posible escribir scripts que interactúen con el DOM de la página y de esta manera lograr páginas muy interactivas. Debido a su popularidad y su uso masivo, el World Wide Web Consortium (W3C) ha definido ya una especificación estándar para dicho objeto, y por lo tanto, ya lo implementan distintos navegadores como Firefox, Safari y Opera.

Implementación básica

Antecedentes

Uno de los principales atractivos de Ajax, es que al usar tecnologías que ya se encuentran implementadas en los browsers actuales, no es necesario instalar nada para comenzar a usarlo.

Aunque parezca increíble, la capacidad real de utilizar estas técnicas ha estado entre nosotros desde 1999, cuando Microsoft lanzó la versión 5 de Internet Explorer, y con él un objeto llamado XMLHttpRequest ideado originalmente para optimizar la interfaz de usuario del

En el siguiente ejemplo definimos una implementación básica en la cual buscamos que al momento de seleccionar un destino en el Panel 1, se actualice la información en el Panel 2, sin redibujar de nuevo la página.

24

JUL-AGO 2007

www.sg.com.mx

Para lograr nuestro cometido, debemos de escribir un script como el siguiente:

acuerdo al modelo de programación, por ejemplo: ASP.NET o Java Servlets / JSP’s.

<script language=”javascript”> var objxmlHttp=null; // Devuelve una instancia correcta del objeto XMLHTTPRequest de acuerdo al browser usado. function ObtenerObjetoxmlHttp() { try // Instancia para navegadores no Microsoft {objxmlHttp=new XMLHttpRequest();} catch (e) // Instancias para navegadores Microsoft { try { objxmlHttp=new ActiveXObject(“Msxml2.XMLHTTP”);} catch (e) { objxmlHttp=new ActiveXObject(“Microsoft.XMLHTTP”);} } return objxmlHttp; }

A continuación presento algunos de los frameworks más usados actualmente en la red.

// Envía la forma y los datos seleccionados en el control <select> function EnviarForma() { objxmlHttp=ObtenerObjetoxmlHttp(); objxmlHttp.open(“POST”,”Servidor.aspx”, true, “”, “”); objxmlHttp.setRequestHeader(“Content-type”, “application/x-www-form-urlencoded; charset=windows-1255”); objxmlHttp.onreadystatechange=MostrarRespuesta; objxmlHttp.send(“selLugares=”+document.getElementById(“selLugares”).selectedIndex); } // Procesa la respuesta del servidor y la muestra en el

del Panel 2 function MostrarRespuesta() { if (objxmlHttp.readyState==4) document.getElementById(“divDescripcion”).innerHTML=objxmlHttp.responseText; }

Listado 1. Implementación de Ajax sin framework

Implementar un código como el anterior no representa mayores problemas cuando se trata de un ejemplo sencillo como el descrito. Sin embargo, conforme la interfaz de usuario tenga mayor complejidad, el código para implementarla se incrementará exponencialmente, haciéndolo difícil de crear y mantener. Ante este panorama, muchos fabricantes y grupos han tratado de facilitar la vida a los desarrolladores mediante la creación de marcos de trabajo que hacen más rápido y sencillo el uso de Ajax. Entre las principales ventajas de utilizar frameworks están: > Simplificación y reducción de la cantidad de código requerida. > Estandarización del modelo de codificación. > Integración con el modelo de programación de la tecnología del lado de servidor. > Aumento de la productividad en el desarrollo. Podemos dividir los frameworks de Ajax en las siguientes dos categorías: > Frameworks de cliente: básicamente scripts de Javascript preescritos y listos para usarse con sólo insertarlos directamente en nuestra página Web. > Frameworks de servidor: son librerías implementadas del lado del servidor, que ayudan a una integración browser/server. Estos frameworks suelen generar dinámicamente el Javascript requerido para Ajax de

www.sg.com.mx

Frameworks de cliente Prototype: es un framework muy sencillo de entender, y bastante popular. Para usarlo sólo es necesario incluir el archivo prototype.js y con esto estamos listos para poder utilizar los objetos que incluye la librería. El listado dos muestra el código que necesitaríamos para lograr el mismo objetivo que en el listado uno, pero usando Prototype. <script language=”javascript” src=”prototype.js”> <script language=”javascript”> function EnviarForma(){ new Ajax.Request(‘Servidor.aspx’, { method: ‘post’, parameters: {selLugares:document.getElementById(“selLugares”).selectedIndex} , onSuccess: function(strRespuesta){ document.getElementById(“divDescripcion”).innerHTML=strRespuesta.responseText; } }); }

Listado 2. Implementación con Prototype

Es evidente que el código anterior es mucho más limpio y sencillo que la implementación original. Sólo hacemos uso del método Request del objeto Ajax incluido en Prototype, y le pasamos como parámetros los detalles de nuestra petición. Podemos ver que Prototype ha manejado automáticamente la detección del browser, la suscripción del objeto y la interpretación de la respuesta. Cabe señalar que Prototype no sólo incluye funcionalidad para Ajax, sino que también incluye funciones para manejo y optimización de arreglos, cadenas, objetos etc. Incluye métodos taquigráficos para hacer el código más legible, extiende el DOM, soporta JSON, y muchas otras características. Prototype tiene un compañero ideal llamado script.aculo.us que es otro script que extiende aun más la interactividad de las páginas mediante funciones de drag and drop, animaciones etc. y toma como base Prototype The Dojo Toolkit: se basa en los mismos principios que Prototype, incluir un script del lado del cliente (en este caso dojo.js) para aumentar la funcionalidad de Javascript. Sin embargo, Dojo va más allá e introduce todo un conjunto de características como gráficos de vectores, un sistema de eventos muy completo, la capacidad de crear widgets (componentes basados en HTML + Javascript) y por supuesto, soporta Ajax. La desventaja de Dojo es que se ha vuelto sumamente complejo debido a su gran cantidad de funciones y su escasa documentación. No obstante, empresas como Sun e IBM están apoyando este proyecto, por lo que en un futuro cercano podríamos ver un mejor soporte.

JUL-AGO 2007

25

Frameworks de servidor Microsoft ASP.NET AJAX: la implementación que sugiere Microsft, obviamente gira en torno a su tecnología ASP.NET. Y nos ofrece una solución completamente integrada al .NET Framework 2.0, expuesta a través de controles de lado del servidor del ASP.NET. Quizá su principal beneficio es que todo se puede hacer visualmente sin necesidad de escribir una sola línea de código en Javascript; de tal forma que si ya usas ASP.NET, sólo debes instalar las extensiones de Ajax, arrastrar a tu página los controles adecuados y obtienes “Ajax instantáneo”; el .NET Framework se encarga de hacer “el trabajo sucio” por ti. La idea es muy simple: diseñas y programas tu página ASP. NET como de costumbre, y para agregar funcionalidad de Ajax realizas los siguientes pasos: > Arrastras desde el toolbox de Visual Studio un control del tipo ScriptManager. > Arrastras otro objeto llamado UpdatePanel y colocas dentro de él todo lo que quieres que sea mostrado asíncronamente, como por ejemplo: etiquetas, tablas de datos, cajas de texto, imágenes, y en general todo lo necesario. > Defines los eventos que dispararán la comunicación en background y… ¡listo! El listado tres muestra el código generado para lograr la funcionalidad que queremos con ASP.NET 2.0.

Listado 3. Implementación con ASP.NET Ajax

Como podrán apreciar en este código, se declara el control ScriptManager (manEjemplo), y posteriormente el UpdatePanel que adentro tiene una etiqueta que será actualizada en forma asíncrona con Ajax. Al momento de visualizar la página, ASP.NET creará dinámicamente todo el Javascript requerido. Con ASP.NET, además de obtener la funcionalidad de Ajax a través de Codeplex, también podemos obtener un conjunto de controles llamados Ajax Control Toolkit, que automatizan e imprimen mucha interactividad a nuestros sitios Web, como validadores, controles slide, controles acordeón, calendarios, búsquedas, tabs etcétera. DWR: es el acrónimo de Direct Web Remoting, y es una librería Ajax para Java EE, que se instala en el servidor de aplicaciones (mediante un archivo .war) y su principal ventaja es que permite a los browsers utilizar métodos de Java ubicados en el servidor como si estuvieran realmente en el browser. Esto se logra mediante un servlet que procesa las peticiones de los browsers y envía las respuestas a los mismos; y código de Javascript generado dinámicamente encargado de procesar las respuestas del servidor. De esta manera, el uso de DWR se convierte en una gran alternativa para minimizar los costos y el tiempo de implementación de Ajax para los programadores en Java. Google Web Toolkit (GWT): es un framework que proporciona el soporte a Ajax mediante la utilización de Java. Con GWT, el desarrollador escribe su página en Java (integrando las clases del GWT), y el compilador de la herramienta se encarga de generar el HTML y el Javascript correspondiente. El modelo de programación es muy parecido a Swing, y actualmente ya existen varios IDEs que proveen integración con GWT para facilitar el desarrollo. Entre los que están IntelliJ IDEA, Eclipse (a través del plugin Cypal Studio), y NetBeans (a través del plugin gwt4nb).

Conclusión

Los frameworks de Ajax facilitan y aceleran el desarrollo de

las aplicaciones antes mencionadas. La elección del framework específico depende de tus necesidades y restricciones: Para quienes desean implementar Ajax a través de scripting en el cliente, Prototype y Dojo son muy buenas opciones, que además de la funcionalidad básica de Ajax, proveen capacidades para extender las estructuras base de Javascript y del DOM, con la ventaja agregada de su independencia de la plataforma en el servidor. Para los que desarrollamos en ASP.NET, sin lugar a dudas la opción natural es Microsoft ASP.NET AJAX debido a su completa integración con el modelo de controles de servidor de ASP.NET; la ayuda del IDE donde ni siquiera es necesario implementar una sola línea de código de Javascript, y el montón de controles incluidos en el Control Toolkit que harán a nuestros sitios verse espectaculares. Los programadores de Java tienen las opciones de DWR y Google Web Toolkit, entre las más conocidas.

Con esto, he presentado tecnologías representativas (por cierto, todas gratuitas), que a pesar de ser muy distintas entre sí, todas ellas facilitan y aceleran el desarrollo de aplicaciones con Ajax. Como podrán apreciar, gracias a estas herramientas puede ser muy sencillo implementar Ajax en nuestros sitios Web. Los invito cordialmente a programar sitios fantásticos sumergiéndose de lleno en Ajax. El código fuente completo de los listados de este artículo se encuentra disponible en www.developersdotnet.com <<

Referencias • www.prototypejs.org • dojotoolkit.org • script.aculo.us • ajax.asp.net • getahead.org/dwr • code.google.com/webtoolkit

Miguel Ángel Morán Bolaños es Microsoft Most Valuable Professional (MVP) en C# y Microsoft Certified Trainer (MCT). Es Licenciado en Informática por la UNITEC y cuenta con 10 años de experiencia desarrollando profesionalmente. Actualmente colabora en Intersoftware como Consultor en TI. Mantiene, junto a un grupo de colegas, la comunidad DevelopersDotNet donde frecuentemente escribe y organiza eventos sobre tecnología. [email protected]

26

JUL-AGO 2007

www.sg.com.mx

FLEX

El sabor de Adobe para RIA Por Edgar Parada

ablar de una tecnología como Flex con una perspectiva H de Web 2.0 forzosamente nos lleva a entender parte de la evolución de la industria del software, darnos cuenta del porqué del sufijo 2.0, y conocer un término que está íntimamente ligado con Flex, nos referimos a la expresión de RIA (Rich Internet Application).

www.sg.com.mx

JUL-AGO 2007

27

Figura 1. Algunos de los términos más representativos del Web 2.0

Evolución de las Aplicaciones Como sabemos, las tecnologías y arquitecturas de las aplicaciones de software están en continua evolución para satisfacer mejor las necesidades de tanto los usuarios como los departamentos de TI. Es así que pasamos por los “mainframes”, y luego por la arquitectura cliente/servidor, cuyas características permitían una mayor productividad, a costa de complicaciones en la distribución y despliegue. Posteriormente, un nuevo modelo vio la luz, y fue tiempo de darse cuenta del potencial del web como un ambiente para ejecución de aplicaciones. En este modelo, los navegadores actúan como clientes ligeros donde se interpreta HTML, y a través de este se hacen peticiones y se reciben respuestas de un servidor. Comúnmente esta interacción también se conoce como arquitectura basada en páginas. Con este modelo se resolvieron los problemas de distribución y despliegue, ya que las aplicaciones residen en el servidor. Sin embargo, esto se logra a costa de la experiencia del usuario. Esto se debe a las limitantes de HTML, así como del protocolo HTTP. Es entonces que llegaron las denominadas RIA (Rich Internet Applications). Este término fue acuñado en el 2002 por la empresa Macromedia, y en ese entonces significaba muchas cosas pero todo se veía sintetizado en la frase “Experience that matters”. Las RIAs proponían una experiencia para el usuario muy diferente a la interacción de cambio de página de las aplicaciones web tradicionales, aquellas que en ese momento se fueron haciendo obsoletas y formaron parte de lo que se conoce como Web 1.0 Una RIA combina lo mejor de dos mundos: > Aprovecha las ventajas del web como plataforma para entregar aplicaciones. > Brinda al usuario una experiencia por lo menos comparable a la de las aplicaciones de escritorio actuales.

28

JUL-AGO 2007

En una RIA se eliminan los viajes innecesarios al servidor, lo cual impacta positivamente el desempeño de las aplicaciones, ya que la mayor parte del procesamiento se ejecuta en el cliente. Este es un cliente enriquecido (rich client) cuya funcionalidad va mucho más allá del comportamiento default de un navegador web. Algunas tecnologías utilizadas para clientes enriquecidos son los prácticamente extintos Java Applets, o el novedoso Silverlight de Microsoft por citar algunos, pero sin duda alguna el de mayor adopción a nivel mundial es el Flash Player de Adobe.

Nociones de Web 2.0 Fue en el año 2004 cuando Tim O’Reilly utiliza el término Web 2.0, aunque nunca ha sido definido un esquema formal para decir qué sitio es 2.0 y qué sitio no lo es. Si algo se ve lo suficientemente “cool” se agrega el mote de 2.0. De los principios más socorridos al momento de hablar de Web 2.0 tenemos: > Usar la Web como plataforma. > Datos como una fuerza de negocios > Tomar los efectos de la red para crear una arquitectura de participación > Innovación en los sistemas y sitios web > Modelo de negocios ligero > Facilidad de adopción

Flex 2: RIA para Web 2.0 Habiendo dicho todo esto, podemos enfocarnos en una tecnología que está creando bastante eco en la comunidad de desarrolladores de aplicaciones web: Adobe Flex. A grandes rasgos, Flex es un framework para desarrollar aplicaciones web que son ejecutadas en la plataforma Adobe Flash. Actualmente, Flex se encuentra en su versión 2, y todo lo que mencionamos en este artículo se refiere a esta versión. En su comportamiento, las aplicaciones hechas con Flex son similares a las aplicaciones Ajax: permiten actualizaciones dinámicas

hacia la interfaz de usuario UI, y también tienen la habilidad de enviar y recibir datos del servidor de forma asíncrona. Una ventaja adicional es que las aplicaciones hechas en Flex pueden ser consideradas multiplataforma debido a la ubicuidad de su cliente (Flash Player). Muchos argumentarán que Ajax también es multiplataforma, lo cual en teoría es cierto. Sin embargo, en la práctica nos encontramos con que los diferentes navegadores tienen distintos niveles y mecanismos de implementación de Javascript y CSS, mientras que Flash Player es una sola máquina virtual estándar para todos los navegadores y sistemas operativos. Además, sería incorrecto comparar directamente ambas tecnologías, ya que en esencia Flex es un framework y una plataforma de desarrollo, mientras que Ajax es una serie de técnicas de desarrollo que explotan el objeto XmlHttpRequest.

Elementos de Flex La plataforma de Flex está formada por los siguientes elementos: > ActionScript 3.0 – Un lenguaje de programación orientado a objetos basado en la última especificación ECMAScript. > Flash Player 9 – La siguiente generación de esta popular pieza de software que incluye una Máquina Virtual (AVM2) que permite ejecutar el código significantemente más rápido. > MXML – Un lenguaje basado en XML que permite manipular los componentes de la aplicación de una forma eficiente. > Compilador y Depurador – Un compilador en línea de comandos así como un modelo de depuración en tiempo de ejecución. > Flex Framework – Una librería de componentes de interfaz de usuario GUI, tales como botones, data grids, acordeon, paneles, controles de árbol, etc. Fáciles de personalizar basándose en CSS o mediante Skins. > LiveCycle Data Services ES Express – Una plantilla de aplicación Web entregada en un servidor J2EE para comunicarse con el cliente Flash Player mediante una serie de www.sg.com.mx

servicios de comunicación, manejo de datos y mensajería y con amplias posibilidades de integración con los sistemas actuales. Estos elementos están incluidos en un SDK gratuito que se puede descargar del sitio de Adobe. Adicionalmente, están las herramientas de desarrollo, las cuales tienen un costo. > Flex Builder 2 – Un IDE construido sobre Eclipse, que permite un ambiente de trabajo visual para construir las interfaces enfocándose siempre en el usuario y a la vez una vista de código muy familiar a los programadores. > Charting Components – Una serie de componentes enfocados a la parte de reportes y gráficas, muy socorridos para crear Dashboards, aplicaciones colaborativas y reportes. > LiveCycle Data Services ES Departamental y Enterprise – Versiones de LiveCycle Data Services ES para 100 usuarios concurrentes o sin límite de usuarios en concurrencia respectivamente.

Figura 2. Estructura de la plataforma Flex

La figura 2 muestra los principales elementos de la plataforma Flex, y la figura 3 muestra el flujo de trabajo bajo el que funcionan estas aplicaciones.

Consideraciones sobre Flex 2 Muchas tecnologías se ven ir y venir hoy en día, pero son pocas las que se vuelven parte del cajón de herramientas de los programadores. Al crear Flex 2, Adobe tomo en cuenta diversas consideraciones para maximizar su adopción y facilitar la curva de aprendizaje. De hecho, Flex está pensado de forma que sea muy sencillo para los desarrolladores de Java dar el salto hacia esta plataforma. Algunas de las características que contribuyen a esto son: ActionScript 3.0 es muy similar a Java > Flex Builder está construido sobre Eclipse, uno de los IDEs más populares > La gran mayoría de las tecnologías Java (EJB, POJO, Hibernate, JMS, etc.) se integran fácilmente con Flex. También existen diversas opciones de integración para aprovechar las características de Flex desde la plataforma .NET, algunos ejemplos son WebOrb y Fluorine. Otras características atractivas de Flex 2 pueden ser: > Esta basado sobre un mecanismo de seguridad sólido

Figura 3. Flujo de trabajo para aplicaciones Flex

> Es capaz de “senderear” datos en tiempo real a la interfaz. > Soporta altas tasas de actualización de imagen (refresh rate) en entidades de datos grandes. > A través de la máquina virtual de Flash Player 9, soporta compilación just-in-time (JIT).

Una visión al futuro de Flex Por ahora, solo falta que los desarrolladores se den cuenta del gran potencial que tiene esta tecnología, que ha tenido una evolución muy rápida. Pensando en un futuro próximo, pronto veremos un complemento a Flex lla-

mado Adobe Integrated Runtime (AIR) –anteriormente conocido como el nombre clave “Apollo”–, que es un ambiente de ejecución que permitirá portar al escritorio aplicaciones RIA de forma transparente e independiente del sistema operativo. Así mismo, la próxima versión de Flex se encuentra a la vuelta de la esquina con la importante noticia de que se hará una apuesta hacia el mundo del código abierto, lo que permitirá a terceros integrar esta tecnología dentro de sus productos y crear sus propias soluciones basadas en ella. <<

Edgar Parada es un Adobe Certified Instructor, consultor de Adobe, colaborador de diversos centros de capacitación e instructor activo en la DGSCA/UNAM. Actualmente dirige Activ (www.activ.com.mx), un Adobe Authorized Training Center especializado en tecnologías como Flex, Flash Lite y Flash Media Server. Es parte del equipo del primer grupo de usuarios en español enfocado en Flex: MadeInFlex ( www.madeinflex.com) y también es manager de Riactive ( www.riactive.com.mx), el grupo de usuarios oficial en México para Flex. [email protected]

www.sg.com.mx

JUL-AGO 2007

29

// COLUMNA

/*CÁTEDRA Y MÁS*/

Web 2.0 La Redefinición de la “Caja de Zapatos” Dr. Raul A. Trejo es Profesor Investigador del Departamento de Sistemas de Información del Tec de Monterrey, campus Estado de México. Sus áreas de interés incluyen Ingeniería de Software, Negocios Electrónicos e Inteligencia Artificial. El Dr. Trejo participa en proyectos que involucren de manera activa a sus estudiantes. Es miembro del Sistema Nacional de Investigadores (SNI) y ha presentado sus trabajos de investigación en diversos foros nacionales e internacionales. El Dr. Trejo es miembro fundador de la Asociación de Sistemas de Información de América Latina y del Caribe.

C

uando alguien decide expresar su opinión sobre un tema, buscando atraer, al menos momentáneamente la atención del auditorio, se dice que: “se sube en su caja de zapatos”; y desde ahí expone su discurso Cuando surgió la WWW, la información que se podía encontrar era de carácter estático, publicada por unas cuantas entidades, y muy especializada. Se podía encontrar información de cursos en los sitios de universidades, noticias en cnn.com y los últimos avances sobre navegadores de red en mosaic.com. Y si uno deseaba subirse a su caja de zapatos, podía hacerlo desde los umbrales de usenet: ese primer intento de grupo de discusión global, al que los geeks llegaban tarde o temprano. En estos inicios de la WWW, lo que podríamos llamar Web 1.0, se tenía una estructura centralizada de información, con relativamente pocas entidades publicando, y una gran mayoría leyéndo. Luego vino el auge de las punto com, con un descubrimiento fundamental: todo el mundo podía tener presencia en Internet, con diseños más atractivos pero estáticos, que se convirtieron en un escaparate de publicidad para las empresas. Sin embargo, estos sitios al estar generalmente disociados de modelos de negocios sólidos, sucumbían del mismo modo meteórico en que habían surgido. Pero quedó un sobreviviente: la página personal. Ahora cualquier persona podía tener un espacio en Internet para subirse a su caja de zapatos, contar sobre su vida, actividades, mascotas o cualquier cosa que le interesara. Estas páginas solían ser el secreto mejor guardado de la red, con direcciones obtusas que sólo los amigos cercanos visitaban, a menos que uno tropezara con una de ellas por accidente. Mi primera página aún está disponible en http://www.cs.utep. edu/robotics/temporal/ (noten que no hay referencia a mi nombre, ni al contenido de la página). Ahora bien, ¿qué hay de la autopista de la información en estas páginas personales? Bueno, yo opino que era una autopista muy rudimentaria, donde las referencias a temas de interés consistían en hiperligas a otras páginas. De nuevo, el contenido era en su mayoría es-

30

JUL-AGO 2007

tático, y el trabajo de mantenimiento consistía en eliminar y actualizar las ligas muertas. La penetración de tecnologías como DHTML y javascript dio lugar a páginas de diseño más dinámico, en las que el visitante podía interactuar y decidir qué información deseaba ver. Hasta aquí podemos rastrear la evolución de Web 1.0: páginas de contenido más dinámico y visual, pero con información centralizada que debe ser consumida en el lugar y el formato que su creador ha decidido. Y la caja de zapatos todavía sigue siendo un lugar escondido. Como referencia, el lector puede consultar mi página académica, en http://webdia.cem.itesm.mx/ ac/rtrejo. Ésta lleva demasiado tiempo sin actualizar, pero podrán notar que indica mi nombre, y en algunas ocasiones recibe algunos visitantes perdidos que se interesan en un curso que no enseño hace años. Llegamos así a Web 2.0. Más que un estándar, en realidad es un concepto, un cambio de paradigma. El más importante es la descentralización de la información. En vez de enlazar a ligas que contienen grandes bloques de información, se puede optar por acceder a servicios que nos proporcionan un fragmento de información específica que puede ser actualizada de manera dinámica por su dueño y transparente para la entidad que consume la información. Aún mejor, ya no existe un formato predeterminado para la información, la cual puede incluirse dentro de nuestra página personal en el formato más apropiado y consumirse por otros dispositivos, como los teléfonos celulares. La primera característica de Web 2.0 es la descentralización. Los creadores de información pueden recopilarla, clasificarla y hacerla disponible en segmentos significativos. ¿Qué pasa con la caja de zapatos? Pues que ahora nuestra capacidad de expresarnos es mucho más rica, y se puede incluir en nuestras páginas personales información creada por terceros de manera directa. Como resultado, se hará común que el viajero de Internet acceda a información desde un sitio distinto a donde ésta fue creada. Lo que nos lleva a la segunda característica: el

poder para el usuario; el poder de generar información, publicarla, agregarla o reagruparla. No en balde los blogs de los reporteros de CNN fueron en un momento más populares que el sitio oficial de la cadena noticiosa. Existe una tercera característica: el concepto de comunidad. Las páginas personales ya no son más islas solitarias. Los usuarios se congregan: publican sus videos en YouTube, resuelven los problemas de otros en foros, o dan a conocer sus datos más personales en hi5. Herramientas tales como las etiquetas inteligentes (smart tags) y los nuevos algoritmos de búsqueda harán que el contenido agregado en las distintas páginas personales sea más fácil de encontrar. En todo caso, es muy seguro que alguien más de la misma comunidad encuentre la nuestra. Consideren mi página actual (rulopotamo. spaces.live.com). Tiene mi nombre, y pertenece a una comunidad. En ella encontrarán información sobre temas de mi interés, y podrán notar el video y el pronóstico del tiempo, extraídos de fuentes externas. Subirse a la caja de zapatos en Internet nunca fue más sencillo. La adopción del concepto Web 2.0 tiene varias consecuencias que proveedores y usuarios deberán considerar. El concepto de propiedad de información se está redefiniendo; el problema del copyright, uno de los puntos sensibles de Internet, se agudizará más con las tecnologías emergentes (Paramount Pictures aún libra una batalla que parece perdida con YouTube). Es claro que los modelos de negocio deben replantearse. Existe también el problema de calidad de información, y el cómo discernir cuál es confiable o verídica ante la gran cantidad disponible, y cómo el sitio donde se encuentre no será necesariamente el mismo que la genere. Queda un último detalle. Ya recibo más visitas en mi página. Pero no estoy seguro si los viajeros de Internet lo hacen por su interesante contenido, o sólo como medio para tener acceso a las páginas de mis amigas. Y dicho esto, me bajo de mi caja de zapatos. —Raul A. Trejo www.sg.com.mx

www.sg.com.mx

JUL-AGO 2007

// PRÁCTICAS

/* MANTENIMIENTO DE SOFTWARE*/

Mantenimiento de Software Todos lo hacemos, pero nadie se acuerda Por José M. Esquivel

La industria de desarrollo de software mantiene una evolución constante. Antes podíamos ver que los ingenieros en sistemas computacionales, electrónica, o incluso otra especialidad contaban con todos los conocimientos necesarios para desarrollar y entregar un software. Sin embargo, la creciente complejidad del software y las tecnologías y procesos necesarios para su desarrollo y mantenimiento ha provocado que los profesionistas tengan que especializarse. Dentro de estas especializaciones encontramos algunas como la programación, el levantamiento y análisis de requerimientos, el diseño de aplicaciones, el diseño de base de datos, las pruebas de software, y recientemente una actividad que es por mucho, una de las mas importantes y menos valoradas de la industria: el mantenimiento de software. Según la terminología ANSI-IEEE, el mantenimiento del software es: “la modificación de un producto software después de su entrega al cliente o usuario para corregir defectos, para mejorar el rendimiento u otras propiedades deseables, o para adaptarlo a un cambio de entorno”. En este artículo exploraremos los aspectos fundamentales de esta actividad. Frente a la considerable velocidad con que se ha desarrollado la ingeniería de hardware, el desarrollo del software ha sufrido un retraso histórico en cuanto a la elaboración y disposición de tecnologías (metodologías y herramientas). Esto evidentemente merma la calidad de los sistemas liberados y corriendo en ambientes de producción. La complejidad del proceso de producción de software se intenta abordar mediante la descomposición en diversas etapas. Esta descomposición recibe el nombre de “Ciclo de Vida del Software”. Los diversos modelos de ciclo de vida típicamente plantean distintas fases derivadas del modelo de cascada, tales como: • Análisis y Definición de Requerimientos • Diseño • Programación • Prueba • Despliegue • Operación y mantenimiento. Las tareas de mantenimiento son las últimas en realizarse en el ciclo de vida clásico del software. Sin embargo, considerando el total de la duración del ciclo de vida, la etapa de mantenimiento es la que más tiempo dura, ya que elaborar un sistema mediano típicamente lleva de 6 meses a 1 año, y posteriormente el sistema en producción po-

drá correr durante varios años durante los cuales el sistema debe ser soportado y mantenido. De la misma forma, aun cuando el mantenimiento de software es la última etapa del ciclo de vida del software, las actividades de mantenimiento no son las menos importantes. Muy al contrario, el mantenimiento del software se ha convertido en el principal componente en cuanto a costo y recursos invertidos en las organizaciones de TI. Esta aseveración responde principalmente a la relación entre el número de sistemas desarrollados anualmente por la industria, comparado con el número de sistemas en funcionamiento que hacen trabajar a las empresas. Dentro de las actividades del mantenimiento de software ocurre un fenómeno muy interesante, que es algo que denominaremos como la barrera del mantenimiento de software, y que en pocas palabras es la incapacidad en la que se ven sumergidas las organizaciones para poder iniciar nuevos proyectos debido al enorme desvió de recursos necesarios para soportar sistemas que son parte de la operación diaria. Se estima que esta barrera se alcanza cuando más de un 90 % de los recursos se encuentran dedicados a soportar aplicaciones. Prácticamente todos los profesionistas de sistemas hemos escuchado el comentario de que somos como los bomberos, apagando fuegos. Bueno, pues precisamente ésta es la razón de traer este tema a reflexión. El mantenimiento de software debe ser una actividad planeada por el área de tecnologías de información de una organización, que debe contar con recursos dedicados y capacitados para desempeñarla. Dividiremos entonces nuestra plática en 2 temas importantes: los problemas del mantenimiento de software y las soluciones a estos problemas.

Problemas del Mantenimiento de Software La problemática del mantenimiento de software se resume en realizar el mantenimiento de forma tan rigurosa y controlada que no se deteriore la calidad del sistema como resultado de este proceso. Por la naturaleza del software, existen problemas relacionados con el mantenimiento de software que están claramente identificados y sobre los cuales hablaré a continuación: La existencia de los llamados “legacy code” (código heredado). Con el paso de los años se ha ido produciendo un volumen muy grande de software en las empresas. En la actualidad, la mayor par-

Jose M. Esquivel es Ingeniero en sistemas computacionales egresado de la Universidad Autonoma de Guadalajara. Actualmente trabaja para Jabil de Mexico como Ingeniero de soluciones empresariales dando soporte a los sistemas de la compañia asi como impartiendo la clase de “Pruebas y Mantenimiento de Software” a nivel licenciatura en la Universidad del Valle de Atemajac. Anteriormente laboró en IBM como ingeniero de pruebas, Ingeniero de desarrollo, arquitecto de producto para clientes como Motorla y Chrysler, entre otros.

32

JUL-AGO 2007

www.sg.com.mx

“El mantenimiento de software debe ser una actividad planeada... que debe contar con recursos dedicados y capacitados para desempeñarla ”.

te de éste software está formado por código antiguo “heredado”; es decir, código de aplicaciones desarrolladas hace algún tiempo, con técnicas y herramientas en desuso y probablemente por personas que ya no pertenecen a la empresa ni al grupo responsable en este momento del mantenimiento del software. La situación se complica porque el código heredado ha sido objeto de múltiples actividades de mantenimiento. La opción de desechar este software y reescribirlo para adaptarlo a las nuevas necesidades tecnológicas o a los cambios en la especificación no es viable en la mayoría de las ocasiones, debido a la gran carga financiera que supuso el desarrollo del software original y la necesidad económica de su amortización. Problemas inherentes al mantenimiento del software. A pesar de toda la estandarización y modelos de procesos que busquemos adoptar, el desarrollo de software es en el fondo un proceso creativo. Es así que en el software siempre encontraremos patrones no uniformes de programación, ya que dependiendo de su habilidad, creatividad y experiencia, los programadores generan código de maneras innumerables. Asimismo, es muy común encontrarse con aplicaciones de software desarrolladas sin seguimiento a metodologías, procesos, ni lineamientos, que se refleja en código mal escrito, mal documentado, y por lo tanto difícil de mantener. Efectos secundarios o laterales no previstos ni deseados. Estos efectos se dan como consecuencias a las modificaciones no controladas a las aplicaciones de software, que a su vez representan problemas para el mantenimiento posterior del software. Existen tres tipos de efectos secundarios y se definen por su impacto en las diferentes áreas de una aplicación de software: a. Efectos secundarios en el código, en donde el código sufre modificaciones como rediseños, eliminación de procedimientos o subprogramas, modificación de macros o dll’s, cambios para mejorar el desempeño, etc... b. Efectos secundarios en los datos, esto al impacto de los cambios en los datos de las aplicaciones, tales como modificaciones en catálogos, formularios, cambios en los parámetros de los programas, etcétera. c. Efectos secundarios en la documentación, en donde generalmente después de un cambio en la aplicación, la documentación no es actualizada y esto genera problemas en la “mantenibilidad” del software.

Soluciones a los problemas de mantenimiento de software Existen diversas estrategias y acciones que podemos llevar a cabo para resolver o mitigar los diferentes problemas descritos anteriormente, y que pueden servirnos de guía sobre la manera en que las organizaciones deben de enfrentar el mantenimiento de software. Entre las principales estrategias están:

www.sg.com.mx

Código mantenible. Como ya lo mencionamos anteriormente, la manera de estructurar un programa depende de la creatividad y habilidad de los programadores, sin embargo existen prácticas que contribuyen a mejorar la facilidad de mantenimiento del código. Estas prácticas se resumen a continuación: • Código documentado: Los diferentes segmentos de código que se escriben deben contener comentarios objetivos que expliquen de forma adecuada el funcionamiento de éstos. Cada programa, clase y método debe incluir documentación sobre su propósito, funcionamiento, entradas y salidas esperadas • Banderas de cambio: es una práctica poco utilizada en la industria, y se refiere a la habilidad de establecer un mecanismo de identificación de cambios a lo largo de la vida de una aplicación. Es decir, si debido a una modificación el día de hoy cambiamos un par de líneas de código, es importante marcar esas líneas con alguna bandera que nos permita identificar en el futuro la razón por la que se modificó el código. Esto nos permite tener una visión de las versiones y justificaciones que pudieron haber inyectado un error a la aplicación. • Documentación actualizada: esta práctica es poco ejercida debido a que el tiempo y la forma de documentación no es suficiente en los proyectos de desarrollo. Sin embargo, me refiero primordialmente a tener las especificaciones de las aplicaciones actualizadas, no al manual de usuario que si bien es de mucha ayuda, es de más ayuda tener documentación técnica actualizada, tal como diseños, diagramas, diccionarios de datos, etc… Equipo dedicado de mantenimiento de software A pesar de la importancia que ya vimos que tiene el mantenimiento de software, muchas organizaciones no justifican la asignación de un equipo dedicado exclusivamente al mantenimiento de software. Sin embargo, es primordial tener identificadas a las personas que realizarán esta actividad, y no solo identificadas, sino también capacitadas y calificadas para realizar estas actividades. La justificación para tener a este equipo es muy sencilla, simplemente basta con cuantificar el costo que tiene que un sistema de producción deje de funcionar, o que genere problemas en su uso debido a un bug.

Conclusión El mantenimiento de software es un área que recibe poca atención, pero no por ello deja de ser sumamente importante, especialmente cuando se considera la cantidad de recursos que se le destinan. Existen muchos aspectos sobre el mantenimiento de software sobre los que vale la pena ahondar, y espero poder hacerlo en futuras ocasiones.

JUL-AGO 2007

33

// PRÁCTICAS

/* ADMINISTRACIÓN DE PROYECTOS*/

Caso Práctico sobre Análisis de Puntos de Función Parte 3. Puntos de Función Ajustados y Uso de los Puntos de Función Por Aquiles Santana

Bienvenidos a la tercera y última parte de este caso práctico sobre análisis de puntos de función. Como podrán recordar, el objetivo de este ejercicio es mostrar cómo se utiliza la técnica de puntos de función aplicada a un caso real. En nuestro caso, la aplicación consiste en un sistema para administrar las ventas de automóviles que realiza una empresa de compra-venta de autos usados. En la parte 1, planteamos los requerimientos iniciales en los que nos basamos para realizar el análisis. Posteriormente, en la parte 2 llevamos a cabo los pasos necesarios para determinar los puntos de función no ajustados. Ahora, ya solo nos falta realizar el ajuste para obtener los puntos de función ajustados. Por último, daremos un vistazo a los múltiples usos que le podemos dar al resultado de nuestro análisis de puntos función. Comencemos entonces …

herramientas tienen ya sus propias variables ambientales y sus propios criterios de evaluación. Por ello, alimentar puntos de función ajustados redundaría el factor ambiental que ya es considerado en la estimación.

7. Determinar los Puntos de Función Ajustados En este paso, se aplican fórmulas que en esencia consideran los puntos de función no ajustados y se multiplican por el factor de ajuste. Las fórmulas a ser aplicadas dependen del tipo de conteo (desarrollo, mantenimiento o aplicación). Para el caso de un nuevo desarrollo, la fórmula es la siguiente: Puntos de Función Ajustados = Puntos de Función no Ajustados x Valor de Ajuste

6. Determinar el Valor del Factor de Ajuste

Aplicación al caso

Este paso, ayuda a determinar un factor de ajuste que puede aumentar o disminuir el valor de los puntos de función en un +/35%. Las características evaluadas se refieren a requerimientos o restricciones no funcionales, como: comunicaciones de datos, actualización online, complejidad de procesamiento, facilidad de instalación, etc.

Sumando las funciones de datos (12 puntos de función no ajustados) y las funciones transaccionales (23 puntos de función no ajustados), esta aplicación mide 35 puntos de función no ajustados, los cuales multiplicados por el factor de ajuste igual a 1, nos daría 35 puntos de función ajustados.

Si la calificación de estos factores ambientales es el mínimo, el valor de ajuste será 0.65. Por el contrario, si los factores ambientales son los más complicados, el valor de ajuste será 1.35.

Una vez que hemos obtenido el total de puntos de función, estamos ya en posibilidad de beneficiarnos de esta poderosa técnica. Algunos de los beneficios que obtenemos directamente son:

Para obtener la evaluación más precisa y objetiva, se recomienda que para esta actividad el analista de puntos de función trabaje en conjunto con el equipo técnico.

• Estimación de Proyectos: El dato de los puntos de función no ajustados, puede ser introducido en algún modelo de estimación estadístico, el cual sea calibrado con información histórica de proyectos ya terminados y también dimensionados en puntos de función. Los datos históricos de tamaño, esfuerzo, personal, fases y características ambientales, proveen las tendencias clave que pueden ser utilizadas para estimar proyectos similares. En nuestro caso la aplicación mide 35 puntos de función y el cliente quiere que terminemos el proyecto en 2 meses. Buscaremos en la BD historia de proyectos en tamaño y características similares, y con la ayuda de las herramientas estadísticas, identificaremos tendencias y evaluaremos las probabilidades de éxito en diferentes situaciones, como por ejemplo: ¿Cuál es la probabilidad de terminar el proyecto en 2 meses?, ¿Cuál es la cantidad adecuada de personas a ser asignadas al proyecto? ¿Cuál es la cantidad de

Aplicación al caso Debido a que no fue proporcionado el detalle de las características ambientales, y sólo se indicó que los requerimientos y restricciones no funcionales son como el “promedio”. Se asumirá un valor de ajuste igual a uno. Cuando se calculan los puntos de función para realizar una estimación mediante el uso de una herramienta estadística, se alimentará únicamente los puntos de función no ajustados. Es decir, funcionalidad “pura” sin la influencia de características ambientales o de implementación. Esto es debido a que estas

34

JUL-AGO 2007

Uso de los Puntos de Función

www.sg.com.mx

esfuerzo requerido?, ¿Cuál sería el escenario con menor costo? y además, si con la información histórica se observara una muy baja probabilidad para terminar en 2 meses, ¿Cuántos puntos de función si podríamos comprometer para liberar en 2 meses?. Las herramientas de estimación paramétrica son excelentes para estudios de “¿Qué pasa sí…?” y en la generación de diferentes escenarios factibles. Siempre, el tener mayor información histórica de nuestros propios proyectos, será mejor para incrementar la exactitud de nuestros estimados. • Control de Alcance: Una vez aprobado el alcance de 35 Puntos de Función, será ahora nuestra línea base de tamaño. Debido a que el proyecto se encuentra en fases tempranas, típicamente existirá un crecimiento de tamaño debido a un mayor entendimiento del negocio y/o aclaración de supuestos. En nuestro caso práctico, hicimos el supuesto de que la aplicación, no contemplaba funcionalidad para definir usuarios y perfiles de seguridad. Sin embargo, durante el desarrollo, dicho supuesto podría cambiar cuando el usuario decidiera que si quiere tal funcionalidad. Como en cualquier administración de cambios, abriríamos nuestro control de cambios al alcance y en la evaluación del impacto, incluiríamos el nuevo tamaño funcional para ver si dicho incremento de tamaño sobrepasa nuestros límites de capacidad. En caso de ser así, ejecutaríamos alguna acción de mitigación o contingencia. Por ejemplo, si derivado del análisis, la funcionalidad creciera hasta 50 puntos de función, ¿mantendríamos el mismo estimado de duración/esfuerzo/personal asociado a los 35 puntos de función?, ¿hasta donde podemos absorber? ¿Sí sólo crece 10 puntos de función, podemos manejar el crecimiento? En este punto, las opciones típicas para administrar el cambio, podrían ser: - Priorizar junto con el usuario para acotar de nuevo a los 35 puntos de función y mover la funcionalidad con menor prioridad a otras fases. - Incrementar el tamaño del equipo (si es aún factible). - Incrementar la duración del proyecto. • Control de producción: Los puntos funcionales nos permiten cuantificar cual es el tamaño del proyecto. Es decir, al final del proyecto de nuestro caso práctico esperamos que se entreguen 35 puntos de función. Ahora bien, durante el ciclo de vida, cada que es terminado un caso de uso, un diseño, un diagrama de clases, una codificación de un método o un caso de prueba, etc; nos vamos acercando a estos 35 puntos de función. Alguna herramienta para el control de producción tomará como entrada estos 35 puntos de función, y hará visible cuanto se ha construido y cuanto debería tenerse construido con base a información histórica, y así comparar si el ritmo de producción es similar a las tendencias esperadas. En caso de que el ritmo de producción fuera menor al esperado, acciones correctivas o de mitigación sería tomadas. Por ejemplo, quizas, el volumen de producto es menor debido a que los peer reviews, están siendo sólo de forma y no de fondo, y los defectos mayores están pasando directamente por el ciclo de vida, sin que sean tempranamente atendidos. Nuestra acción sería atender esta causa modificando el proceso de peer reviews para detectar estos defectos tempranamente e incrementar el

www.sg.com.mx

JUL-AGO 2007

// PRÁCTICAS

/* ADMINISTRACIÓN DE PROYECTOS*/

• Construcción de base de datos histórica para benchmarks y proyectos de mejora continua: Cuando terminemos nuestro proyecto de 35 puntos de función, como parte de las actividades de cierre del proyecto obtendremos y registraremos métricas y lecciones aprendidas. Entre las métricas que deberán ser recopiladas están: el tamaño funcional, el esfuerzo (horas-hombre, meses-hombre), duración (días calendario, días hábiles), número de personas, cantidad de defectos, número de cambios, cantidad de líneas de código, cantidad de casos de uso, número de riesgos, número de issues, etc. Estos datos serán almacenados en nuestra base de datos de proyectos históricos con el propósito de ser analizados y utilizados para realizar benchmarks en la propia organización y contra el mercado, y derivado de ello, arrancar proyectos de mejora con el fin de reducir el costo de nuestros proyectos, incrementar nuestro desempeño y lograr mejores oportunidades de mercado. Estos proyectos de mejora, partirían de metas objetivas para disminuir el costo de nuestros proyectos mediante el incremento de productividad y calidad. Por ejemplo, si la información de la industria, nos indicara que la productividad típica de un proyecto es de 15 puntos de función por persona-mes, y en nuestros proyectos tenemos un promedio de 10 puntos de función por persona-mes, esto nos daría una meta clara de que por lo menos debemos incrementar la productividad en 5 puntos. De esta forma, los programas de mejora complementarán sus objetivos y no sólo estarán enfocados a lograr tal o cual certificación, o nivel de madurez. Los programas de mejora continua, deben tener objetivos claros y medibles para el negocio, y no sólo el objetivo de obtener un papel o reconocimiento. Adicionalmente, el ingreso de más información en nuestra base de datos de proyectos, incrementará la exactitud de nuestros estimados y nos dará mayor oportunidad y certeza para dar estimados agresivos pero factibles.

Potenciales usos del Proceso de Análisis de Puntos de Función Obviamente, el objetivo principal del análisis de puntos de función es obtener los puntos de función para un sistema. Sin embargo, existen beneficios adicionales derivados de la aplicación del proceso. Como su nombre lo indica el Análisis de Puntos de Función, es también una técnica de análisis sistemática que aporta beneficios tangibles como: • Rastreabilidad de componentes: Como pudo ser apreciado en nuestro caso práctico, al momento de realizar el conteo de Puntos de Función, se identifican componentes funcionales que tienen una granularidad definida, debido a que seguimos las reglas y definiciones del estándar del IFPUG. Estos componentes lógicos

funcionales, pueden ser relacionados contra los componentes físicos (tablas, pantallas, clases, casos de prueba, etc), lo cual sienta las bases para la construcción de una matriz de rastreabilidad que sea utilizada para evaluar de manera completa y consistente el impacto de los cambios, y aumentar la productividad en los mantenimientos debido a curvas de aprendizaje menores. En nuestro caso, la función de datos: “Vehículo” está implementado en dos tablas: Tb_Vehículos y Tb_Accesorios_Vehículo. Por lo tanto cuando funcionalmente se identifique una modificación a la función de datos “Vehículo”, el equipo técnico sabrá que estados dos tablas podrían ser impactadas. • Identificación de scope creep o inconsistencias en los requerimientos: Cuando se están contando los puntos de función e identificando las funciones de datos y transaccionales, el análisis es realizado de manera sistemática, por lo cual aparecen preguntas que deben ser resueltas por el equipo de análisis o el cliente. Por ejemplo, en nuestro caso práctico, al momento de contar las funciones transaccionales, vemos que tenemos la función de “Insertar Compra”, sin embargo, cabe pensar que pueda existir un “Actualizar Compra”, funcionalidad que no está incluida en los requerimientos, pero que podría presentarse y debe ser evaluado con el cliente si dicha funcionalidad será parte del sistema. Así mismo, el análisis de puntos de función ayuda a revisar los productos derivados de otras técnicas de análisis. En mi experiencia, ha sido muy útil para identificar defectos presentes en especificaciones de casos de uso.

Conclusión La técnica de análisis de puntos de función es muy valiosa para nuestra industria, donde la carencia de métricas de productividad estándar reduce la madurez con la que nuestros clientes y nosotros mismos podemos evaluarnos. Una industria madura se fundamenta en métricas y no en percepción y buenos deseos. Por esto, como consumidores de productos de ingeniería de software debemos exigir y evaluar a nuestros proveedores con métricas de productividad y calidad, y como proveedores debemos empujar e incrementar nuestro desempeño orientados a la reducción de costos y aumento en la satisfacción. A fin de cuentas, el objetivo no es alcanzar un nivel de madurez o una certificación, ese es sólo el medio. El objetivo real es producir aplicaciones con oportunidad, mínimo costo y alta satisfacción para nuestros clientes y nuestros empleados, y en ese camino, los puntos de función tienen mucho que ofrecer.

Aquiles Santana Álvarez es Certified Function Points Specialist por parte del IFPUG y Project Manager Professional por parte del PMI. Ha sido responsable de la estimación de proyectos de software críticos para EDS de México y Latinoamérica. Ha impartido entrenamiento en la técnica de Puntos de Función y estimaciones a más de 300 personas en 6 países. Actualmente se desempeña como consultor en Project Management e Ingeniería de Software.

36

JUL-AGO 2007

www.sg.com.mx

// PRÁCTICAS

/* MEJORA DE PROCESOS*/

Factores Clave para la Mejora de Procesos La diferencia para el éxito Por Rocío García Ocaña

Sin duda alguna, las necesidades y tendencias externas determinan los cambios en las organizaciones, cambios de toda índole y tamaño. Desde cambiar un poco la forma de hacer las cosas hasta cambios que implican un programa formal dando pie al surgimiento de un programa de mejora cuyos objetivos son el incremento de calidad, disminución de costos, aumento de competitividad, entre otros. Usualmente, la mejora de procesos se concentra en la definición o redefinición de procesos, procedimientos, políticas, mediciones, uso efectivo de herramientas, etcétera. Sin embargo, esto no es suficiente para lograr la mejora que buscamos, ya sea en el desempeño o en la calidad. Pensemos que para conseguir resultados con impacto, es necesario cambiar cosas no sólo en papel o en electrónico, sino en hábitos, comportamientos y percepciones, para conseguir una alineación a los objetivos que perseguimos. Una de las quejas más frecuentes durante la fase de implementación de un programa de mejora de procesos, se refiere a la cooperación limitada o nula de algunos miembros de la organización, respecto a seguir los procesos definidos, pero ¿qué hay detrás de ese comportamiento?, ¿y cómo mitigarlo para lograr que nuestro programa genere verdaderamente los resultados que buscamos? Antes de pensar en introducir mejoras de proceso, lo primero que debemos saber es que, hacerlo implica cambios en la forma de trabajar, lo cual tiene un impacto directo en esfuerzo y por consiguiente, en tiempos. Es así como caemos en la cuenta que uno de los riesgos más grandes es la aparición y permanencia de la resistencia de los miembros de la organización, que a la larga, se convierte en un verdadero dolor de cabeza para una implementación exitosa. ¿Les suena familiar? Si han implementado y están en la actualidad involucrados en el mencionado proceso, comprenderán sin lugar a dudas a lo que me refiero. La importancia de considerar otros factores que contrarresten el efecto de los cambios y se conviertan en aliados para implementar exitosamente nuestro programa, es crítico. Los factores a los que me refiero son: cultura, comunicación, disciplina, convencimiento, manejo del cambio, coaching y enfoque.

www.sg.com.mx

Considerar dichos factores nos permitirá tener una estrategia más robusta y con mayores posibilidades de alcanzar los resultados que esperamos. El objetivo de este artículo es explicar en qué consisten estos factores y entender su importancia para implementar un programa de mejora.

La cultura Al igual que un país, las organizaciones son entes únicos, con una identidad que las diferencia y una serie de valores que las identifica. A este conjunto de identificadores es a lo que llamamos cultura organizacional. Entenderla es fundamental porque nos ayuda a sensibilizarnos con el ambiente de la organización y prever un poco su reacción ante la introducción de cambios. La importancia de conocer y entender la cultura organizacional radica en el hecho de que existen elementos imperceptibles a simple vista, como hábitos, sentimientos, motivadores, clima laboral, estilos, etcétera; que pueden convertirse en poderosos obstructores durante una implementación. El plan de mejora busca incrementar la calidad a través de diseño de procesos, pero dichos procesos son ejecutados por personas con una identidad individual incrustada en una identidad colectiva, por eso requerimos hacer un alto, y recapacitar antes en el tipo de cultura que tenemos. Supongamos por ejemplo, que la ejecución de los procesos me ayuda en un mediano plazo a hacer que los integrantes de los equipos de desarrollo trabajen en un ambiente más controlado, que los trabajos se logren terminar en tiempo y presupuesto, pero ¿qué hay más allá de eso? Probablemente parte de la cultura de la empresa, es el valor a los detalles funcionales del producto que se construye, más aún hablando de software. Tal vez uno de los valores de la empresa es propiciar la lealtad de los clientes; y la cultura de atención en los detalles no es sólo cuestión de calidad sino de valores. Todos estos pequeños detalles nos darán la pauta para saber orientar el programa de mejora y hacer que no sólo encajen con una estrategia de negocio, sino con la cultura de trabajo de las personas que forman parte de la organización. Lo que nos dará como resultado: minimizar el shock ocasionado por los cambios, facilitar la introducción del cambio, así como lograr un cambio más duradero en la organización.

JUL-AGO 2007

37

// PRÁCTICAS

/* MEJORA DE PROCESOS */

“Manejar el cambio significa: subir a todos al barco del cambio, sin olvidar que estamos a cargo del timón”. Comunicación “La comunicación es la base de todo”, seguramente han escuchado en varias ocasiones esta frase, y ahora me permito repetirla una vez más, pues en los programas de mejora no es la excepción. De la claridad y efectividad con que los comuniquemos dependerá en gran medida la respuesta de las personas de la organización para asimilar y aceptar los cambios que implican las mejoras. Para denotar la importancia de una comunicación efectiva, recapitularemos un poco sobre lo que sucede al decidir trabajar con un programa de mejora: se identifica una necesidad, se conforma al equipo de trabajo, comienza la planeación; si los patrocinadores del programa están de acuerdo se autoriza y comienza a ponerse en marcha. El tiempo pasa, y aunque vemos avance en las actividades de cada fase del plan de mejora, ¡sorpresa!, la implementación no está arrojando los resultados esperados, o tal vez no con la rapidez que esperamos; es entonces cuando nos preguntamos: ¿qué falta? Las razones pueden ser varias, pero una de las principales es la falta de comunicación o la comunicación no efectiva. Un plan de mejora es generalmente gestionado por un grupo de personas, pero no hay que perder de vista que es “ejecutado” por un grupo más grande de personas que, de una u otra forma, ven alteradas sus actividades como efecto de los cambios introducidos. Es por ello que la comunicación honesta, abierta, oportuna e integral, es fundamental en todas las fases del programa. Es importante que desde el inicio consideremos el tiempo suficiente y los medios adecuados para informar a todos los involucrados, a todos los niveles, sobre lo que se busca lograr, en qué vamos, qué implica y por qué se está haciendo, qué impactos tiene y qué pasa si no se hace. El no sostener una comunicación efectiva y constante durante todas las fases del plan de mejora, provoca desorientación, y cada una de las personas involucradas en el cambio caminará con su propia visión de las cosas, la cual puede no coincidir con la visión general del programa, lo que impedirá que el esfuerzo y el trabajo rinda los frutos esperados.

Disciplina Como todo en la vida, el logro de objetivos requiere disciplina

en la ejecución de las acciones que demanda nuestro plan de mejora, esto con la finalidad de tener un progreso real que nos garantice el logro de los resultados que buscamos, lo anterior no es nada nuevo, sin embargo ¿cómo generar disciplina en nuestra gente?, no es una tarea fácil. Comencemos por definir el término. La palabra disciplina tiene un vínculo tanto a áreas de conocimiento como al apego de las reglas. En el contexto de un programa de mejora, se refiere a conocer y seguir los procesos como fueron definidos, para lo cual, la autoridad (llámese comité de mejora) contribuirá para guiar a la organización y verificar el apego a los procesos. Si esta disciplina no se fomenta a todos los niveles, difícilmente lograremos los cambios que esperamos. No obstante, hay que tomar en consideración que la disciplina no es lo mismo que la imposición. La disciplina se inculca, se enseña con el ejemplo y se mejora con el tiempo, pero si la intentamos desarrollar con intimidación puede generar efectos secundarios, tales como la apatía.

Convencimiento Para explicar este factor, quisiera que pensaran por unos segundos en la razón por la cual usan el cinturón de seguridad una vez que suben a su auto, tal vez lo hacen por instinto o por costumbre, pero a fin de cuentas, probablemente lo usan porque están convencidos de que puede salvarles la vida en un accidente cuando menos lo esperen. Dichas circunstancias imaginarias nos provocan cierta disciplina en su uso. El punto al que pretendo llegar es que, el estar convencido de la utilidad o el valor de las cosas es algo que buscamos en las personas para generar disciplina, es decir, que esa comunicación de los nuevos procesos vayan acompañados de información contundente; lógica que tenga el poder de convencer y que haga que en las personas florezca la disciplina para seguir los procesos definidos y lograr un hábito a largo plazo, haciendo verdaderamente sustentables las prácticas que se pretenden introducir a través del programa de mejora.

Manejo del cambio La mejora de procesos representa sin duda un esfuerzo organizacional con impactos de distintas magnitudes en el ambiente, y

Rocío García Ocaña labora en Avantare Consultores como Consultora de ingeniería de procesos de software. Su desarrollo profesional la ha llevado a empresas como Getronics ICT Solutions donde fue Coordinadora de Procesos y Aseguramiento de Calidad del Software, y FORD Motor Company México donde tuvo a su cargo la definición de procesos de procesos de administración, respaldo y recuperación. Rocío es Licenciada en Sistemas Computacionales Administrativos por el ITESM-CEM, y cuenta además con una Maestría en Administración por la misma institución.

38

JUL-AGO 2007

www.sg.com.mx

como tal, estos cambios requieren ser conducidos de la manera correcta, siempre con el apoyo de la alta gerencia, pero ¿qué significa manejar el cambio? Primeramente entender que cada pequeño o gran cambio que ocurre dentro de la organización provoca diversas reacciones en las personas, desde la cooperación hasta la resistencia. El manejo del cambio en todo el proceso del programa es en definitiva una de las claves para hacer la implementación suave y con efectos duraderos. El manejo del cambio, más allá de generar un plan, monitorearlo y garantizar que sea apoyado por la alta gerencia, implica tener objetivos claros, visión nítida de dónde queremos llegar, dedicación y atención para guiar a las personas durante toda la iniciativa; de tal manera que en todo momento podamos percibir y canalizar todos los sentimientos que generan los cambios en las personas que forman parte de la organización. Es necesario entender que la mejora conlleva cambio y el cambio, tanto en nuestras vidas personales como profesionales, genera una serie de mecanismos de defensa, los cuales en ningún momento deben ser subestimados. Manejar el cambio significa: “subir a todos al barco del cambio”. Sin olvidar que estamos a cargo del timón y debemos monitorear la dirección de dicho barco.

Coaching El siguiente factor muy íntimamente ligado al manejo del cambio, es el coaching, es decir, el estar “cerca” de las personas a quienes impactará el cambio. Proporcionar coaching, significa escuchar y otorgar a las personas que forman parte de la organización la oportunidad de expresar las opiniones que soportan sus decisiones; aclarar sus dudas de manera oportuna y acompañarlos en el proceso de cambio que un programa de mejora implica. La ausencia del coaching puede provocarnos problemas, desde una práctica errónea que más tarde puede ser diseminada, una formación inapropiada que resulta en la generación de resistencia, hasta la pérdida de interés por sentimiento de ausencia de un guía.

Enfoque Un elemento más, y no menos importante, es el enfoque, para entender un poco mejor, imaginemos la nitidez y claridad de la imagen que logramos cuando ajustamos unos binoculares para ver a cierta distancia. En el contexto de un programa de mejora, el enfoque se refiere a tener una perspectiva entendible y coherente tanto del mediano como del largo plazo. Además significa tener claro qué objetivo perseguimos, cuáles son los pasos definidos y mantenernos avanzando sin perderlo de vista, lo cual nos permitirá identificar los momentos cuando se requiere hacer un ajuste, que de cualquier modo, nos permita llegar al objetivo. Avanzar sin un enfoque, es como caminar en un terreno desconocido, es como decir: “quiero mejorar, pero no sé en qué”. Finalmente quisiera recapitular y mencionar que un programa de mejora implica cambios, además de una constante lucha contra el tiempo y los recursos, dado lo cual, vale la pena tener en cuenta estos siete factores , que sin ser secuenciales, sí se encuentran estrechamente ligados unos con otros. Nos ayudarán a soportar el proceso de implementación, y lo más importante, pueden ser los diferenciadores entre una simple implantación de procesos y una implantación efectiva de procesos. ¡Mucho éxito!

www.sg.com.mx

JUL-AGO 2007

// PRÁCTICAS

/* DISEÑO */

El Mariachi Orientado a Objetos Entendiendo el diseño OO Por Carlos “Fofo” Ordóñez

¿Cómo hacen los diseñadores de automóviles para construir un auto compacto, que pueda ser conducido por una persona que mide 1.60 de estatura, y un grandulón de 2.10? La respuesta es sencilla: considerando al momento de diseñar, y antes de fabricar, los potenciales de cambio, tomando así las medidas pertinentes para crear una solución “flexible”: la palanquita que recorre los asientos. Cuando desarrollamos sistemas, todos nos hemos enfrentado a esta constante de nuestra profesión: el cambio. Cambio de requerimientos, cambio de versiones, cambio de plataforma, etcétera. Para combatirlo, tenemos que dedicar una buena parte del tiempo de análisis y diseño a la flexibilidad de nuestra solución, con el único objetivo de disminuir el riesgo y el costo que éste implica, para tener un cliente satisfecho con menos dinero.

Figura 2. Mariachi con músicos bailarines.

Al parecer nuestra solución ha sido suficientemente flexible para adaptarse a los cambios, hasta que el cliente nos solicita un nuevo músico: “hagamos una mezcla cultural, quiero escuchar un Mariachi con batería”. Inmediatamente pasa por nuestra mente agregar una nueva clase: Baterista (véase figura 3).

El Mariachi orientado a objetos es un divertido ejemplo de cómo lidiar con los cambios de requerimientos al diseñar clases flexibles, utilizando el patrón de estrategias para diseño orientado a objetos.

Cantemos con Mariachi Supongamos que tenemos un cliente extranjero cuya pasión musical es desmesurada, y nos ha pedido desarrollar una aplicación que simule la forma de hacer música de un Mariachi, sólo desea integrar un guitarrista, un violinista y un trompetista a la simulación, dado que todos tocan música de diferentes formas y tienen un canto característico, la mayoría comenzaríamos planteando un diagrama de clases similar al mostrado en la figura 1.

Figura 3. Mariachi con Baterista.

El problema es claro: “Bateristas Bailarines”. Esto lo podemos resolver de una forma muy sencilla, sobrescribiendo el método bailar en Baterista de tal forma que no baile: public void bailar() { // hacer nada … }

Figura 1. Primer acercamiento a la solución.

Nuestro cliente quedó satisfecho con la solución, mas sin embargo, al ver que los integrantes del Mariachi pueden bailar, no esperó mucho para solicitar un cambio de requerimientos: “Ahora quiero Mariachis bailarines”. Nuestro equipo de diseño reacciona rápidamente y agrega el método bailar a la clase Músico. (Véase figura 2).

40

JUL-AGO 2007

Evidentemente, después de este cambio, estamos violando el principio de sustitución de Liskov, el cual indica que “debe ser posible utilizar cualquier objeto instancia de una subclase, en el lugar de cualquier objeto instancia de su superclase sin que la semántica del programa escrito en los términos de la superclase se vea afectado”. En nuestro caso, esto significaría que no será posible reemplazar semánticamente a cualquier Músico por un Baterista, pues el último limita la funcionalidad del primero. Días mas tarde y aún sin resolver el problema del Baterista, recibimos

www.sg.com.mx

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

Figura 4. Mariachi con cantante de opera

La solución parece suficiente. No obstante, nos damos cuenta que estamos en un gran aprieto: Cantantes de Ópera que cantan como Mariachi… ¡Ah, y bailan! Hasta ahora no hemos tenido éxito entre clases rígidas y malos diseños, lo que definitivamente nos convierte en presa fácil de un exceso de presupuesto. Es entonces que uno de los diseñadores sugiere: “intentémoslo con interfaces”. La figura 5 muestra una solución utilizando interfaces.

Figura 5. Mariachi usando interfaces

www.sg.com.mx

JUL-AGO 2007

// PRÁCTICAS

/* DISEÑO */

Esta solución parece correcta. Incluso hasta el trompetista ha dejado de cantar, para dedicarse únicamente a tocar música y bailar. Sin embargo, este diseño tiene un problema muy grave: “reutilización de código”. Cuando volteamos y vemos que los métodos bailar, tocar música y cantar tienen que ser implementados por las clases concretas, estamos en aprietos.

de estrategias para cada método con alto potencial de cambio. Para cada una de estas estrategias se construye una interfaz o clase abstracta que define qué es lo que hacen cada uno de los conjuntos de algoritmos, y aplicando el patrón de estrategias obtenemos el resultado en la figura 7.

Patrón de estrategia Es en estos momentos, donde el patrón de diseño denominado “Estrategia” llega a nuestro rescate. Este es uno de los patrones descritos en el libro “Gang of Four”, que como sabemos, es la biblia de los patrones de diseño orientado a objetos. De acuerdo con esto, el patrón estrategia: “Define una familia de algoritmos encapsulados y los hace intercambiables (…) permite al algoritmo cambiar, independientemente del cliente que lo utiliza” En concreto, el patrón de estrategia nos permite construir una colección de comportamientos intercambiables, independientemente de quién haga cantar al Mariachi. La figura 6 muestra la estructura de una solución genérica utilizando el patrón de estrategia.

Figura 7. Mariachi utilizando el patrón de estrategia

Conclusión Después de darle muchas vueltas a este problema, llegamos a una solución que cumple los requerimientos, y además explota las ventajas de la orientación a objetos. Figura 6. Solución propuesta por el patrón de estrategia

Lo que tenemos que hacer entonces es encontrar cuáles son los potenciales de cambio, es decir, cuáles clases y/o comportamientos tienen una gran probabilidad de ser modificadas y aislar los cambios de las demás clases, y al mismo tiempo, explotar el polimorfismo agregando una clase abstracta o una interfaz para cubrir las diferentes estrategias. Siguiendo este consejo, se detecta que el comportamiento de los músicos es el que tiende a cambiar, entonces se decide crear un conjunto

Esta solución es mejor, pues si se desea agregar un nuevo músico, sólo es necesario heredar de músico y en el constructor, enviar como parámetro sus comportamientos. De esta forma, nuestro diseño queda abierto para extensión, pero cerrado para modificación y lo mejor de todo, si en un momento dado, se requiere cambiar el comportamiento de hacer Música, sólo creamos un nuevo comportamiento: Cantar Como Gloria Trevi, y lo asignamos al músico en cuestión, e incluso lo podemos hacer en tiempo de ejecución, y listo, ahora tenemos un Mariachi que canta de pelo suelto.

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

42

JUL-AGO 2007

www.sg.com.mx

/*TENDENCIAS EN SW*/

// COLUMNA

Web 2.x y Web 3.x Un nuevo camino por recorrer Luis Daniel Soto es director de Divulgación Tecnológica para América Latina en Microsoft. 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

En un inicio, el Web 2.0 era sinónimo del “Web semántico”, con contenido altamente definido. Sin embargo, esto ha ido cambiando, y actualmente la etiqueta de “Web 2.0” puede referirse a una o más de las siguientes características: • El web de lectura-escritura. • Sitios que facilitan la colaboración o creación colectiva. • Sitios con una interfaz de usuario visualmente rica, y altamente interactiva, a través de tecnologías como Silverlight y Flex, o incluso el web tridimensional (www.web3d.org). • El web como plataforma para crear aplicaciones. Con esto me refiero a servicios web que permiten crear composición de páginas y “mashup”. Algunos de los ejemplos para esto son Yahoo Pipes (pipes.yahoo.com) , Dapper (dapper.net), Teqlo (www.teqlo.com), y Microsoft Popfly (www.popfly.com), el cual se muestra en la siguiente figura.

Figura 1. Usando Popfly para crear un mashup.

Las palabras clave, tecnologías y “buzz words” asociados proliferan, incluyendo RSS, Wiki, SaaS, Ajax, Folksonomies y muchas otras. El proceso por definir “niveles” dentro de Web 2.0 continua, y ante ello yo me atrevería a llamar estos diferentes niveles como “Web 2.x”.

www.sg.com.mx

El debate de Web 3.x Hay quienes ya se atreven a hablar sobre un Web 3.x. Las especulaciones de lo que el futuro depara son ya abundantes, pero hay elementos que parecen ser ineludibles. Entre ellos, destaco los siguientes: • La transformación del “web en una base de datos” o la “web del sentido común”. Hoy, las búsquedas en un altísimo porcentaje no conducen al usuario a responder preguntas. Aquí algunas normas del “Web semántico” y otras como SPARQL (www.w3.org/TR/rdf-sparql-query/) seguramente serán relevantes, en conjunto con inteligencia artificial que permita comprender intenciones y agentes en Internet. • La convergencia de información personal: perfiles de usuario, historias de navegación realizada, análisis de calendarios y contenido de correo electrónico. Todo esto es explotable para dirigir y personalizar la publicidad y mercadotecnia en línea. • La mayor velocidad de acceso a Internet. ¿Qué se podrá hacer con anchos de banda 10 a 100 veces más veloces que las mejores conexiones de hoy? Todavía no lo sabemos, pero definitivamente será mucho más que la composición de videos en tiempo real. Incluso hay quienes se han atrevido a pronosticar el fin de las laptops, dado que el 100% de la información personal podrá residir en Internet. • La democratización y proliferación del acceso. El porcentaje de la población mundial que actualmente tiene acceso al Internet es de tan solo el 17.2% (www.internetworldstats.com/stats.htm). Esto nos indica que la mayor oportunidad definitivamente está por venir, así como la definición de mecanismos para alcanzar a más gente. • Hablando de lo que sucedería hacia el interior de las organizaciones, algo que se espera es el “remix” real entre aplicaciones y datos de misión crítica. Otro escenario es el de la habilitación total del auto-servicio, así como el ensamble dinámico y en tiempo real de cadenas de suministro. El Web 3.0 no será solo una plataforma, posiblemente el sistema operativo mismo del futuro. El camino por recorrer nuevamente es extenso… —Luis Daniel Soto Referencias adicionales: • dsiegel.blogs.com/thoughts/2007/05/defining_web_30.html • en.wikipedia.org/wiki/Web_3.0

JUL-AGO 2007

43

// UML

Procesos Basados en UML MANTENLO SIMPLE Por Sergio Orozco

¡Estoy harto de los procesos y estándares de desarrollo! Ese suele ser el grito desesperado de muchos responsables de organizaciones de software que han intentado formalizar sus procesos con resultados poco eficientes. Y no es para menos, pues muchas veces la experiencia de los “gurús” que los asesoran en la mejora de sus procesos se reduce a lo que aprendieron en libros o cursos y no a la realidad de los proyectos. No es un secreto que no necesariamente lo que dicen los libros es lo que aplica para todas las organizaciones. El caso de UML entra en esta categoría de estándares incomprendidos. Y es que intentar usar todo UML, simplemente porque aprendiste cuáles son los diagramas que lo conforman, no es precisamente el camino que te llevará a obtener los mejores resultados. Recuerda que UML no es el proceso, sino que es una notación que puedes utilizar parcial o totalmente en tu proceso.

Proceso A. El Más Simple: Requerimientos, el Principio de Todo Si actualmente tu proceso consiste en entrevistar a tus usuarios y con base en dicha información comienzas a programar de inmediato, entonces mi recomendación es que por lo menos agregues casos de uso a tu proceso (diagramas y especificaciones de casos de uso). Básate en estos para planear, para repartir el trabajo, para cotizar, para desarrollar, así como para diseñar tus pruebas. Verás que este simple cambio será un cambio drástico y sumamente beneficioso en los resultados de tus proyectos.

Selección de Artefactos La experiencia nos ha demostrado que muchas veces es necesario seleccionar un mínimo indispensable de artefactos a desarrollar durante un proyecto. Los clientes quieren calidad, pero también necesitan eficiencia. Los recursos son limitados, y sabemos que un proceso mal utilizado puede traer resultados contraproducentes en este sentido. El mal uso de UML puede ser una causa para esta frustración por parte de los desarrolladores y un motivo de decepción en el uso de procesos formales. Así que muchas veces conviene aplicar la filosofía de KISS (“Keep it Simple, Stupid” o “Keep it Short and Simple”). Si vas a usar un diagrama de UML asegúrate de obtener un beneficio en tu proyecto, o mejor no lo uses. Y si tienes una limitante importante de tiempos y recursos, es mejor que elijas el mínimo indispensable para poder obtener beneficios de un estándar, pero sin agregarle costos que no puedes absorber por las restricciones del proyecto. A continuación intentaremos esquematizar diferentes variantes de procesos, en cuanto a la selección de artefactos de UML que utilizan, desde uno muy simple hasta otro medianamente elaborado. Imagina que tu forma de desarrollar consiste en entrevistarte con el usuario y después programar; actividades elementales que no podrían desaparecer. La pregunta que trataré de responder es: ¿qué agrego (de UML) en medio de esas dos actividades?

Figura 1. Proceso simplificado al máximo.

Proceso B. El Sencillo: Requerimientos y Diseño. Si estás un poco menos limitado de tiempo (y de motivación) como para formalizar un poco más las tareas de tu proyecto entonces aprovecha los beneficios de otro artefacto básico de UML: el diagrama de clases.

Figura 2. Proceso sencillo

Si puedes utilizarlo con un enfoque de análisis primero (modelo de dominio) y después refinarlo para convertirlo en tu modelo de diseño, sería ideal. De esta forma obtendrás beneficios al tratar de comprender los requerimientos y el dominio, así como en las decisiones respecto a cómo construir una aplicación orientada a objetos. Pero, si consideras que no tienes tiempo de usarlo con los dos enfoques mencionados entonces por lo menos úsalo para realizar el di-

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. [email protected] www.milestone.com.mx

44

JUL-AGO 2007

www.sg.com.mx

“El mal uso de UML puede ser una causa de frustración por parte de los desarrolladores y un motivo de decepción en el uso de procesos formales ”.

seño de tu aplicación. Considera que no necesariamente tienes que desarrollar el diagrama de clases completo antes de comenzar con la programación, seguramente identificarás nuevas clases al comenzar con dicha actividad que podrás reflejar posteriormente en tu modelo. Proceso C. El Intermedio: Requerimientos, Análisis y Diseño El proceso anterior inicia el camino a la formalización en requerimientos, análisis y diseño. Eso ya es ganancia para la mayoría de los equipos de desarrollo, en los que el valor lo concentran exclusivamente en la programación y no en el resto de las actividades del proyecto. La siguiente recomendación para mejorar tu proceso consiste en refinar tus actividades de análisis y diseño. Para lograrlo te recomiendo el diagrama de secuencia (en su lugar puedes usar el de comunicación). Una vez identificado tu modelo de dominio, aprovéchalo y basándote en los flujos de tus casos de uso modela las interacciones entre las clases. Modelar las interacciones te permitirá tomar mejores decisiones de diseño. El beneficio será el desarrollo de una mejor aplicación. Una advertencia: no intentes desarrollar los diagramas de secuencia para todos y cada uno de tus casos de uso. En general considero que sólo es indispensable para aquellos casos de uso más críticos y complejos. Usa la regla del 20-80 y utilízalo para modelar el 20% de tus casos de uso; los más complejos e importantes. Si modelas las interacciones de todos tus casos de uso tendrás que invertirle tiempo valioso que podrías estar aprovechando en otro tipo de actividades del proyecto.

Figura 3. Proceso intermedio

Casos Especiales: ¿Cómo es tu Sistema? Los 3 ejemplos anteriores de procesos pueden ser suficientes para muchos de los proyectos que suelen desarrollarse. Pero, adicional a estos puedes agregar otro tipo de artefactos, dependiendo de las características del proyecto. Hazte preguntas como las siguientes: ¿Tu proyecto va a requerir control de documentos o productos? ¿Es un sistema distribuído? ¿Estás automatizando un proceso de negocio complejo? Dependiendo de estas condiciones es recomendable utilizar artefactos adicionales de UML que te darán una perspectiva diferente, pero necesaria, para comprender mejor y tomar decisiones apropiadas para la construcción de tu proyecto. A continuación se mencionan posibles artefactos de UML que podría convenir agregar en condiciones especiales. www.sg.com.mx

1. Sistemas de Control Para cierto tipo de sistemas es bastante recomendable agregar el diagrama de estados. Por ejemplo en aquellos sistemas en los que tienes que controlar y monitorear el estado por el que va un cierto documento o producto dentro del proceso de negocio que estás automatizando o para aquellos sistemas de control que automatizan dispositivos electrónicos, como un refrigerador, un elevador o un despachador automático de refrescos. 2. Sistemas Distribuidos Si tu sistema va a construirse de manera distribuida, es decir, parte de la funcionalidad va a correr en una máquina y parte en otra. O si estás pensando construir partes reutilizables, entonces te recomiendo que utilices el diagrama de componentes y el diagrama de despliegue estos permitirán especificar dónde repartirás cada “parte” del sistema. Estos diagramas corresponden a la disciplina de diseño. 3. Negocios Complejos Si tu proyecto va a desarrollarse para automatizar un proceso complejo de tu usuario, entonces te recomiendo que aproveches los diagramas de actividades. En un caso muy sofisticado puedes usar los diagramas de procesos de negocios del estándar BPMN, pero asegúrate de aprender bien ese nuevo estándar antes de decidir utilizarlo. Buscando lo Simple en la Complejidad UML ha ido evolucionando en algo que no necesariamente cumple, a decir de algunos, con uno de los objetivos originales de dicho estándar: el de mantener la simplicidad. Por lo tanto, es importante comprender que no necesariamente aplican todos los artefactos y elementos para tus proyectos para lograr la simplicidad en tu trabajo al utilizar esta notación. Este artículo no pretende de ninguna manera ser “La guía definitiva”, pero estoy seguro que a algunas personas les facilitará el trabajo a la hora de decidir respecto a la formalización de sus procesos de software, con respecto a la elección de los artefactos de dicho estándar. De hecho hay otros artefactos de UML que no están considerados aquí, por corresponder a los menos utilizados. Vale la pena notar que en este artículo ni siquiera estoy recomendando un ciclo de vida; ya sea de cascada, iterativo, o cualquier otro. En general, podrías utilizar cualquiera de los subconjuntos de artefactos mencionados independientemente del ciclo de vida que utilices. Espero que saques algún provecho de este artículo y recuerda que “mucho no necesariamente significa mejor”. Hasta la próxima y suerte con tus modelos. JUL-AGO 2007

45

// COLUMNA

/*TIERRA LIBRE*/

Lean Software Development Libera tus proyectos por Emilio Osorio

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

En los seminarios sobre métodos ágiles que realizo, típicamente pregunto lo siguiente a la audiencia: “Levante la mano por favor, aquella persona a la cual un diagrama de Gantt le haya sido la diferencia para sacar adelante un proyecto, o que para darle mantenimiento al software de alguien más haya utilizado documentación separada al mismo código, o tal vez aquel líder de proyecto que le haya funcionado asignar y controlar el avance de microtareas por cada miembro del equipo, para que así se comprometan más con una fecha de entrega. Sorprendentemente (o no tanto), hasta la fecha nadie ha levantado la mano. Si todas estas prácticas que son la quinta esencia de la administración de proyectos, y para las cuáles invertimos miles de pesos en herramientas y cursos no funcionan, entonces ¿por qué lo seguimos haciendo? Al parecer, pensamos que cuando algo no sale bien lo que necesitamos es una capa más de “control”, un proceso más definido y detallado que “obligue” a los programadores rebeldes, negligentes o apáticos, a tener “conformidad” con el proceso mágico que resolverá todos nuestros problemas. Anhelamos recetas secretas, pero en realidad lo que necesitamos es tan solo un conjunto sólido de principios y sentido común. ¿Como liberar a nuestros proyectos de balas de plata que no funcionan? Afortunados somos de tener Lean Software Development (LSD) a nuestro alcance; es libre, gratis y simplemente funciona. LSD fue desarrollado por Mary y Tom Poppendieck a partir de experiencias en 3M y Toyota, y se basa en aplicar al desarrollo de software los principios de “lean” que han hecho tan exitosas a estas empresas. Se le considera parte de los métodos ágiles, pero desde mi punto de vista está por encima de ellos, ya que LSD nos obliga a pensar, cuestionarnos y encontrar nuestras propias respuestas.

46

JUL-AGO 2007

LSD se basa en los siguientes 7 principios: 1. Eliminar el despilfarro. Es decir, evitar todo lo que no agregue valor al proyecto. ¿Qué es aquello que no agrega valor al proyecto? Sencillo, todo lo que el cliente no pidió, pero en lo que invertimos tiempo. En esta categoría entra funcionalidad adicional a la que pidió el usuario, o especificación de requerimientos demasiado detallada en etapas tempranas del ciclo de vida. Aprendamos a ver éstas cosas como un despilfarro. 2. Ampliar el aprendizaje. Debemos aceptar que nunca se sabrá exactamente lo que se tiene que construir al principio del proyecto. Así que cualquier tiempo que ocupemos tratando de hacer que el cliente nos “firme” el requerimiento, rompe con el principio anterior. Ampliar el aprendizaje significa aceptar que el desarrollo es un proceso de aprendizaje, por lo tanto tenemos que repetirlo muchas veces para aprender. Solución: Muchas iteraciones cortas, tan cortas como haga sentido. 3. Retrasar los compromisos. Cada vez que aceptamos trabajar en un proyecto que tiene fecha de entrega pero no tiene requerimientos fijos es como si decidiéramos casarnos con alguien que conocimos hoy mismo. Si no lo hacemos en la vida real, entonces ¿por qué hacerlo en nuestro trabajo? Las iteraciones cortas ayudan a comprometernos con tan solo lo que podemos estimar bien. 4. Liberar rápido. Todos hacemos desarrollo por iteraciones, ¿verdad? Bueno, tener iteraciones no es lo mismo que liberar rápido. Liberar rápido significa que si te piden un sistema que facture, liberes “a producción” la funcionalidad para facturar lo antes posible, aunque no se haya terminado el resto del sistema. Empresas como Google o Yahoo entienden esto y lo aplican en sus desarrollos. Libera funcionalidades, no sistemas. 5. Facultar al equipo. ¿Qué es lo mejor que puede hacer un líder de proyecto? No estorbar. Tenemos que confiar en que las personas pueden ponerse de acuerdo, trabajar en equipo y en esencia autodirigirse. Si, cometerán erro-

res. Pero si liberan rápido y tienen iteraciones cortas, entonces sus errores no nos costarán caro, y sobre todo se ampliará el aprendizaje. Si no pueden resolverlos por ellos mismos, entonces debemos evaluar si tenemos el equipo correcto. El trabajo en equipo ES el desarrollo de software. 6. Construir integridad intrínseca: En Japón, las mismas máquinas que producen las piezas para manufactura, prueban las piezas que producen, las miden y desechan las que no cumplen con los requisitos mínimos. No hay una inspección o control de calidad separada de la producción. Nuestros equipos nunca podrán alcanzar madurez, en un esquema donde el responsable de la calidad sea otro grupo separado del de desarrollo. 7. Pensar en el todo. “O todos coludos, o todos rabones” decían nuestros abuelos. Al parecer, antes se entendía mucho cómo hacer que una organización o una familia funcionara como un equipo. Abandonemos el modelo de programador estrella, lo único que producimos son divas y gangsters. En un equipo todos ganan y todos pierden, así que olvidémonos de las mediciones de desempeño individuales. Lo único que esto provoca es que los que salgan bien se busquen un trabajo donde les paguen más, y los que no salgan tan bien, harán lo mismo. Creemos equipos que compartan logros y fracasos y reduciremos la rotación de personal. ¿Por que hablo con tanta seguridad? Sencillo, yo mismo he pasado de creer en cosas que no funcionan y sufrir en mi trabajo, a experimentar los frutos de LSD en mi propia práctica. Finalmente, les recomiendo que busquen en Internet a Mary Poppiendick y agradecerán como yo, todo el material gratuito que tiene a nuestra disposición para ayudarnos a empezar. Regalar sus libros a nuestros directores de sistemas probablemente serán los pesos mejor invertidos en mucho tiempo en nuestras carreras. —Emilio Osorio www.sg.com.mx

www.sg.com.mx

JUL-AGO 2007

// FUNDAMENTOS

Los Estándares de TI

¿Qué ofrecen a la Industria Mexicana de Software? Por Juan Manuel Hernández Jiménez

Antecedentes A principios de 1994, al entrar en vigor el TLC con Estados Unidos y Canadá, México se incorporó de manera definitiva al proceso de globalización de las economías que rigen al mundo actual, las exigencias en materia de calidad y productividad se volvieron más importantes y apremiantes. Siendo la normalización un reflejo del avance industrial de un país, es imposible basarla en los principios rígidos establecidos superficialmente que le resten la flexibilidad necesaria para adaptarse a las condiciones de una determinada época, al avance tecnológico o a la idiosincrasia de un país, así como a su propio desarrollo. La experiencia ha permitido establecer una serie de principios generales que aplicados con el rigor necesario no significan un obstáculo, sino una forma para garantizar el éxito de la aplicación en el contexto que se esté normalizando. En este artículo plantearemos la importancia de contar con estándares, y describiremos los pasos necesarios para generar una norma.

Importancia de los estándares La normalización o creación de estándares, por ejemplo para las Tecnologías de la Información, es una disciplina que trata sobre el establecimiento, aplicación y adecuación de reglas destinadas a conseguir y mantener un orden dentro del campo de la producción de software. El resultado de la normalización surge de un balance técnico y socioeconómico propio de una etapa, por lo cual no se considera estático. Es una disciplina con base técnica y científica que permite formular normas cuyo ámbito no se limita únicamente al establecimiento de reglas, sino que comprende también su aplicación. De tal suerte que al generarse un nuevo estándar (norma mexicana- NMX) se dice que se está “haciendo industria” porque en ese momento se generan los lineamientos

mínimos que determinado producto o servicio deben de cubrir para que se diga que se esta cumpliendo con lo estipulado por la misma industria. Al día de hoy, existen 38 estándares ó normas mexicanas vigentes en el ámbito de las TI, los cuales definen las mejores prácticas aceptadas para la mayoría de las áreas directamente relacionadas con la terminología, producción, calidad y seguridad del software.

Proceso de generación de una norma Una norma es un documento establecido por consenso y aprobado por un organismo reconocido, que suministra, para uso común y repetido, reglas, directrices o características para las actividades o sus resultados, encaminados al logro del grado óptimo de orden en un contexto dado. Para generar una norma, se lleva a cabo un proceso basado en la Ley Federal sobre Metrología y Normalización, que resumiremos en 7 pasos, pero no por esto se le debe restar importancia y cierto grado de dificultad en los temas de especialización que ahí se tratan: 1. El organismo normalizador forma el Comité Técnico especializado en la materia. 2. Se generan las invitaciones a los posibles participantes indicándoles los temas a tratar. Es importante mencionar que se busca la participación de representantes de diferentes entidades como: industria (empresas privadas), universidades (v.gr. UNAM, IPN), gobierno (v.gr. DGN, SE, SHCP), cámaras de la industria (v.gr. CANIETI), y asociaciones (v.gr. AMITI). 3. Una vez programadas las reuniones con los diferentes representantes, incluyendo a toda aquella persona que se considere necesaria en la elaboración del estándar, se procede a realizar las reuniones de trabajo necesarias, hasta que el estándar esté concensuado entre los sectores involucrados y quede formalizado poniendo al margen la rubrica de todos los participantes. Por ejemplo, para

la generación de la NMX-I-059, se tomaron como base los modelos MoProSoft y EvalProSoft, se estructuraon en formato de norma, y se concensuaron con los interesados. 4. El organismo envía el proyecto del estándar a publicar en el DOF mediante un “Aviso de consulta pública” por un período de 60 días naturales. 5. Si dentro de éste período hay algún comentario, se le envía formalmente al organismo, quien lo somete a la consideración del Comité Técnico para su aprobación. 6. Si no hay comentarios, una vez transcurridos los 60 días naturales, el organismo envía 2 juegos impresos de la norma a la Dirección General de Normas (DGN), dependiente de la Secretaría de Economía. 7. La DGN publica entonces la “Declaratoria de Vigencia” y 60 días naturales posteriores, entra en vigencia, naciendo formalmente una nueva norma mexicana.

¿Cómo se eligen los temas de Normalización? El organismo normalizador invita a los diferentes sectores (industria, gobierno, etc.) a proponer temas de normalización, y las propuestas recibidas son incluidas en el Programa Nacional de Normalización, el cual se somete a la consideración de la Comisión Nacional de Normalización, a fin de obtener su aprobación. Una vez aprobado, se publica en el Diario Oficial de la Federación (DOF) y se procede a programar las reuniones de trabajo del Comité Técnico de Normalización.

Conclusión Las normas se deben basar en los resultados consolidados de la ciencia, la tecnología y la experiencia, y sus objetivos deben ser los beneficios óptimos de la comunidad. Es fundamental para la industria de TI, generar estándares y seguir normas, que le permitan “hacer industria”.

Ing. Juan Manuel Hernández Jiménez actualmente es el Gerente de la División de Verificación de Software de NYCE. Sus responsabilidades incluyen obtener y mantener la acreditación de NYCE como organismo de verificación de procesos y de certificación de producto de software con base en los estándares vigentes actuales, administrar las unidades de verificación y certificación, así como participar activamente en los comités técnicos de normalización en los procesos de desarrollo de nuevos estándares mexicanos de TI.

48

JUL-AGO 2007

www.sg.com.mx

www.sg.com.mx

JUL-AGO 2007

// INFRAESTRUCTURA

Administración de la Capacidad Planeando la Infraestructura Por Ariel García

Hoy en día, todas las áreas responsables de la administración de TI tienen el reto de incrementar su productividad y eficiencia, a la par de reducir sus costos de operación e inversión. El proceso de Administración de la Capacidad es uno de varios procesos de ITIL, que define estándares para lograr la eficiencia y optimización de costos en la entrega de servicios de TI.

Un poco de teoría Por definición, el proceso de la administración de la capacidad tiene como objetivo asegurar el óptimo uso de los recursos de TI, de tal forma que se cumplan los niveles de rendimiento acordados con los usuarios a un costo justificado. Además, debe proporcionar información de los recursos actuales y planeados, así como la utilización de los componentes. La administración de la capacidad permite a la organización decidir acerca de cuáles componentes debe actualizar, cuándo hacerlo y el costo involucrado. Dentro del proceso de la administración de la capacidad podemos encontrar las siguientes actividades: • Administración de la demanda: se enfoca en el control y la influencia de la demanda de servicios de TI. • Dimensionamiento de la solución: generalmente se inicia con un nuevo requerimiento de negocio, o un cambio considerable en la infraestructura actual. Dura hasta que el nuevo requerimiento o cambio entra en operación. • Planeación de la capacidad: documenta los niveles reales de utilización de los componentes de la infraestructura y el desempeño de los servicios de TI. • Almacenamiento de la base de datos de capacidad: documenta la información de capacidad del negocio. • Modelado: se realiza el modelado de la infraestructura de TI para predecir su comportamiento bajo cambios en su volumen de trabajo. • Actividades iterativas: análisis, ajuste, implementación y monitoreo. El monitoreo se debe establecer en todos los componentes y para cada uno de los servicios. Los datos deben ser analizados de tal forma que puedan compararse contra umbrales preestablecidos. El resultado de los análisis generará reportes y ajustes a ser implementados. Estos cambios después serán monitoreados. Para ejecutar tales actividades, el proceso de la administración de la capacidad se subdivide en tres subprocesos: • Administración de la capacidad del negocio (ACN): tiene un enfoque estratégico y consiste en asegurar la consideración, planeación e implementación en un tiempo razonable de los futuros re-

50

JUL-AGO 2007

querimientos de servicio por parte del negocio. • Administración de la capacidad de servicio (ACS): su enfoque es táctico, y se ocupa de la administración de la operación real de los servicios de TI acorde a los niveles de servicios acordados con los usuarios. • Administración de la capacidad de los recursos (ACR): su enfoque es operacional y consiste en la administración de los componentes individuales de la infraestructura de TI. Las salidas del proceso de administración de la capacidad son: un plan de capacidad, líneas base, perfiles, reportes de capacidad, umbrales y alarmas tanto para servicios como componentes. También se realizan recomendaciones en acuerdos de servicios, cambios proactivos, mejoras a servicios y componentes, y reportes de auditoria, entre otros. El plan de capacidad es posiblemente el más importante de estos productos de salida. Dentro de su contenido destaca el resumen de los servicios, capacidades y costos de la infraestructura. El plan debe indicar claramente cualquier suposición efectuada, así como cualquier recomendación cuantificada en términos de recursos requeridos, costos, beneficios e impacto.

Aterrizándolo un poco Ya echamos un vistazo teórico a la estructura del proceso de administración de capacidad. Ahora vamos a aterrizarlo en ejemplo sencillo de infraestructura de servidores. Como sabemos, es muy común para el área de TI administrar el desempeño de sus servicios de forma reaccionaria, analizando y resolviendo los problemas conforme los usuarios los reportan. A través de la ejecución del proceso de administración de la capacidad, lo que nosotros buscamos es llegar al escenario donde los administradores del sistema sean capaces de evitar cuellos de botella en el desempeño de los servicios y, utilizando las herramientas adecuadas, predecir cómo los servidores deberán configurarse para soportar cargas adicionales de trabajo en el futuro. Los pasos que llevaremos a cabo para esto son los siguientes: 1. Determinar los niveles de servicio El primer paso en el proceso es categorizar el trabajo de los sistemas y cuantificar las expectativas de los usuarios en cómo se debe realizar este trabajo. Para poder realizarlo es necesario entender el concepto de cargas de trabajo. Con este concepto se busca visualizar el desempeño de un sistema en términos de negocio, en lugar de términos técnicos. Antes de definir los niveles de servicio, es necesario determinar las métricas para medir el trabajo a soportar. Una vez definidas, se establecen los requerimientos de niveles de servicio, en otras palabras: el desempeño prometido por el área de TI.

www.sg.com.mx

Cargas de trabajo. Desde la perspectiva de la administración de la capacidad, un sistema de cómputo procesa cargas de trabajo y entrega un servicio a los usuarios. Como primeros pasos del proceso de planeación de la capacidad, se deben identificar estas cargas de trabajo y en base a ello, definir un servicio satisfactorio desde la perspectiva del usuario. Unidades de trabajo. A fin de medir las cargas de trabajo, es necesario establecer unidades de trabajo. Ésta es una métrica de la cantidad de trabajo realizado, contrario a la cantidad de recursos necesarios para completar el trabajo. En este ejemplo en específico, los recursos necesarios son procesadores, almacenamiento en disco, memoria, ancho de banda de red, etcétera. La medición de los recursos antes mencionados es importante, pero no sirven para cuantificar las cargas de trabajo o para definir las unidades de trabajo. Por ejemplo: para una carga de trabajo en línea, una unidad de trabajo puede ser una transacción. Para una carga de trabajo interactiva o por batch, la unidad de trabajo puede llegar a ser un proceso. Establecimiento de niveles de servicio. Una vez definidas las unidades de trabajo, procedemos a establecer un acuerdo de nivel de servicio. Dicho acuerdo se da entre el área de TI y el área usuaria para definir el nivel aceptable del servicio. El nivel aceptable se define típicamente desde la perspectiva del usuario, en términos de tiempo o unidades de trabajo. Idealmente, los niveles de servicio deberán ser determinados por los requerimientos del negocio. En la vida real, comúnmente se definen por experiencias del pasado, por ejemplo: “que el tiempo de respuesta del servicio sea como mínimo al tiempo registrado actualmente, aun cuando se llegue a incrementar la carga de trabajo”. En la medida que se pueda predecir o conocer la carga de trabajo, se podrá mantener el nivel de servicio requerido. Para poder definir los niveles de servicio, es necesario conocer la capacidad de respuesta de la infraestructura actual. 2. Análisis de la capacidad actual Una vez determinados los niveles de servicio, lo siguiente es analizar la capacidad actual de los sistemas para determinar si están cumpliendo con las expectativas de los usuarios, y en base a esto, hacer recomendaciones. Los pasos para realizar el análisis de la capacidad actual son: • Realizar una comparación de las mediciones de los elementos referenciados en los acuerdos de niveles de servicio, contra los objetivos especificados. Esto proveerá información básica para definir

www.sg.com.mx

si el sistema es adecuado para soportar la capacidad requerida. Se establecen líneas base, umbrales y alarmas. • Ejecutar mediciones en los recursos del sistema (procesadores, memoria, discos, red, etcétera). El análisis de estas mediciones permitirá detectar recursos sobrecargados que podrían provocar problemas en el presente o futuro. • Identificar los recursos demandados para cada una de las cargas de trabajo existentes. Esto permite detectar y enfocar la atención en las cargas de trabajo que realizan la mayor demanda de recursos del sistema. • Una vez identificadas las cargas de trabajo, se debe realizar un análisis de los tiempos de respuesta de cada uno de sus componentes, a fin de determinar cuáles son los recursos con mayor impacto en el tiempo de respuesta. 3. Planeación para el futuro Una pregunta muy común es: ¿cómo asegurar que el próximo año los sistemas no se encuentren sobrecargados y el presupuesto del área por los cielos? La mejor forma de mitigar tal riesgo, es con un plan de capacidad basado en pronósticos de procesamiento requerido. Lo que debemos hacer es obtener un pronóstico de los requerimientos del negocio para con los sistemas de TI en el futuro. Esta información se debe registrar en forma de incrementos de cargas de trabajo, que a su vez se traducirá en una demanda de mayores recursos del sistema. En base a modelados o prototipos de estas nuevas cargas, se definirá la configuración de la infraestructura necesaria para soportarlas.

Conclusión A través de la ejecución de los pasos anteriores, es posible realizar un plan de capacidad para soportar los niveles de servicios requeridos por el negocio en el presente y el futuro. Se contará con la información necesaria para realizar un presupuesto fundamentado con requerimientos del negocio y garantizar un servicio adecuado a los usuarios, sin necesidad de aprovisionar de más. Resultaría imposible poder entregar en este artículo un nivel más detallado del trabajo, actividades y procesos involucrados en la administración de la capacidad. El objetivo simplemente es resaltar la utilidad de la implementación de dichos procesos. En América Latina existe una enorme área de oportunidad para la adopción de estas prácticas, que se traduciría en empresas más competitivas con mayor valor agregado para sus clientes.

JUL-AGO 2007

51

////TECNOLOGÍA TECNOLOGÍA

/* GADGETS */

SaWestern Digital

Caviar SE16 750GB Pensado especialmente para computadoras de escritorio que utilizan aplicaciones con muchos datos, computación de alto desempeño y sistemas multimedia, el Caviar es una unidad de disco duro interno de gran capacidad que ofrece un índice de transferencia de 3GB por segundo, cache de 16MB y cola de instrucciones nativas. Incluye la tecnología propietaria de Western Digital, SecurePak que estaciona las cabezas grabadoras fuera de la superficie del disco mientras gira hacia arriba y hacia abajo cuando la unidad no está operando, de tal manera que se reduce el desgaste. Por otra parte, con StableTrac se minimiza la vibración inducida por el sistema y estabiliza el plato para un mejor rastreo durante operaciones de lectura y escritura. Además ahorra en consumo de energía.

Samsung

B-jack i321n

Black Jack es un smartphone lanzado recientemente bajo el concepto de “oficina móvil”, que cuenta con Windows Mobile 5.0 para ofrecer al usuario potentes aplicaciones de negocios, así como acceso a diversas cuentas de correo electrónico a través de Outlook Mobile. Soporta una extensa variedad de formatos multimedia, funciones de entretenimiento y comunicación instantánea permitiendo reproducir y almacenar fotografías, música y videos gracias al Windows Media Player. Entre sus características destacan su diseño ultradelagado; cámara fotográfica de 1.3 megapixeles, puerto infrarrojo, ranura para memoria, visores de archivos adjuntos de e-mail (.doc, .xls, .ppt, .pdf .wmf ); agenda, alarma, altavoz integrado, aplicaciones Java; conexión inalámbrica Bluetooth con gran capacidad de transmisión y recepción de datos que permite conectarse con otros dispositivos tales como PDA o computadoras portátiles que se encuentren a una distancia máxima de 10 metros; y memoria interna de 64MB.

Kilo

Taza personalizada Definitivamente este no es un dispositivo de alta tecnología, pero no por eso es menos útil. Esta taza está diseñada para que nadie en la oficina te la robe, ya que queda personalizada con tu nombre, apodo o gráfico de tu preferencia. Solo necesitas pintar con un plumón indeleble sobre el recuadro blanco. Esta taza es invención de uno de los diseñadores de SG, y puedes adquirir la tuya en www.kilo.com.mx

Viewsonic

PJ258D Incorporando la innovadora tecnología ViewDock hacia otra línea de productos, nace el primer proyector DLP multifuncional de alta definición con base para iPod: el PJ258D ofrece nuevas opciones de entretenimiento gracias a la opción de portabilidad de exhibición para llevar contenidos visuales sin necesidad de una computadora. Pesa alrededor de 2 kilos; su diseño es versátil y fácil de usar. La estación base conecta al iPod directamente al proyector para disfrutar de su contenido, mientras recarga la batería. Este equipo además, soporta otros medios digitales a través de múltiples opciones de conectividad como video VGA, haciéndolo compatible con PCs, reproductores de DVD y consolas de videojuegos. Tiene resolución XGA de 1024X768, 2 mil lúmenes y una proporción de contraste 2000:1, para una reproducción clara de fotografías y video sin importar el ambiente.

52

JUL-AGO 2007

www.sg.com.mx

SanDisk

MicroSDCH

Las tarjetas de memoria flash no sólo son cada vez más pequeñas, sino también más poderosas y ahora son perfectas para dispositivos móviles tales como teléfonos celulares. Con capacidades de 6GB y 8GB las microSDHC son ideales para todos los gadgets con innumerables funciones multimedia que integran teléfono, reproductor de música y video, cámaras digitales, entre otros; ya que permiten almacenar, por ejemplo en la de 8GB alrededor de 2 mil canciones, 5 mil fotos en alta resolución o hasta cinco horas de video MPEG4. Son compatibles con cualquier dispositivo que cuente con ranura para tarjeta micro.

IBM

Greenpeace

IBM lanzó el microprocesador de doble core POWER 6, que con sus 4.7 GHz duplica la velocidad de su predecesor, el POWER 5, pero utilizando prácticamente la misma cantidad de energía.

Greenpeace genera un reporte trimestral donde califica a los principales proveedores de computadoras y electrónicos en base a sus políticas y prácticas para eliminar químicos dañinos, así como hacerse responsable de sus productos una vez que termina su vida útil. En la edición más reciente de este ranking (junio 2007), Nokia fue la compañía considerada “más verde”, mientras que Sony tuvo el deshonroso último lugar.

Power6

Green Electronics Guide

La nueva línea de servidores IBM System p 570 hace uso de l POWER 6, y hasta el momento ha logrado conseguir 25 diferentes records de evaluación de desempeño, además de ser el primer sistema que obtiene el primer lugar en las categorías de: capacidad de procesamiento de transacciones, tasa de transferencia de cálculo con enteros, tasa de transferencia de cálculos con punto flotante, y rendimiento de Java en operaciones por segundo

Logitech

X-530 Es común que las bocinas integradas de una computadora no brinden la calidad de sonido que el usuario desea, por tal razón Logitech ofrece el sistema X-530 que se puede conectar, además, a cualquier reproductor de CD, DVD, MP3; PlayStation o Xbox. Entre sus características destacan sus 70 watts de potencia www.sg.com.mx

totales, un moderno subwoofer que regula automáticamente los sonidos graves sin distorsión al producir más movimiento de aire y lograr mayor profundidad. Cinco bocinas satélite de montaje giratorio para pared con tecnología FDD2 que elimina irregularidades, brindando nitidez, uniformidad y balance perfecto de audio. JUL-AGO 2007

53

// REFERENCIA

Business Service Management ¿Qué es y cómo llegar? Por Ricardo Rodríguez Bernal

En su búsqueda por mejorar la calidad de los servicios que proveen al negocio, las organizaciones de TI están cambiando su enfoque para poder reflejar un mayor valor al negocio. Una de las estrategias más recurridas para lograr esto, es la de Business Service Management (BSM). Forrester Research define BSM como una estrategia para “alinear la infraestructura de TI, con servicios de TI alineados al negocio”. BSM está basado en el concepto de una vista compartida a través de todas las áreas de TI que permita saber cómo los recursos de TI soportan directamente al negocio. Existen diversos proveedores de software y servicios BSM, y ésta es un área que está mostrando mucho crecimiento en los últimos meses, ya que a fin de cuentas está fuertemente relacionada con prácticas como ITIL y COBIT. Existe una gran diversidad de proveedores de software y servicios para BSM, y cada uno sugiere una estrategia o “roadmap” para implementarlo. BMC Software sugiere una implementación de BSM basada en 8 disciplinas denominadas “Rutas de Valor”. Evaluando la madurez que tiene la organización en cada una de estas 8 disciplinas, se puede construir un mapa que ayude a reforzar las necesidades de TI y del negocio. A continuación explico estas rutas de valor y los problemas con los que lidia cada una.

Gestión y Descubrimiento de Activos Los activos de TI representan una fuerte inversión, así como costos de operación recurrentes derivados de soporte y renovación de licencias. Uno de los requerimientos principales de la alineación de TI con el negocio consiste en el rastreo y gestión de los activos de TI para lograr eficiencias en costos y demostrar que estén generando un retorno de inversión. La gestión de activos permite evaluar y reasignar recursos de TI de forma eficiente en base a cambios en las necesidades del negocio.

Gestión y Aprovisionamiento de Capacidad La gestión de la capacidad se encarga de asegurar que las aplicaciones existentes cumplan con los requerimientos de los usuarios en términos de tiempos de respuesta y volumen de transacciones soportadas. El aprovisionamiento de capacidad se preocupa por empatar el uso con las necesidades de recursos de TI de forma que no exista desperdicio.

Gestión de la Configuración y el Cambio Los cambios no controlados o no probados adecuadamente son una de las principales causas de fallas y “caídas” en sistemas de producción. Una buena gestión del cambio y configuración contribuye a reducir los costos de soporte significativamente, y disminuye la frecuencia de fallas en sistemas de producción.

Gestión de la Identidad El principal valor de la gestión de identidad es asegurar el uso autorizado y protegido de los activos y procesos de negocio. Esta seguridad se basa en la capacidad de saber quién es un usuario en particular, a que activos de TI tiene acceso, y qué nivel de uso puede tener.

Gestión de Incidentes y Problemas Los incidentes de TI tales como fallas en sistemas de misión crítica tienen un fuerte impacto en el negocio. Una gestión efectiva de los incidentes maneja a estos de forma preventiva, más que correctiva, implementando mecanismos para detectar y resolver anormalidades, antes de que se conviertan en un problema que impacte el negocio.

Gestión de Infraestructura y Aplicaciones Se preocupa por administrar y controlar todas las aplicaciones y componentes de infraestructura de la organización desde una perspectiva de servicios de negocio. De esta forma, asegura que los recursos estén enfocados en la optimización del ren-

dimiento y la disponibilidad de los actuales servicios de negocio.

Gestión del Impacto en Servicios Refleja el impacto en los servicios de negocio provocado por las condiciones o cambios de estatus en la infraestructura de TI. Se enfoca en conectar el estatus de un servicio de negocio con el estatus de los recursos de TI relacionados. Esto permite mostrar claramente el impacto al negocio que tiene algún evento de TI.

Gestión de los Niveles de Servicio Un aspecto fundamental de la operación del negocio es la capacidad de establecer objetivos de nivel de servicio y cumplir dichos acuerdos. Desde la perspectiva del negocio, los objetivos de nivel de servicio son, como su nombre lo dice, una medida de qué tantas operaciones de negocio se pueden realizar en determinado tiempo.

Referencias • Tim Grieser. “Implementing Business Service Management: BMC Software’s Routes to Value Approach”. IDC, Enero 2005. • Peter O’Neill. “BSM is Coming of Age: Time to Define What it is”. Forrester Research, Febrero 2006.

Conclusión Implementando BSM, las organizaciones de TI pueden entender las relaciones críticas entre el negocio y los servicios de TI, así como detectar los cambios y darle prioridad a la administración de los componentes de la infraestructura de TI basados en las métricas y requerimientos del negocio. Entender estas relaciones, y darle la prioridad adecuada a distintas situaciones, puede ser de gran ayuda al negocio para operar de forma más efectiva, reduciendo costos e incrementando la satisfacción del cliente.

Ricardo Rodríguez Bernal es Arquitecto de Soluciones de Business Service Management en BMC Software México

54

JUL-AGO 2007

www.sg.com.mx

INDEX

DIRECTORIO

Anunciante



Avantare CIAPEM e-Quallity Gartner IDC Innevo Intersoftware Itera Milestone Consulting NYCE SafeNet SG’07

Páginas

Sitio

13 9 39 47 49 35 F3 41 F4 31 11 F2-1

www.avantare.com www.ciapem.veracruz.gob.mx www.e-quallity.net www.gartner.com www.idc-eventos.com www.innevo.com www.intersoftware.com.mx www.itera.com.mx www.milestone.com.mx www.nyce.com.mx www.safenet-inc.com www.sg.com.mx/sg07

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

www.sg.com.mx

JUL-AGO 2007

55

////BIBLIOTECA TECNOLOGÍA

Code Quality: The Open Source Perspective Diomidis Spinellis

01

Addison Wesley, 2006 En un mundo donde la mayoría de las discusiones sobre calidad de software están enfocadas en administración y otros temas de alto nivel, Diomidis Spinellis nos invita a analizar este tema partiendo de una perspectiva diferente, calidad del código. En lugar de explicar cómo resolver proyectos complejos, este libro describe cómo juzgar la calidad de lo que estás viendo: código. Basado en el estándar de calidad ISO 9126, Spinellis descompone su propuesta en las categorías: confiabilidad, seguridad, desempeño de tiempo, desempeño de espacio, portabilidad, y mantenimiento. Cada una obtiene un capítulo, pero lo más peculiar de este libro, es que cada capítulo muestra docenas de ejemplos basados en código fuente de conocidos proyectos de software libre, tal como Perl, ACE, y NetBSD, donde cada ejemplo confirma su punto de una manera clara e irrefutable. El libro está saturado de experiencia y observación detallada. Diomidis es un profesor asociado en la Universidad de Atenas,

quien ha trabajado directa o indirectamente con los conceptos de este libro desde 1985, escribiendo y manteniendo mas de 250,000 líneas de código para numerosos proyectos comerciales y de software libre. Code Quality es la continuación al libro previo escrito por Spinellis titulado “Code Reader”, que está enfocado en la importancia que tiene el saber leer código, para aprender a programar con calidad. Code Quality debería ser una lectura requerida para todos los cursos de programación, y debería ser considerado una biblia no solo para los programadores, sino para todos los involucrados en análisis, mantenimiento y control de cambios del software.

Refactoring Databases: Evolutionary Database Design Scott W. Ambler y Pramod J. Sadalage

02

Addison Wesley Professional, 2006 Refactorizar una base de datos consiste en realizar pequeños cambios al esquema de una base de datos existente (y posiblemente en producción) para mejorar su diseño, pero manteniendo su semántica. El proceso de refactorización se enfoca en mejorar de forma evolutiva un esquema de datos de tal forma que pueda soportar con mayor facilidad nuevas necesidades de los clientes, incorporar ajustes realizados a las aplicaciones, y corregir problemas de diseño existentes en bases de datos legadas. Este libro enseña diferentes técnicas para poder realizar cambios a las base de datos de forma ágil. Refactoring Databases está lleno de consejos prácticos sobre cómo mejorar el diseño de la base de datos, desde que se está creando, hasta cómo manejar las transiciones y migraciones. El contenido revela la experiencia de los autores en el tema de desarrollo ágil, demostrando la premisa fundamental de este libro: “los datos y las bases de datos deben evolucionar en la misma manera que el código evoluciona - de manera incremental”. Refactoring Databases no solo se enfoca en aspectos técnicos o tecnológicos, sino que también aborda el tema de cómo incorporar

56

JUL-AGO 2007

la refactorización de datos en el proceso de desarrollo y mantenimiento de software. Adicionalmente, también dedica atención a analizar aspectos culturales, que de acuerdo a los autores serán los más difíciles de superar. La refactorización es un concepto crucial en la práctica moderna de desarrollo exitoso, y las bases de datos particularmente necesitan de “agilidad” y “administración evolutiva”, fundamentos de la refactorización. Tanto gerentes como administradores de bases de datos necesitan familiarizarse con este concepto, y aquí es donde Ambler siempre ha sobresalido: en su habilidad para comunicar abstracciones arquitectónicas que sean entendidas tanto por los tomadores de decisiones, como por los programadores.

www.softwareguru.com.mx www.sg.com.mx

Año 03 No. 4

www.sg.com.mx

SG SOFTWARE GURU CONOCIMIENTO EN PRÁCTICA

Julio-Agosto 2007