SG16 (Julio-Agosto 2007)

Software Guru CONOCIMIENTO EN PRÁCTICA

www

.sg.

com

.mx

SG

SO

FT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

J

ulio

-Ago

sto

200

7

Año 03 No. 4 • Julio-Agosto 2007 • www.sg.com.mx

[ Tutorial ] Apache Lucene

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

Año

03

No.

4

México, $65.00 WEB 2.0El poder de la colaboración

[ ENTREVISTA ]

Scott Ambler La Evolución de Ágil

• Mejora de Procesos • Mantenimiento • Diseño orientado a objetos

JUL-AGO 2007 www.sg.com.mx

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

Arte y DiseñoDavid GutiérrezOscar 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.

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

FotografíaLectores SG

Ventas Claudia Perea

Natalia Sánchez

Marketing y RPDafne Vidal

Circulación y Subscripciones Daniel Velázquez

AdministraciónAraceli Torres

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

directorio

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 since-ramente nos disculpamos por contribuir a ello. Es solo que consideramos que real-mente 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 nota-ble de Web 2.0 no es la tecnología, sino la participación. Esto es lo que realmen-te 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 resulta-dos. 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 en-víen fotografías personales, y obtener tan

buena respuesta. Muchas gracias. Espe-ramos que les haya gustado el resultado, y que logren encontrarse por ahí.

Esta edición de SG es una de las más den-sas 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 sen-tir esa energía. Sabemos que ustedes tam-bién están muy interesados en poder asis-tir para aprender y compartir experiencias con sus colegas. Les garantizamos que estamos haciendo todo para que esta edi-ción salga todavía mejor que el año pasa-do. La visión sigue siendo la misma: tener en México un congreso de clase mundial para profesionistas de software.

— Equipo Editorial

Editorial

// CONTENIDO

02

JUL-AGO 2007www.sg.com.mx

Columnas

Tejiendo Nuestra Red 06por Hanna Oktaba

Mejora Continua 08por Luis Cuellar

Cátedra y Más 30por Raul Trejo

Tendencias en Software 43por Luis Daniel Soto

Tierra Libre 46 por Emilio Osorio

EntrevistaScott Ambler La Evolución de Ágil

14

Productos

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

Prácticas

MANTENIMIENTO 32Mantenimiento de SoftwareJosé M. Esquivel hace un repazo sobre la impor-tancia del mantenimiento de software, y algunas mejores prácticas de esta disciplina.

ADMINISTRACIÓN DE PROYECTOS 34Análisis de Puntos Función, parte 3Finalizamos este caso de estudio, donde apren-dimos a aplicar la técnica de análisis de puntos función a un caso real.

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

DISEÑO 40El Mariachi Orientado a ObjetosCarlos Ordoñez adopta un enfoque divertido para explicar un tema bastante complicado: la incor-poración de patrones para hacer más flexible y robusto un diseño orientado a objetos.

EN PORTADA

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

18contenido jul-ago 2007

03

// CONTENIDO

En Cada Número

NOTICIAS Y EVENTOS 04 FUNDAMENTOS 48

INFRAESTRUCTURA 50 BIBLIOTECA 56


// NOTICIAS

04

SUN Tech Days 2007La gira mundial Sun Tech Days 2007 realizó su visi-ta 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 in-cluido 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 reali-zó 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 oportuni-dad 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 Stra-tegic Innovation Forum, uno de los eventos más im-portantes de IBM en el 2007, donde acudieron clien-tes 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, go-bernabilidad, 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 2007Los días 13 al 15 de junio, hospedada en la Universidad Vera-cruzana, 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: mo-delos 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 ac-tualidad, 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 involu-crados pongamos nuestro granito de arena.Para mayor información visita: www.aniei.org.mx


// EVENTOS

05

16 al 18 de Julio 2007CIISA 2007Guadalajara, JaliscoInfo: www.ciisa.gda.itesm.mxe-mail: [email protected]

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

26 de Julio 2007El Director de Proyectos y el Analista de Negocios Ciclo de conferencias, PMI Capítulo México y REPs Cd. de México Info: www.pmichapters-mexico.org/mexicoe-mail: [email protected]

23 de Agosto 2007Estrategia para una PMO y Equipos VirtualesCiclo de conferencias, PMI Capítulo México y REPsCd. de México Info: www.pmichapters-mexico.org/mexicoe-mail: [email protected]

AMITI elige nuevo Consejo DirectivoEl 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 rati-ficados, 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 aprove-chamiento de las TIs.

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

Empresas recientemente evaluadas en CMMI y MoProSoft:

Empresa Evaluación Apoyado por:Computación XXI MoProSoft 1 – nov 2006 SIE Center*Praxis CMMI 4 – ene 2007 América XXIMedisist CMMI 2 – feb 2007 SIE Center*ST CMMI 2 - feb 2007 SIE Center*Novutek CMMI 3 – may 2007 IteraMexware CMMI 3 – jun 2007 IteraEISEI CMMI 2 – jul 2007 Innevo

*Ahora ESI Center

Congreso ANADIC 2007 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 go-bernadores y diputados. El evento estuvo lleno de dis-tintas actividades como: foros, reuniones de trabajo, presentaciones de productos, talleres, capacitación y certificaciones.

27 y 28 de Agosto 2007IDC 3a. Cumbre de Gobierno y Tecnología Centro Banamex, Cd. de MéxicoInfo: www.idc-eventos.come-mail: [email protected]

30 y 31 de Agosto 2007Agile Project Management: Innovation in Action Strategic IT Training Cycle, Cutter Consortium30 de Agosto - Hotel Camino Real, Monterrey, N.L.31 de Agosto - Hotel JW Marriott, Cd. de MéxicoInfo: www.cutter.com.mx/ciclo2007Tel: +52 (81) 2282 6266 y +52 (55) 5336 0418e-mail: [email protected]


/*TEJIENDO NUESTRA RED*/

06

Del 21 al 25 de mayo de 2007 Moscú fue la sede de la se-sió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 MoPro-Soft 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 Delega-ció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 re-presentó a México. La sesión plenaria del lunes 21 de mayo em-pezó con la presentación de alrededor de 140 delegados que vinieron de varios países para participar en 13 grupos de traba-jo. 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 (Soft-ware 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 ac-tualizació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 sorpren-dió que de la India llegara una sola persona; y que la Delega-ció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 represen-tació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 cla-ses de español gratis.

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 perso-nas) 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 em-presas 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, yo La quinta va a contener la guía para implementar el Perfil 1 basado en nuestro modelo de procesos y en paquetes de im-plementación aportados por otros miembros del grupo.

El trabajo de nuestro grupo estuvo enfocado en obtener resul-tados, pasamos de una etapa de propuestas a otra de decisio-nes 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 pode-mos 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ón-de “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-

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, Tecnolo-gía Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Es fundadora de la AMCIS. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

// COLUMNA// COLUMNA


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 partici-pación organizó una reunión del comité en Acapulco, que todavía es recordada con gusto por algunos de los delegados. Desafortunada-mente cuando Arnoldo se retiró, la participación de nuestro país per-dió 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.

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

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 letre-ros 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

JUL-AGO 2007 www.sg.com.mx08

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 activida-des 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 problemasAntes que nada, la primera pregunta es: ¿para que moverse a una or-ganizació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 orga-nizació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 interrela-cionados 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ónEl 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-

vicios coherentes con la finalidad de sumar el trabajo de cada individuo en un todo a gran escala, apoyando a asegurar la consistencia y produc-tividad del servicio. Detectando la madurezCuando 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 ha-bilidad 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 infraestruc-tura, etcétera). Esto hace parecer que todo lo que pasa en proyectos depende de tantas variables fuera de nuestro control, que resulta impo-sible 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 conver-sació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 res-ponsable 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 per-sona?, 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 pro-cesos, simplemente espera que algo salga mal y observa si la conver-sació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 in-dividuos, al encontrarse con un problema.

—Luis R. Cuellar

/*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.

// COLUMNA// COLUMNA


/* LO QUE VIENE*/// PRODUCTOS

JBoss Seam 2.0 Uniendo Web 2.0 con Java EE

Tan solo tres meses después de liberarse la versión 1.2.1 de Seam, ya te-nemos 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

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 arqui-tectura estándar para procesos batch no le deja a las organizaciones otra opción más que desarrollar so-luciones 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 administra-ción de procesos batch.

Spring Batch fue creado por Interface21 en colabo-ració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 extender-lo 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 en-tendemos 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

Visual Studio 2008Ambiente de desarrollo para .NET 3.0

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á dispo-nible como Beta 1, y se espera un Beta 2 este verano, para es-tar lanzando el producto final antes de que termine el año.

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 aplicacio-nes .NET. Otra característica importante es que Visual Studio Tools for Office –el componente para extender las aplicacio-nes de Office– ya estará integrado dentro de Visual Studio 2008. Asimismo, Visual Studio Tools for Office –el compo-nente para extender aplicaciones de Office– ya vendrá inclui-do como parte de Visual Studio.

Más información en msdn2.microsoft.com/en-us/vstudio

Flex, Silverlight y JavaFX La guerra de las RIA

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 in-terna 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 cam-bió 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 ofi-cialmente iniciada la guerra de los RIA.

Uno de los primeros acontecimientos notables al respecto, es que Mi-guel de Icaza ya se apuró a desarrollar una implementación de Silverlig-ht basada en Mono, que lleva el nombre de Moonlight.

Por otro lado, JavaFX se está moviendo un poco más lento, ya que has-ta 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 libe-rado 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.


/* TUTORIAL*/// PRODUCTOS

Apache Lucene y SolrBúsqueda sencilla y poderosaPor Pedro Galván

¿Alguna vez han considerado que es iróni-co de que la funcionalidad más impor-

tante 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 utili-zando. Aquellas aplicaciones que requieren un sistema de búsqueda más complejo y flexible típicamente deben recurrir a pro-ductos comerciales, o desarrollar una so-lució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 de-sempeño escrito en Java. Está diseñado y de-sarrollado de tal forma que se pueda utilizar en prácticamente cualquier aplicación que requiera búsqueda de texto completo, espe-cialmente aplicaciones multiplataforma.

En esencia, Lucene es una librería que pu-ede ser invocada desde aplicaciones Java para realizar búsquedas. Pero si lo que que-remos 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 Lu-cene, 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 expli-car como instalar y utilizar una solución de búsqueda utilizando Solr.

1. Instalación de SolrPara ejecutar Solr requerimos tener insta-lado un JDK 1.5 o posterior.

Teniendo instalado nuestro JDK, simple-mente descargamos la versión más reciente

de Solr de http://mirror.x10.com/mirror/apache/lucene/solr/ y extraemos el con-tenido en nuestra computadora. Solr se puede ejecutar en cualquier con-tenedor 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 arran-car 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ónYa 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 almacena-remos 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 con-tiene 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 local-mente). Si la información a buscar está alma-cenada 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 directa-mente desde la base de datos. Esto reduce fuertemente los requerimientos de almace-namiento de Lucene, y evita duplicar datos.

La sección <fields> es donde se listan los diferentes elementos tipo <field>, es decir, los campos de información. Cada <field> tiene un nombre que se utiliza como ref-erencia al agregar documentos o realizar búsquedas, y un <type> que identifica el tipo de datos. Los tipos de datos son declarados utilizando elementos <fieldType>. 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:

<field name=”id” type=”string” indexed=”true” stored=”true” required=”true”/><field name=”sku” type=”textTight” indexed=”true” stored=”true” omitNorms=”true”/><field name=”nombre” type=”text” indexed=”true” stored=”true”/><field name=”fabricante” type=”text” indexed=”true” stored=”true” omitNorms=”true”/><field name=”caracteristicas” type=”text” indexed=”true” stored=”true” multiValued=”true”/><field name=”peso” type=”sfloat” indexed=”true” stored=”true”/><field name=”precio” type=”sfloat” indexed=”true” stored=”true”/>

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 val-or de todos los campos que queremos que sean incluidos en la búsqueda. El valor de los campos originales se copia utilizando el elemento <copyField>. Un esquema de con-figuración de Solr puede contener un núme-ro ilimitado de declaraciones <copyField>. 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.


ConclusiónEn 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

<field name=”texto” type=”text” indexed=”true” stored=”false” multiValued=”true” /><copyField source=”nombre” dest=”texto”/><copyField source=”fabricante” dest=”texto”/><copyField source=”caracteristicas” dest=”texto”/>

3. Agregando documentos a indexarLa forma de alimentar datos a Lucene es a través de documentos XML que contienen instruc-ciones de indexado para agregar, borrar o actualizar documentos. El siguiente listado mues-tra 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.

<add> <doc> <field name=”id”>3007WFP</field> <field name=”nombre”>Dell Widescreen UltraSharp 3007WFP</field> <field name=”fabricante”>Dell, Inc.</field> <field name=”caracteristicas”>30” TFT active matrix LCD, 2560 x 1600, .25mm dot pitch, 700:1 contrast</field> <field name=”peso”>401.6</field> <field name=”precio”>5199</field> </doc></add>

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úsquedasLas 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 po-sible 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.

¿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 de-cir 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 conside-rando 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 for-mado 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 ori-ginal 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 evolu-ció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 traba-jo 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 cierta-mente complicada. Desafortunadamente, la gestión de datos se manteni-do 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,

los DBAs que no comprenden esto se enfocan en hacer demasiado mode-lado muy temprano en el ciclo de vida, lo cual en el libro “Agile Database Techniques” demuestro que es una forma de trabajo altamente ineficien-te. 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 comu-nidad Ágil está involucrándose y desarrollando alternativas para resolver estos problemas. Yo he escrito varios artículos al respecto que están dis-ponibles 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 simple-mente es cuestión de una mentalidad diferente?El aspecto fundamental es la mentalidad. Los desarrolladores ágiles bus-can colaborar estrechamente con otros, aprender de cada uno, y desarro-llar nuevas habilidades. También tienen un fuerte enfoque a la calidad, típicamente utilizando una estrategia “test-first” (probar primero). El he-cho 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 con-trol, 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 es-fuerzo 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 lineamien-tos 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 ro-tafolios para modelar. Lo que no es tan común es el enfoque que promue-

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.


// 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 bue-nos 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á buscan-do un problema que resolver, y no veo que eso vaya a cambiar.

¿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 dis-ponible, 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 mo-delado de datos ágil.

¿Algunas palabras para nuestros lectores?Estoy muy entusiasmado de visitar México. Nos vemos en SG ’07.

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

A finales de 2006, la revista Time anun-ciaba a la persona del año y terminaba con la incertidumbre. Para sorpresa de muchos, esta vez no se trataba de un pa-

cifista 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 recepto-res de información, sino que también fueron autores de contenido. Y no es que los usuarios no quisieran partici-par anteriormente, sino que la Web no lo permitía, porque originalmente no estaba pensada de esa forma. Pero des-de su inicio, la Web ha ido evolucionando cada vez más del modo lectura, al modo lectura-escritura desde la pers-pectiva 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 con-formado por lo sistemas y prácticas alrededor de estos in-gredientes 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 tecnolo-gía. Su construcción está basada en infraestructura y len-

guajes existentes. Lo que es nuevo son las herramientas o aplicaciones construidas con dichos lenguajes. Estas herramientas tienen algo en mente, algo que ha empeza-do 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 junta-mos 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 in-teracció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 conoci-miento disponible, no todos los usuarios han participado de la misma manera. Por ejemplo: un blog puede ser visi-tado y habitualmente leído por muchas personas, pero no todas participan con sus comentarios. Este tipo de usua-rios 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.

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

Por Oscar Cortés Santos


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

Por otro lado, existen usuarios con una persona-lidad 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 ju-gado 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 ayudar-nos a aprender más y volvernos más produc-tivos, ya que nos motiva a estar en contacto constante con los temas que nos interesan, y aprender de lo que otros están creando. Ade-más podemos tomar ventaja del escenario para darnos a conocer globalmente. El principio bási-co es una cultura de participación, de compartir nuestro conocimiento o experiencia. Las mane-ras 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 ser-vicios 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 noti-cias. Aunque un blog puede usarse para temas casuales, también es una oportunidad para desarrollarse como una autoridad. Mi recomen-dació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 comu-nidad agregando valor al contenido y de promo-ver 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 re-putación de dicho blog.

Compartiendo creatividad. Con cada vez más dispositivos portátiles que permiten tomar imágenes digitales y video en cualquier rin-có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áge-nes directamente en los sitios. Dándonos la oportunidad de crear no sólo nuevo contenido en forma de texto, sino también como multi-media. 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 concep-to 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 reco-lectan datos para relacionar individuos o comunidades enteras. Esta gente se conecta basada en sus intereses o pasatiempos, ubi-cació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 co-nocimiento 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 ca-sos los diferentes desarrolladores están dis-tribuidos en todo el mundo. Una Wiki permite a un grupo de personas actualizar la misma página Web manteniendo una historia de ac-tualizaciones. Otro recurso son los foros espe-cializados, 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 empresarialEl 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 conocimien-to e incrementar productividad.

El principio de Inteligencia Colectiva se vuelve entonces relevante para las empresas. Al ofre-cer una comunicación con los clientes para saber qué piensan de sus productos, una com-pañí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 men-cionadas 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 ecosiste-ma. Además pueden servir para tener una co-municació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 aplica-ciones. Los mashups explotan los datos que se proveen a través de RSS, WebServices y APIs ofrecidas por entidades externas, y los mez-clan 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 mas-hups típicamente son presentados usando interfaces visuales ricas, denominadas RIAs (Rich Internet Applications). Las RIAs permiten crear aplicaciones con elementos visuales so-fisticados e interactivos que brindan al usuario una mejor experiencia de lo que se puede con-seguir 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 experien-cia 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 tam-bié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 comu-nidades existentes en Web 2.0 para poder tomar ventaja de ello. La mejor manera creo yo, es perteneciendo, es desarrollando una personalidad Web Tú. <<

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

M ashup es una palabra que proviene de un término mu-sical en inglés, que significa la creación de una nueva

canción a partir de la mezcla o pedazos de otras canciones. Desde este concepto se basa el mashup de software. La Wikipe-dia lo define como “una aplicación o sitio web que combina contenido de una o más fuentes dentro de una nueva experiencia de usuario o manejo de información”.

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 dis-tribución de la información.

Las características que podemos en-contrar actualmente en el Web 2.0 son: > Hecho por el usuario para él mismo.> Capacidad dinámica de integración de infor-mació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.

¿Qué no es un mashup?Antes de continuar, debemos aclarar dos concepciones erróneas que tienden a existir relacionadas con los mashups. La primera es que un mashup no es un portal. Sin embar-go, un portal puede complementarse por un mashup y viceversa.

La segunda aclaración es que un mashup tampoco es una aplicación compuesta (com-posite application). El término composite application se utiliza para referirse a apli-caciones que en lugar de ser desarrolladas desde cero, son “ensambladas” a partir de servicios disponibles en una arquitectura SOA. Este concepto puede parecer muy simi-lar al de un mashup, sin embargo hay una di-ferencia crucial: las composite applications parten de un enfoque centrado en TI, mien-tras 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 so-lamente 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 soft-ware son la reutilización e integración. La mayor parte de los presupuestos de TI para los próxi-mos 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

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 di-ferentes fuentes de información.> Integración dinámica temporal a fuentes de información. > Integración realizada por el usuario y no nece-sariamente por el área de sistemas.> Acceso rápido a la información significa mayor competitividad y productividad.

Clasificación de mashupsUn mashup puede dividirse en dos tipos:> Orientado hacia el navegador (browser). Está más enfocado en la mezcla o composi-ción de información con imágenes del lado del navegador, principalmente usando Java-Script 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 ejem-plo: 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 empresa-rial). 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 gene-rar vistas necesarias para la toma de decisiones. Este tipo de mashup es capaz de interactuar con data centers para generar valor .

Funcionalidades del mashup empresarialEstas son algunas de las acciones más comu-nes que se pueden realizar con un mashup empresarial:

Mashups Qué Son y Qué No Son

Por Aldo Hernández

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. Cuen-ta 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.


> Filtrar información: en ocasiones un ser-vicio regresa información necesaria para construir una vista y por lo mismo es re-querido 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 virtua-lización de los servicios para abstraer la com-plejidad 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 esta-dísticas como matemáticas, a los resultados de los servicios invocados. (Vgr. Tomar la informa-ción de un servicio que nos da precios de accio-nes 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 es-tructuras 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ási-ca 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 empresarialYa definidas las cualidades y funcionalidades de un mashup empresarial, veamos la arqui-tectura de sus componentes, para así, enten-der cómo se integran la funcionalidad y los ser-vicios 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 po-der integrar, orquestar, mezclar, transformar y visualizar nuevos servicios.

Caso de uso de un mashupUsemos ahora un ejemplo específico para

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 pro-ducto 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 dife-rentes 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 ti-pos de servicios, es decir, generar una manera estándar de invocarlos sin importar de qué tipo sean. Esta virtualización puede ser representa-da a través de un XML como el siguiente:

<Servicios> <Servicio nombre=”BuroDeCredito” tipo=”WebService”> <operación nombre=”obtenerHistorialCrediticio”> <parámetro tipo=”string” nombre=”numeroDeTarjetaCredito” /> </operación> </Servicio>

<Servicio nombre=”HabitosConsumo” tipo=”RSS”> <operación nombre=”consumo”> <parámetro tipo=”string” nombre=”numeroDeTarjetaCredito” /> </operación> </Servicio></Servicios>

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 requie-re 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 in-teractuar, 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 nue-va generación de aplicaciones empre-sariales centradas en los usuarios. <<

Referencias • blogs.jackbe.com

Enterprise AjaxFramework

PRESTO DASH (AMBIENTE DE EJECUCIÓN)

Enterprise AjaxFramework

PRESTO STUDIO(AMBIENTE DE DESARROLLO)

Integración dirigidapor los usuarios

RIAs construidaspor desarrolladores

Envío de datosdirigido por eventos

ComunicaciónDefinición de fuentes de datos

Acceso a servicios, colaboración & mashups

PRESTO EDGE(SERVIDOR DE MASHUPS)

RDBMS RSS

REST

POJO

WSDL

GEO

.NETWSRP

Figura 1. Arquitectura para mashups Presto


La forma de publicación y con-sumo de información en la web de hoy en día ha sufrido un cambio fundamental. El

advenimiento de un paradigma mu-cho más proactivo en el uso de la web por parte de los usuarios –que publi-can su propio contenido en forma de blogs, wikis, videos, fotografías– ha provocado que anualmente se esté ge-nerando un volumen de información (estimado en 1.5 exabytes tan sólo para este año) que es mayor al que se ha producido en los últimos 5000 años de la historia humana.

Este nuevo paradigma ha dado pie a una inte-racción mucho más profunda entre los usua-rios 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 nue-vas aplicaciones o experiencias personaliza-das 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, sa-tisfacción en sus clientes, economías de escala basadas en la web, mercadotecnia viral, comu-nidades en línea y sistemas de distribución.

Y entonces, ¿qué consideraciones debo tener en cuenta al desarrollar aplicaciones de este tipo? Precisamente ese es el objetivo de este artículo, explicar desde el punto de vista ar-quitectónico las principales consideraciones que debemos tener para el desarrollo de las aplicaciones de esta nueva generación. Co-mencemos entonces.

Enfoque en la Experiencia de UsuarioLos ejemplos más exitosos que podemos en-contrar en el desarrollo de sitios y aplicaciones de la web 2.0 han sido aquellos que implemen-taron una experiencia integrada y altamente funcional de uso. La alta cohesión en la inter-faz de usuario y el uso de tecnologías como Ajax, que permiten proveer interactividad en el browser similar a la ofrecida por las aplicacio-nes de escritorio, han sido factores clave para fomentar la adopción masiva de aplicaciones como YouTube o MySpace, pues permiten re-ducir 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). Silver-light, por ejemplo, es un plugin multipla-taforma para el desarrollo de RIAs que utiliza lenguajes avanzados como JavaS-cript, C# ó VB e incorpora las funcionali-dades 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 de-jado 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, enten-diendo é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 desarrolla-dores están dando prioridad a estas funciona-lidades, pues la web 2.0 nos ha demostrado que, con la nueva realidad de accesos de ban-da ancha y usuarios altamente demandantes, es precisamente la experiencia de usuario el componente principal para que éstas aplica-ciones tengan la capacidad de generar los al-tos volúmenes de lealtad, crecimiento y opor-tunidades de negocio que las organizaciones están buscando.

Modelo de Programación 2.0Una de las premisas del concepto web 2.0 acuñado por Tim O’Reilly en 2005 es la ne-cesidad de contar con modelos ligeros de programación que permitan que las aplica-ciones sean interconectadas para la creación de funcionalidad personalizada. Las apli-caciones web 2.0 son inherentemente en-samblables y para ello es necesario que su arquitectura considere la utilización de es-tá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 pun-tos de conexión que puedan ser usados para la creación de mashups.

prácticas arquitectónicas en aplicaciones Web 2.0

Consideraciones que no puedes olvidarPor Alexis Castañares

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 ex-periencia 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.


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 composi-ción de aplicaciones, los mashups prometen eventualmente ser capaces de reducir los lar-gos 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 Re-presentativa de Estado ó REST por sus siglas en inglés (Representational State Transfer). La programación “RESTful”, como es comúnmen-te denominada, se refiere a la separación de tareas en recursos y a la utilización de los mis-mos por medio de mensajes transmitidos sin al-macenamiento de estado utilizando protocolos de comunicación estándares y generalmente transparentes a los firewalls, como HTTP.

Finalmente, la aplicación debe concebirse des-de sus inicios bajo el paradigma de “lectura-escritura” para promover la interactividad con sus usuarios, así como de “colaboración” para fomentar esta interactividad entre los propios usuarios, aprovechando así la inteligencia co-lectiva y el potencial de generación de comuni-dad que describíamos al inicio.

Estrategia para la Distribución de AplicativosEl modelo aplicativo de la web 2.0 ha potencia-lizado los logros del modelo de Software como

Servicio (SaaS). La distribución de software como servicio puede habilitar a las organi-zaciones 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 organi-zació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 estra-tegias que permitan crear aplicaciones que atiendan múltiples clientes en instancias de ejecución compartidas. Empresas como sa-lesforce.com han sido exitosas en la utiliza-ció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 argumen-ta que los productos con bajos volúmenes de venta pueden en conjunto igualar o su-perar 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 ga-nancias 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 ob-tener la organización vendiendo el mismo producto a un precio menor pero a un mer-cado potencial mucho mayor. Las ganan-cias 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 dis-tribució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 dis-tribuirse vía la web a un mercado poten-cial 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 pue-den proveer las aplicaciones de escritorio conectadas a estos servicios. De igual for-ma, las empresas de desarrollo han comen-zado a explorar el uso de Plataformas de Distribución de Software o SDPs (Software Delivery Platforms) para encapsular en un sistema subyacente servicios comúnmen-te requeridos por los aplicativos –como subsistemas de facturación, análisis esta-dístico, almacenamiento de datos– permi-tiendo así a las organizaciones focalizarse en la estructuración de las funcionalidades más específicas del dominio de la aplica-ció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.

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 arqui-tectó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 me-dios de acercamiento con los clientes internos o externos de las organizaciones por medio de sus activos en Internet.

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 aplica-tivos. En incrementos exponenciales estos modelos van evolucionan-do 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. <<

Figura 1. The Long Tail


Desde 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 tecno-logías ya existentes como Javascript y XML, para mejorar consi-derablemente 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.

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

acceso Web de Outlook (OWA) . Este objeto se encarga de establecer un canal de comunicación independiente del browser para enviar y re-cibir datos, y así evitar que el usuario se percate de lo que está suce-diendo 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ásicaUno de los principales atractivos de Ajax, es que al usar tecnologías que ya se encuentran implementadas en los browsers actuales, no es nece-sario instalar nada para comenzar a usarlo.

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.

FraMeWorks habilitadores de aJaX¿Cuál Elegir? Por Miguel Ángel Morán

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

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

<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;}

// 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 <div> del Panel 2 function MostrarRespuesta() { if (objxmlHttp.readyState==4) document.getElementById(“divDescripcion”).innerHTML=objxmlHttp.responseText; }

</script>

Listado 1. Implementación de Ajax sin framework

Implementar un código como el anterior no representa mayores proble-mas cuando se trata de un ejemplo sencillo como el descrito. Sin embar-go, conforme la interfaz de usuario tenga mayor complejidad, el código para implementarla se incrementará exponencialmente, haciéndolo di-fícil de crear y mantener.

Ante este panorama, muchos fabricantes y grupos han tratado de facili-tar la vida a los desarrolladores mediante la creación de marcos de tra-bajo 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 pre-escritos y listos para usarse con sólo insertarlos directamente en nuestra página Web.> Frameworks de servidor: son librerías implementadas del lado del ser-vidor, que ayudan a una integración browser/server. Estos framewor-ks suelen generar dinámicamente el Javascript requerido para Ajax de

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

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

Frameworks de clientePrototype: es un framework muy sencillo de entender, y bastante popular. Para usarlo sólo es necesario incluir el archivo prototy-pe.js y con esto estamos listos para poder utilizar los objetos que incluye la librería. El listado dos muestra el código que necesita-ríamos para lograr el mismo objetivo que en el listado uno, pero usando Prototype.

<script language=”javascript” src=”prototype.js”></script><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; } }); }</script>

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 arre-glos, 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.acu-lo.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 au-mentar 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 vuel-to 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 po-dríamos ver un mejor soporte.


Frameworks de servidorMicrosoft 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 prin-cipal beneficio es que todo se puede hacer visualmente sin necesi-dad 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 ins-tantá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 reali-zas 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 funcionali-dad que queremos con ASP.NET 2.0.

<asp:ScriptManager ID=”manEjemplo” runat=”server”/> <asp:UpdatePanel ID=”upnContenedor” runat=”server”> <ContentTemplate> <asp:Label ID=”lblDescripcion” runat=”server” Text=”Seleccione un destino y se le mostrara su descripcion” /> </ContentTemplate> <Triggers> <asp:AsyncPostBackTrigger ControlID=”drpDestinos” EventName=”SelectedIndexChanged”/> </Triggers></asp:UpdatePanel>

Listado 3. Implementación con ASP.NET Ajax

Como podrán apreciar en este código, se declara el control ScriptMa-nager (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 sli-de, 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 (median-te un archivo .war) y su principal ventaja es que permite a los brow-sers utilizar métodos de Java ubicados en el servidor como si estu-vieran 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 en-cargado 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 progra-madores en Java.

Google Web Toolkit (GWT): es un framework que proporciona el so-porte a Ajax mediante la utilización de Java. Con GWT, el desarro-llador 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 pa-recido 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).

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 comuni-dad DevelopersDotNet donde frecuentemente escribe y organiza eventos sobre tecnología. [email protected]

Conclusión

Los frameworks de Ajax facilitan y aceleran el desarrollo de las aplicaciones antes mencionadas. La elección del framework espe-cí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 capaci-dades para extender las estructuras base de Javascript y del DOM, con la ventaja agregada de su independencia de la pla-taforma 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, to-das gratuitas), que a pesar de ser muy distintas entre sí, todas ellas facilitan y aceleran el desarrollo de aplicaciones con Ajax. Como po-drá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 encuen-tra disponible en www.developersdotnet.com <<

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


FleXEl sabor de Adobe para RIAPor Edgar Parada

Hablar de una tecnología como Flex con una perspectiva 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á íntima-mente ligado con Flex, nos referimos a la expresión de RIA (Rich Internet Application).


Evolución de las AplicacionesComo sabemos, las tecnologías y arquitectu-ras 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 permi-tían una mayor productividad, a costa de com-plicaciones 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 apli-caciones. En este modelo, los navegadores ac-túan como clientes ligeros donde se interpreta HTML, y a través de este se hacen peticiones y se reciben respuestas de un servidor. Co-múnmente esta interacción también se cono-ce como arquitectura basada en páginas. Con este modelo se resolvieron los problemas de distribución y despliegue, ya que las aplicacio-nes 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érmi-no fue acuñado en el 2002 por la empresa Macromedia, y en ese entonces significaba muchas cosas pero todo se veía sintetiza-do 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 momen-to 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 pla-taforma para entregar aplicaciones.> Brinda al usuario una experiencia por lo menos comparable a la de las aplicaciones de escritorio actuales.

En una RIA se eliminan los viajes innecesa-rios al servidor, lo cual impacta positivamen-te 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 utiliza-das para clientes enriquecidos son los prác-ticamente extintos Java Applets, o el novedo-so 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.0Fue en el año 2004 cuando Tim O’Reilly utiliza el término Web 2.0, aunque nunca ha sido de-finido un esquema formal para decir qué sitio es 2.0 y qué sitio no lo es. Si algo se ve lo sufi-cientemente “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 enfo-carnos en una tecnología que está creando bastante eco en la comunidad de desarro-lladores de aplicaciones web: Adobe Flex. A grandes rasgos, Flex es un framework para desarrollar aplicaciones web que son ejecu-tadas en la plataforma Adobe Flash. Actual-mente, 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 he-chas con Flex son similares a las aplicaciones Ajax: permiten actualizaciones dinámicas

hacia la interfaz de usuario UI, y también tie-nen la habilidad de enviar y recibir datos del servidor de forma asíncrona. Una ventaja adi-cional es que las aplicaciones hechas en Flex pueden ser consideradas multiplataforma debido a la ubicuidad de su cliente (Flash Pla-yer). 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 implemen-tación de Javascript y CSS, mientras que Flash Player es una sola máquina virtual estándar para todos los navegadores y sistemas ope-rativos. Además, sería incorrecto comparar directamente ambas tecnologías, ya que en esencia Flex es un framework y una platafor-ma de desarrollo, mientras que Ajax es una serie de técnicas de desarrollo que explotan el objeto XmlHttpRequest.

Elementos de FlexLa plataforma de Flex está formada por los siguientes elementos:> ActionScript 3.0 – Un lenguaje de progra-mación orientado a objetos basado en la úl-tima 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 compo-nentes de interfaz de usuario GUI, tales como botones, data grids, acordeon, paneles, con-troles 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

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


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án-dose siempre en el usuario y a la vez una vista de código muy familiar a los programadores.> Charting Components – Una serie de compo-nentes 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 res-pectivamente.

La figura 2 muestra los principales elemen-tos de la plataforma Flex, y la figura 3 mues-tra el flujo de trabajo bajo el que funcionan estas aplicaciones.

Consideraciones sobre Flex 2Muchas 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 programa-dores. 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. Algu-nas 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 inte-gració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 segu-ridad sólido

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

Una visión al futuro de FlexPor 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) –an-teriormente conocido como el nombre clave “Apollo”–, que es un ambiente de ejecución que permitirá portar al escritorio aplicacio-nes RIA de forma transparente e indepen-diente del sistema operativo.

Así mismo, la próxima versión de Flex se en-cuentra a la vuelta de la esquina con la im-portante 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]

Figura 2. Estructura de la plataforma Flex

Figura 3. Flujo de trabajo para aplicaciones Flex



Cuando 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, pub-licada por unas cuantas entidades, y muy es-pecializada. Se podía encontrar información de cursos en los sitios de universidades, noticias en cnn.com y los últimos avances sobre naveg-adores 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 in-tento de grupo de discusión global, al que los geeks llegaban tarde o temprano. En estos ini-cios de la WWW, lo que podríamos llamar Web 1.0, se tenía una estructura centralizada de in-formació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 convirti-eron en un escaparate de publicidad para las empresas. Sin embargo, estos sitios al estar generalmente disociados de modelos de ne-gocios sólidos, sucumbían del mismo modo meteórico en que habían surgido. Pero quedó un sobreviviente: la página personal. Ahora cu-alquier persona podía tener un espacio en In-ternet para subirse a su caja de zapatos, contar sobre su vida, actividades, mascotas o cualqui-er 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 cerca-nos 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-

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 inter-actuar 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 ac-tualizar, pero podrán notar que indica mi nom-bre, y en algunas ocasiones recibe algunos visi-tantes 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án-dar, en realidad es un concepto, un cambio de paradigma. El más importante es la descentral-ización de la información. En vez de enlazar a ligas que contienen grandes bloques de infor-mación, se puede optar por acceder a servicios que nos proporcionan un fragmento de infor-mació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 predeter-minado para la información, la cual puede in-cluirse 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 de-scentralización. Los creadores de información pueden recopilarla, clasificarla y hacerla dis-ponible en segmentos significativos. ¿Qué pasa con la caja de zapatos? Pues que ahora nues-tra 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 in-formación, publicarla, agregarla o reagruparla. No en balde los blogs de los reporteros de CNN fueron en un momento más populares que el si-tio oficial de la cadena noticiosa. Existe una ter-cera característica: el concepto de comunidad. Las páginas personales ya no son más islas soli-tarias. 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 co-munidad encuentre la nuestra.

Consideren mi página actual (rulopotamo.spaces.live.com). Tiene mi nombre, y pertenece a una comunidad. En ella encontrarán infor-mació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 de-berá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 re-plantearse. Existe también el problema de cali-dad de información, y el cómo discernir cuál es confiable o verídica ante la gran cantidad dis-ponible, 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 viaje-ros de Internet lo hacen por su interesante con-tenido, 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

Web 2.0La 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ÁTEDRA Y MÁS*/// COLUMNA


/* MANTENIMIENTO DE SOFTWARE*/// PRÁCTICAS

La industria de desarrollo de software mantiene una evolución cons-tante. Antes podíamos ver que los ingenieros en sistemas compu-tacionales, 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 manteni-miento ha provocado que los profesionistas tengan que especiali-zarse. 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 manteni-miento de software. Según la terminología ANSI-IEEE, el manteni-miento 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 in-geniería de hardware, el desarrollo del software ha sufrido un retra-so 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 mode-los 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 manteni-miento 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 dia-ria. 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. Bue-no, 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 proble-mas del mantenimiento de software y las soluciones a estos problemas.

Problemas del Mantenimiento de SoftwareLa problemática del mantenimiento de software se resume en realizar el mantenimiento de forma tan rigurosa y controlada que no se de-teriore la calidad del sistema como resultado de este proceso. Por la naturaleza del software, existen problemas relacionados con el man-tenimiento 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-

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

32

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 Manten-imiento 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.


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 reescri-birlo 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 oca-siones, 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 bus-quemos 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 ma-neras innumerables. Asimismo, es muy común encontrarse con apli-caciones 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 dife-rentes áreas de una aplicación de software: a. Efectos secundarios en el código, en donde el código sufre modi-ficaciones como rediseños, eliminación de procedimientos o subpro-gramas, modificación de macros o dll’s, cambios para mejorar el des-empeñ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 general-mente 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 softwareExisten diversas estrategias y acciones que podemos llevar a cabo para resolver o mitigar los diferentes problemas descritos anterior-mente, y que pueden servirnos de guía sobre la manera en que las or-ganizaciones deben de enfrentar el mantenimiento de software. Entre las principales estrategias están:

Código mantenible. Como ya lo mencionamos anteriormente, la manera de estructurar un programa depende de la creatividad y habilidad de los progra-madores, sin embargo existen prácticas que contribuyen a mejorar la facilidad de mantenimiento del código. Estas prácticas se resu-men a continuación:• Código documentado: Los diferentes segmentos de código que se escriben deben contener comentarios objetivos que expliquen de for-ma 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 pu-dieron 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 ma-nual 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, dic-cionarios de datos, etc…

Equipo dedicado de mantenimiento de softwareA pesar de la importancia que ya vimos que tiene el mantenimien-to de software, muchas organizaciones no justifican la asignación de un equipo dedicado exclusivamente al mantenimiento de soft-ware. Sin embargo, es primordial tener identificadas a las perso-nas 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, simple-mente 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ónEl 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.

“El mantenimiento de software debe ser una actividad planeada... que debe

contar con recursos dedicados y capacitados para desempeñarla ”.


/* ADMINISTRACIÓN DE PROYECTOS*/// PRÁCTICAS

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óvi-les 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 …

6. Determinar el Valor del Factor de AjusteEste paso, ayuda a determinar un factor de ajuste que puede au-mentar 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.

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 ambien-tales son los más complicados, el valor de ajuste será 1.35.

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.

Aplicación al casoDebido a que no fue proporcionado el detalle de las caracterís-ticas ambientales, y sólo se indicó que los requerimientos y res-tricciones 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 es-timació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

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 con-siderado en la estimación.

7. Determinar los Puntos de Función AjustadosEn 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 nue-vo desarrollo, la fórmula es la siguiente:

Puntos de Función Ajustados = Puntos de Función no Ajustados x Valor de Ajuste

Aplicación al casoSumando las funciones de datos (12 puntos de función no ajus-tados) y las funciones transaccionales (23 puntos de función no ajustados), esta aplicación mide 35 puntos de función no ajusta-dos, los cuales multiplicados por el factor de ajuste igual a 1, nos daría 35 puntos de función ajustados.

Uso de los Puntos de FunciónUna vez que hemos obtenido el total de puntos de función, esta-mos ya en posibilidad de beneficiarnos de esta poderosa técnica. Algunos de los beneficios que obtenemos directamente son:

• 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, fa-ses 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 diferen-tes 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

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

34


esfuerzo requerido?, ¿Cuál sería el escenario con menor costo? y además, si con la in-formació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 he-rramientas 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 informa-ció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 tempra-nas, 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 funcionali-dad creciera hasta 50 puntos de función, ¿mantendríamos el mismo estimado de dura-ció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 mo-ver 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 ta-mañ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


• Construcción de base de datos histórica para benchmarks y proyectos de mejora continua: Cuando terminemos nuestro pro-yecto 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 reco-piladas están: el tamaño funcional, el esfuerzo (horas-hombre, meses-hombre), duración (días calendario, días hábiles), núme-ro de personas, cantidad de defectos, número de cambios, can-tidad 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 pro-ductividad en 5 puntos. De esta forma, los programas de mejora complementarán sus objetivos y no sólo estarán enfocados a lo-grar 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 re-conocimiento. 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ónObviamente, el objetivo principal del análisis de puntos de fun-ción es obtener los puntos de función para un sistema. Sin em-bargo, 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 rastreabi-lidad que sea utilizada para evaluar de manera completa y con-sistente 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á implemen-tado 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 es-tados dos tablas podrían ser impactadas.

• Identificación de scope creep o inconsistencias en los reque-rimientos: 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 fun-ción de “Insertar Compra”, sin embargo, cabe pensar que pueda existir un “Actualizar Compra”, funcionalidad que no está inclui-da 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 re-visar 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.

/* ADMINISTRACIÓN DE PROYECTOS*/// PRÁCTICAS

Aquiles Santana Álvarez es Certified Function Points Specialist por parte del IFPUG y Project Manager Professional por parte del PMI. Ha sido respon-sable 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.

ConclusiónLa 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.


/* MEJORA DE PROCESOS*/// PRÁCTICAS

Sin duda alguna, las necesidades y tendencias externas determi-nan 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 com-petitividad, 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 des-empeñ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 implemen-tación de un programa de mejora de procesos, se refiere a la cooperación limitada o nula de algunos miembros de la organi-zació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 de-bemos saber es que, hacerlo implica cambios en la forma de traba-jar, lo cual tiene un impacto directo en esfuerzo y por consiguiente, en tiempos. Es así como caemos en la cuenta que uno de los ries-gos 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 involu-crados 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.

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

La culturaAl 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 llama-mos 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 ejecu-ció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? Pro-bablemente 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.

Factores Clave para la Mejora de ProcesosLa diferencia para el éxitoPor Rocío García Ocaña

37


/* MEJORA DE PROCESOS */// PRÁCTICAS

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 Computacio-nales Administrativos por el ITESM-CEM, y cuenta además con una Maestría en Administración por la misma institución.

“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 escucha-do 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 depende-rá 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, recapi-tularemos 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 activi-dades de cada fase del plan de mejora, ¡sorpresa!, la implementa-ció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 princi-pales 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 introduci-dos. 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 sufi-ciente y los medios adecuados para informar a todos los involu-crados, 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 im-pedirá que el esfuerzo y el trabajo rinda los frutos esperados.

DisciplinaComo 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érmi-no. La palabra disciplina tiene un vínculo tanto a áreas de co-nocimiento 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.

ConvencimientoPara explicar este factor, quisiera que pensaran por unos segun-dos 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 cos-tumbre, pero a fin de cuentas, probablemente lo usan porque están convencidos de que puede salvarles la vida en un acciden-te cuando menos lo esperen. Dichas circunstancias imaginarias nos provocan cierta disciplina en su uso. El punto al que preten-do 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 pro-cesos 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 cambioLa mejora de procesos representa sin duda un esfuerzo organi-zacional con impactos de distintas magnitudes en el ambiente, y


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 en-tender 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 ma-nejo 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 geren-cia, 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 mo-mento 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 di-rección de dicho barco.

CoachingEl 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 organiza-ció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.

EnfoqueUn 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 en-foque 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 cam-bios, 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 imple-mentación, y lo más importante, pueden ser los diferenciadores entre una simple im-plantación de procesos y una implantación efectiva de procesos. ¡Mucho éxito!


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

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

Cuando desarrollamos sistemas, todos nos hemos enfrentado a esta constante de nuestra profesión: el cambio. Cambio de re-querimientos, 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.

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

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

Figura 1. Primer acercamiento a la solución.

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

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 escu-char un Mariachi con batería”. Inmediatamente pasa por nuestra mente agregar una nueva clase: Baterista (véase figura 3).

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 …}

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

40

El Mariachi Orientado a ObjetosEntendiendo el diseño OOPor Carlos “Fofo” Ordóñez


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

Figura 4. Mariachi con cantante de opera

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

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

La figura 5 muestra una solución utilizando interfaces.

Figura 5. Mariachi usando interfaces

El Mariachi Orientado a Objetos


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

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

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.

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

Esta solución parece correcta. Incluso hasta el trompetista ha deja-do de cantar, para dedicarse únicamente a tocar música y bailar.

Sin embargo, este diseño tiene un problema muy grave: “reutili-zación de código”. Cuando volteamos y vemos que los métodos bailar, tocar música y cantar tienen que ser implementados por las clases concretas, estamos en aprietos.

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

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

Figura 6. Solución propuesta por el patrón de estrategia

Lo que tenemos que hacer entonces es encontrar cuáles son los po-tenciales de cambio, es decir, cuáles clases y/o comportamientos tienen una gran probabilidad de ser modificadas y aislar los cambios de las demás clases, y al mismo tiempo, explotar el polimorfismo agregando una clase abstracta o una interfaz para cubrir las diferen-tes estrategias.

Siguiendo este consejo, se detecta que el comportamiento de los mú-sicos es el que tiende a cambiar, entonces se decide crear un conjunto

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

Figura 7. Mariachi utilizando el patrón de estrategia


En un inicio, el Web 2.0 era sinónimo del “Web semántico”, con contenido altamente definido. Sin embargo, esto ha ido cam-biando, 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 altamen-te 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 re-fiero 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 si-guiente figura.

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

El debate de Web 3.xHay quienes ya se atreven a hablar sobre un Web 3.x. Las espe-culaciones 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 por-centaje 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 rele-vantes, en conjunto con inteligencia artificial que permita com-prender intenciones y agentes en Internet. • La convergencia de información personal: perfiles de usuario, historias de navegación realizada, análisis de calendarios y con-tenido 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á re-sidir 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 organiza-ciones, 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 tiem-po 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

Web 2.x y Web 3.x Un nuevo camino por recorrer

/*TENDENCIAS EN SW*/ // COLUMNA

Luis Daniel Soto es director de Divulgación Tecnológica para América Latina en Microsoft. Entre sus funciones actuales están la de admi-nistración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Es jurado del “Gran Orden del Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de TI. Ganó el primer lugar en el concurso nacional para software de exportación en 1989. blogs.msdn.com/luisdans

Figura 1. Usando Popfly para crear un mashup.

43


// UML

Procesos Basados en UMLManTenLo sIMPLePor Sergio Orozco

Sergio Orozco es director general e instructor senior certificado por la OMG en Milestone Consulting (UML Value Added Training Center), empresa especializada en capacitación práctica y consultoría en UML, CMMI y orientación a objetos. Milestone Consulting es la primer empresa mexicana miem-bro de la OMG. [email protected] www.milestone.com.mx

¡Estoy harto de los procesos y estándares de desarrollo! Ese suele ser el grito desesperado de muchos responsables de organizacio-nes de software que han intentado formalizar sus procesos con re-sultados poco eficientes.Y no es para menos, pues muchas veces la experiencia de los “gu-rú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 pro-yectos. 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 incomprendi-dos. Y es que intentar usar todo UML, simplemente porque apren-diste cuáles son los diagramas que lo conforman, no es precisa-mente 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.

Selección de ArtefactosLa 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 cos-tos 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 utili-zan, 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?

Proceso A. El Más Simple: Requerimientos, el Principio de TodoSi actualmente tu proceso consiste en entrevistar a tus usuarios y con base en dicha información comienzas a programar de inme-diato, entonces mi recomendación es que por lo menos agregues casos de uso a tu proceso (diagramas y especificaciones de ca-sos 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.

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 com-prender 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 enfo-ques mencionados entonces por lo menos úsalo para realizar el di-


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ñoEl proceso anterior inicia el camino a la formalización en requerimien-tos, análisis y diseño. Eso ya es ganancia para la mayoría de los equi-pos 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 refi-nar 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án-dote en los flujos de tus casos de uso modela las interacciones entre las clases. Modelar las interacciones te permitirá tomar me-jores decisiones de diseño. El beneficio será el desarrollo de una mejor aplicación.Una advertencia: no intentes desarrollar los diagramas de secuen-cia para todos y cada uno de tus casos de uso. En general considero que sólo es indispensable para aquellos ca-sos 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 aprove-chando 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 arte-factos adicionales de UML que te darán una perspectiva diferente, pero necesaria, para comprender mejor y tomar decisiones apro-piadas para la construcción de tu proyecto.A continuación se mencionan posibles artefactos de UML que po-dría convenir agregar en condiciones especiales.

1. Sistemas de ControlPara 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 automati-zan dispositivos electrónicos, como un refrigerador, un elevador o un despachador automático de refrescos.

2. Sistemas DistribuidosSi tu sistema va a construirse de manera distribuida, es decir, par-te de la funcionalidad va a correr en una máquina y parte en otra. O si estás pensando construir partes reutilizables, entonces te re-comiendo 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 discipli-na de diseño.

3. Negocios ComplejosSi 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 de-cidir utilizarlo.

Buscando lo Simple en la ComplejidadUML 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 tra-bajo al utilizar esta notación.Este artículo no pretende de ninguna manera ser “La guía defini-tiva”, pero estoy seguro que a algunas personas les facilitará el trabajo a la hora de decidir respecto a la formalización de sus pro-cesos de software, con respecto a la elección de los artefactos de dicho estándar. De hecho hay otros artefactos de UML que no es-tán considerados aquí, por corresponder a los menos utilizados.

Vale la pena notar que en este artículo ni siquiera estoy recomendan-do 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.

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

45


En los seminarios sobre métodos ágiles que realizo, típicamente pregunto lo siguiente a la audiencia: “Levante la mano por favor, aque-lla persona a la cual un diagrama de Gantt le haya sido la diferencia para sacar adelante un proyecto, o que para darle mantenimien-to 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 fe-cha nadie ha levantado la mano. Si todas es-tas 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 se-guimos 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 se-cretas, 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 he-cho tan exitosas a estas empresas. Se le con-sidera 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.

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? Sen-cillo, 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 usua-rio, o especificación de requerimientos dema-siado 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 tra-tando 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 itera-ciones no es lo mismo que liberar rápido. Libe-rar rápido significa que si te piden un sistema que facture, liberes “a producción” la funcio-nalidad para facturar lo antes posible, aunque no se haya terminado el resto del sistema. Em-presas como Google o Yahoo entienden esto y lo aplican en sus desarrollos. Libera funcionali-dades, 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 pue-den 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, en-tonces 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 pro-ducen, las miden y desechan las que no cum-plen 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 se-parado 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 programa-dor 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 equi-pos que compartan logros y fracasos y reducire-mos 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 experi-mentar los frutos de LSD en mi propia prácti-ca. 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 empe-zar. Regalar sus libros a nuestros directores de sistemas probablemente serán los pesos mejor invertidos en mucho tiempo en nues-tras carreras.

—Emilio Osorio

Lean Software Development Libera tus proyectos por Emilio Osorio

/*TIERRA LIBRE*/// COLUMNA

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


AntecedentesA principios de 1994, al entrar en vigor el TLC con Estados Unidos y Canadá, México se in-corporó 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 im-portantes y apremiantes.

Siendo la normalización un reflejo del avan-ce industrial de un país, es imposible basarla en los principios rígidos establecidos super-ficialmente que le resten la flexibilidad ne-cesaria para adaptarse a las condiciones de una determinada época, al avance tecnológi-co o a la idiosincrasia de un país, así como a su propio desarrollo. La experiencia ha per-mitido establecer una serie de principios ge-nerales 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 Infor-mació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 formu-lar normas cuyo ámbito no se limita única-mente 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 ser-vicio 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 acepta-das para la mayoría de las áreas directamen-te relacionadas con la terminología, produc-ció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ís-ticas 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 Norma-lización, que resumiremos en 7 pasos, pero no por esto se le debe restar importancia y cierto grado de dificultad en los temas de es-pecializació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 tra-tar. Es importante mencionar que se busca la participación de representantes de dife-rentes 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 for-malizado 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 EvalPro-Soft, se estructuraon en formato de norma, y se concensuaron con los interesados.4. El organismo envía el proyecto del están-dar 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 co-mentario, se le envía formalmente al organis-mo, quien lo somete a la consideración del Comité Técnico para su aprobación.6. Si no hay comentarios, una vez transcurri-dos 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 dife-rentes sectores (industria, gobierno, etc.) a proponer temas de normalización, y las propuestas recibidas son incluidas en el Pro-grama Nacional de Normalización, el cual se somete a la consideración de la Comisión Na-cional 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 traba-jo del Comité Técnico de Normalización.

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

// FUNDAMENTOS

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 obte-ner 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.

ConclusiónLas normas se deben basar en los re-sultados consolidados de la ciencia, la tecnología y la experiencia, y sus objetivos deben ser los beneficios óptimos de la comunidad. Es funda-mental para la industria de TI, gene-rar estándares y seguir normas, que le permitan “hacer industria”.


// INFRAESTRUCTURA

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íaPor 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 proporcio-nar 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 influen-cia 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 in-fraestructura actual. Dura hasta que el nuevo requerimiento o cam-bio entra en operación. • Planeación de la capacidad: documenta los niveles reales de uti-lizació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 moni-toreo. 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 preestab-lecidos. 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 en-foque estratégico y consiste en asegurar la consideración, plane-ación e implementación en un tiempo razonable de los futuros re-

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, um-brales y alarmas tanto para servicios como componentes. También se realizan recomendaciones en acuerdos de servicios, cambios pro-activos, 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 re-sumen 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 recur-sos requeridos, costos, beneficios e impacto.

Aterrizándolo un pocoYa echamos un vistazo teórico a la estructura del proceso de adminis-tració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 reaccio-naria, 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 servicioEl primer paso en el proceso es categorizar el trabajo de los siste-mas 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 necesa-rio 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.

Administración de la CapacidadPlaneando la InfraestructuraPor Ariel García

// INFRAESTRUCTURA


Cargas de trabajo. Desde la perspectiva de la administración de la capacidad, un sistema de cómputo procesa cargas de trabajo y en-trega 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 per-spectiva del usuario.

Unidades de trabajo. A fin de medir las cargas de trabajo, es necesa-rio 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 recur-sos necesarios son procesadores, almacenamiento en disco, memo-ria, ancho de banda de red, etcétera. La medición de los recursos an-tes 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 uni-dades de trabajo, procedemos a establecer un acuerdo de nivel de servicio. Dicho acuerdo se da entre el área de TI y el área usu-aria para definir el nivel aceptable del servicio. El nivel aceptable se define típicamente desde la perspectiva del usuario, en tér-minos 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 actualUna vez determinados los niveles de servicio, lo siguiente es analizar la capacidad actual de los sistemas para determinar si están cum-pliendo 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 ref-erenciados en los acuerdos de niveles de servicio, contra los obje-tivos especificados. Esto proveerá información básica para definir

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 per-mitirá detectar recursos sobrecargados que podrían provocar prob-lemas 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 recur-sos 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 componen-tes, a fin de determinar cuáles son los recursos con mayor impacto en el tiempo de respuesta.

3. Planeación para el futuroUna 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 re-querido. Lo que debemos hacer es obtener un pronóstico de los requerimientos del negocio para con los sistemas de TI en el fu-turo. 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 infrae-structura necesaria para soportarlas.

A través de la ejecución de los pasos anteriores, es posible reali-zar 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 funda-mentado 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.

Conclusión

51


/* GADGETS */// TECNOLOGÍA// TECNOLOGÍA

SaWestern Digital

Caviar SE16 750GBPensado especialmente para computadoras de escritorio que utilizan aplicaciones con muchos datos, computación de alto desempeño y sistemas multimedia, el Caviar es una uni-dad 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 propietar-ia 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.

Viewsonic

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

Samsung

B-jack i321nBlack Jack es un smartphone lanzado recientemente bajo el concepto de “oficina móvil”, que cuenta con Win-dows Mobile 5.0 para ofrecer al usuario potentes aplicaciones de negocios, así como acceso a diversas cuen-tas 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ám-brica Bluetooth con gran capacidad de transmisión y recepción de datos que permite conectarse con otros dis-positivos 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 personalizadaDefinitivamente 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


/* GADGETS */// TECNOLOGÍA

SanDisk

MicroSDCHLas 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 gad-

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

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 des-tacan sus 70 watts de potencia

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, brindan-do nitidez, uniformidad y balance

perfecto de audio.

IBM

Power6IBM lanzó el microprocesa-dor de doble core POWER 6, que con sus 4.7 GHz du-plica la velocidad de su pre-decesor, el POWER 5, pero utilizando prácticamente la misma cantidad de energía.

La nueva línea de servido-res IBM System p 570 hace uso de l POWER 6, y hasta el momento ha logrado con-seguir 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 ente-ros, tasa de transferencia de cálculos con punto flotante, y rendimiento de Java en operaciones por segundo

Greenpeace

Green Electronics Guide Greenpeace genera un reporte trimestral donde califica a los principales proveedores de computadoras y electróni-cos en base a sus políticas y prácticas para eliminar quí-micos dañinos, así como hacerse responsable de sus pro-ductos 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.


En su búsqueda por mejorar la calidad de los servicios que proveen al negocio, las organi-zaciones de TI están cambiando su enfoque para poder reflejar un mayor valor al nego-cio. 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 ne-gocio”. 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 disci-plinas denominadas “Rutas de Valor”. Eva-luando 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 continua-ción explico estas rutas de valor y los proble-mas con los que lidia cada una.

Gestión y Descubrimiento de Activos Los activos de TI representan una fuerte in-versión, así como costos de operación recu-rrentes derivados de soporte y renovación de licencias. Uno de los requerimientos prin-cipales 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 de-mostrar que estén generando un retorno de inversión. La gestión de activos permite eva-luar y reasignar recursos de TI de forma efi-ciente en base a cambios en las necesidades del negocio.

Gestión y Aprovisionamiento de Capacidad La gestión de la capacidad se encarga de ase-gurar que las aplicaciones existentes cumplan con los requerimientos de los usuarios en términos de tiempos de respuesta y volumen de transacciones soportadas. El aprovisiona-miento de capacidad se preocupa por empa-tar 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 pro-ducción. Una buena gestión del cambio y con-figuración contribuye a reducir los costos de soporte significativamente, y disminuye la fre-cuencia 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 ac-tivos 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 sis-temas de misión crítica tienen un fuerte im-pacto en el negocio. Una gestión efectiva de los incidentes maneja a estos de forma pre-ventiva, más que correctiva, implementando mecanismos para detectar y resolver anor-malidades, antes de que se conviertan en un problema que impacte el negocio.

Gestión de Infraestructura y AplicacionesSe 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 ServiciosRefleja el impacto en los servicios de nego-cio 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 clara-mente el impacto al negocio que tiene algún evento de TI.

Gestión de los Niveles de ServicioUn aspecto fundamental de la operación del negocio es la capacidad de establecer ob-jetivos 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 Ser-vice 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, Fe-brero 2006.

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

// REFERENCIA

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

ConclusiónImplementando BSM, las organiza-ciones de TI pueden entender las relaciones críticas entre el negocio y los servicios de TI, así como detec-tar 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 relacio-nes, 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 satisfac-ción del cliente.


INDEX

Anunciante Páginas Sitio

Avantare 13 www.avantare.comCIAPEM 9 www.ciapem.veracruz.gob.mxe-Quallity 39 www.e-quallity.netGartner 47 www.gartner.comIDC 49 www.idc-eventos.comInnevo 35 www.innevo.com Intersoftware F3 www.intersoftware.com.mx Itera 41 www.itera.com.mxMilestone Consulting F4 www.milestone.com.mxNYCE 31 www.nyce.com.mxSafeNet 11 www.safenet-inc.comSG’07 F2-1 www.sg.com.mx/sg07

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

DIRECTORIO

55


02Addison Wesley Professional, 2006Refactorizar 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 co-rregir 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 da-tos, 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

la refactorización de datos en el proceso de desarrollo y mante-nimiento de software. Adicional-mente, también dedica atención a analizar aspectos culturales, que de acuerdo a los autores se-rá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

01 Addison Wesley, 2006En un mundo donde la mayoría de las discusio-nes 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 descompo-ne su propuesta en las categorías: confiabilidad, seguridad, des-empeño de tiempo, desempeño de espacio, portabilidad, y man-tenimiento. 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 in-directamente con los conceptos de este libro desde 1985, escri-biendo y manteniendo mas de 250,000 líneas de código para numerosos proyectos comercia-les y de software libre. Code Quality es la continuación al libro previo escrito por Spine-llis 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 de-bería ser considerado una biblia no solo para los programado-res, sino para todos los involucrados en análisis, mantenimien-to y control de cambios del software.

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

Code Quality: The Open Source Perspective Diomidis Spinellis

// TECNOLOGÍA// BIBLIOTECA

www

.sg.

com

.mx

SG

SO

FT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

J

ulio

-Ago

sto

200

7A

ño 0

3 N

o. 4

SG16 (Julio-Agosto 2007)

Documents

Transcript of SG16 (Julio-Agosto 2007)