SG23 (Febrero-Abril 2009)

• Aseguramiento de Calidad • Casos de Uso • Arquitectura Empresarial

Software Guru CONOCIMIENTO EN PRÁCTICA No.23 • Febrero - Abril 2009 • www.sg.com.mx

[ Especial ]

Premios SG 2008

[ MEXICANOS EN EL EXTRANJERO ]

Miguel Madero Rodrigo García Arie Grapa México. $65 MXN

La Inteligencia de Negocios como herramienta estratégica

Noticias • Eventos • Fundamentos • UML • Infraestructura • Tendencias

[ Tutorial ] JUnit 4

// CONTENIDO

directorio Dirección Editorial Pedro Galván Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Alejandro Escamilla

Editorial

Arte y Diseño Grisel Otero Desarrollo Web Nathanael Gutiérrez Consejo Editorial Jorge Valdés - PMI; Luis Cuellar - Softtek; Francisco Camargo, Luis D. Soto - Microsoft; Hanna Oktaba - UNAM; Ralf Eder, Raúl Trejo, Guillermo Rodríguez - ITESM CEM; Emilio Osorio - Sistemas Humanos; Luis Vinicio León - e-Quallity.

En estos tiempos de presupuestos recortados, todas las organizaciones se ven en la necesidad de hacer “más con menos”, y la inteligencia de negocios es una herramienta fundamental para lograr esto. Es por ello que dedicamos el artículo principal de esta edición a este tema. Hace justamente tres años (Enero-Febrero 2006) ya habíamos dedicado el artículo principal de SG a este mismo tema. Analizando como ha cambiado o evolucionado la inteligencia de negocios en este tiempo, consideramos que lo más notable es el énfasis que se está haciendo actualmente para introducirlo en las PyMEs. Hasta hace unos años, la inteligencia de negocios era algo que solamente los grandes corporativos hacían. Sin embargo, conforme los sistemas de información han permeado en las pequeñas y medianas empresas, también ha llegado la capacidad (y necesidad) de sacarle jugo a la información que éstos generan.

Presentamos la segunda edición de los Premios SG, donde buscamos reconocer los productos más populares entre nues-

tros lectores. Agradecemos su asidua participación y pronta respuesta tanto en la nominación como en la elección de los ganadores para las diferentes categorías.

La información recabada nos ayuda a tener una mejor idea de las herramientas y tecnologías más utilizados por los profesionales de desarrollo de software en nuestra región.

En esta ocasión publicamos una pequeña entrevista con tres profesionistas de software de origen mexicano que actualmente laboran en el extranjero. Más allá de presumir los logros de estas personas (que sí merecen presumirse), lo que queremos hacer notar es que estas son personas comunes y corrientes, que estudiaron en nuestro país. Para poder estar en el mismo lugar que ellos basta con trabajar duro y no ponernos barreras.

Agradecemos a todos nuestros lectores y colaboradores por seguir apoyando esta querida revista con el entusiasmo de siempre. Les deseamos lo mejor para este año. » Equipo Editorial

02

FEB-ABR 2009

Colaboradores Gunnar Wolf, Francisco Vaca, Ernestina Ortíz, Dafne Rosso, Héctor Franco, Erick Frausto, Rodrigo Corral, Ma. Julia Orozco, Claudia Alquicira, Oswaldo Gómez, Alejandro Ramírez, Carlos Ortega, Charlie Macías, Manik Surtani, Rob Smoot, Susana Tamayo, Edna Gutiérrez, Agustín Gutiérrez, Aurora Pérez Luis Márquez, Miguel Madero, Rodrigo García, Arie Grapa, Jaime Ruíz Ariel Jatuff, Guadalupe Bautista.

Ventas Claudia Perea Circulación y Administración Edgar Dorantes Contacto info@sg.com.mx +52 55 5239 5502 SG Software Guru es una publicación trimestral 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 febrero de 2009 en Roma Color, S.A. de C.V. Distribuido por Sepomex.

www.sg.com.mx

contenido feb - abr 2009

26

EN PORTADA Inteligencia de Negocios

26

Premios SG 2008

18

La inteligencia de negocios como herramienta estratégica.

Productos

Columnas

LO QUE VIENE ASP.Net MVC, Spring + BlazeDS, Python 3 y Drools 5

12

TUTORIAL JUnit 4.

14

Prácticas

Tejiendo Nuestra Red por Hanna Oktaba

08

Prueba de Software por Luis Vinicio León

52

Mejora Continua por Luis Cuellar

10

Tendencias en Software por Luis Daniel Soto

54

La arquitectura empresarial se encarga de alinear la estrategia, los procesos y la tecnología.

Programar es un Modo de Vida por Gunnar Wolf

47

Cátedra y Más por Raúl Trejo

64

REQUERIMIENTOS 40 Cuando los Casos de Uso no Alcanzan

04

INFRAESTRUCTURA

58

INDUSTRIA

06

TENDENCIAS

60

FUNDAMENTOS

56

GADGETS

62

Miguel Madero Rodrigo García Arie Grapa

www.sg.com.mx

42

PROCESOS COMPETISOFT

Noticias y Eventos

Perfiles

38

Recomendaciones sobre la correcta aplicación de los casos de uso.

En Cada Número

22

ARQUITECTURA Enteprise Architecture

Mejora de procesos de software en Iberoamérica

ASEGURAMIENTO DE CALIDAD Implementación de Modelos de Calidad

44

Diagnóstico de las empresas en México

UML Las Relaciones son Importantes

48

Aprendamos a detallar relaciones en base a la información de diagramas de secuencia.

PM CORNER 50 Aplicando Project Management al BI Analizamos los puntos clave para administrar proyectos de inteligencia de negocios.

FEB-ABR 2009

03

// NOTICIAS

Microsoft PDC 2008 Del 27 al 30 de octubre del 2008 se llevó a cabo en la ciudad de Los Angeles el Microsoft Professional Developer’s Conference (PDC) 2008. Este evento se realiza cada dos o tres años con el objetivo de mostrar a los desarrolladores las tecnologías que Microsoft estará liberando en el futuro próximo. Entre los temas que más destacaron estuvieron: Azure, una plataforma para cloud computing; Windows 7, la próxima versión del sistema operativo para desktop; Oslo, una nueva plataforma para desarrollo dirigido por modelos (MDD), y diversos proyectos de Microsoft Research tales como Microsoft Surface y Worldwide Telescope. Durante este año estaremos publicando en SG artículos relacionados con estos temas.

Las sesiones del PDC 2008 están disponibles en: www.microsoftpdc.com

Gartner “The Future of IT 2008” Durante la 11ª Conferencia Anual sobre el Futuro de las Tecnologías de Información, Gartner presentó una visión de las tendencias más importantes de las TI que tendrán un impacto en las empresas en los próximos cinco años. Analistas de Gartner presentaron temas como virtualización, software como servicio, y seguridad; incluyendo casos de estudio y páneles de discusión.

El evento ofreció a las empresas mexicanas una perspectiva real de la industria, e información fundamental para alinear las TI con sus objetivos de negocio.

BajaTech Business Solutions 2.0 El Clúster de Tecnologías de Información de Baja California, A.C. (IT@baja), realizó por primera vez durante el pasado mes de Noviembre el evento “BajaTech Business Solutions 2.0”, un punto de encuentro entre las empresas proveedoras de soluciones tecnológicas con el sector empresarial. La inauguración presidida por el Ing. Ismael Álvarez Silva, Presidente de IT@baja, fue realizada de manera simultánea en las ciudades de Tijuana y Mexicali, logrando la participación de más de 50 empresas de TI y telecomunicaciones, quienes interactuaron con cerca de 1,000 empresarios de la región. BajaTech cumplió su misión de impulsar el desarrollo tecnológico y fomentar el uso de las TI en los sectores productivos y sociales de la región.

Para conocer más visita: www.itbaja.com

04

FEB-ABR 2009

www.sg.com.mx

// EVENTOs

17 al 19 de Febrero 2009

26 al 28 de Febrero 2009

Cintermex Monterrey, Nuevo León Info: www.compushow.com.mx e-mail: info@compushow.com.mx

Tecnológico de Monterrey, Campus Monterrey Info: www.siscti.com e-mail: saul.cruz@siscti.com

24 de Febrero 2009

26 y 27 de Marzo 2009

Select Centro Banamex, México, D.F. Info: www.select.com.mx/tendencias/tendencias09/index.html e-mail: liliana.garcia@select.com.mx

IDC México Hacienda de los Morales, México, D.F. Info: www.idc-eventos.com e-mail: denriquez@idc-eventos.com

CompuShow 2009

SISCTI

Tendencias 2009

WebSec Conference 2009

25 de Febrero 2009

Information Management & BI 2.0 Conference IDC México Hacienda de los Morales, México, D.F. Info: www.idc-eventos.com e-mail: denriquez@idc-eventos.com

GULEV 2008 La paradisiaca playa de Cancún fue sede de la edición 2008 del Congreso Internacional de Software Libre GULEV, realizado del 4 al 6 de diciembre. Este año, el invitado de honor fue Rasmus Lerdorf, creador de PHP, quien impartió un taller sobre monitoreo y optimización de aplicaciones, además de una plática sobre el pasado y futuro de PHP. Las presentaciones del GULEV 2008 están disponibles en www.gulev.org.mx/eventos/gulev2008

28 y 29 de Abril 2009

Gartner Enterprise Integration Summit Centro Banamex, México, D.F. Info: www.gartner.com/mx/appint e-mail: latin.america@gartner.com

Arranca proyecto para desarrollo de Capital Humano El proyecto dirigido por IMPULSA “Modelo de Vinculación Empresa-Academia-Gobierno para el Desarrollo en Capacidades de Capital Humano en TI”, inició sus actividades. Este proyecto busca resolver una necesidad urgente de México: contar con profesionistas capacitados y certificados, que puedan integrarse a la industria.

Cabe mencionar que este proyecto es apoyado por ANIEI y AMITI, y ha sido financiado por el BID. Pronto conoceremos más a detalle sus avances e impacto.

Empresas recientemente evaluadas en CMMI: Empresa SAITO PLENUMSOFT Grupo Mnemo Vicerrectoría de RH y TI, Tec de MTY Qualysis

www.sg.com.mx

Evaluación CMMI Nivel 2 CMMI Nivel 2 CMMI Nivel 3 CMMI Nivel 2 CMMI Nivel 3

Fecha marzo 2008 julio 2008 agosto 2008 diciembre 2008 enero 2009

Lead Appraiser José Enrique Pérez Enrique Morey Mariana Pérez-Várgas José Enrique Pérez Mariana Pérez-Várgas

Apoyado por SIE Center SIE Center Avantare SIE Center Avantare

FEB-ABR 2009

05

// INDUSTRIA

Mejorando la Industria Adoptando MoProSoft Como ya hemos visto anteriormente en estas páginas, el Modelo de Procesos para la Industria de Software (MoProSoft) es un modelo de calidad que permite a la pequeña y mediana empresa de desarrollo de software el acceso a las prácticas de Ingeniería de Software y Administración de Proyectos.

MoProSoft está basado en el modelo SWCMM, en el estándar ISO 9000 y el reporte técnico ISO/IEC TR 15504.

El propósito de la norma NMX-I-059/02-NYCE es proporcionar una guía de implantación para el modelo MoProSoft, ya que en nuestro país 85% de las empresas dedicadas al Desarrollo y Mantenimiento de Software son PyMES. Por su estructura, diseño, fácil comprensión y aplicación, esta norma es adecuada para implantar un programa de mejora.

La adopción de MoProSoft habilita la obtención de un certificado de la norma NMXI-059/02-NYCE y/o ISO 9000 y reduce la brecha para la obtención de una evaluación CMMI® nivel 2.

En marzo de 2006 se iniciaron las verificaciones formales, y actualmente ya contamos con más de 100 empresas verificadas en algún nivel de la norma, y continuamente se agregan más. Para conocer las empresas verificadas visita: www.nyce.com.mx/dictamenes.htm Debido al corto periodo que lleva la implantación de MoProSoft, aún no se cuenta con métricas cuantitativas suficientes que permitan conocer la mejora e impacto en las organizaciones, pero sí contamos con un dato muy valioso, lo que sus usuarios opinan: • La implementación del modelo tardó varios meses, pero bien valió la pena, ya que cumplió el objetivo de satisfacer las necesidades de los clientes.

• Existe un cambio real en la cultura de la organización (cuestiones de horarios, compromiso de las personas).

• La definición e instrumentación de los objetivos organizacionales permite delinear nuestras actividades.

• Los procesos documentados funcionan como guías de las actividades que debemos realizar.

16 06

FEB-ABR 2009

• Se establecieron medios de comunicación que han permitido una mejor relación con los clientes y satisfacer sus necesidades.

• Las prácticas de administración de proyectos nos han ayudado a optimizar el manejo de recursos.

• Se establecieron formatos base consensuados al interior de la organización que nos permite concentrar el conocimiento y aplicar las mejores prácticas.

• Ya contamos con medios de difusión y comunicación en la Organización.

• La base de conocimiento concentra el conocimiento y experiencia acumulada que será útil para futuros proyectos.

• Se formalizaron las funciones del área de Recursos Humanos.

ASUM En respuesta a la adopción de MoProSoft en la industria mexicana, se ha creado la Asociación de Usuarios de MoProSoft (ASUM), la cual tiene una misión clara y concreta: integrar a la comunidad interesada en el modelo MoProSoft para promover su estudio, adopción, mejora y difusión a nivel nacional e internacional, representando los intereses de los asociados ante los organismos e instituciones pertinentes.

De igual manera, busca brindar a sus asociados, conocimiento y dominio de MoProSoft, información actualizada, bibliografía, red de contactos, investigación, piloteo de proyectos, círculos de estudio y colaboración con otros organismos.

La ASUM se enfoca en los siguientes puntos: • Elevar el nivel de competitividad de la industria de software mediante la promoción del modelo MoProSoft y su valor.

• Mejorar el modelo mediante el estudio de los resultados de sus implementaciones, así como la investigación de temas relacionados.

• Ser el vínculo coordinador de los usuarios del modelo para propiciar el intercambio de mejores prácticas.

• Promover programas que contribuyan a la misión de la asociación realizando actividades en conjunto con la industria, gobierno y academia.

• Intercambiar experiencias y colaborar con organizaciones afines nacionales e internacionales.

• Contribuir a la identificación, definición y promoción de los estándares derivados del modelo MoProSoft.

• Asesorar a empresas privadas, organismos gubernamentales y académicos sobre el buen uso del modelo.

• Respaldar la correcta implementación del modelo mediante el sello de confianza para proveedores de servicios. Trabajar coordinadamente con los organismos verificadores oficiales.

Actualmente existen varios proyectos ejecutándose en la Asociación, todos administrados por distintos equipos de trabajo, como por ejemplo: • Proyecto de Vinculación. Estandarizar los criterios de implementación y verificación del modelo entre los consultores y organismos verificadores.

• Proyecto de Promoción. Contribuir con la identificación, definición y promoción de estándares derivados. Orientar a organismos sobre el valor del modelo.

• Proyecto de Investigación. Investigar e incorporar guías para apoyar la implantación del modelo.

• Proyecto de Mejora. Identificar los hallazgos y proponer enmiendas a la norma. Mejorar el modelo a partir de las buenas prácticas identificadas. Recopilar y publicar las mejores prácticas.

MoProSoft ha sido reconocido internacionalmente, siendo utilizado como base de diferentes normas y modelos. Las empresas mexicanas debemos aprovechar que este modelo ha sido creado en México y tomar ventaja para lograr una industria más competitiva.

Únete a la ASUM contacta: asummoprosoft@gmail.com Los responsables son: • Coordinador General: Dra. Hanna Oktaba • Coordinador Suplente: Ariel Jatuff • Secretario: Karla Fernández • Coordinación de Mejora: Guadalupe Bautista • Coordinación de Promoción: Ariel Jatuff • Coordinación de Vinculación: Jorge Palacios • Coordinación de Investigación: Blanca Gil

www.sg.com.mx

www.sg.com.mx

FEB-ABR 2009

17 07

// COLUMNA

/*TEJIENDO NUESTRA RED*/

Reunión del WG 24 en la Ciudad de México Orgullosos Anfitriones La Dra. Hanna Oktaba es profesora de la UNAM a nivel licenciatura y posgrado. Sus áreas de interés son Ingeniería de Software, Tecnología Orientada a Objetos, Modelos de Procesos de Software y Mejora de Procesos. Actualmente es miembro de International Process Research Group (IPRC). También es Directora Técnica del proyecto COMPETISOFT.

D

el 10 al 14 de noviembre de 2008 México fue el país anfitrión de la reunión del grupo de trabajo WG24 del subcomité SC7 del JTC1 ISO/IEC. En esta ocasión se batió record de asistencia de 32 delegados. Por supuesto, México aprovechó la ocasión de ser sede y designó a 12 delegados, aún así 20 personas de 10 distintos países no se había visto en ninguna reunión anterior.

Tailandia mandó 8 representantes, lo que muestra un fuerte apoyo por parte de su gobierno al proyecto de estándar liderado por su compatriota Tanin Uthayanaka. Llegaron los dos representantes habituales de Japón y de Estados Unidos, así como uno de Canadá, Finlandia, Bélgica y Colombia. Faltó solo el representante de Irlanda, que no pudo conseguir recursos. Las nuevas incorporaciones fueron dos representantes de Perú, una de Argentina y uno de Sudáfrica. Los peruanos y la argentina son mis colegas del proyecto COMPETISOFT y fervientes promotores de MoProSoft como una alternativa del modelo de procesos en sus países.

La reunión se desarrolló en las instalaciones de CANIETI, en la Ciudad de México, organizada y coordinada de manera excelente por Fernando Solís, con apoyo de Angélica Fonseca. Después de una breve inauguración nos dividimos en cinco grupos de trabajo, uno por cada parte de la norma, para analizar los comentarios recibidos. La delegación mexicana se dividió de la siguiente manera: Juan Manuel Hernández, Arturo Ramírez y Cuauhtémoc Nápoles del NYCE, junto con Jorge Palacios (JPE) se unieron al grupo que revisaba comentarios a la parte tres Assessment Guide, dirigido por el experto finlandés en la ISO/IEC 15504, Timo Varkoi. Ana Vázquez (Praxis/UNAM) coordinó los trabajos de la parte 4-1 Specification – Basic Profile acompañada por japoneses, peruanos y tailandeses.

Mientras que Claudia González (Kernel), Blanca Gil (SIE) y Diana Guzmán (Avantare), se unieron al grupo de la parte 5-1 Management and Engineering Guide – Basic Profile coordinado por Perry Deweese de Estados Unidos y su servidora. Había otras personas de México que no pudieron estar toda la semana, pero ocasionalmente se reunían a los grupos de trabajo para observar o participar en las discusiones.

El trabajo fue arduo, de 9:00 a 17:00 horas, con una hora para comer, que gracias al patrocinio de Microsoft se sirvió en una sala adjunta, lo que ahorraba los traslados, pero no se prestaba mucho para el descanso. Cada comentario recibido se discutía en grupo para lograr el consenso, si se aceptaba aceptaba en principio o rechazaba. En el primer caso, se aceptaba la propuesta del que

08

FEB-ABR 2009

emitió el comentario, en el segundo se tenía que describir qué es lo que se acepta y qué no se acepta y, en el último caso, había que redactar una justificación convincente. Todo por supuesto, en inglés. Aquí quiero reconocer el gran trabajo que realizaron Ana Vázquez para la parte 4-1, y Claudia González con Blanca Gil para la parte 5-1. Quienes redactaron lo que se llama “disposition of comments”, que entregamos al final de la reunión.

Hubo comentarios que afectaban a más de un documento, o todos. Para discutirlos, Tanin nos convocaba a una sesión plenaria durante la cual teníamos que llegar al consenso. En una de éstas, acordamos cambiar el nombre de Very Small Enterprises por Very Small Entieties, lo que mejor refleja la definición de empresas, departamentos o proyectos con menos de 25 personas. Lo bueno de este acuerdo, es que la abreviatura VSE no cambia, lo malo es que hay que solicitar permiso de JTC1 SC7 para modificar el nombre del estándar.

Otro de los comentarios que llevó a una discusión plenaria, fue el tema de si los perfiles van a requerir de un modelo de evaluación propio, o es suficiente referirse a la ISO/IEC 15504. Es un tema que surgió hace varias reuniones y todavía sigue sin lograr consenso.

Algunos consideramos que sería bueno tener algo específico, por lo que no nos quedó mas que aceptar el compromiso como delegación mexicana, de hacer una propuesta para la siguiente reunión que será en mayo de 2009 en la India.

En cada reunión también resurge el tema del Perfil Básico que es todavía demasiado complejo para los grupos realmente pequeños, de menos de 10 personas. Analizamos la lista propuesta por Canadá y Bélgica de prácticas mínimas de administración del proyecto y del propio desarrollo y, después de una acalorada discusión y unas cuantas modificaciones, delegamos a los dos países que preparen una propuesta para la siguiente reunión.

Nosotros, como México, esbozamos la posibilidad de crear dos perfiles más amplios, el Intermedio (agregando los procesos de Gerencia) y Avanzado (con Gestión de Negocio) basados en MoProSoft. Nos comprometimos a presentar el borrador de las partes 4-2 y 5-2 del Perfil Intermedio para la próxima reunión. Es un compromiso muy fuerte por lo que invito a todos los que han experimentado con MoProSoft a nivel 2 y 3, a que me envíen sus sugerencias de prácticas que tengan valor real para las empresas. www.sg.com.mx

Terminamos la revisión de comentarios, y los demás pendientes, el jueves por la tarde. Esa misma noche NYCE, nuestro segundo patrocinador, nos ofreció una agradable cena en WTC. Las palmas de la noche las llevó el grupo de mariachi que dejó a todos muy sonrientes y, a algunos, bailando. Todos se llevaron de regalo una botellita de tequila con dos caballitos, por lo que las clases de tomar tequila correctamente tuvieron mucho éxito.

Los extranjeros estaban felices porque podían aprovechar el viernes para hacer turismo. Pero no todos, el finlandés Timo aceptó con gusto dedicar su mañana a un encuentro con la delegación mexicana para discutir el tema de evaluaciones basadas en ISO/IEC15504. No asistí a la reunión, pero sé que fue muy interesante y provechosa.

El viernes 14 de noviembre llevé al canadiense Claude Laporte, la colombiana Lily Gómez, la argentina Paula Angeleri y los peruanos Abraham Dávila y Víctor Guevara, a visitar la UNAM. Fue un día de sol esplendoroso. La Ciudad Universitaria se estaba luciendo con su Biblioteca y sus murales como Patrimonio de la Humanidad. Los alumnos, con sus fachas tan particulares, aparecían en cantidades industriales por el fin del semestre. El Centro Cultural con su espacio escultórico, el nuevo Museo Universitario del Arte Contemporáneo, los volcanes que aparecieron en el horizonte y la comida al aire libre

www.sg.com.mx

en Azul y Oro, dieron el toque final. Los invitados quedaron totalmente embobados y decidieron continuar la aventura en las trajineras de Xochimilco, donde ya no los acompañé.

Los días siguientes, Claudia, Blanca, Ana y yo nos dedicamos a incorporar todas las correcciones aprobadas o aprobadas en principio en las partes 4-1 y 5-1. Fue un trabajo muy complicado porque las dos partes dependen una de otra, y los cambios tuvieron que ser sincronizados. Además, con Claudia trabajamos a distancia desde Monterrey, y con Ana desde Montreal. Al fin lo logramos, y el 18 de diciembre subimos las nuevas versiones al sitio del WG24.

Ahora nos espera el siguiente turno de revisión y votación, la preparación de los siguientes perfiles y del modelo de evaluación.

El trabajo va para largo. Según los planes, el primer perfil saldrá como estándar en 2010. Espero que mis colegas, que en esta ocasión pudieron ver los trabajos del WG24 de cerca, así como los organismos gremiales y gubernamentales, se convenzan que el esfuerzo vale la pena. No hay duda, México ya aparece como país que está aportando estándar internacional para la industria de software. Apoyen el esfuerzo. » Por Hanna Oktaba

FEB-ABR 2009

09

// COLUMNA

/*MEJORA CONTINUA*/

El Diablo no Sólo Está en los Detalles También Está en los Defectos 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.

E

n todas las industrias tanto de productos como de servicios los defectos son el principal problema que debemos evitar. No hay nada que moleste a un cliente más que no recibir lo que esperaba debido a la falla de una máquina o un individuo, los defectos son el enemigo número uno. Pero por alguna razón esto no parece aplicar a la industria de sistemas. Tal vez se deba a nuestros orígenes, donde dos jóvenes crean una industria desde la cochera de su casa. Parece ser que en nuestro caso los defectos son ineludibles, un efecto secundario que debe esperarse; desde la liberación de gigantescos sistemas operativos que salen a la venta bajo la premisa de que continuamente se liberaran parches para resolver todos los problemas que surjan, hasta el proyecto de mantenimiento, autorizando que la corrección de un defecto detectado sea manejado como un nuevo requerimiento para facilitar el proceso.

En los proyectos de software, la principal preocupación es la entrega a tiempo: gastamos una interminable cantidad de horas estimando el esfuerzo, planeando el proyecto, y dando seguimiento a cada paso. En mi experiencia, una gran cantidad de proyectos barridos no se deben a malas estimaciones sino a la cantidad de cambios en los requerimientos, la experiencia de la gente que lleva a cabo el proyecto, y la cantidad de defectos que se generaran y se tienen que resolver.

El problema de la medición Puntos funcionales, líneas de código, números de módulos; existe gran cantidad de formas de estimar un proyecto, pero extrañamente no parece haber tantas formas de definir un defecto. No quiero decir que medir el tamaño no es importante, ya que no es lo mismo tener 3 defectos en cien líneas de código que 3 defectos en mil líneas de código. Medir tamaño consistentemente es básico para medir densidad de defectos. Pero necesita-

10

FEB-ABR 2009

mos trabajar más en una definición que nos sirva para medir defectos.

Al igual que en la definición de tamaño, no podemos tener una sola métrica para toda la industria, ya que las necesidades son diferentes dependiendo del tipo y características de cada organización. Al crear una definición de defectos para tu organización, son importantes estas dos características: 1. Que sea consistente. Esto quiere decir que si seleccionamos una forma de medir defectos necesitamos poder mantener la definición congruente a través de los diferentes proyectos, con esto comparamos si estamos mejorando o no a través del tiempo.

2. Se requiere una métrica con suficiente granularidad como para darnos información útil. Por ejemplo si contamos un programa defectuoso como un solo defecto sin importar cuantas líneas tengan error y nuestro sistema tiene una pequeña cantidad de programas, no tendremos suficiente información para encontrar y mejorar nuestra salida de defectos.

Características de los defectos Los defectos tienen diferentes características, pero hay dos especialmente importantes: 1. Crecen en forma exponencial debido a un efecto llamado “la fábrica escondida” (the hidden factory). Este fenómeno indica que si tenemos varios pasos en un proceso y cada paso tiene un porcentaje de defectos, la posibilidad de que el producto final no tenga defectos es igual a la multiplicación de las posibilidades de cada paso. Por ejemplo, si tenemos un proceso con cinco pasos y tenemos un 90% del producto bien en cada paso, al final la posibilidad de terminar sin defectos es de 90%^5 = 59%. Si consideramos la cantidad de pasos que se llevan al desarrollar software, entenderemos lo dificil que es tener un sistema sin defectos.

2. Se ha demostrado que los seres humanos tendemos a repetir errores. Cuando nos equivocamos haciendo algo, el error es parecido a errores anteriores. Nuestro cerebro teje redes que se van formando gracias a la repetición de nuestras actividades, por lo que si te equivocas en la declaración de variables de un programa en forma consistente, aumenta la posibilidad de que en el futuro te equivoques en lo mismo.

Esto nos lleva a dos estrategias que nos ayudan a reducir la cantidad de defectos en nuestros productos: 1. Revisar los productos durante sus diferentes pasos. Está demostrado que no es suficiente probar el sistema hasta el final del proyecto, sino que cada fase: análisis, diseño, programación, etc. debe considerar actividades de prueba. No sólo es importante medir la cantidad y tipo de defectos, sino la eficiencia de las pruebas mismas a través de métricas de grado de escape (escape rate) que midan el número de defectos, la fase donde se generó el defecto y la fase donde finalmente se detectó.

2. Si acostumbramos repetir errores, entonces el utilizar checklists para hacer las revisiones es la estrategia con mayor retorno de inversión y creo que de los menos utilizados. Algunos checklists internos nos ayudan a recordar en lo que se ha equivocado otras personas, pero deben ser personales.

“Los humanos se equivocan, nadie es perfecto”, Esto es cierto pero no debería ser una excusa para no trabajar lo mejor posible. De alguna manera si queremos crecer y superarnos como industria es sumamente importante que nos hagamos responsables de lo que hacemos y aprendamos de nuestros defectos. » Por Luis Cuellar www.sg.com.mx

www.sg.com.mx

FEB-ABR 2009

11

// PRODUCTOS

/* LO QUE VIENE*/

ASP.Net MVC

Desarrollo web civilizado

Spring + BlazeDS

Lo mejor de dos mundos Una tecnología que está teniendo muy buena recepción entre los desarrolladores de aplicaciones web con la plataforma .Net es ASP.NET MVC. Éste es un framework para desarrollo web basado en el patrón Modelo-Vista-Controlador. Como tal, ASP.NET MVC es una alternativa a Web Forms que ofrece los siguientes beneficios: • Clara separación de responsabilidades entre componentes • Soporte para test-driven development • URLs limpios

SpringSource y Adobe anunciaron el proyecto Spring BlazeDS Integration, el cual proveerá una integración robusta entre Spring y Adobe BlazeDS. Dicha integración permitirá desarrollar fácilmente aplicaciones basadas en el framework Spring que utilicen Adobe Flex como cliente front-end.

En enero se liberó el Release Candidate de ASP .NET MVC y se espera que la versión 1.0 esté disponible al público en general durante el primer trimestre del año.

SpringSource también está desarrollando un adaptador para Adobe LiveCycle Data Services, logrando así que las aplicaciones Spring puedan “empujar” datos para la generación de interfases gráficas en tiempo real con Flex.

Más información en www.asp.net/mvc

Más información en www.springsource.org/spring-flex

Drools 5 Python 3

Integración de reglas de negocio, procesos y manejo de eventos

Por fin llega

La comunidad de desarrolladores de Python liberó el pasado diciembre la versión 3.0 de este lenguaje de programación. Python ha cobrado gran popularidad en el último par de años no sólo por su poder, sino también por su flexibilidad. Otro factor que lo ha impulsado es el hecho de que Google lo haya elegido como el lenguaje default para el Google App Engine.

Esta nueva versión, anteriormente conocida como Python 3000, introduce una gran cantidad de cambios, y lo más significativo es que no es compatible con la versión anterior (2.6). Lo que significa que para migrar aplicaciones a Python 3 hay que cambiar código para satisfacer la nueva sintáxis y APIs. Afortunadamente existe una herramienta que automáticamente traduce el código de una versión a otra.

Más información en www.python.org

12

FEB-ABR 2009

La próxima versión de Drools (5) promete traer una oferta bastante atractiva en el área de los sistemas para manejo de reglas de negocio (BRMS). Esta nueva versión integra en un solo producto, la capacidad de modelar procesos, definir reglas, gestionar la ejecución de procesos con reglas, y procesar eventos de negocio. La integración de estas capacidades pone a Drools a la par de los productos líderes en el mercado, con la ventaja de que Drools es open source.

Drools 5 actualmente está disponible como versión previa (Milestone release) y se espera que la versión para producción se libere en febrero.

Más información en www.jboss.org/drools

www.sg.com.mx

www.sg.com.mx

FEB-ABR 2009

// PRODUCTOS

/*tutorial*/

JUnit 4 - ¡A Toda Máquina!

Introducción a la Evolución y Nuevas Características de JUnit 4 Por Erick Frausto

En este artículo presentaremos la evolución que ha sufrido el framework para el desarrollo de pruebas unitarias JUnit en su última versión, así como sus nuevas características.

Objetivos de la versión 4 de JUnit

Así haríamos la misma prueba con JUnit 3: import junit.framework.TestCase; public class CalculatePercentageTest extends TestCase {

JUnit es ya de por sí un framework que facilita en demasía el desarrollo de prueba unitarias, pero ahora la versión 4 simplifica más el desarrollo de éstas por medio de la explotación de las anotaciones otorgadas por Java 5, eliminando el desarrollo de pruebas basado en subclassing, reflection y convenciones de nombrado.

La intención de Kent Beck (creador de JUnit junto con Erich Gamma) con esta nueva versión, es animar a más desarrolladores a escribir más pruebas unitarias por medio de la simplificación de JUnit.

private double x = 50.0; private double y = 20.0; public void testCalculatePercentage() { double z = x * (y/100); assertEquals(10.0, z); } }

Una vez conocidos los objetivos de esta versión, veamos cómo aplicar las nuevas características de JUnit haciendo comparativas sobre cómo es que hacíamos la cosas en la versión anterior.

Como podemos ver en la implementación de la prueba con JUnit 4, no ha sido necesario heredar de la clase TestCase ni poner el prefijo test a cada uno de los métodos de prueba por lo que podríamos generar nuestras propias convenciones de nombrado de pruebas.

Métodos de prueba

Evolución de los métodos setUp() y tearDown()

Con JUnit 4 se eliminan las convenciones de nombrado y el uso de reflection para localizar los métodos de prueba. Ahora, para señalar un método de prueba lo anotaremos con @Test. No será necesario heredar de la clase TestCase para hacer uso de los métodos assertXXX() y podremos hacer uso de ellos mediante la utilización de importaciones estáticas, característica proporcionada por Java 5. Ejemplo:

Los métodos setUp() y tearDown() ya no serán necesarios, los métodos anotados con @Before y @After toman su lugar. Además de eliminar las convenciones de nombrado, podremos tener tantos métodos anotados con @Before y @After como deseemos, donde la ejecución de estos métodos se hace en el caso de los métodos anotados con @Before antes de ejecutarse cada uno de los métodos de prueba y la de los métodos anotados con @After se hará después de la ejecución de cada una de las pruebas. Ejemplo:

import org.junit.Test; import static org.junit.Assert.*; public class CalculatePercentageTest2 {

import org.junit.Before; import org.junit.Test; import static org.junit.Assert.*; public class CalculatePercentageTest2 { private double x; private double y;

private double x = 50.0; private double y = 20.0;

@Before public void initializeTest() { x = 50.0; y = 20.0; }

@Test public void calculatePercentage() { double z = x * (y/100); assertEquals(10.0, z); }

@After public void finalizeTest() { } …

} }

14

FEB-ABR 2009

www.sg.com.mx

“ La nueva versión de Junit 4 simplifica el desarrollo de pruebas por medio de explotación de las anotaciones otorgadas por Java 5”.

En JUnit 4 se introduce una característica sin equivalente en JUnit 3 con el comportamiento de los métodos anotados con @BeforeClass y @AfterClass. Sólo puede existir un método anotado con @BeforeClass y uno con @AfterClass, ambos métodos sólo se ejecutarán una sola vez por todos los métodos de prueba existentes, antes de la ejecución de éstos en el caso del método anotado con @BeforeClass y después de la ejecución de éstos en el caso del método que sea anotado con @AfterClass. Dicha característica sirve bien para apertura y cierre de recursos necesarios para la ejecución de pruebas, pero que son costosos en cuanto a desempeño al momento de abrir y/o cerrar.

¡La claridad de esta prueba en JUnit 4 es excepcional!

Ignorando pruebas Ya no será necesario comentar un método de prueba cuando no queramos que éste se ejecute, quizá porque aún no desarrollamos la implementación del código a probar o porque sólo queremos probar algún otro método en particular. Los métodos anotados con @Ignore serán ignorados para su ejecución. Ejemplo:

Prueba de excepciones

import org.junit.Ignore; import org.junit.Test;

La forma en que se prueba el lanzamiento de una excepción en JUnit 4 también cambia en relación con JUnit 3. Ejemplo:

public class ExceptionTest2 { private int[] array = new int[2]; private String str; …

import org.junit.Test;

@Ignore public void ignoreTest() { str.contains(“a”); }

public class ExceptionTest2 { private int[] array = new int[2]; @Test(expected=ArrayIndexOutOfBoundsException.class) public void testException() { int x = array[2]; }

}

Ayuda en pruebas de desempeño

}

Así haríamos la prueba con JUnit 3:

import junit.framework.TestCase; public class ExceptionTest extends TestCase {

JUnit 4 proporciona ayuda para realizar pruebas de desempeño dentro de las pruebas unitarias. Y aunque no resuelve de todo el tema de este tipo de pruebas por no ser su objetivo principal, sí proporciona una ayuda importante. Ejemplo:

import org.junit.Test; public class PerformanceTest {

private int[] array = new int[2]; public void testException() { try { int x = array[2]; fail(“Exception does not occur”); } catch(ArrayIndexOutOfBoundsException success) { assertNotNull(success); } } }

www.sg.com.mx

@Test(timeout=2000) public void performanceTest() { for(;;); } }

En el ejemplo anterior estamos diciendo que si la ejecución de la prueba pasa los 2000 milisegundos se interrumpirá su ejecución. El mensaje que arrojará será el siguiente: FEB-ABR 2009

15

// PRODUCTOS

/*tutorial*/

“JUnit 4 proporciona ayuda para realizar pruebas de desempeño dentro de las pruebas unitarias”.

PerformanceTest Failed – test timed out after 2000 milliseconds

Nuevas aserciones JUnit ha sido diseñado desde sus inicios, para de manera eficiente poder capturar las intenciones del desarrollador sobre su código y rápidamente poder revisar que cubra éstas intenciones. Sin embargo, existen algunas cosas que son difíciles de decir con JUnit 3 y que con JUnit 4 se hará mas fácil integrando la aserción assertThat().

Nota: Esta nueva aserción se incluye a partir de la versión 4.4 del framework. Ejemplo:

import org.junit.Test; import static org.junit.Assert.assertThat; import static org.junit.matchers.JUnitMatchers.either; import static org.junit.matchers.StringContains.containsString; import static org.hamcrest.CoreMatchers.is; import static org.hamcrest.CoreMatchers.not; public class NewAssertionsTest { private int x=3; private String str = “colour”; @Test public void newAssertions() { assertThat(x, is(3)); assertThat(str, is(not(“color”))); assertThat(str, either(containsString(“colour”)).and(not(containsString(“color”)))); } }

Conclusión • JUnit 4 más que una nueva versión de ésta ya de por sí poderosa herramienta para pruebas unitarias, es la versión más significativa desde el surgimiento de este framework.

• Basando su funcionamiento mediante la explotación de las características de Java 5, permite un desarrollo de pruebas más flexible sin la rigurosidad de convenciones de nombrado.

• Se aportan nuevas formas para realizar pruebas como lo son las de desempeño, y una manera mucho más elegante para probar el lanzamiento de una excepción.

• Con la versión 4.4 se agrega la capacidad de poder decir de una manera más fácil a través de nuestro código, aquéllas cosas que antes eran más complejas, esto mediante assertThat().

• Con esta nueva versión de JUnit se simplifica la escritura de pruebas unitarias, por lo que se agiliza su desarrollo, intentando motivar a más desarrolladores a escribir más pruebas unitarias haciéndolo ¡a toda máquina!

Referencias [ junit.org ] [ -128.ibm.com/developerworks/java/library/j-junit4.html ] [ devx.com/Java/Article/31983 ]

La intención de assertThat como mencionamos antes, es poder expresar mediante el código que escribimos, la prueba que queremos realizar.

[ code.google.com/p/hamcrest/ ]

Erick Frausto es egresado de la carrera de Ingeniería en Informática de UPIICSA–IPN, cuenta con certificaciones SUN en tecnología Java y actualmente se desempeña como Arquitecto JEE. Erick invita a todos, a nunca dejar de soñar y luchar por hacer sus sueños realidad.

16

FEB-ABR 2009

www.sg.com.mx

www.sg.com.mx

FEB-ABR 2009

18

FEB-ABR 2009

www.sg.com.mx

Los Premios SG son un reconocimiento a los productos y tecnologías para desarrollar software que más destacaron en el año. El objetivo es conocer cuáles son las herramientas más populares entre los lectores de SG.

Dado que estos son premios “elegidos por los lectores”, el mecanismo utilizado consiste en que a través de un wiki abierto, los participantes de SG nominaron productos que consideraron deberían estar en cada categoría, y posteriormente se realizó una encuesta donde las personas eligieron sus productos favoritos de entre los nominados para cada categoría. Si eres suscriptor del newsletter de SG, seguramente te llegó una invitación por correo electrónico tanto para participar en la definición de nominados, como en la votación final.

En la votación intervinieron más de 1,200 personas principalmente de México, pero también de otros países de habla hispana como Argentina, Chile, Colombia, Perú y Uruguay. Resaltó que incluso las empresas proveedoras hicieron promoción de la encuesta, invitando a sus clientes a participar. Vale la pena destacar que se utilizaron mecanismos como captchas y filtrado de direcciones IP para minimizar la posibilidad de abuso y tener resultados justos y fidedignos.

Para cada categoría solo estamos listando los tres primeros lugares. Si deseas ver la lista completa de nominados para cada categoría, puedes visitar el wiki de premios SG en wiki.sg.com.mx Veamos entonces los resultados ...

» Administración de datos 1. MySQL Enterprise Monitor 2. IBM Rational Data Architect 3. EMS SQL Management Studio En esta categoría participaron productos muy diversos, lo cual se refleja en los productos ganadores: MySQL Enterprise Monitor es para monitorear el desempeño de bases de datos durante operación, mientras que IBM Rational Data Architect es para modelar los datos de una aplicación, y SQL Management Studio se enfoca más en la parte de integración y sincronización de datos.

» Ambiente de programación (IDE) 1. Microsoft Visual Studio Professional 2. Eclipse 3. NetBeans Esta es la categoría donde se recibieron más votos, lo cual es de esperarse porque el IDE es la herramienta central de cualquier desarrollador. Visual Studio retuvo su cetro del 2007 en esta categoría, y Eclipse se mantuvo en segundo lugar. La sorpresa este año fue la popularidad que ha cobrado NetBeans.

Modelado y validación de arquitectura 1. IBM Rational Software Architect 2. Microsoft Visual Studio Team System Architecture Edition 3. Sparx Enterprise Architect Conforme los sistemas de información distribuidos y las arquitecturas orientadas a servicios se vuelven más comunes en las organizaciones, el rol de la arquitectura de sistemas se ha convertido en algo crucial, y por

www.sg.com.mx

lo tanto han surgido nuevas herramientas para sustentar las actividades de este rol.

» ETL 1. Oracle Warehouse Builder 2. IBM Information Server 3. Business Objects Data Integrator Las herramientas ETL se utilizan para extraer información de una o más fuentes de datos, transformarla y depositarla en otro repositorio.

» Framework para desarrollo Web 1. ASP .Net MVC 2. Struts 3. Spring Llama la atención que el primer lugar lo haya ganado una tecnología que todavía no llega siquiera a su versión 1.0. Esto resalta la alta necesidad de un framework de este tipo para la plataforma .Net.

» Generador de aplicaciones 1. Genexus 2. PowerBuilder 3. Clarion Las herramientas para generar aplicaciones se mantienen vigentes y han evolucionado significativamente para responder a las necesidades del mercado. Definitivamente distan mucho de los 4GLs que conocimos hace 20 años. Genexus es posiblemente el producto de ésta categoría que ha incorporado más capacidades en el último par de años. Vemos que esto le ha generado dividendos en su popularidad, incluso rebasando la de un producto tan conocido como PowerBuilder.

FEB-ABR 2009

19

» Gestión de la configuración 1. Subversion 2. Microsoft Team Foundation Server 3. IBM Rational ClearCase La categoría de gestión de la configuración es bastante amplia e involucra productos con funcionalidad muy variada. Aun así, el corazón de estas herramientas es el control de versiones. Cabe notar que la votación en esta categoría fue muy cerrada, con menos de 10 votos separando al primero y tercer lugar, así que cualquiera de estos tres productos pudo haber quedado en primer lugar.

» Gestión de requerimientos 1. IBM Rational RequisitePro 2. Microsoft Team Foundation Server 3. Borland Caliber RM Las herramientas para gestión de requerimientos ayudan a llevar el control de la asignación y estatus de los requerimientos de un software durante su construcción.

RequisitePro se mantiene como el rey de esta categoría, aunque TFS ya se está haciendo presente.

» Librería de componentes 1. Apache Commons 2. NetAdvantage for .Net 3. VCL – Delphi Visual Components Es común recurrir a componentes previamente desarrollados para resolver problemas como graficación de datos, manejo de seguridad o manejo de bitácoras, entre otros. Muchas personas y organizaciones recurren a componentes desarrollados internamente, pero es bueno saber que hay muchas opciones allá afuera, tanto de software libre como comercial.

» Modelado UML 1. IBM Rational Software Modeler 2. Visual Paradigm for UML 3. Sparx Enterprise Architect En el campo de las herramientas para modelado visual con UML, Rational Software Modeler, heredero del legendario Rational Rose se mantiene a la cabeza. Visual Paradigm es un producto que ha cobrado gran popularidad en los últimos años, principalmente debido a que ofrecer una versión gratuita.

» Gestión de pruebas 1. IBM Rational Quality Manager 2. HP Quality Center 3. Borland SilkCentral Test Manager Este año decidimos separar las herramientas de prueba de software en tres categorías diferentes, la primera de ellas es la de gestión de pruebas. El enfoque de estas herramientas no necesariamente es ejecutar las pruebas, sino encargarse de llevar el control de los aspectos de gestión tales como registro de casos de prueba, estatus

20

FEB-ABR 2009

de cobertura de pruebas, bitácora de pruebas aplicadas a una versión/build de un producto de software, etc.

» Pruebas funcionales 1. IBM Rational Functional Tester 2. Borland SilkTest 3. HP QuickTest Professional Como su nombre lo indica, las herramientas para pruebas funcionales permiten probar la funcionalidad de un software. Típicamente proveen “robots” para pruebas automatizadas y grabación de scripts que posteriormente se puedan ejecutar n número de veces con distintos datos de prueba. Para quienes no reconozcan a HP como un jugador en este espacio, les recordamos que hace un par de años HP compró a Mercury Interactive, así que la oferta de HP en este espacio está basada en los productos que adquirió de Mercury.

» Pruebas de desempeño 1. IBM Rational Performance Tester 2. Apache JMeter 3. HP LoadRunner Las herramientas para pruebas de desempeño sirven para validar los atributos de calidad no funcionales de un sistema, tales como velocidad de respuesta, utilización de recursos, confiabilidad y escalabilidad.

» Inteligencia de negocios 1. IBM Cognos 8 2. Oracle Business Intelligence Suite 3. Microsoft Business Intelligence Suite En esta categoría apareció una gran cantidad de proveedores tanto nacionales como internacionales así como de software libre. Al final, la votación fue dominada por los sospechosos comunes.

» Portal empresarial 1. IBM WebSphere Portal 2. Microsoft Sharepoint Server 3. Apache JetSpeed El segmento de portales empresariales está viviendo un momento interesante, conforme la oferta busca evolucionar del ya añejo mundo del web 1.0 hacia el web colaborativo (sí, ese que llamamos 2.0). Consideramos que este segmento en su forma actual ya tiene fecha de caducidad y que eventualmente será absorbido por las plataformas de colaboración (ver siguiente categoría).

» Plataforma de colaboración empresarial 1. Google Apps 2. Microsoft Sharepoint 3. IBM Lotus Connections La nueva generación de portales empresariales está orientada hacia la colaboración. Capacidades como wikis, mashwww.sg.com.mx

ups, edición de documentos colaborativa, redes sociales intra/extra-empresa, mensajería instantánea integrada son el común denominador. Google Apps es gratuito y por lo tanto tiene una amplia base de usuarios. Por el otro lado, la oferta de Microsoft e IBM es mucho más funcional y robusta.

» Plataforma BPM 1. IBM WebSphere 2. JBoss jBPM 3. Oracle BPA Suite Hace un par de años, los BPMS (Business Process Management System) eran considerados “el futuro” de los sistemas de información. Actualmente ya no suenan tanto, pero no por ello pierden importancia. Simplemente, conforme la oferta ha ido madurando, ha quedado más claro en qué casos un BPMS es una buena opción y en que otros casos es mejor buscar otro tipo de solución.

» Plataforma SOA 1. IBM WebSphere 2. Microsoft SOA 3. Apache ServiceMix El año pasado vivimos la “fiebre de SOA”, donde prácticamente todos los proveedores de middleware aseguraban ser los nonplus-ultra del SOA y trataban de empujar su visión, generando mucha confusión. Afortunadamente dicha fiebre va de bajada, por lo que auguramos que conforme avance este www.sg.com.mx

año será más fácil distinguir el ruido de la realidad en cuanto la oferta de SOA.

» Sistema para Gestión de Contenido (CMS) 1. Joomla 2. Lotus Web Content Management 3. Wordpress

El cómputo móvil ha tenido grandes avances en los últimos años, no sólo lo relacionado al hardware sino también en cuanto al software.

Java ME se mantiene como la plataforma más popular, pero vemos que el fenómeno iPhone ya está presente entre los lectores de SG, que lo ven como una opción muy atractiva sobre la cual desarrollar aplicaciones.

Conforme el grueso de los sitios en el web ahora manejan información dinámica (noticias, comentarios, registro de usuarios, etc), los sistemas para gestión de contenido se han convertido en una herramienta esencial.

» Respaldo y recuperación de datos

» Servidor de base de datos

Las soluciones para respaldo y recuperación de datos es una de esas herramientas de las cuales no te acuerdas hasta que las necesitas, y si no la tienes es muy doloroso. Les recomendamos analizar opciones para encontrar una que se ajuste a sus necesidades y presupuesto.

1. Oracle Database 2. Microsoft SQL Server 3. MySQL Después de los IDEs, ésta es la categoría que más votos recibió, lo cual es de esperarse ya que prácticamente todas las aplicaciones empresariales requieren una base de datos. A pesar de que este es un segmento muy maduro, todavía hay mucho espacio para innovación, lo cual se ha visto con las versiones más recientes de los productos de los principales proveedores.

» Plataforma para aplicaciones móviles 1. Sun Java Mobile Edition 2. iPhone 3. Windows Mobile

1. IBM Tivoli Storage Manager 2. Symantec NetBackup 3. Sun StorageTek Enterprise Backup Software

Conclusión Con esto terminamos el listado de ganadores de Premios SG. Agradecemos a todas las personas que participaron en la definición de nominados, así como en la votación. Esperamos que hayan quedado satisfechos con el resultado. El objetivo de estos premios es que sea un ejercicio que le sirva a ustedes, los lectores, para conocer más categorías y productos, y así tener más opciones a considerar en sus próximos proyectos.

FEB-ABR 2009

21

// perfiles

¿Alguna vez has considerado trabajar en otro país? Nuestra profesión tiene la bondad de ser global, y que en prácticamente cualquier parte del mundo germina. Aquí te presentamos el perfil de tres desarrolladores de software mexicanos que actualmente radican en el extranjero. Tú podrías ser uno de ellos, sólo es cosa de que lo intentes.

yectos de gran magnitud. También he podido conocer a gente muy talentosa, aunque esto no es muy distinto a otras oportunidades que existen en México. Trabajando en Torreón y en las diferentes comunidades de desarrollo de .NET, encontré siempre gente muy capaz.

Por otro lado, personalmente ha sido una experiencia muy grata hasta el momento, ya que el país ofrece de todo, en muchos aspectos me siento aún como turista, pues no termino de conocer y disfrutar nuevos lugares. Algo a destacar es la diversidad de culturas, debido a la gran cantidad de inmigrantes que hay. Por ejemplo, en mi actual proyecto trabajo con personas de 10 distintas nacionalidades, sólo uno de ellos es australiano. Esto se ve reflejado en las tradiciones y especialmente en la comida.

Miguel Madero Miguel es desarrollador de software para Readify Consulting, en Sydney, Australia.

Actualmente trabaja con el grupo de medios más importante de Australia desarrollando una aplicación en Silverlight. Anteriormente, Miguel tenía su despacho de desarrollo de aplicaciones basado en Torreón, Coahuila. ¿Cómo conseguiste ese trabajo?

Desde México estuve trabajando con gente de diversos países en un proyecto open source para dispositivos móviles. Una de las personas involucradas en el proyecto era de Australia y me puso en contacto con Readify.

A partir de esa recomendación empecé un proceso muy corto de entrevistas para continuar con uno muy largo de trámite de visa de trabajo. Creo que la recomendación fue algo muy importante para agilizar el proceso. El estar involucrado en proyectos open source y participar en comunidades de desarrollo también ayudó mucho. ¿Qué tanto te ha servido estar allá?

Profesionalmente ha sido muy provechoso, ya que he tenido oportunidad de trabajar en pro-

28 22

FEB-ABR 2009

¿Pretendes regresar a México?

A corto plazo será sólo de visita, ya que seguiré viviendo en Australia por lo menos otros dos años. Para regresar a vivir a México no existe ningún plan, el enfoque en este momento es disfrutar esta oportunidad que tenemos.

nicas. La recomendación es muy simple: si quieren venir a vivir acá, arreglen todo desde la comodidad de su casa.

A quienes les interese, les recomiendo que visiten el blog de Toni-anne, gerente de recursos humanos de Readify (mother-tonianne.spaces.live.com), tiene algunos posts respecto a la vida en Australia y buenas recomendaciones. ¿Cuál es tu opinión sobre la industria de software en Australia en términos de los procesos, tecnologías y personas?

Las empresas y gente que he conocido pueden ser una muestra sesgada en este punto, pero es mi percepción que, a diferencia de México, aquí no se habla de CMMI o procesos de madurez estructurados. En cambio, las metodologías ágiles en especial SCRUM, son muy populares, inclusive en grandes corporaciones. De hecho, en Readify buena parte del trabajo que realizamos es consultoría y entrenamiento para implantación de métodos ágiles.

¿Recomendarías a un colega irse a trabajar a Australia?

Sí, definitivamente. Vivir en otro país siempre te enriquece, y Australia es una gran opción. Por un lado está el aspecto profesional, económico, y la facilidad que existe para obtener una visa de trabajo a través de un patrocinador en el área de IT. Pero más importante, y algo que yo no consideraba en un principio es la diversidad cultural que mencioné antes.

En el aspecto tecnológico, nos enfocamos en .NET, sin embargo, he tenido la oportunidad de participar en algunos eventos mixtos y he podido ver que la comunidad de Java y Ruby tiene una buena presencia en Sydney que es sede de muchos eventos importantes, como el TechEd, ReMix y JAOO. Existen tantas comunidades de desarrollo, que aunque todas ofrecen algo interesante, hay que ser muy selectivo para tener tiempo de ir a los eventos más importantes y aún tener algunas tardes libres.

He conocido a algunas personas que vienen sin una visa de trabajo, pensando conseguir trabajo en IT una vez llegados a Australia. Hace 20 años pudiera parecer la única opción, pero aún estando acá, las empresas prefieren recibir correos por email o a través de su website. Si la compañía está dispuesta a contratar a alguien del extranjero, tendrán los procesos adecuados para realizar todo el trámite de manera remota, incluyendo entrevistas y evaluaciones téc-

En cuanto a las personas, en esta industria tenemos un problema muy similar en Australia y en México: es muy difícil encontrar gente bien capacitada. Existe una brecha muy grande entre lo que demandan las empresas y lo que entregan las universidades. La ventaja que existe aquí es que fácilmente se puede contratar a gente de otros países, y no necesariamente India o México, sino también de países como Francia o Estados Unidos. www.sg.com.mx

Rodrigo García Rodrigo es COO de Softtek China y Director del GDC (Centro de Desarrollo Global) de Beijing. En enero de 2000 inició su carrera en Softtek dentro del área de desarrollo web, en 2005 fue nombrado Gerente de Producto de la oferta de desarrollo de aplicaciones y en 2007 inició su aventura en China.

¿En qué consiste tu trabajo actual?

Mi trabajo consiste en asegurar que todos los proyectos que se elaboran tanto para el mercado doméstico como en el GDC se entreguen en tiempo, calidad y presupuesto. Actualmente trabajamos con clientes de China, Asia, Europa y América. ¿Por qué aceptaste ir a China?

El mercado de servicios en China está creciendo a pasos agigantados. En agosto de 2007 Softtek compró una empresa aquí y me preguntaron si quería reubicarme para ayudar con la integración de procesos y el arranque de las operaciones en esta región, inmediatamente dije que sí. Anteriormente había visitado China durante unas vacaciones y me gustó mucho Beijing. Es una ciudad totalmente cosmopolita, donde encuentras todo tipo de personas, eventos, cultura, comida y productos. ¿Trabajan localmente o envían trabajo para México? ¿Cómo funciona su operación?

Las operaciones de China están divididas en dos grupos, la local y la de Global Nearshore. La operación local da servicio a empresas dentro de China. Para esto tenemos oficinas en Beijing, Shangai, Xian y Xiamen ofreciendo servicios de desarrollo, mantenimiento y soporte de aplicaciones. Por otro lado, la operación de Global Nearshore es la que provee servicios a nuestros clientes que se encuentran fuera de China: en Asia, Europa y América. Para esto, contamos con turnos de trabajo dinámicos que permite tener una ventana de interacción con los equipos de México, España, Estados Unidos y clientes.

De esta forma damos atención las 24 horas sin tener gente trabajando durante las noches y madrugadas. www.sg.com.mx

¿La mayoría de los empleados del centro de desarrollo de Softtek en China son chinos, mexicanos, o cómo está la mezcla?

Aunque la mayoría de los empleados son chinos (más del 95%), en la oficina trabajan personas de Suiza, Australia, Canadá, Reino Unido y México. Pero todos nos comunicamos a través del idioma oficial de la empresa que es el inglés. ¿Cuál es tu opinión sobre la industria de software en China en términos de procesos, tecnología y personas?

China espera ser la economía número uno del mundo para 2025, y requiere una industria de servicios de TI que soporte esto. Este segmento ha tenido un boom impresionante, y la demanda por talento ha sido superada por la oferta. El gobierno central tiene una visión a largo plazo y comenzó a promover las carreras de TI hace varios años. Según el ministro de educación, en 2007 China capacitó entre 350 y 400 mil personas en diversas áreas de TI, mientras que India sólo 200 mil y Estados Unidos 75 mil. Actualmente, la demanda sigue siendo mucho mayor a la oferta, y estos egresados no son suficientes.

Las empresas chinas comienzan a entender el valor que le da al servicio el contar con una certificación ISO, CMMI, ITIL, etcétera.

Desgraciadamente el mercado aún no está tan maduro para pagar por ellas. La mayor parte de las empresas buscan staffing dentro de sus oficinas, y no están muy interesadas en niveles de servicio y métricas, buscan el proveedor que les de el mejor precio por el mejor currículo.

En cuanto a tecnología se refiere, una gran parte de R&D se hace en diversas empresas.

Muchas de ellas, Microsoft y Cisco son un caso, tienen fuertes inversiones en centros cautivos de ingeniería, lo que hace que ahora China no solamente se perciba como un mercado de manufactura y reproducción de tecnología, sino que también de innovación y creatividad. Sólo basta mencionar que en septiembre de 2008, China logró su primera caminata espacial con el Shenzhou 7, siendo así la tercera nación en lograrlo después de Rusia y Estados Unidos. ¿Cómo te ha servido estar allá?

La experiencia de trabajar con una cultura que es tan diferente en algunas cosas y tan similar en otras es algo invaluable. Como persona te abre los ojos, te ayuda a entender mejor el porqué otras culturas y sociedades se desarrollan y comportan de una manera, y otras de una forma totalmente opuesta. Entiendes que ambas están haciendo lo correcto desde su perspectiva de cómo miran al mundo. ¿Le recomiendas a los lectores de SG buscar oportunidades en China?

Absolutamente, sí. Mi recomendación es que se decidan a venir. Muchas de las personas extranjeras que conozco llegaron a China como maestros de inglés y otros como maestros de español. Hay empresas Chinas que están buscando personas de otras nacionalidades que quieran venir a intercambiar procesos, formas de trabajo y conocimiento con la gente de China.

Inmigrar a China no es tan complejo como ir a otros países, pero sí se necesita llegar con la mente abierta y entender que lo que para nosotros está mal aquí no necesariamente es malo y viceversa. No por ser extranjero lo van a tratar a uno diferente.

FEB-ABR 2009

23

// perfiles

Arie Grapa Arie Grapa es gerente de ingeniería en el corporativo de Yahoo! en Silicon Valley. Después de cerrar su empresa de ISP en México a finales de los 90 cuando las telefónicas ingresaron a este mercado, Arie logró matricularse a un posgrado en la universidad de Stanford, y posteriormente fue reclutado por Yahoo!

¿En qué consiste tu trabajo actual?

Actualmente soy responsable de dirigir un grupo de ingenieros que producen un software llamando “APT Demand UI”. Es el frente para los ad-networks que quieren comprar anuncios en Apex, nuestro nuevo sistema de intercambio de anuncios. Funciona como una gran red de bolsas de valores donde la gente puede comprar y vender anuncios en Internet. Anteriormente dirigía el equipo de ingenieros a cargo del sitio Yahoo! Personals. ¿Cómo se maneja el ciclo de desarrollo en una empresa como Yahoo!?

Nuestro trabajo es como parte de la línea de producción de una fábrica de software: primero se hace la investigación de mercado, luego se diseña el PRD (Product Requirements Document), luego UED (User Experience Design) y Visde (diseño visual), posteriormente el diseño técnico y desarrollo del software, el debugging, lanzamiento y por último la medición de los resultados. ¿Qué se necesita hacer para que más empresas de tecnología (como Yahoo!) establezcan centros de ingeniería en países como México?

Es una pregunta difícil, ya que el grueso de los proyectos se realiza en Estados Unidos, y muchos están de camino a China e India. A ambos se les conoce como países con muy buenas escuelas que producen buenos ingenieros, y los salarios son más accesibles que en Estados Unidos. Yahoo! por mucho tiempo ha mantenido oficinas

24

FEB-ABR 2009

en México, y en varias visitas he conocido a excelentes ingenieros que trabajan allí. En la mayoría de los casos su trabajo consiste en personalizar y lanzar productos para el mercado de habla hispana.

No tengo una fórmula para que las empresas de tecnología establezcan oficinas en México, pero sé que en otros lugares, los gobiernos han dado incentivos financieros, en muchos casos con promesas de descuentos en impuestos o en rentas de inmuebles. En otros lugares han construido grandes parques tecnológicos con infraestructura preestablecida y legislación especial que favorece este tipo de compañías (www.dubaiinternetcity.com). ¿Crees que deberíamos fomentar que este tipo de empresas se establezcan en México o que sería mejor apoyar la creación/desarrollo de empresas locales de tecnología?

Creo que debemos tratar por ambos caminos, crecer la capacidad de desarrollo de software del país y nuestra participación en esta importante industria. Otra sugerencia es que para proyectos de gobierno o para estatales se le diera preferencia a software de desarrollo nacional, siempre y cuando cumpliese con los requisitos del proyecto. ¿Cómo comparas el recurso humano de México con el de otros países?

En México se producen muy buenos ingenieros, y creo que en habilidades no hay diferencia con los que vienen de otros países.

Sin embargo, en países como India y China

hay mucho mayor población, y por lo tanto mucho más ingenieros.

Por otro lado, las escuelas en estos países son más formativas, como es el caso del IIT (ver en.wikipedia.org/wiki/Indian_Institutes_of_Technology). Un amigo mexicano que trabajaba en Cisco me decía que en la carrera le enseñaron a utilizar y configurar ruteadores, es decir a ser un “usuario” del ruteador. Creo que esto es natural ya que para muchos ingenieros en lugares donde hay poco R&D, ésta es la información que van a necesitar durante su vida profesional.

En comparación, en escuelas en Estados Unidos, India y China enseñan la teoría de cómo deben funcionar y diseñarse dichos ruteadores, para que puedan crearlos o mejorarlos. Estoy seguro de que hay muchas excepciones, pero en general creo que en estos países se hace más énfasis en la formación “ingenieril”. ¿Has encontrado que personas de distintos países tiendan a tener mayor aptitud para uno u otro tipo de trabajo?

Yo creo que todos nacemos con ciertas habilidades mentales que se nos facilitan y otras que se nos dificultan. La educación que recibimos y la práctica nos ayudan a reforzarlas y ser mejores en ellas. Al igual que con los músculos, las partes del cerebro que no se usan, se debilitan, y las que sí se usan se fortalecen.

No creo en las aptitudes por país de origen o por región. Creo que lo que tiene mayor impacto en las aptitudes es la educación. www.sg.com.mx

www.sg.com.mx

FEB-ABR 2009

25

Los Retos de la Inteligencia de Negocios Por Héctor Franco Beltrán

M

ucho se habla de Inteligencia de Negocios como algo novedoso que involucra a las organizaciones a través de tecnologías de vanguardia. A lo largo de los años se ha acuñado una gran cantidad de términos tales como Executive Information Systems (EIS), Decision Support Systems (DSS), Corporate Performance Management (CPM), Bi-Predictive Analytics, BI 2.0, etc.; en fin, existen múltiples autores, analistas, proveedores y organizaciones que definen qué es y qué no es, lo que yo prefiero llamar simplemente: “Inteligencia de Negocios”.

En realidad, los Sistemas de Inteligencia de Negocios no existen como tal. Lo que existen son arquitecturas de inteligencia de negocios que integran múltiples componentes tanto técnicos como humanos, que interactúan entre sí.

26

FEB-ABR 2009

www.sg.com.mx

Para ahondar en el tema, lo primero que sugiero es hacer una diferenciación entre los términos “inteligencia” y “negocios” e ir a sus bases, obviamente intentando no volverse loco en el intento.

Tan solo la inteligencia tiene múltiples connotaciones que van desde lo semántico hasta lo divino. Para fines de este artículo aceptemos que: “la inteligencia es la capacidad evolutiva por la cual el individuo es capaz de tomar decisiones dependiendo de su entorno, y mejorar sus condiciones de supervivencia, como individuo, como grupo o como especie”.

En el tema de los negocios también encontramos un sinfín de paradojas, pero me parece correcto retomar lo que la Wikipedia dice al respecto:“el término negocio deriva de las palabras latinas nec y otium, es decir, lo que no es ocio. Para los romanos otium era lo que se hacía en el tiempo libre, sin ninguna recompensa; entonces negocio para ellos era lo que se hacía por dinero. Es una ocupación lucrativa que cuando tiene un cierto volumen, estabilidad y organización se llama empresa. También es la consecuencia de la correcta administración de los recursos con un resultado económicamente positivo para las partes; es importante señalar que no solamente puede ser dinero, sino relaciones de poder”.

Lo que une los dos conceptos como “Inteligencia de Negocios” y le da sentido es la estrategia, la táctica y la operación de las organizaciones como herramienta de supervivencia. En otras palabras, como decía Lee A. Iacocca: “Ventaja competitiva es tener 1% más información con un día de anticipación y saber qué hacer con ella…”

Aplicaciones de la inteligencia de negocios La inteligencia de negocios es un área de conocimiento que nos brinda una gran oportunidad de crecimiento personal y profesional, no solo en nuestros ámbitos empresariales sino como nación.

Es tan amplio el espectro técnico, funcional, operativo, táctico y estratégico de las disciplinas derivadas, que sería imposible entrar en detalle en cada una de ellas en un solo artículo, ya que existen metodologías, habilidades y herramientas específicas para cada componente. Algunas disciplinas o aplicaciones, por citar algunas son: • Definición de Estrategia / Planeación Dinámica.

• Data Governance & Compliance (SOX, Basilea II, etcétera).

• Medición y Mejora del Desempeño Corporativo (CPM).

• Análisis y Diseño Dimensional (OLAP).

• Enterprise Content Management (datos estructurados y no estructurados ).

• Sistemas de Información Geográfica (GIS).

• Balanced Scorecard / Performance Dashboards.

• Costeo Basado en Actividades (ABC-ABM).

• Análisis Predictivo / Minería de Datos.

• Reconocimiento de Patrones / Detección de Fraudes.

Claves para un BI efectivo Lograr instrumentar una iniciativa de inteligencia de negocios requiere de disciplina, dedicación y una labor de equipo… realmente actuar como equipo, ya que es tan importante el responsable de la construcción del sistema para el VP de finanzas, como el responsable de limpiar o integrar los datos que éste visualizará para la toma de decisiones. Tan importante es el portero de un equipo de fútbol, como el delantero y el director técnico, ¿no?

He aquí algunas recomendaciones generales: Estrategia: Dominar las estrategias como si fuera una guerra • Hoy más que nunca, la estrategia se vuelve una pasión que cambia de manera paranoica y desenfrenada. Las organizaciones deben estar seguras de quiénes son y hacia dónde van.

• Estar conscientes que, a diferencia de los grandes estrategas, ahora tenemos más información, más rápido, pero no sabemos qué hacer con ella.

• Leer el silencio… más que escuchar las palabras… sobre todo de nuestros competidores y nuestros clientes.

• La mejor estrategia inicia por la doctrina: “educación y capacitación de tus guerreros en la era del conocimiento”.

Información: Entender su valor real y salvaguardarla • Entender el valor de los datos, su limpieza y sus implicaciones en los metadatos (datos acerca de los datos).

• Entender los efectos de la web 2.0, la nube y su impacto en la inteligencia de negocios.

• Salvaguardar la información en contextos seguros, proteger contra ataques, infiltraciones, rotación de personal. Usar técnicas de Project Management para proyectos confidenciales, tales como el DoD PMBoK basado en prácticas del Departamento de Defensa de Estados Unidos de América.

Integración: El reto y los premios • Lidiar con la integración de datos, información no estructurada, plataformas heterogéneas.

• Enfoque en reducir costos, mejorar procesos, incrementar beneficios, predecir analíticamente, mejorar campañas, conocer a los clientes, evaluar el desempeño.

• Empezar pequeño, generar resultados de alto impacto y crecer rápido.

Disciplina, experiencia y conocimiento • Ser conscientes que la tecnología sólo representa uno de los múltiples componentes de la solución y que los puntos de falla más frecuentes radican en factores metodológicos y humanos.

• El rol de la innovación como apuesta estratégica en tiempos de recesión. En el caso de México, el Decreto de Austeridad Gubernamental puede ser la gran oportunidad de mostrar las bondades de la inteligencia de negocios en el sector Gobierno.

• Es inteligente utilizar y optimizar lo que ya se tiene para inteligencia de negocios. ¡He visto milagros en hojas de cálculo y desastres en plataformas de millones de dólares!

El Ing. Héctor Franco Beltrán, PMP, es socio consultor de Grupo Frabel-Business Intelligence, así como Vicepresidente del Business Intelligence Institute, y Coordinador del Diplomado en Business Intelligence del ITAM. Cuenta con más de 18 años de experiencia, y sus áreas de especialidad son data warehouse y business intelligence. Ha publicado artículos y dictado conferencias para SG, ComputerWorld, IDC, ITAM, ExpoComm, y Conacyt, entre otros. hfranco@tbii.org.mx www.tbii.org.mx

www.sg.com.mx

FEB-ABR 2009

27

Minería de Datos

Descubriendo y Describiendo Patrones de Datos Por Dafne Rosso

Actualmente y desde hace un par de décadas, la cantidad de información que se genera en los medios comerciales, educativos

y en general en cualquier sector, se ha incrementado notoriamente. Lo que ha provocado el desarrollo de varias tecnologías enfocadas a aprovechar los datos que se encuentran escondidos en estos grandes volúmenes de información. Algunas de estas tecnologías son por ejemplo los OLAP, Data Warehouse y la Inteligencia de Negocio (Fig. 1), éstas han aportado una considerable mejora en el tratamiento de los datos estructurados y en la mejora de la toma de decisiones. Las bases de datos relacionales (BDR), Data Warehouse (DW), Data Mart (DM), OLAP y OLTP son tecnologías que permiten obtener conclusiones en base a consultas predeterminadas, es decir, son consultas deductivas, realizadas de manera óptima en tiempos cortos y enormes volúmenes de información, conclusiones que serían imposibles de obtener en un proceso manual.

28

FEB-ABR 2009

www.sg.com.mx

Para las organizaciones es de vital importancia hacer un uso eficaz de la información generada en sus procesos, por medio de esquemas de Inteligencia de Negocios.

BI

Know How

MINERÍA

Buscar relaciones ocultas (conocimiento)

OLAP / OLTP

Análisis del pasado

Data Warehouse / Data Marts

Histórica

OLAP

BDR

Data Warehouse / Data Marts

Transaccional / Operacional

Preparación de Datos

Fig. 1 Tecnologías para el tratamiento de información.

Minería de datos Minería de datos es un concepto que involucra la obtención de conocimiento en forma práctica, no en el sentido teórico. El punto de interés principal, es el de descubrir y describir patrones encontrados en los datos. Pretende resolver problemas o pronosticar nuevos datos a partir de los datos ya presentes que se encuentren en el Data Warehouse corporativo. Por ejemplo: permiten pronosticar la lealtad de un cliente en función de los patrones encontrados en su comportamiento, otro tipo de aplicaciones se encuentran en la predicción de fraudes, fallas de maquinarias, y múltiples aplicaciones orientadas al servicio.

BI

Cómo detectar y orientar las tendencias del mercado

MINERÍA

Cuál podrá ser el comportamiento de la zona sur este año

OLAP / OLTP Data Warehouse / Data Marts BDR

Las técnicas de minería de datos al día de hoy se encuentran plenamente desarrolladas, y para algunos tipos de análisis se encuentran en fase de maduración. Los métodos de minería de datos operan sobre datos altamente estructurados (Fig. 3), que se encuentran en repositorios como Data Warehouse o Data Marts, o bien son resultado de aplicar en ellos algún análisis OLAP. Para efectuar la minería es necesario que se realice previamente una preparación sobre los datos, que les provea de la estructura necesaria para la técnica de minería a emplear.

Cuál fue el total de ventas mensual de los últimos 5 años con un detalle por estado y punto de venta Cuál fué el total de ventas mensual de los últimos 5 años

Fig. 2 Aportación de las tecnologías en el tratamiento de información.

www.sg.com.mx

Minería

Figura 3. Minería de datos

El proceso de descubrimiento de patrones puede ser automático o semiautomático, los patrones identificados deben ser significativos y aportar alguna ventaja, usualmente de tipo económico.

Aplicación de la minería de datos Las técnicas empleadas en la minería de datos dependen del tipo de conocimiento que se desee obtener. Existen dos clasificaciones que agrupan los algoritmos de minería, estas son: minería dirigida y no dirigida. Para el primer caso se conoce el tipo de decisión (clase) al que se desea llegar, como por ejemplo: booleano (si /no), tipo, acción.

Las entradas son de tipo numérico o bien de tipo nominal. Los datos numéricos presentan valores talesvv que las comparaciones en rangos tengan sentido, mientras que los

FEB-ABR 2009

29

datos nominales tienen un significado específico. El dato nominal más común es algo que puede ser clasificado como cierto o falso.

A continuación vamos a realizar un ejemplo de minería dirigida con una muestra de datos referentes a las preferencias de compra de automóviles. La muestra fue recabada dentro de una población reducida de clase media, cuyo centro de trabajo se encuentra en la zona centro de la ciudad. Los tipos de datos son nominales.

La siguiente figura presenta un extracto del conjunto de datos nominales, previamente procesados para realizar la minería.

Edad

Sexo

41-50 21-30 51-60 41-50 31-40 31-41 21-30 41-50 41-50 41-50 41-50 51-60 41-50 31-40 31-40 51-60 51-60 21-30 21-30 51-60 51-60 21-30 21-30 51-60

F M M F F M M F F F M F F F M M F M F M M F M F

Delegación

Marca

Tipo

Motivo

Azcapotzalco Azcapotzalco Azcapotzalco Gustavo A. Madero Tlalnepantla Tlalnepantla C. Izcalli Gustavo A. Madero Gustavo A. Madero Naucalpan Naucalpan Naucalpan Naucalpan Benito Juárez Benito Juárez Atizapán Atizapán Atizapán Atizapán Atizapán Álvaro Obregón Atizapán Atizapán Atizapán

Ford Mazda Pontiac Chrysler Chevrolet Chevrolet Chevrolet Toyota Ford Ford Mazda Toyota Toyota Toyota Chevrolet Honda Chrysler Susuki Pontiac Pontiac Nissan Seat Pontiac Honda

Sedán Deportivo Sedán Sedán Sedán Camioneta Sedán Camioneta Camioneta Camioneta Camioneta Sedán Sedán Sedán Camioneta Camioneta Sedán Compacto Sedán Sedán Deportivo Sedán Sedán Camioneta

Marca Gusto Precio Gusto Precio Precio Precio Gusto Tamaño Tamaño Gusto Servicios Precio Gusto Marca Gusto Precio Precio Gusto Gusto Gusto Precio Gusto Tamaño

El dato que se pretende pronosticar es la marca. Es decir, si se presenta un nuevo individuo a comprar un vehículo, ¿cuál es la marca que podría escoger?

Realicemos la minería paso a paso, con un pequeño subconjunto de los datos anteriores, el método que emplearemos se conoce como ID3, éste es una estrategia que divide y conquista, que opera tratando de maximizar el nivel de ganancia en cada paso.

La siguiente tabla contiene el cálculo de la entropía para el atributo edad, se realiza el cálculo de la entropía de cada atributo, la cuál es una medida de la incertidumbre existente en el conjunto de atributos, de los cuales se escoge sólo aquel atributo con mayor ganancia (diferencia entre la entropía del sistema y la entropía del atributo). El atributo seleccionado es el nodo del árbol.

Este cálculo se repite desde la selección de la raíz y para cada nivel del árbol.

Calculando las entropías de cada atributo para el primer nivel del árbol tenemos: Atributo Edad Sexo Delegación Tipo

Ganancia 1.29989551 .65923654 1.7532697 1.1328787

Figura 6. Preferencias en compra de automóviles.

Edad

Elementos

Chev

Chry

Ford Honda Mazda

Mercedes

Nissan

Pontiac

Seat

Susuki

21-30 6 1 0 0 0 1 0 0 2 1 1 31-40 4 3 0 0 0 0 0 0 0 0 0 41-50 7 0 1 3 0 1 0 0 0 0 0 51-60 8 0 1 0 2 0 1 1 2 0 0

25 4 2 3 2 2 1 1 4 1 1 Razon de ocurrencias 21-30 6 0.16 0 0 0 0.16 0 0 0.33 0.16 0.16 31-40 4 0.75 0 0 0 0 0 0 0 0 0 41-50 7 0 0.14 0.42 0 0.14 0 0 0 0 0 51-60 8 0 0.12 0 0.25 0 0.12 0.12 0.25 0 0

25 0.16 0.08 0.12 0.08 0.08 0.04 0.04 0.16 0.04 0.04 Logaritmo de la razon de ocurrencias 21-30 6 -2.58 -2.58 -1.58 -2.58 -2.58 31-40 4 -0.41 41-50 7 -2.8 -1.22 -2.8 51-60 8 -3 -2 -3 -3 -2

25 -2.64 -3.64 -3.05 -3.64 -3.64 -4.64 -4.64 -2.64 -4.64 -4.64 Entropia 21-30 6 2.25 0.54 31-40 4 0.81 0.12 41-50 7 1.72 0.48 51-60 8 2.5 0.8

25 3.253 Entropia sistema

1.953 Entropia edad

1.299 Ganancia Tabla 1. Cálculo de entropía primer nivel.

30 32

FEB-ABR 2009

Toyota 0 1 1 1 4 0 0.25 0.14 0.12 0.16 -2 -2.8 -3 -2.64

Esto nos da el primer nodo de nuestro árbol, el nodo seleccionado es aquel que presenta la mayor ganancia. El proceso continúa hasta explorar nuevamente los atributos restantes y obtener los nodos del árbol de los niveles inferiores.

En el mercado existen varias herramientas comerciales que realizan el minado de datos. Éstas desarrollan técnicas de aprendizaje automatizado y permiten aplicarlas a problemas reales de minería de datos. También se encuentran disponibles en el web algunas herramientas como Weka y See5, ambas contienen diversos algoritmos de clasificación y asociación.

La siguiente figura presenta una fracción del árbol de decisión, obtenido de efectuar la minería en el conjunto de datos seleccionados.

En el árbol podemos observar que la delegación es el principal atributo que interviene en la selección de una marca particular de vehículo, en el caso de las delegaciones, en particular los casos de Azcapotzalco y www.sg.com.mx

%FMFHBDJwO Azcapotzalco

Gustavo A. Madero

&EBE

&EBE

Tlalnepantla

otros. En general, el proceso de toma de decisiones mejora de manera significativa.

Naucalpan

.PUJWP

.PUJWP

31-40 Precio

41-50

Marca

Servicios Gusto

SedĂĄn 41-50

51-60

Gusto

GPSE

NB[EB QPOUJBD

DISZTMFS

UPZPUB

&EBE

F

Camioneta

.PUJWP

21-30

TamaĂąo

Precio

4FYP

5JQP

TamaĂąo

M

41-50

31-40

TamaĂąo

GPSE

OJTTBO EPEHF $IFWSPMFU

W X

NB[EB

UPZPUB

IPOEB

GPSE

Figura 4. Ejemplo de un ĂĄrbol de decisiĂłn resultante de la minerĂ­a.

Gustavo A. Madero, se observa que el siguiente factor determinante es la edad de la persona, sin embargo, en Naulcalpan se observa que se tienen motivos particulares que marcan la preferencia en la selecciĂłn del auto, por ejemplo: la gente prefiere Toyota si se guĂ­an por los costos y calidad de los servicios.

Por supuesto mientras mĂĄs grande y variado sea el conjunto de datos seleccionados, el resultado serĂĄ mĂĄs aproximado a la realidad.

La minerĂ­a de datos en este ejemplo nos permitiĂł obtener conclusiones que, a simple vista no son aparentes: uno no esperarĂ­a que la delegaciĂłn fuera un factor determinante en la selecciĂłn de un vehĂ­culo, esperando que cuestiones como el precio o los servicios fueran mĂĄs significativos. Sin embargo, el proceso de

minado descubre esta relaciĂłn. El analista de datos debe ahora interpretarla. Por ejemplo, es posible que la variable delegaciĂłn estĂŠ actuando como un indicador del estilo de vida de las personas, lo que definitivamente influirĂ­a en la elecciĂłn del auto a comprar. Esta interpretaciĂłn parece apoyada por el hecho de que las personas mĂĄs jĂłvenes prefieran autos de lĂ­nea mĂĄs deportiva.

MinerĂ­a de datos en la empresa Las tĂŠcnicas de minerĂ­a de datos, pueden ser implementadas en las empresas para el descubrimiento de informaciĂłn, aportando valor a los procesos de negocio, por ejemplo, incrementando niveles de venta, aumentando la diversificaciĂłn de mercado, y mejorando la satisfacciĂłn del cliente, entre

Las aportaciones que este tipo de tecnologĂ­a puede hacer en las empresas, son encausadas a mantener el nivel competitivo de la empresa, los beneficios de la minerĂ­a como la capacidad de identificar patrones, comportamientos, reglas y relaciones en los datos, permiten realizar previsiones y encontrar nuevas soluciones o rutas de acciĂłn.

Para obtener el valor mĂĄximo de las tĂŠcnicas de minerĂ­a en las soluciones de inteligencia de negocio, es necesario contar con tecnologĂ­a que pueda llevar a cabo el proceso en tiempos satisfactorios al negocio y pueda permitir a los tomadores de decisiones, en cada nivel de su organizaciĂłn, analizar la informaciĂłn y actuar con base a los resultados obtenidos.

Referencias [ Sholom Weiss, Nitin Indurkhya,Tong Zhang & Fred J. Damerau. Text Mining.

Springer, 2005 ] [ Ian H. Witten, Eibe Frank. Data Mining: Practical Machine Learning Tools and Techniques. Second Edition ]

Dafne Rosso ha participado desde 1998 en iniciativas orientadas a la implementaciĂłn de soluciones basadas en inteligencia de negocio. Actualmente cursa el Doctorado en Ciencias Computacionales en el ĂĄrea de Sistemas Inteligentes, que se imparte en ITESM. Cuenta con una maestrĂ­a en Ciencias Computacionales del ITESM y una maestrĂ­a en TecnologĂ­as de InformaciĂłn y AdministraciĂłn del ITAM, asĂ­ como numerosos cursos de especializaciĂłn en tecnologĂ­a de punta.

www.sg.com.mx

FEB-ABR 2009

33 31

¿Cómo Surge la Necesidad de Utilizar BI en las PyMEs? Explotar los Beneficios de BI

Trabajando en un entorno cada vez más competitivo, las PyMEs ya no sólo interactúan de forma local, incluso se han aventurado en nuevas oportunidades de competencia en áreas antes totalmente desconocidas. Para lo cual se necesita explotar los indicadores de gestión, que se encargan de revisar datos procesados (históricos) para convertirlos en decisiones basadas en información clave (presente).

Un sistema de monitoreo basado en indicadores de gestión, implica la capacidad de procesar en tiempo real y a una gran velocidad, cantidades importantes de datos provenientes de diferentes fuentes y en diversos formatos para generar información precisa sobre las áreas clave de éxito de la empresa. La aplicación de herramientas BI facilita el flujo de la información, reduce el costo de hacer negocios y se convertirá en una nueva fuente de ingresos.

Sin embargo, las soluciones de TI implementadas en la mayoría de las PyMEs, corresponden a sistemas transaccionales, en algunos casos se puede contar con ERP que soportan procesos administrativos, de ven-

32

FEB-ABR 2009

tas y producción, y que generan reportes de las operaciones. Pero estas soluciones no se enfocan en los indicadores de gestión, lo que provoca que se inviertan días o meses de análisis de información para tomar decisiones de forma inoportuna o incorrecta.

Dificultades detectadas en la explotación de herramientas BI en las PyMEs Mauro González, Director de Inteligencia de Negocios de AC Group Assembler Consultants, indicó que BI son potentes sistemas implementados en las empresas más exitosas en el mundo, que resultan a veces, inaccesibles para muchas PyMEs por razones económicas o de infraestructura.

Dentro de las dificultades en la elección de herramientas BI, se encuentran que los usuarios que ya han trabajado con herramientas BI anteriormente, se inclinan por las que ya conocen o se guían por recomendaciones como las que se pudieran tomar de artículos como los publicados por Gartner;

Por Ma. Ernestina Ortíz

en lugar de evaluar los beneficios y costos de las mismas, así como los requerimientos específicos del negocio.

Las dificultades que existen en la explotación adecuada de las herramientas de BI ya implementadas son: • Uso nulo o escaso por parte de los usuarios, ya sea por dificultad en su uso, por falta de información requerida, porque no es confiable o porque al usuario no le gusta.

• Se utiliza únicamente para extraer información aunque el análisis se haga manualmente.

• Se utiliza únicamente como generadora de reportes y no se aprovechan todos sus beneficios.

• Se adquirió sólo prestigio, no por una justificación válida de una necesidad de información.

• Poca adaptabilidad de usuarios que ya han trabajado con herramientas similares.

• Dar por hecho que todos los usuarios tienen el conocimiento o el tiempo para usar estas herramientas.

www.sg.com.mx

• Si la herramienta BI está basada en hojas de cálculo, se corre el riesgo de perder calidad y consistencia en la información, ya que la fuente de datos puede ser modificada manualmente.

Consideraciones en la adquisición de BI Para adquirir una solución BI se debe: • Identificar los beneficios que la información generará, como acelerar un proceso, reducir costos o mejorar la productividad en un área en particular. No se debe enfocar en un objetivo general.

• Identificar el método de integración de información más oportuno y menos costoso.

• Incluir a los usuarios del negocio en la decisión para asegurarse que ésta será aceptada.

• Realizar un ROI con claridad definido, donde se identifiquen las necesidades del negocio abiertamente.

• Debe ser una herramienta capaz de favorecer la comunicación e interacción de las distintas entidades funcionales, para que la información generada fluya a todos los estratos donde se requiera tomar decisiones de forma perfectamente coordinada y en base a una sola fuente consolidada de información.

• La elección adecuada de la herramienta BI debe considerar comparaciones entre la plataforma, alcance, funcionalidad, tecnología y arquitectura de cada opción, lo que definirá criterios técnicos y funcionales para su adquisición.

Alternativas de BI para PyMEs Para poder explotar los beneficios de la inteligencia de negocios en las PyMEs, la alternativa más común es recurrir a las hojas de cálculo, que tienen una amplia capacidad de gestión empresarial. En esta aplicación se pueden importar datos desde otros sistemas de información (minería de datos) y monitorear los cambios en tiempo real a partir de las gráficas, con la misma efectividad que herramientas propias de BI. Esta alternativa se hace accesible porque no requiere adquisiciones adicionales como licencias o mayor infraestructura. Dentro de algunas soluciones propias de BI, ofrecidas en el mercado se encuentran: • Microstrategy Solutions for Microsoft Excel de Microstrategy.

• Cognos TM1 Midmarket Edition de Cognos • Productos de Hyperion: Hyperion Strategic Finance, Hyperion Capital, Expense Planning, Hyperion Workforce Planning, etcétera.

• Solutions for Mid Size Companies de Information Builders.

• SAS Desktop Data Mining for Midsize Business y SAS Business Intelligence for Small to Midsize Business de SAS.

Conclusión En el mundo globalizado en el que se desempeña la PYME, donde la competencia es fuerte y la posibilidad de subsistencia depende de las decisiones que se tomen por los ejecutivos, se requiere de herramientas que permitan procesar las grandes cantidades de infor-

mación de manera eficiente, para conducir la adecuada toma de decisiones. Las actividades empresariales se desarrollan diariamente, lo que requiere de un concienzudo análisis que derivará en la elección e implementación de sistemas adecuados de soporte a la decisión, como lo es la inteligencia de negocios.

Esta tarea no es sencilla, y en ocasiones requiere de grandes proyectos de reingeniería para alinear los distintos procesos del negocio. El error de automatizar o incorporar sistemas en PyMEs donde aún no se han establecido claras directrices del negocio, podría estar condenándolas al fracaso. En cambio, si se realiza un análisis minucioso de las capacidades de la empresa, sus necesidades, el presupuesto disponible y los beneficios de la herramienta, la implementación de una herramienta de BI llegará a ser exitosa.

Referencias [ Colón S. “Aplique la Inteligencia de Nego cios en su Empresa”, El Economista. 28 de febrero de 2008 ] [ topmanagement.com.mx ] [ Rodríguez M.; Sarmiento M. “Monitoreo competitivo del entorno tecnológico: Importancia de la aplicación de sistemas inteligentes”. Revista Transferencia.

Octubre 2002 ] [ Turban, E.;Aronson, J.; Liang, T. “Implementing MSS in the E-Business Era. Decision Support Systems and Intelligent Systems”. Prentice Hall 2005 ]

Ma. Ernestina Ortíz García es Licenciada en Sistemas Computacionales Administrativos en la Universidad Veracruzana, Maestría en Administración de Tecnologías de Información por parte de la Universidad Virtual del ITESM. Actualmente es Jefe del Departamento de Sistemas de la Universidad del Golfo de México, Rectoría Norte. Se interesa en lo que tiene que ver con la aplicación de la tecnología en soluciones al trabajo cotidiano, o como propuesta de mejora o innovación de procesos.

www.sg.com.mx

FEB-ABR 2009

33

Business Intelligence y Cambio Organizacional Profundizando en la Perspectiva de Análisis Por Francisco Vaca

Muchos proyectos de BI que se terminan correctamente desde el punto de vista tecnológico no cumplen sus expectativas de retorno de inversión. Creemos que uno de los factores que lo impiden es que no se tomaron en cuenta los impactos en la cultura y en la organización que supone el disponer de una nueva plataforma para organizar, hacer disponible y analizar la información.

Hace no mucho tiempo participamos en la implementación de un proyecto de BI para una empresa del sector financiero. Desde el punto de vista de ejecución del proyecto, los resultados fueron satisfactorios en tiempo, costo y funcionalidad, sin embargo, tras seis meses de operación, tuvimos que hacer una revisión del proyecto, dado que existía un bajo nivel de satisfacción en el principal patrocinador del proyecto en cuanto al cumplimiento de sus expectativas de resultados.

En un principio no se encontró ningún problema significativo ni en la operación, ni en el hardware, ni en las herramientas: la información estaba al día y “cuadraba”, el performance era adecuado, los usuarios conocían las herramientas: ¿Cómo es que tenemos un solución que “funciona” desde los puntos de vista técnico y operativo, pero que desde la perspectiva del usuario principal no cumple con sus expectativas?

Analizamos con detalle el caso de un reporte trimestral de ventas que se consideraba crítico, ya que era usado por la alta dirección, y que es un caso representativo de lo que sucedía. Esto es lo que encontramos:

34

FEB-ABR 2009

Expectativa

Situación actual

Causas

Mayor oportunidad en la entrega del reporte.

El reporte se sigue entregando en la segunda semana de cada mes.

A pesar de que existe una función para la producción automática del reporte trimestral, el reporte se produce bajo el formato antiguo de powerpoint y el proceso de revisión y ajuste no se modificó.

Mayor exactitud en los datos.

Los datos finales de ventas presentados en el reporte no coinciden con los datos del datamart.

Algunos datos son “ajustados” durante el proceso de revisión (en ocasiones hay ventas que “se guardan” para los meses malos).

En base al reporte se deciden bonos e incentivos por lo que hay una presión muy grande para que los números se “vean bien”.

Menores costos de producción de reportes.

El número de personas involucrado se mantuvo igual.

Aunque el reporte básico está automatizado los pasos de “revisión” y “ajuste” continúan siendo los mismos (hay cuatro niveles jerárquicos que participan en el proceso).

El proceso de elaboración continúa siendo manual en las etapas finales de producción.

Más tiempo disponible del equipo de análisis

El esfuerzo de producción del reporte se redujo en un 80% principalmente por automatizar el proceso de datos.

Este beneficio no se ve con claridad ya que los tiempos de entrega no cambiaron.

Otras funcionalidades de la herramienta de análisis no han sido explotadas.

www.sg.com.mx

Al estudiar las causas que provocaron que se lograra un proyecto técnicamente adecuado, pero que presenta dificultades para cumplir con las expectativas de uso son: Un enfoque tecnológico del proyecto. El líder del proyecto tenía una formación y experiencia dentro de las tecnologías de información, el presupuesto provenía del área de sistemas, prácticamente todos los miembros del equipo tenían la misma orientación técnica que el líder, el proveedor de la tecnología aportó metodología y expertise de desarrollo.

En muchos casos, las personas tenían la información, y por lo tanto la capacidad para tomar una decisión, pero al final tenían que ir “a tocar base con su jefe”, perdiéndose en el camino la posibilidad de aprovechar la capacidad plena de las herramientas.

95% del esfuerzo y de los recursos se dedicaron a la tecnología: selección y puesta a punto del hardware, a la selección del proveedor de la tecnología, a los procesos de ETL.

Se dió prioridad a resolver las necesidades de los analistas. El esfuerzo de análisis y de definición de requerimientos se realizó fundamentalmente desde la perspectiva de analistas y procesadores de información; la visión del alto directivo quedó únicamente reflejada en un conjunto de reportes, que si bien basados en las necesidades declaradas por los directores, no tomó en cuenta sus “usos y costumbres” del proceso real para tomar decisiones.

La capacitación se enfocó exclusivamente al uso de las herramientas de explotación.

Para elevar el nivel de uso, y por lo tanto de éxito del proyecto, recomendamos lo siguiente:

El involucramiento de usuarios se enfocó en resolver las necesidades y los problemas de desarrollo del proyecto, por lo que los temas asociados al uso no fueron evidentes en las fases de desarrollo.

Ampliar la perspectiva de análisis al considerar el contexto de toma de decisiones. El alcance del proyecto debe considerar aspectos de cambio organizacional, de forma que se puedan hacer ajustes en roles, responsabilidades y procesos de toma de decisiones.

El enfoque metodológico se basó en determinar y resolver las necesidades de información, y se estudió muy poco el contexto de toma de decisiones.

Expectativas de resultados asociadas a la calidad y disponibilidad de los datos. Los usuarios y los miembros del equipo del proyecto pusieron muy poco énfasis en el uso de los datos, ya que el problema que se definió era la disponibilidad y oportunidad de los mismos. Se supuso que no habría problema en el “uso” de los mismos.

No se tomaron en cuenta los cambios organizacionales que necesariamente provocaría la implementación del proyecto. El más importante de todos ellos consiste en que se trataba de una organización altamente “jerárquica”, y la disponibilidad generalizada de la información, suponía cambios en la estructura de poder que implicaba una redefinición de roles y responsabilidades.

• Definir los cambios en las estructuras formales e informales de toma de decisiones que permitirán aprovechar las ventajas del proyecto. Algunas de estas ventajas tienen carácter estratégico.

• Definir quiénes pueden tomar decisiones y diseñar esquemas de incentivos que alienten la toma de decisiones.

• Demostrar que tomar decisiones basadas en hechos, reduce la incertidumbre en base a experiencias exitosas.

Alinear expectativas de los usuarios finales en cuanto al uso de las herramientas.

No es posible tener un Ferrari y manejarlo como si tuviéramos un “vochito”, debemos hacer ajustes en los hábitos de conducción si se desea maximizar la experiencia de conducir un Ferrari.

• Mejorar las competencias estadísticas y matemáticas.

• Mejorar la capacidad de hacer preguntas y plantear hipótesis.

• Mejorar la capacidad para “explorar” en los datos.

Entrenar a alta dirección en los procesos de toma de decisiones utilizando las herramientas. Tradicionalmente los resultados se muestran en “powerpoints”, pero ahora se puede presentar y analizar mediante la herramienta OLAP. • Capacitar en el proceso de sesiones de análisis en tiempo real.

• Capacitar en el uso de las funciones y capacidades de análisis visual que muchas herramientas ofrecen (colores, tamaños, formas, tipos de gráficas).

• Capacitar en procesos formales de análisis y toma de decisiones.

Buscar pequeños éxitos y difundirlos ampliamente. Tenemos que demostrar cómo las nuevas herramientas agregan valor a la empresa, y que la “forma tradicional” es mucho menos efectiva que la “nueva forma” de tomar decisiones; que no es más compleja sino más simple, que no lleva más tiempo sino menos. Muchas personas que tengan una postura de escepticismo frente a la solución, pueden cambiarla al ver a otros tener éxito. Tratamos de publicar casos que tengan alguna característica de estas: • Se redujo el tiempo para tomar la decisión porque fue más simple.

• Se incrementa la satisfacción del cliente debido a que el método de tomar decisiones es más efectivo (tomó menos tiempo, el diagnóstico fue más preciso).

• Se optimiza un proceso debido a que se pudo analizar desde diversos puntos de vista.

Referencias [ Adelman, Sid. 2003. Impossible Data Warehouse Situations. Addison-Wesley. ] [ Biere, Mike. 2003. Business Intelligence for the enterprise. IBM Press. ] [ Davenport, Thomas, Jeanne Harris, David DeLong y Alvin Jacobson. 2001.

Data to knowledge to results. California Management Review. ]

Francisco Vaca Gómez es socio director de TEDE de 2006 a la fecha. Ha realizado diseño e implementación de proyectos de educación basados en competencias, instrucción de programas educativos, investigación y promoción de la educación basada en competencias

www.sg.com.mx

FEB-ABR 2009

35

// publireportaje

SEPG LA 2008 Memoria del evento

Del 12 al 14 de noviembre se llevó a cabo la quinta edición de la conferencia SEPG LA 2008 (Software Engineering Process Group Latin America) en Mar del Plata, Argentina; a la cual tuvimos la oportunidad de asistir. Esta conferencia es organizada anualmente por el European Software Institute (ESI) en conjunto con el Software Engineering Institute (SEI), y coordinada por el anfitrión local, en este caso: el ESI Center Cono Sur. Este año el tema de la conferencia fue “Combinando Disciplina con Métodos Ágiles”, teniendo como objetivo apoyar a las empresas para que sean capaces de ofrecer respuestas ágiles a las necesidades de sus clientes y adaptarse rápidamente a las nuevas tecnologías. La conferencia se centró en las lecciones obtenidas de varias experiencias en el campo de la mejora de procesos de software, especialmente en América Latina, pero también en todo el mundo.

La bienvenida del evento contó con la participación de Paul D. Nielsen, Director y CEO del SEI, Manu Prego, Director General del ESI, Guillermo Leruga, Presidente del ESI Center Cono Sur, Carlos Gianella, Presidente de la Comisión de Investigaciones Científicas (CIC), Miguel Ángel Calello, Presidente de la Cámara de Software y Servicios Informáticos (CESSI), Gerardo Renzetti, Director de Servicios del ESI Center Cono Sur y Jesús Salilllas, Chair Comité de Programa.

La audiencia El SEPG LA es un congreso dirigido a profesionistas implicados en actividades de mejora sistemática de personas, procesos y tecnologías en organizaciones donde el software es un elemento clave para la consecución del éxito empresarial. Durante esta quinta edición pudimos ver desde reconocidos gurús, hasta profesionistas que se inician en temas de procesos de software y sistemas. Una situación peculiar que observamos, fue que este congreso ha desarrollado una comunidad de profesionistas que año con año asisten a encontrarse con sus colegas, aportando al evento un ambiente de amistad y compañerismo.

La agenda El programa estuvo compuesto por conferencias magistrales, sesiones, paneles de discusión y seminarios sobre temas adaptados a la realidad de América Latina: disciplina con métodos ágiles, competitividad en el mercado global de TI, mejora de procesos en situaciones de estrés, preparación para evaluaciones, y mejora de procesos en

entornos pequeños, entre otros. Empresas como Motorola, TATA e IBM, compartieron sus experiencias; y ponentes del SEI, ESI, así como de empresas de consultoría y universidades, nos ofrecieron una agenda variada y de interés para todos los niveles.

La expo El espacio ideal para lograr un networking entre los asistentes, es la expo, que en esta ocasión cumplió su objetivo. Contó con 13 stands; y en medio de un ambiente bastante agradable, permitió a los asistentes tanto conocer la oferta de los expositores como contactar a nuevos colegas.

El evento social Al término del primer día se ofreció un coctel de apertura en el área de expo, contando con un performance acompañado de luces y música, disfrutamos el momento ideal para “romper el hielo”. Al término del segundo día y como evento de cierre, asistimos a una cena de gala, en la que nos dejamos deleitar por cantantes y bailarines de tango, y saboreamos la excelente comida argentina. Por si

Cabe mencionar que esta edición de SEPG LA, contó con el apoyo del gobierno de Argentina, el patrocinio de la CIC y de empresas como CDA, Apertura - Information Tecnlology, Liveware Ingeniería de Software, Grupo Tekne, BMC Software, Oracle y SITEPRO. Así como con el apoyo de múltiples organismos y universidades locales.

36

FEB-ABR 2009

www.sg.com.mx

fuera poco, nos sorprendió el gran entusiasmo de los asistentes, ya que todos bailamos y cantamos por un buen rato.

La sede Durante las fechas de la conferencia, en la ciudad de Mar del Plata se llevó a cabo una muestra de cine, así como un evento deportivo estudiantil, dando a la sede un panorama tecnológico, cultural y deportivo, con vista al mar. Los anfitriones se lucieron por su gran hospitalidad, desde los organizadores hasta los mismos argentinos que asistieron al congreso, quienes no se cansaron de atendernos y apoyarnos en todo lo necesario.

La participación del ESI El ESI es una organización sin fines de lucro que se lanzó como una iniciativa de la Comisión Europea, con el apoyo de diversas organizaciones europeas de TI, y desde 2003 forma parte de Tecnalia, una de las principales corporaciones tecnológicas privadas en Europa.

En 2002 creó la Red ESI Center, con el objetivo de facilitar el acceso mundial a sus servicios.

Es mediante esta red que llega a América Latina, y como parte de dicho esfuerzo, organiza anualmente la conferencia SEPG LA.

www.sg.com.mx

“La principal actividad del ESI se centra en apoyar a las empresas en sus objetivos de producir software de mayor calidad, con menor esfuerzo y menor costo”, nos comentó su Director Manu Prego, que además nos compartió datos muy interesantes sobre la visión del ESI. Por ejemplo, mencionó que el ESI asigna gran porcentaje de sus ingresos a investigación y desarrollo, actividades enfocadas a desarrollar productos que ayuden a las empresas a ser más maduras y productivas. “Ya hay suficientes modelos en el mercado, el problema real de las empresas es cómo ponerlos en práctica. En esa área el Instituto no desarrolla nuevos modelos, sino proyectos que ayuden a las empresas”, comentó Manu.

Entre sus productos más recientes se encuentra IT Mark, enfocado en mejorar los procesos de software en las empresas pequeñas, cubriendo áreas como mercadotecnia, comercialización y finanzas.

Para conocer más sobre esta conferencia visita: www.esi.es/SEPGLA

FEB-ABR 2009

37

// PRÁCTICAS

/*arquitectura empresarial*/

Enterprise Architecture Estrategia + Negocio + Tecnología Por Jaime Ruíz

Proceso 1

/FHPDJPT

Proceso 2 Proceso 3

*OGPSNBDJwO Flujo de Datos

Reutilización de Objeto

Diccionario de Datos

Sistemas

4JTUFNBT

Servicios Web

La ejecución adecuada de esta disciplina reduce de manera significativa la brecha entre el desempeño deseado y el real porque, a través de un mapa global, integra y administra todas las áreas de una organización. Lo que también le permite analizar el impacto de los cambios, tomar decisiones clave de negocio y asegurar mejoras sin afectaciones catastróficas.

Como se aprecia en la figura 1, la arquitectura empresarial consiste de un repositorio de modelos y documentos integrados bajo tres perspectivas: Estrategia (Strategy), Negocio (Business) y Tecnología (Technology), lo cual se representa por la fórmula EA = S+B+T. Cada perspectiva describe el estado actual, el estado futuro y la brecha entre ambos.

El objetivo de todo esto es tomar decisiones estratégicas efectivas para mejorar la calidad, eficacia y responsabilidad del negocio, así como responder de manera rápida y positiva a las oportunidades y desafíos del mercado, consolidaciones del sector y avances tecnológicos.

3FEFT

&" 4 # 5

Iniciativa Estratégica 2

Aplicaciones

La arquitectura empresarial es la disciplina que define y mantiene los modelos e iniciativas para llevar, tanto al área de negocio como a la de TI, a trabajar juntas para lograr la estrategia corporativa. En pocas palabras, la arquitectura empresarial alínea la tecnología a las necesidades reales del negocio.

le permitirá identificar los servicios reutilizables, diseñar esquemas de orquestación y, lo más importante, definir pautas para implantar el esquema de gobernabilidad, del cual depende el éxito de este tipo de iniciativas.

Iniciativa Estratégica 1

&TUSBUFHJB

/FHPDJP Z "MJOFBDJwO EF 5FDOPMPHrB

No es ningún secreto que los proyectos de TI comúnmente se retrasan o cuestan más de lo planeado. Pero aún peor es cuando dichos proyectos no logran cumplir los objetivos de negocio deseados. Esto típicamente se debe a falta de alineación entre la estrategia, los procesos de negocio, y las tecnologías de información. Y justamente ese es el problema que busca resolver la disciplina de la Enterprise Architecture (EA), o arquitectura empresarial.

Una arquitectura empresarial incluye: • Modelos de procesos de negocio, información, sistemas y tecnología.

• Descripciones de artefactos gráficos y textuales.

• Trazabilidad total de las metas y objetivos de la organización.

• Estándares que respaldan el contenido y presentación de la arquitectura.

Red de Datos Red de Voz Red de Video

Una arquitectura empresarial bien integrada proporciona capacidad para responder a los cambios; costos reducidos en la gestión de infraestructura de TI; mejor comunicación, procesos y análisis de negocio; respuestas rápidas, eficaces y positivas; mapas de la organización, indispensables en iniciativas de SOA o reingeniería de procesos.

Figura 1. EA alinea estrategia, negocio y tecnología.

Toda organización que encamine sus esfuerzos hacia una arquitectura orientada a servicios (SOA) tendrá que recurrir al EA. Es ahí donde encontrará los mapas y documentación de procesos de negocio y sus interrelaciones con los dominios de estrategia y tecnología. Además, Marco Preliminar

A Visión Arquitectónica H Gestión de Cambios de Arquitectura

G Implementación de Gobernabilidad

B Arquitectura de Negocios

C Sistemas de Información

Requerimientos

F Planeación de Migración

2 Considerar Vistas

1 Crear Baseline E Oportunidades y Soluciones

8 Análisis de Brecha

3 Crear Modelo Arquitectónico

D Arquitectura Tecnológica

4 Seleccionar Servicios

7 Definir Arquitectura

6 Determinar Criterios

5 Confirmar Objetivos de Negocios

Figura 2. Architecture Development Method (ADM).

Jaime Arturo Ruiz García es Director General de Matersys Group, consultoría especializada en Tecnologías de la Información y Comunicación. Su éxito: soluciones de vanguardia y a la medida de sus clientes. jruiz@matersys.com

38

FEB-ABR 2009

www.sg.com.mx

El marco de referencia TOGAF

Uso de herramientas

El marco de referencia TOGAF, desarrollado por The Open Group, se ha convertido en el paradigma con mayor aceptación para desarrollar arquitecturas empresariales. A diferencia de otros marcos de referencia como por ejemplo el de Zachman, TOGAF no sólo es un marco para categorizar los elementos que hay que capturar, sino que también define un método para hacer las cosas. Dicho método es el Architecture Development Method (ADM), el cual define cómo desarrollar, implementar y mantener una arquitectura empresarial. El ADM funciona en conjunto con las notaciones y técnicas de modelado más populares tales como Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), modelado de datos, e IDEF.

Si vas a desarrollar y mantener la arquitectura empresarial de una organización no trivial, te recomiendo que utilices una herramienta especializada para esto. En el mercado existen herramientas que permiten utilizar métodos y técnicas de modelado estándar para generar un repositorio de modelos donde se administra la arquitectura empresarial de una organización.

La figura 2 ilustra los pasos y flujo del ADM para desarrollar y mantener una arquitectura empresarial.

www.sg.com.mx

La figura 3 muestra una imágen de Telelogic System Architect, una de las herramientas para EA más populares.

Conclusión Aunque EA no es la panacea de todos los males por los que una organización puede sufrir, es sin duda el mejor mecanismo para aglutinar y alinear los diferentes dominios de la organización. y ante todo dar un sentido estratégico y de beneficios reales a iniciativas de mejora de procesos, reingeniería y apego a estándares y normas de la industria como son: CMMI, ITIL, COBIT y SOX entre otros.

Referencias [ TOGAF. opengroup.org/togaf ] Figura 3. Modelado de EA con System Architect.

FEB-ABR 2009

39

// PRÁCTICAS

/*requerimientos*/

Cuando los Casos de Uso no Alcanzan Antipatrones en la Concepción de CU Por Carlos Ortega

Mucho se ha escrito sobre los Casos de Uso, ¿qué son?, ¿para qué sirven?, ¿cómo se pueden identificar?, etcétera. Uno puede encontrar en cualquier biblioteca, navegando por Internet o en una tienda electrónica como Amazon, decenas de artículos y bibliografía especializada sobre el tema. De hecho, emplear casos de uso se ha vuelto la técnica de captura de requerimientos más popular.

La facilidad de concepción y diagramado los ha vuelto algo así como un sinónimo de “que se tratan de hacer las cosas con calidad” o que se emplea “algo” de ingeniería o procesos de software.

Ahora bien, quienes nos hemos dedicado a desarrollar software y empleado esta técnica de manera intensiva en algún proyecto mediano o grande, seguramente nos encontramos con particularidades donde claramente se perciben los beneficios y limitaciones de los casos de uso. El presente artículo está dedicado a describir varias de estas situaciones.

Para iniciar esta discusión, permítanme ser claro sobre lo que varios consultores, e incluso personal de nuestros clientes, observamos durante la ejecución de diferentes proyectos en los que hemos tenido la oportunidad de participar, y en otros que conocemos de manera indirecta, y esto es: La falta de conocimiento formal que predomina en nuestra industria sobre lo que es un caso de uso, cómo debe describirse, para qué sirve y para qué no sirve.

Podría parecer aventurada dicha afirmación (personalmente desearía que así lo fuera). Sin embargo, la cantidad de sistemas y proyectos que arrastran tal problema es bastante grande.

Este artículo no pretende explicar estos conceptos, ni tampoco desea exponer las razones de esta debilidad, sino sólo enumerar los problemas y antipatrones particulares. Algunos de los cuales citamos a continuación.

Errores y antipatrones comunes • Considerar que la interacción/comunicación que se muestra en los diagramas de CU donde aparece algún CU vinculado a uno o varios actores es sinónimo de flujo de datos.

• Considerar un subflujo como un caso de uso.

Ejemplo: · CU Alta de Cliente, CU Baja de Cliente, CU Consulta de Cliente • Considerar la “regla de oro” para entidades: Un CU debe exhibir forzosamente una funcionalidad “ABC” completa (Altas, Bajas, Cambios ).

Ejemplo: · CU Ventas: - Subflujo Altas de Órdenes de Compra - Subflujo Bajas de Órdenes de Compra - Subflujo Cambios de Órdenes de Compra • Para considerar qué es incorrecto o no, deben existir líneas con cabezas de flecha asociando a un Actor con un CU. • Considerar a la sección de precondiciones dentro de la descripción del CU como útil para incluir cualquier situación o evento que deba existir antes para iniciar un CU. Ejemplo: · Para que se de el CU “Administrar Órdenes de Compra”, debe tenerse como precondiciones: - Que el vendedor esté autenticado en el sistema - Que exista un catálogo de artículos - Que exista una interfase con el sistema que maneja el catálo go de artículos - Que exista la comunicación con el sistema que maneja el

catálogo de artículos • Incluir detalles de diseño o de bajo nivel dentro de la especificación de CU. Ejemplos: · El sistema debe conectarse con el sistema de administración de inventarios y obtener de la tabla “artículos” el artículo X utilizan do el articuloID como llave foránea... · El usuario da click en el campo “Artículos de Oficina” y selecciona la categoría del combo “categoría” · El sistema debe actualizar la tabla tarjetahabiente utilizando el query “select * from...”

Carlos Ortega es consultor en metodologías y prácticas ágiles(XP,TDD, Refactoring, Pair programming) cuenta con certificaciones en RUP, OOAD, UML, etcétera. Certified Profesional Software Architect ambos avalados por el SEI. Ha colaborado en numerosos proyectos para diversas organizaciones como el Banco de México, Banco Azteca, Fandelli, Oracle, IMSS,Heinson, Accenture,EDS.Actualmente colabora con Software Ágil, empresa dedicada al tutelaje e implementación de metodologías ágiles (SCRUM, XP, Cristal).

40

FEB-ABR 2009

www.sg.com.mx

“La facilidad de concepción y diagramación han convertido a los CU en sinónimo de hacer las cosas con calidad”.

• Considerar que el comportamiento de uno o varios de los elementos de la interfase gráfica asociada son reglas de negocio.

sico son más que suficientes, frente a esto solo hay un 2 puntos que también se invita a considerar:

• Considerar como “regla de oro” que no es necesario incluir un documento de requerimientos no funcionales, si estos se pueden cubrir totalmente incluyendo una sección llamada “requerimientos no funcionales” en la descripción de los CU.

1. Ni Internet ni ningún libro poseen todo el conocimiento. Muchas veces la exposición e intercambio de experiencias e ideas con otros consultores y asistentes puede proporcionar una mayor variedad, profundidad o enfoque de los temas y conceptos.

• Creer que los lineamientos que están descritos en un proceso sobre algún formato específico son inamovible (aún cuando sea muy difícil emplearlo, no tenga sentido, o simplemente existan maneras alternativas que pueden proporcionar mayores beneficios).

2. Al desear que un solo asistente pretenda dispersar internamente el conocimiento a otros miembros del equipo, puede ser contraproducente, sobre todo considerando que es posible que al intentar replicar la capacitación se reproduzcan también dudas, malas interpretaciones o conceptos aún no entendidos totalmente, esto es, se desvirtúan los conceptos al pasar de boca en boca sin un pleno dominio del tema.

• Y finalmente, lo que desde mi punto de vista es uno de los más grandes errores: Creer que la única forma de capturar requerimientos funcionales es utilizar CU. Seguramente para muchos lectores estas descripciones (y otras más) les resultarán familiares, y para otros más les será una sorpresa saber que muchos conceptos o prácticas que aplican tan vehemente en sus proyectos en realidad son errores, fallas o antipatrones comunes de concepción o aplicación.

Como éste artículo no pretende incendiar los ánimos para indicar si algo está bien o no, sino sólo realizar sugerencias para ampliar y enriquecer el conocimiento de los roles que capturan, analizan y administran requerimientos, a continuación se hacen las siguientes recomendaciones.

Sugerencias y recomendaciones • Estudiar bibliografía de Ingeniería de Requerimientos y no sólo de casos de uso. Acceder también a bibliografía de diferentes autores. · Al investigar, el lector podrá constatar que los CU no es la única técnica para capturar requerimientos, y que en diversas situaciones tales como cuando exista poca interacción actores-sistema o cuando se trata de interfases de usuarios ricas y complejas manejadas por una gran cantidad de eventos, el tratar de utilizar CU resultará en tareas improductivas o muy costosas.

• Asistir a entrenamiento formal. · Es muy posible que muchos directores, gerentes y líderes, consideren que no es necesario si existe Internet. Hay libros sobre el tema y quizá con uno o dos recursos que asistan a un curso bá-

www.sg.com.mx

• Pensar “out-of-the-box”: Muchas veces queremos, deseamos o prometemos capturar los requerimientos funcionales utilizando sólo CU, esto es lo mismo que pensar: porque tengo un coche puedo tomarlo e ir de vacaciones a cualquier parte en él. Ciertamente es posible ir a Cuernavaca, Pachuca, Toluca, Puebla, Querétaro y Guadalajara, sin embargo, si quiero tomar vacaciones en Tijuana, San Francisco, Bogotá o Río de Janeiro, quizá ir en coche no resulte la mejor o más inteligente opción; en términos de los tiempos costos y esfuerzo asociado.

• Tratar de tocar mas de un dominio, esto es, tratar de intervenir o conocer proyectos en dominios o industrias tradicionales donde existan diferentes conceptos y procesos que por su naturaleza resulten en un reto para su conceptualización, tratamiento y comprensión.

• Relacionarse con otros analistas con diverso background y experiencia.

Referencias [ Leffingwell, Dean;Widrig, Don. “Managing Software Requirements A Use Case Approach”. Addison Wesley ] [ Adolph, Steve; et. al.”Patterns for Effective Use Cases”.

Addison Wesley ] [ Palmkvist, Övergaard.“Use Case Patterns and Blueprints”.

Addison Wesley Professional]

FEB-ABR 2009

41

// PRÁCTICAS

/*MEJORA DE PROCESOS*/

COMPETISOFT

Mejora de Procesos de Software en Iberoamérica Por Ma. Julia Orozco, et. al.

Este artículo resume el proyecto iberoamericano COMPETISOFT que tiene como objetivo incrementar la competitividad de las PyMEs en el desarrollo de software.

COMPETISOFT Es un proyecto financiado por CYTED, programa internacional de cooperación científica y tecnológica multilateral, de ámbito iberoamericano que tiene como propósito incrementar el nivel de competitividad de las PyMEs iberoamericanas productoras de software mediante la creación y difusión de un marco metodológico común que, ajustado a sus necesidades específicas, llegue a ser la base sobre la que se pueda establecer un mecanismo de evaluación y certificación de la industria del software reconocido en toda Iberoamérica.

El proyecto fue dirigido por el Dr. Mario Piattini de España y la Dra. Hanna Oktaba de México.

Se buscó recoger el conocimiento de más de 100 investigadores de países como España, México, Brasil, Argentina, Uruguay, Colombia, Ecuador, Costa Rica, Chile, Perú, entre otros.

En el proyecto se plantearon los siguientes objetivos específicos: • Generar un marco metodológico común iberoamericano • Difundir la cultura de procesos mediante la formación de investigadores, docentes y profesionales.

• Incidir en los diferentes organismos de normalización y certificación de los países iberoamericanos, para que asuman que los principios metodológicos, objeto de este proyecto puedan ser la base para establecer un mecanismo común y mutuamente reconocido de evaluación y certificación de la industria del software iberoamericana.

Marco metodológico

Categoría

COMPETISOFT es una iniciativa integradora que ha tomado como base a modelos y mejores prácticas ya existentes, los cuales han sido mejorados y adaptados con las experiencias de los investigadores, PyMEs y unidades gubernamentales.

Considera un modelo de referencia de procesos, un modelo de mejora de procesos y propone usar como marco general para la evaluación a la norma internacional ISO/IEC 15504: Performing an Assessment.

Alta Dirección (DIR)

Gestión de Negocio Categoría

Gerencia (GER)

Gestión de Procesos Gestión de Cartera de Proyectos Gestión de Recursos · Humanos · Bienes, Servicios e Infraestructura · Conocimiento Categoría

Operación (OPE)

Administración del Proyecto Desarrollo de Software Mantenimiento de Software

.PEFMP EF 1SPDFTPT

Experiencia de las unidades gubernamentales

Experiencia de las PyMEs

Experiencia de los investigadores

Modelo de Referencia

MoProSoft EvalProSoft CMMI ISO 15504 ISO 12207

Modelo de Evaluación

Métrica v3 Agile SPI

mps Br. MARES

IMPACT

Modelo de Mejora

7JTJwO (FOFSBM

Modelo de procesos o modelo de referencia El modelo de referencia de COMPETISOFT, está basado en MoProSoft que establece tres categorías que agrupan procesos de acuerdo a la estructura típica de una organización: Alta Dirección, Gerencia y Operación.

La categoría de Alta Dirección, establece la razón de ser, lo que se desea alcanzar y las estrategias para lograrlo en un plan estratégico.

La categoría de Gerencia, se encarga de crear planes de acción para instrumentar las estrategias en cuanto a proyectos, procesos y recursos necesarios para alcanzar los objeti-

vos estratégicos. La categoría de Operación, se encarga de llevar a cabo los proyectos de desarrollo y mantenimiento de software establecidos en la categoría de Gerencia.

Gerencia monitorea y retroalimenta a la categoría de Operación, y retroalimenta la de Alta Dirección.

COMPETISOFT enfatiza la diferencia entre la Gestión de Cartera de Proyectos (Gerencia) que coadyuvará en el cumplimiento del Plan Estratégico y el Proceso de Administración del Proyecto (Operación) que se enfoca en cumplir con los compromisos establecidos con el cliente en tiempo y costo.

COMPETISOFT agrega en la capa de operación el proceso de Mantenimiento de Software, el cual tiene como objetivo llevar a cabo de forma ágil los cambios solicitados a un producto de software de tal forma que no se pierda la consistencia, y que cumpla con las necesidades del cliente. Permite los cambios durante el camino, y considera una retroalimentación constante con el cliente junto con una entrega rápida y periódica de atención a las peticio-

Ma. Julia Orozco es directora Técnica de Ultrasist participante en el proyecto COMPETISOFT como investigadora, instructora de instructores y coautora del libro: “Competisoft Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos”.

Claudia Alquicira es responsable del Grupo de procesos de Ultrasist participante en el proyecto COMPETISOFT como investigadora, instructora de instructores y coautora del libro: “Competisoft Mejora de Procesos Software para Pequeñas y Medianas Empresas y Proyectos”.

42

FEB-ABR 2009

www.sg.com.mx

El proceso de mantenimiento considera una fase de preparación en la cual con base en el plan de proyecto, se asignan los roles, se definen criterios, formas de trabajo y mecanismos de comunicación. Una petición de modificación puede ser una solicitud de cambio (perfectivo, adaptativo y preventivo) o un informe de problema correctivo urgente, o no urgente.

Considera el mecanismo para recibir, analizar y dar seguimiento a las peticiones de modificación. Las peticiones se atienden por grupos en ciclos, los cuales se clasifican en planificable y no planificable. Cada ciclo es conocido en COMPETISOFT como SprintM. La definición está basada en Sprint de SCRUM. Cada ciclo considera la selección, análisis de las peticiones, intervención, pruebas y paso a producción. Incluye actividades para dar seguimiento al registro de las peticiones, obtener el estado de avance y posibles problemas que puedan ocurrir dentro de su ejecución, identifica qué se puede mejorar en la solución del próximo grupo de peticiones.

Modelo de mejora de procesos El modelo de mejora está basado en Agile SPI. Define los elementos necesarios para conducir la mejora de procesos en una pequeña organización de software de una forma ágil, económica, con pocos recursos y en poco tiempo.

Incluye un proceso de mejora denominado PmCOMPETISOFT, una metodología para la evaluación interna de procesos y una guía para formular y ejecutar mejoras usando SCRUM.

PmCOMPETISOFT está basado en un enfoque iterativo e incremental, de tal forma que se pueda tener una entrega temprana y continua de mejoras que den visibilidad de los resultados a la Alta Dirección.

El proceso de mejora continua considera ciclos de mejora en donde cada uno incluye las actividades de instalación, diagnóstico, formulación de mejoras, ejecución de mejoras y revisión del ciclo.

Las iteraciones son priorizadas

nes de mantenimiento que permita cumplir con los niveles de servicio solicitados.

Iteración de Mejora 1

La guía del consultor PmCOMPETISOFT Se generó el perfil base para la categoría de Operación para las empresas que inician en un programa de mejora con los procesos de Desarrollo de Software, Mantenimiento de Software y Administración de Proyecto.

Incluye PmCompetisoft.

En el perfil base se ajustaron los procesos de la categoría de Operación para ser implantados en una organización sin necesidad de los demás procesos.

Referencias

Iteración de Mejora 2

Iteración de Mejora 3

Iteración de Mejora n

1SPZFDUP P $JDMP EF .FKPSB

Otros componentes Durante el proyecto se generaron plantillas de apoyo para el proceso de desarrollo de software como: • Plantilla para Especificación de Requisitos.

• Lista de chequeo de Casos de Uso (Nivel conceptual).

• Guía para preparar el documento de Requisitos.

• Plantilla para generar el Plan de Pruebas.

• Lista de chequeo del Plan de Pruebas.

• Guía para generar el Plan de Pruebas de Sistemas.

Un cuestionario para el diagnóstico del estado del proceso de Administración del Proyecto.

[

Oktaba, H.; Piattini, M.; Pino, F.; Orozco, M.J; Alquicira, E. COMPETISOFT. “Mejora de Procesos de Software para Pequeñas y Medianas Empresas y Proyectos”. 2008.

Madrid España, RA-MA Editorial. ]

[

Oktaba, H. “MoProSoft: A Software Process Model for Small Enterprises”. Proceedings of International Research Workshop for Process Improvement in Small Settings”. 19-20 de octubre 2005. pp.93-101. Pittsburgh, EEUU. SPECIAL REPORT CMU/SEI-2006SR-001. ]

[

Oktaba, H.; García, F.; Piattini, M.; Pino, F.; Alquicira, C.; Ruíz, F. “Software Process Improvement: The COMPETISOFT Project”.

October, 2007. Vol. 40(10), pp. 21-28. IEEE Computer]

[

NYCE. “Modelo de Procesos para la Industria de Software - MoproSoft - Versión 1.3”.

Agosto 2005. NMX-059/03-NYCE-2005. Ciudad de México, Organismo nacional de normalización y evaluación de la conformidad -NYCE. normalizacion-nyce.org.mx/php/ loader.php?c=interes.php&tema=21 ]

Oswaldo Gómez consultor de Ultrasist participante en el proyecto COMPETISOFT como autor de capítulo “Mediciones del Software y su implementación en el Modelo de Procesos de COMPETISOFT”.

Alejandro Ramírez consultor de Ultrasist cuenta con un posgrado en Ciencia e Ingeniería de la Computación, UNAM, México, 2007, que fueron tomadas en cuenta en el modelo COMPETISOFT.

www.sg.com.mx

FEB-ABR 2009

43

// PRÁCTICAS

/*aseguramiento de calidad*/

Implementación de Modelos de Calidad Diagnóstico de las Empresas Desarrolladoras de Software en México Por Edna Gutiérrez, et. al.

Este artículo analiza el entorno de los modelos de calidad de software para las empresas mexicanas. En el marco del desarrollo de la tesis de la alumna Edna Gutiérrez Gasca para la Maestría en Ciencias de la Computación, en el año 2007 se realizó un diagnóstico del conocimiento y uso de modelos de calidad en empresas desarrolladoras de software. Este artículo presenta los resultados obtenidos en dicha investigación.

Acerca del instrumento de medición El instrumento de medición utilizado fue un cuestionario donde se obtenía información sobre las características de la empresa, el proceso de desarrollo de software que aplican, la forma en que manejan las entregas, y el proceso que utilizan para evaluar la calidad del producto.

La población objeto fueron empresas desarrolladores de software con centros de operación en México. La convocatoria para que se contestara la encuesta se realizó con el apoyo de la revista SG, la hoy extinta AMCIS, y el Tec de Monterrey Campus Ciudad de México.

En total, 114 empresas respondieron la encuesta, siete fueron descartadas debido a que no contestaron el cuestionario en su totalidad. El nivel de confianza resultó de 96%, con un error máximo admisible de 10%, considerando una población de 1,243 empresas, según datos proporcionados por el Directorio de Empresas de Tecnologías de Información (DETI).

Análisis e interpretación de los resultados • Tipo de empresa. 55% de las empresas que contestaron la encuesta, desarrolla software a la medida, mientras que 33% su giro no es específicamente el software, pero lo desarrollan, y 12% pertenecen al giro de desarrollo de software empaquetado. En base a esto se establece que 88% de las empresas de software en México lo desarrolla de acuerdo con las especificaciones del cliente y sólo 12% restante desarrolla software para un mercado abierto.

• Cantidad de personal involucrado en la elaboración del producto.

Como se aprecia en la tabla 1, el número de personas involucradas en la elaboración de software es muy pequeño, ya que más de un tercio de las empresas encuestadas cuentan con menos de cinco personas para la realización de software.

Número de personas

Menos de 5 6 a 10 11 a 20 Más de 20

% de empresas 36% 28% 15% 21%

Tabla 1. Personas involucradas en la elaboración de software.

44

FEB-ABR 2009

El resultado muestra que son pocos los recursos humanos asignados por las empresas para la ejecución del proceso de desarrollo y mantenimiento de software. Según la norma NMX-059/03-NYCE2005 (MoProSoft), este proceso requiere de al menos nueve roles diferentes. Esto provoca que las personas desempeñen distintos roles, lo cual se traduce en documentación incompleta y la concentración en actividades operativas, como la codificación del producto para cumplir con los requerimientos del cliente.

Proceso de desarrollo de software utilizado De acuerdo con la investigación, 71% de las empresas utilizan un proceso o metodología, mientras que el 29% restante considera al desarrollo de software como un proceso creativo que no puede ajustarse a una metodología.

Al ampliar la respuesta definiendo cuál metodología utilizan, encontramos que el primer lugar lo ocupan las “metodologías propias”, seguido de las “metodologías ágiles” entre las que destacaron XP, SCRUM y metodología en espiral, y en tercer lugar los “modelos y normas establecidas”, como: CMM, CMMI, ISO 9000:2000 y PMBOK. Resalta que este último grupo no distingue entre modelo y metodología. Un modelo es un marco de referencia que responde a la pregunta: ¿qué se debe hacer?, mientras que la metodología está asociada a la pregunta ¿cómo debe implantarse?

Metodología

% de empresas

Propia Métodos ágiles Modelos establecidos

45.41% 41.25% 13.34%

Tabla 2. Metodología utilizada.

Calidad de la documentación La investigación arroja que más de la mitad de las empresas que participaron en la encuesta (53%) consideran que la documentación generada por ellos no es de calidad.

La determinación de que la documentación no es de calidad está referida a que sólo se documenta el manual de usuario por falta de recursos humanos especializados, y por considerar a la documentación como elemento accesorio y no como la evidencia de la realización de un proceso, ejecutándose una vez terminado el producto software. Algunas empresas incluso, carecen de documentación, por considerar que sus productos son pequeños.

Finalmente, las que sí cuentan con ella argumentan que los documentos generados en el proceso están desfasados contra la funcionalidad implantada en el producto. www.sg.com.mx

En contraparte, existe un porcentaje de empresas que consideran que su documentación sí es de calidad (47%), principalmente en aquellos casos en que la documentación técnica se hereda y se reutiliza.

Modelos de calidad utilizados La tabla 3 refleja los modelos de calidad utilizados por las empresas encuestadas.

Modelo

Ninguno CMM/CMMI MoProSoft ISO 12207

% de empresas 71% 22% 6% 1%

Si partimos del hecho que la condición de terminación de una iteración es la generación de un entregable (prototipo), se concluye que la mayor parte de las empresas encuestadas requieren afianzar sus productos con el cliente, a través de entregas parciales (al menos una). Estas entregas parciales, representan puntos de control para detectar y corregir desviaciones contra los requerimientos establecidos. Por lo tanto, a través de dicha estrategia, se reducen los defectos en la entrega final del producto de software.

Cantidad de productos que la empresa entrega De acuerdo con la investigación, 44% de las empresas entregan de uno a tres productos al año, 30% de cuatro a siete y 26%, ocho o más.

El porcentaje que menos productos entrega tiene un promedio de liberación de tres productos al año.

Tabla 3. Modelo de calidad utilizado.

Resalta el alto porcentaje de empresas que no utiliza ningún modelo. Al indagar un poco más, averiguamos que 86% de las empresas encuestadas ha considerado utilizar un modelo de aseguramiento de calidad de software, es sólo que en el momento de la encuesta no lo había logrado implementar. Entre este grupo, 44% se inclina por MoProsoft como opción, 26% por CMMI y el resto no refiere modelos.

Tiempos de entrega del producto 74% de las empresas entrega un producto en un plazo de 3 a 5 meses, el 22% en un periodo de 6 a 12 meses, y finalmente el 4% lo entrega en 13 meses ó más. A partir de estos datos, se concluye que la mayoría de los encuestados se enfocan en proyectos de corto plazo.

Entrega de prototipos La tabla 4 muestra la cantidad de prototipos que las empresas entregan por proyecto.

Cantidad de Prototipos

Ninguno Uno De 2 a 4 5 o más

Tabla 4. Entrega de Prototipos.

% de empresas 30% 34% 30% 6%

Es por ello que los modelos de calidad propuestos, tanto de proceso como de producto, deben ser adaptables y fáciles de implantar para las empresas (en su mayoría micro) que realizan sus entregas en tiempos cortos (menor o igual a tres meses).

Evaluación de calidad del producto 64% de las empresas encuestadas reportó que sí mide la calidad del producto final. De dicho porcentaje, 67% realiza principalmente pruebas unitarias y de funcionalidad, 33% comenta que la miden a través de una encuesta de satisfacción del cliente que se realiza posteriormente a la entrega del producto.

Tenemos entonces que, más de la mitad de las empresas que participaron en la encuesta realiza la evaluación de su producto utilizando el enfoque del productor; es decir, que la calidad está determinada por el apego a los requerimientos del cliente (en su mayoría funcionales) y no desde el punto de vista del producto, donde la calidad está determinada por el cumplimiento de las siguientes características: confiabilidad, mantenibilidad, eficiencia, portabilidad y usabilidad. Por otra parte, un 36% señala que desconoce los métodos de evaluación, por lo que no realiza evaluación alguna del producto final.

Por otro lado, al considerar el uso de herramientas para evaluar la calidad del producto de software, 78% de las empresas reportaron carecer de herramientas, porque las considera muy costosas.

Edna Gutiérrez Gasca es alumna de la Maestría en Ciencias de la Computación en el Tecnológico de Monterrey, Campus Ciudad de México.

Agustín Francisco Gutiérrez Tornés es profesor de Asignatura en el Tecnológico de Monterrey, Campus Ciudad de México.

www.sg.com.mx

FEB-ABR 2009

45

// PRÁCTICAS

/*aseguramiento de calidad*/

“Según las encuestas, hay interés en contar con un modelo de procesos para el desarrollo de software dentro de la industria mexicana”.

En cuanto a los modelos y normas que utilizan para asegurar la calidad del producto de software, 93% de la muestra reportó que no utiliza modelos para evaluar la calidad del software, mientras que 6% utiliza la norma ISO/IEC 9126 y 1% utiliza MECA.

Garantía ofertada al cliente Encontramos que 75% de las empresas encuestadas otorga una garantía a sus clientes, mientras que 25% no lo hace. La garantía generalmente se hace válida por errores encontrados en post-producción, contra especificación de los requerimientos, y el plazo típicamente va de los 45 días hasta los 3 meses.

Resalta que la mayoría de los encuestados otorgan garantía a partir de la especificación de requerimientos funcionales, pero no contempla los requerimientos no funcionales.

Conclusión Esta encuesta ha servido para detectar la necesidad de contar con un modelo de calidad para empresas desarrolladoras de software con equipos pequeños de trabajo: menos de diez personas, dónde el desarrollo del producto se realiza en tiempos cortos entre 3 y 5 meses, y a la medida del cliente.

Tomando en consideración estas afirmaciones, se puntualiza que los modelos de calidad tanto de proceso como de producto para las empresas mexicanas de desarrollo de software, deben considerar lo siguiente: • Adaptabilidad a equipos pequeños de desarrollo y a entregas de producto en plazos menores a tres meses.

• Definición de desarrollos iterativos y entregas de prototipos funcionales al cliente con base en su especificación de requerimientos.

• Aumento de la calidad de la documentación generada en el proceso de desarrollo de software.

Referencias [ Gutiérrez Tornés, Agustín. “Propuesta de un modelo cualimétrico para la evaluación de la calidad del software”; Septiembre1999; CIC-IPN; México. ] [ MoProSoft. Versión 1.1, Mayo 2003. http://tinyurl.com/a7cnzz ]

Hay interés en contar con un modelo de procesos para el desarrollo de software y dado que los desarrollos son iterativos, es muy útil contar con prototipos funcionales que en realidad sirven para reducir el riesgo de inconformidades en el proceso de desarrollo, y lograr una mayor satisfacción para el cliente en la entrega del producto final.

Por otra parte, la mayoría de las empresas reportaron no contar con una herramienta de evaluación del producto de software, y no utilizan modelos para asegurar la calidad del producto. Adicionalmente, se puede identificar la escasez de las empresas que conocen modelos de calidad enfocados al producto, por lo que es necesario capacitar a las empresas en estos rubros.

[ Mendoza, Luis E; Pérez, María A; Griman, Anna C. “Prototipo de Modelo Sistémico de Calidad del software”. Revista Computación y Sistemas. Vol. 8. Num. 3. CIC-IPN. México. pp. 196-217. ] [ Garvin, David. “What Does Product Quality Really Mean?” Sloan Management Review. 1984.] [ PMI. “Guía de los fundamentos de la dirección de proyectos” (PMBOK.). México. Tercera edición 2004. ] [ DETI. edigital.economia.gob.mx/deti ]

Aurora Pérez Rojas es profesor Investigador de la Universidad Autónoma del Estado de Hidalgo (UAEH).

Luis Felipe Márquez López es egresado del Instituto Tecnológico Autónomo de México (ITAM).

46

FEB-ABR 2009

www.sg.com.mx

/*PROGRAMAR ES UN MODO DE VIDA*/

// columna

La Seguridad en Cómputo ¿Con qué se Come?

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM; entusiasta y promotor del Software Libre, desarrollador del proyecto Debian GNU/Linux desde el 2003, miembro externo del Departamento de Seguridad en Cómputo de DGSCA-UNAM desde 1999.

L

a evolución del rol que cumplen los sistemas en las organizaciones ha cambiado por completo –afortunadamente– el punto de vista que la mayor parte de los desarrolladores tiene con respecto a la seguridad.

siguientes ediciones de SG, iré abordando en esta columna algunos temas fundamentales.

Hace una o dos décadas, el tema de la seguridad en cómputo era frecuentemente evitado. Y hasta era justificable: ¿Intrusos? ¿Integridad? ¿Validaciones? En ese entonces había muy poco software diseñado para su operación en red, y mucho menos para la idea de red que tenemos hoy en día. Si bien es cierto que la mayor parte de los ataques se origina y siempre se ha originado dentro del perímetro de confianza de nuestra organización, hace 20 años sencillamente había menos información sensible alojada en medios electrónicos, menos gente con el conocimiento necesario para manipularla, e incluso la manipulación tenía efectos menos nocivos, ya que la información en medios electrónicos era el respaldo de la copia maestra que estaba en papel. Hoy en día estamos transitando hacia la situación opuesta, donde la versión electrónica es la primaria, por lo que una intrusión en nuestros sistemas puede poner en jaque la integridad de la información primaria.

A riesgo de que parezca que me limito a perogrulladas, un “sistema seguro” es sencillamente un sistema “que responde como debe”. Claro, hay que ver esto a la luz de varios criterios para que en verdad signifique algo. Intentemos nuevamente... un sistema seguro presenta: • Consistencia. Ante las mismas circunstancias, debe presentar el mismo comportamiento. Ante un sistema “seguro”, el tradicional remedio “¿ya intentaste reiniciarlo?” no surte efecto. Si nos hemos acostumbrado a que un reinicio resuelve las cosas, no es sino porque el ambiente de ejecución se ensucia con elementos que debería haber descartado.

• Protección y separación. Los datos, instrucciones y espacio de memoria de un programa o usuario, no deben interferir ni permitir interferencia de otros. Las condiciones anormales ocurridas en uno de los componentes (sean accidentales o expresas) deben tener un impacto mínimo en el sistema como un conjunto.

• Autenticación. El sistema debe asegurar que un usuario es realmente quien dice ser.

• Control de acceso. Nuestro sistema debe ser capaz de controlar el acceso a sus datos, con el nivel de granularidad requerido –quién tiene acceso a qué recursos, y qué tipo de acceso tiene.

• Auditoría. El sistema debe ser capaz de registrar, así como de notificar a quien sea necesario de cualquier anomalía o evento importante.

Mantener la seguridad en los sistemas que desarrollamos implica un alto costo: los programadores deben aprender a evitar errores comunes; hay que dedicar recursos para implementar baterías de pruebas; entran en juego validaciones y conversiones sobre los datos que manipulamos, con costos en tiempos de procesamiento de cada solicitud... pero, afortunadamente, ha crecido también la conciencia de que esto es algo necesario.

El problema sigue siendo, coloquialmente... “¿con qué se come?” La seguridad en cómputo sigue siendo un campo difícil de entender, con muchas aristas ocultas. Es por esto que, en las www.sg.com.mx

Para iniciar, ataquemos lo fundamental: ¿Qué debemos entender por seguridad en cómputo?

Todos estos atributos deben ir matizados, priorizándolos al nivel adecuado a nuestras necesidades. Ir demasiado lejos en uno de estos objetivos puede incluso ser perjudicial para los fines de nuestro sistema. Por ejemplo, en México un usuario de banco por

Internet se autentifica a través de usuario y password, en combinación con un dispositivo que genera cadenas de números que cambian periódicamente. Esto tiene sentido para el manejo de una cuenta de banco, pero podría ser demasiado para una simple cuenta de correo electrónico.

Una recomendación es no perderse tratando de lograr la perfección. Bien dice el refrán que “lo perfecto es enemigo de lo bueno”. Es importante que, en toda etapa de la planeación, desarrollo, implantación y tiempo de vida de un sistema, recordemos que 100% de seguridad es una utopía, un objetivo que sólo puede servir para guiar nuestro trabajo diario.

Los programas son escritos por humanos, y son también humanos quienes administran los sistemas en que corren. Hay una gran cantidad de interacciones entre sus elementos; y un cambio en cualquiera de ellos puede tener consecuencias inesperadas si no se hace con cuidado y conciencia. Constantemente aparecen nuevas categorías de errores capaces de llevar a problemas de seguridad. Parte fundamental de nuestra actuación como profesionales en nuestro campo, debe ser mantenernos al día con los últimos desarrollos y amenazas.

Dos de las organizaciones más influyentes en la investigación y respuesta a incidentes de seguridad informática, SANS y MITRE, acaban de publicar su lista de los 25 errores de seguridad más importantes: www.sans.org/top25errors.

Este listado incluye muchos temas de fundamental relevancia, algunos de los cuales abordaré en posteriores columnas. Vienen explicados con un buen nivel de detalle, puntualizando cómo evitar o mitigar sus efectos. Les recomiendo ampliamente familiarizarse con ellos. » Por Gunnar Wolf FEB-ABR 2009

47

// UML

Las relaciones son importantes Obteniendo Diagramas de Clases Por Charlie Macías

Dicen por ahí que “lo prometido es deuda”, así que en esta ocasión hablaremos del modelado de las relaciones entre las clases de diseño. Este compromiso lo adquirimos, Sergio Orozco y un servidor, en el artículo publicado en la edición de Marzo-Abril de 2006 de esta revista… también dicen por ahí que “más vale tarde que nunca”.

En el artículo antes mencionado expusimos las técnicas aplicables para obtener un diagrama de clases a partir de uno de secuencia, las cuales podemos resumir en el cumplimiento de tres reglas: 1. Cualquier línea de vida (objeto) que aparezca como participante en el diagrama de secuencia, debe ser instancia de una clase.

2. Cualquier mensaje recibido por una línea de vida (objeto) debe estar soportado por una operación definida en la clase de la cual es instancia.

3. Cualquier intercambio de mensajes entre dos líneas de vida (sobre todo cuando éstas son instancias de clases distintas) debe verse reflejado mediante algún tipo de relación (asociación binaria, agregación de tipo shared, agregación de tipo composite o dependencia) en el diagrama de clases.

En este artículo nos enfocaremos en la tercera regla, porque es la que quedó, digamos “oscura”, en el artículo anterior. Las figuras 1 y 2 nos ayudarán a regresar al contexto del ejemplo que tomaremos como base para el resto de la disertación.

sd Punto de Venta

El asunto es responder a la pregunta ¿por qué entre TPV y Venta se modeló una dependencia, mientras que entre Venta y RenglonVenta una composición?

tpv: TPV

1.0 Venta(ventaXML)

nuevaVenta: Venta

1.1 agregarRenglonVenta(renglonesVentaXML)

1.2 RenglonVenta(cantidad, idProducto)

rv: RenglonVenta

1.3 registrarPago(monto)

Figura 1. Diagrama de secuencia para registrar una venta.

que, si aplicamos la tercera regla, debe existir algún tipo de relación entre TPV y Venta, así como entre Venta y RenglonVenta (Figura 2). cd Diagrama de Clases-Operaciones

La diferencia entre el modelado de una dependencia o de una asociación (binaria, agregación shared o agregación composite) radica en la transitoriedad o permanencia del enlace entre los objetos que participan en la interacción, es decir, qué tanto dura el enlace.

TPV

Enlace transitorio Venta - fecha: Date - folio: String + agregarRenglonVenta(String) : void + registrarPago(double) : void + Venta(String)

renglonesVenta

1..x

RenglonVenta

Como podemos observar en el diagrama de secuencia (Figura 1), la instancia de la clase TPV le envía tres mensajes a la instancia de la clase Venta, y esta última a su vez, le envía un mensaje a la instancia de la clase RenglonVenta, así

La respuesta o respuestas cortas son: porque la relación entre TPV y Venta no es estructural, mientras que la relación entre Venta y RenglonVenta sí lo es. O también podríamos decir que: porque entre TPV y Venta se forma un enlace transitorio, mientras que entre Venta y RenglonVenta se establece uno permanente. La segunda forma de explicarlo es la que prefiero, y estoy convencido que es la que resulta más clara, por tanto, es la que usaré para la respuesta larga.

- cantidad: int + RenglonVenta(int, long) : void

Figura 2. Diagrama de clases derivado del diagrama de secuencia.

Si el enlace entre los objetos tiene el alcance de una ocurrencia de ejecución (rectángulo delgado que se modela sobre la línea de vida, y que en código lo veríamos como el cuerpo de la operación) entonces en el diagrama de clases lo modelaríamos como dependencia.

Cuando en el código vemos que desde el cuerpo de una operación (método) podemos acceder a los servicios de un objeto, ya sea porque recibimos una referencia hacia el mismo mediante parámetro o porque creamos esa referencia localmente al instanciarlo, o porque dicha referencia es consecuencia de que el objeto sea de acceso global (como en el patrón del Singleton) entonces modelamos una dependencia. En el caso de nuestro

Charlie Macías es arquitecto en jefe e instructor senior en Milestone Consulting. Primer empresa mexicana miembro de la OMG, especializada en la capacitación práctica y consultoría en modelado de sistemas y negocios con UML, BPMN y SysML. Puedes contactarnos en info@milestone.com.mx www.milestone.com.mx

48

FEB-ABR 2009

www.sg.com.mx

ejemplo y apoyándonos en el siguiente fragmento de código, podemos observar que en el método “registrarVenta” se crea una referencia hacia una instancia de la clase Venta llamada “nuevaVenta”, pero dicha referencia se pierde al concluir el método. public class TPV { public void registrarVenta(String ventaXML){ …

Venta nuevaVenta = new Venta(ventaXML); nuevaVenta.agregarRenglonVenta (renglonesVentaXML); nuevaVenta.registrarPago(monto); … } }

Enlace permanente Si el enlace entre los objetos trasciende ocurrencias de ejecución, entonces significa un enlace permanente y se modelará una asociación (binaria, agregación shared o agregación composite) en el diagrama de clases.

Para conseguir que un enlace trascienda ocurrencias de ejecución, es necesario alojar la referencia hacia el objeto en un atributo de la clase. En nuestro ejemplo podemos observar que los renglones venta son alojados en la colección “renglonesVenta”, la cual es un atributo de la clase Venta, esto hace posible que las referencias hacia los objetos del tipo ReglonVenta sobrevivan a la conclusión del método “agregarRenglonVenta”. public class Venta { List< RenglonVenta > renglonesVenta = new ArrayList<RenglonVenta>(); public void agregarRenglonVenta (String renglonesVentaXML){ … renglonesVenta.add (new RenglonVenta(cantidad, idProducto)); … } }

En nuestro ejemplo, la relación entre Venta y RenglonVenta resulta ser una agregación del tipo composite, lo que le indica al programador que el manejo de la colección debe ser por valor, y que la relación debe ser simétrica.

Pero bien pudimos haber modelado una agregación del tipo shared si nuestra decisión de diseño hubiera sido que el manejo de la colección fuera por referencia. Una relación de asociación binaria se modelaría en el caso de que el enlace entre los objetos estuviera limitado a una sola instancia de sendas clases.

www.sg.com.mx

Las relaciones entre las clases manifiestan decisiones de diseño Finalmente, una idea importante es que las relaciones de los distintos tipos dependen de las decisiones de diseño que tomen los que plantean la solución al problema, y cuando hablamos de problemas para los que aplican soluciones de ingeniería, son problemas de solución abierta, es decir, hay muchas posibles soluciones, unas mejores que otras. Algunos criterios podrían ser los siguientes: • Si un objeto requiere de un enlace hacia otro objeto una y otra vez, es decir, que parece permanecer relacionado al otro incluso a través de la ejecución de una o más operaciones, entonces probablemente una relación de asociación sea lo más conveniente.

• Si un objeto se enlaza con otro para consumir sus servicios, y después lo deshecha, entonces podríamos preferir una dependencia.

• Si en tiempo de ejecución varios objetos necesitan y comparten de un tercero, una y otra vez, quizá podíamos decidir compartir al tercero pasándolo como parámetro. También podríamos decidir o necesitar que el objeto compartido fuera único y global en el proceso (patrón del Singleton), en cualquiera de estos dos casos, modelaríamos una dependencia.

• Si a fin de mejorar el desempeño y escalabilidad del sistema, descubrimos que nos sale más barato mantener un objeto en memoria que creando y destruyendolo podríamos decidir alojarlo en una variable de clase (atributo) y esto nos llevaría a escoger una asociación.

Conclusión En términos simples: • Si el enlace entre dos instancias de clases distintas que colaboran para alcanzar un objetivo es transitorio, entonces se modela una dependencia.

• Si el enlace entre dos instancias de clases distintas que colaboran para alcanzar un objetivo es permanente (sobrevive a ocurrencias de ejecución), entonces se modela una asociación (binaria, agregación de tipo shared, agregación de tipo composite).

La temporalidad de los enlaces, y por tanto la naturaleza de las relaciones entre las clases, obedece a las decisiones de diseño que se tomen al plantear la solución al problema.

FEB-ABR 2009

49

// PM CORNER

APlICANDO PROJECT MANAGEMENT AL BI De las Bases de Datos a la Inteligencia de Negocios Por Jorge Valdés

Como hemos visto en este número de SG, la Inteligencia de Negocios se refiere al uso de los datos de una empresa para facilitar la toma de decisiones estratégicas; es decir, la comprensión del funcionamiento actual y la anticipación de acciones para dar una dirección bien informada a la empresa. Visto de otro modo, podríamos decir que este concepto consiste en sacar el máximo provecho de los recursos de información con que cuenta una organización, con el fin de tomar las mejores decisiones. Desde decidir el lanzamiento de nuevos productos o servicios basados en la segmentación de sus clientes, hasta decisiones de reducción de costos para mejorar la rentabilidad de una línea de negocio que quizás no está dando los resultados esperados.

Como Gerentes de Proyecto, debemos conocer y entender las particularidades de este tipo de proyectos, de tal forma que el día de mañana que estemos a cargo de un proyecto de implantación de BI, lo podamos manejar de forma adecuada. A continuación comparto algunos de los puntos que considero de mayor relevancia.

Etapas Normalmente en la integración de los repositorios de información, a partir de datos de diversas fuentes, se usa un proceso conocido como ETL (Extraction, Transformation and Load). A continuación lo describo: • En la fase de extracción, típicamente se identifican las fuentes de datos que abastecerán al sistema de información, así como los criterios de normalización de los mismos, para que la información llegue depurada a los grandes almacenes de datos (Data Warehouses) que servirán para producir los análisis que requiere la alta dirección de la empresa para apoyar la toma de decisiones.

• Durante la fase de transformación, se aplican los criterios definidos, de manera que la información es homologada, depurada y normalizada, para poder darle un tratamiento masivo una vez que esté en los almacenes de datos.

• Finalmente la fase de carga tiene como objetivo la población de los distintos repositorios que se hayan definido, de acuerdo al análisis inicial de tipos de datos y fuentes de información.

Estar conscientes del reto y el costo Un proyecto de esta naturaleza requiere que tanto el Gerente de Proyecto como su equipo de trabajo, así como el patrocinador del mismo, hagan un análisis a conciencia del desafío que representa para la organización. El manejo de los riesgos se vuelve crucial, pues

50

FEB-ABR 2009

en un proyecto de esta naturaleza, son muchas las posibilidades de que algo no resulte como fue planeado y, si no contamos con los planes de contingencia para manejar dichas situaciones, el proyecto sufrirá y la organización aun más.

En mi experiencia, una solución de BI es intensiva en el uso de recursos tecnológicos, tanto de hardware como de software, así que antes de iniciar una iniciativa de esta naturaleza es importante tomar en cuenta las capacidades reales de la organización para considerar el costo completo.

La comunicación es clave Es también necesario contar con un Plan de Comunicación que plantee la forma en que habrá que interactuar con los distintos actores del proyecto, los mensajes que habrá que cuidar y la forma en que serán manejadas las expectativas. Sobra decir la importancia que reviste el hecho de que los participantes en el proyecto se comuniquen de manera activa y proactiva.

Un proyecto de esta naturaleza puede durar varios meses o incluso años. Por lo tanto, se sugiere tomar en cuenta las siguientes recomendaciones: • Planificar algunas actividades de integración del equipo de trabajo en ambientes extra laborales, pues más vale ir creando relaciones de confianza, sentido de pertenencia y excelente entendimiento entre nuestro equipo, que nos permita estar unidos para enfrentar el gran desafío que se nos avecina.

• Identificar actores clave en la organización, y aquí me refiero a personas que quizás no tengan el rango más alto de sus respectivas áreas, pero que sean capaces de influir en ella de manera que, llegado el momento los podamos tener como aliados. Uno nunca sabe cuándo va a necesitar un favor.

• Finalmente, apliquen el principio del destripador; es decir, vayan por partes chiquitas y manejables, que les permitan lograr pequeños éxitos y que en suma logren cumplir los objetivos planteados originalmente por la organización. Un proyecto así, difícilmente se puede ver como uno solo, más bien se tiene que administrar como un programa.

Asegurarse que el usuario sea capaz de aprovecharlo El objetivo final de la inteligencia de negocios es poner a disposición de los usuarios, herramientas de explotación que les permitan analizar www.sg.com.mx

“Un proyecto de BI requiere que tanto el Gerente de Proyecto así como su equipo, y el patrocinador haga un análisis a conciencia del desafío que presenta”.

la información relevante desde diversas perspectivas. Por supuesto, dichas herramientas deben ser de fácil manejo y muy intuitivas, pues están dirigidas hacia usuarios que no necesariamente tienen conocimientos técnicos y habilidades avanzadas en el uso de la tecnología.

Un esquema de inteligencia de negocios busca abarcar más allá de la simple generación de reportes estáticos, y llegar hasta los usuarios y proveerles con poderosas herramientas que les ayuden a manejar cubos de información dinámicos, que faciliten el establecer varios tipos de relaciones seleccionando los datos que sean de su interés para llevar a cabo análisis predictivos de acuerdo a sus necesidades. Esto implica que, por un lado, el sistema debe ser fácil e intuitivo, pero que también debemos desarrollar entre los usuarios la capacidad de aprovechar el sistema, lo cual implica capacitarlos.

Principales complicaciones Como seguramente ya se han dado cuenta, implantar una iniciativa de BI en una organización no es una tarea trivial. A continuación las principales razones que complican este tipo de proyectos: • Son iniciativas transversales. Es decir, que comprenden diversas áreas de la organización.

• Se requiere involucrar recursos con un profundo conocimiento de cada uno de los aspectos que integran el negocio.

• Es necesario contar con gran poder de procesamiento y almacenamiento de información, pues en proyectos de esta naturaleza se manejan varias copias de los datos de la organización.

• Requiere que los usuarios tengan un entendimiento de cómo sacar el mayor provecho de los almacenes de datos para beneficio de la corporación.

• El proyecto necesariamente requiere la participación de expertos externos a la organización y la selección de los mismos puede ser tan complicada que en sí misma deba manejarse como un proyecto preliminar.

Estos puntos que pueden parecer muy sencillos, realmente exigen que el Gerente del Proyecto aplique sus habilidades al máximo y por supuesto que tenga varios años de “cicatrices de guerra”.

Aunque no tengo información fidedigna, intuitivamente y en base a mi propia experiencia, les puedo decir que muchos de estos proyectos fracasan por aspectos técnicos, pero son más los que fracasan por cuestiones humanas.

Compartiendo experiencia En un proyecto en el que participé hace algún tiempo, se buscaba integrar un almacén de datos con información de clientes. El problema principal radicaba en que cada una de las líneas de negocio de la empresa, contaba con bases de datos independientes, con la información de sus respectivos clientes. Esto provocaba que existieran muchos registros duplicados; pero además, que la información entre las distintas bases de datos no estuviera homologada. Probablemente yo podía aparecer en la base de datos de una organización como Jorge Valdés Garciatorres, mientras que en otra, podía estar registrado como Jorge Valdez García. Como se podrán imaginar, lo anterior dificultaba enormemente la tarea de consolidación de información. El simple hecho de definir quién debería participar en la definición de criterios para depurar y limpiar la información, generó mucha polémica al interior de la organización, creando grandes luchas de poder y aspectos políticos que, nada más de recordarlos me pongo a temblar.

Por otra parte, ya sobre la marcha, nos dimos cuenta que era necesario nombrar un responsable de administrar la información; en este caso, de personas. Pues aun y cuando pudiéramos hacer un excelente trabajo de depuración, limpieza y normalización de los datos, al no existir un único dueño de la información, se provocaría que los nuevos registros se pudieran contaminar rápidamente, y otra vez, tener discrepancias. Es decir, teníamos que asegurar que la calidad de la información mejorara desde que ésta se ingresaba a los sistemas de información de la empresa. El contar con un “dueño” de la información favorecería la creación de políticas y estándares de trabajo alrededor de los procesos de captura y mantenimiento de datos, y la vigilancia periódica de su cumplimiento. Esto reduciría la aparición de incidencias y reduciría el volumen de información contaminada haciendo el proceso ETL más eficiente.

Como pueden suponer, no fue fácil encontrar a la persona idónea, pero es un aspecto en el cual también se tiene que pensar, si se quiere implantar un buen marco de inteligencia de negocios que le sirva a la organización a largo plazo.

Jorge Valdés Garciatorres (PMP, ITIL, CC) es Socio Director de la firma global de consultoría y educación en procesos de negocio y dirección de proyectos TenStep Latinoamérica. Participa como vicepresidente de Desarrollo Profesional en el PMI Capítulo México en donde además es miembro del consejo editorial. Es miembro del consejo editorial de SG y es miembro activo de Toastmasters International. jvaldex@tenstep.com.mx

www.sg.com.mx

FEB-ABR 2009

51

// COLUMNA

/*PRUEBA DE SOFTWARE*/

Modelos de Calidad para Prueba de Software Constituyentes Fundamentales de los Modelos de Calidad Especializados en Prueba de Software Luis Vinicio León Carrillo es actualmente Director General de e-Quallity, empresa especializada en prueba de software, de la que es cofundador. Fue profesor-investigador en el ITESO durante varios lustros, que incluyeron una estancia de posgrado en prueba de software en Alemania, en la que abordó aspectos formales de esa disciplina. Es autor de varias publicaciones nacionales e internacionales, e invitado frecuente en eventos relacionados con la prueba de software.

E

n la edición agosto-octubre 2008 mencionamos que los modelos de calidad (MC) deben proporcionar un marco de referencia tanto para diagnosticar las capacidades de una organización, como para diseñar y ejecutar planes de mejora. Dijimos que los MC deben ser completos, consistentes y objetivos, y que deben proporcionar una manera rápida de obtener una evaluación inicial de capacidades.

5. Personal del área de pruebas 6. Posición en el organigrama del área de prueba 7. Comunicación y reportes 8. Administración de defectos 9. Administración del testware 10. Infraestructura tecnológica para probar

También comentamos que los MC, incluidos los especializados en prueba de software, suelen tener una estructura matricial como la figura 1, e hicimos un muy breve análisis de varios de ellos. Ahora profundizaremos en la estructura de los modelos especializados en prueba de software (MCEP).

CMMI y MoProSoft no incluyen este núcleo, razón por la cual no nos fue útil en nuestros esfuerzos por mejorar las capacidades de prueba de software, como comentamos en el número antepasado.

Elementos fundamentales de un MCEP Haciendo un análisis de nuestra experiencia en consultoría, diagnosticando y ayudando a mejorar organizaciones de prueba, y de lo publicado en la literatura especializada, vemos que las áreas listadas abajo son de las más relevantes y comunes a una proporción significativa de (MCEP): 1. Proceso de prueba 2. Estrategia de pruebas 3. Punto de arranque de las pruebas 4. Métricas

Es también común que los MCEP midan los avances en cuatro ó cinco niveles. Varios de ellos utilizan subniveles, lo que en la práctica resulta de mucha utilidad, porque los pasos de mejora pueden ser más pequeños y detallados.

Los MCEP deben tomar en cuenta, tanto el caso de que la organización de prueba se encuentre dentro de una empresa de desarrollo de software, como el de que forme parte de una empresa especializada en prueba o calidad. Igualmente deben mostrar diferencias entre los casos en que se prueba software convencional, de aquéllos en que lo que se evalúa, si es software crítico (aquél en el que si falla, alguien se muere).

Figura 1. Estructura matricial.

52

FEB-ABR 2009

www.sg.com.mx

“Los Modelos de Calidad deben ser completos, consistentes, y objetivos”.

Aplicación de esos elementos En nuestra experiencia en los diagnósticos y ayuda a mejorar organizaciones de pueba hemos encontrado útil comenzar a abordar las áreas del MCEP antes mencionadas, en el orden que muestra la siguiente figura, prestando atención primero a áreas de capas interiores para luego, sin dejar de trabajar en esas, comenzar a abordar las de la siguiente capa exterior.

.nUSJDBT

0SHBOJ[BDJwO

*OGSBFTUSVDUVSB 1SPDFTP

&TUSBUFHJB 3FDVSTPT )VNBOPT 1VOUP EF JOJDJP

%FGFDUPT 5FTUXBSF $PNVOJDBDJwO

Una vez cubiertos los fundamentos anteriores podemos ocuparnos también de que el equipo de pruebas tenga una posición adecuada en el organigrama (en particular, buscando que no dependa de un directivo responsable de entregar en tiempo y forma, desarrollos de software, para evitar la situación de ser “juez y parte”); de que cuente con el personal suficiente en cantidad (aproximadamente 25% del total de los recursos asignados al desarrollo de software) y en calidad (selección y entrenamiento apropiados); de que se administre adecuadamente los insumos y productos de las pruebas (y evitar estar probando una versión no actual del software); y de que se cuente con un laboratorio de pruebas adecuado.

En una tercera fase podemos trabajar también en recabar y explotar sistemáticamente métricas; en que las pruebas comiencen más temprano en el ciclo de desarrollo; y en que las labores y los resultados de las pruebas resulten de utilidad a un grupo mayor de roles en la organización.

Un aspecto muy importante a considerar al diseñar el plan de mejora es la recuperación de la inversión, lo que induce la pregunta: ¿cuál es la secuencia de pasos que más conviene para la organización en sus circunstancias particulares?

Continuaremos con estos temas en el próximo número.

Figura 2. Áreas en capas.

Lo vemos así, porque es muy común encontrar organizaciones de prueba con fuertes carencias en la definición de su proceso, en el diseño de una estrategia que combine adecuadamente técnicas de prueba, y en la administración de los defectos que se detectan, lo que dificulta mucho avanzar con paso firme. Podemos considerar estas primeras áreas como asépticas.

Invitación En marzo tendremos como invitado en e-Quallity a un experto internacional, con quien ofreceremos pláticas sobre temas relacionados con los MCEP en el D.F., Monterrey y Guadalajara. Si tienes interés en asistir, escribe a contact@e-quallity.net con el encabezado “Plática con Expertos”. ¡Hazlo yá; hay cupo limitado! » Por Luis Vinicio León / Berenice Ruíz

Berenice Ruíz Eguino es consultora de e-Quallity en proyectos de mejora de organizaciones de prueba. A lo largo de su trayectoria profesional ha actuado también como tester senior, administradora de proyectos de prueba nacionales e internacionales, y directora de operaciones. Ha sido profesora de la Universidad Autónoma de Guadalajara, institución en la que realizó sus estudios de Maestría en Ciencias Computacionales.

www.sg.com.mx

FEB-ABR 2009

53

// COLUMNA

/*tendencias en SOFTWARE*/

El Software 2010-2015 Capacidades Avanzadas de TI, Democratización y Especialización Luis Daniel Soto Director de Divulgación Tecnológica para Microsoft. Responsable de la cuarta área de trece a nivel mundial en atención a desarrolladores de software. Coordina el esfuerzo de un grupo de 100 personas encargadas de Divulgación Tecnológica en América Latina.

Ingeniero en computación por la Fundación Arturo Rosenblueth, especialista en el tema de liberación al mercado de nuevas tecnologías y toma electrónica de decisiones. luisdans@microsoft.com luisdans.com\Twitter

H

ace tiempo, pasaba varias noches escribiendo software y preguntándome sobre su alcance; nunca imaginé todo lo que hoy permitiría hacer. La importancia del futuro del software ha sido recurrente desde que mi responsabilidad de tiempo completo es la de trabajar para los desarrolladores y empresas creadoras de software. ¿Cuál es el futuro del software para el entrante quinquenio?

Las nuevas tecnologías generalmente maduran en un periodo mayor a 5 años, es decir que no tendremos sorpresas hasta 2015. Lo que podemos esperar son mejoras en diversos frentes, algunos de los más destacados son:

lente charla es: twurl.nl/5zceki. La gran ambigüedad es la privacidad de la información.

4. Desempeño del software. Hoy es fácil señalar cuando un servicio opera o ha dejado de funcionar. Pero hay respuestas dudosas al efectuar la pregunta ¿el administrador de base de datos está operando de forma eficiente?

Las máquinas virtuales en combinación con grandes grids trabajan en la nube y permitirán revertir el estado de equipos no responsivos por imágenes frescas, pero la instrumentación será fundamental en las aplicaciones.

Para esto será necesario ampliar los servicios del sistema operativo definiendo los eventos importantes a monitorear y permitir dejar de ejecutar servicios que no estén en uso.

1. El verdadero Web portátil. Aun cuando parece maravilloso el acceso total a Internet desde un dispositivo electrónico portátil, la realidad no lo es. El soporte a tecnologías como flash y java es pobre, de tal suerte que casi ningún portal bancario opera en celular si éste no fue diseñado de forma especial.

Por una parte, el avance de hardware permitirá emular exploradores más recientes, pero por otra, los avances en herramientas hará más fácil construir y acceder sitios desde cualquier dispositivo. RIA para las masas, Internet extendido por sensores.

El futuro del software será especialización + democratización. El rumbo de la tecnología es resolver los problemas de cada dominio específico, y al mismo tiempo permitirle a todo tipo de usuario crear programas fácilmente (twurl.nl/eqwn5d ). Este último concepto se denomina democratización de la creación de software. Incluye ampliar el acceso a personas que hoy no tienen una PC, utilizar voz, terminales compartidas y objetos conectados a la red.

2. Mayor facilidad de interacción con la PC. Al avance de la parte portátil, la interacción con una PC de casa y oficina crecerá y no será alcanzado por el Web. El tacto, la voz y elementos altamente interactivos simplificarán el uso de la computadora derribando las limitantes del teclado. Las aplicaciones deberán ser multicanal y llegar a gente que no tiene computadoras. (Ver twurl.nl/tf3mtw ).

Todos los dominios tendrán elementos en común como privacidad, administración de máquinas virtuales, verificación, instrumentación, aprovechamiento de la red social del usuario, clientes multi-cabeza, aprovechamiento del nuevo hardware (OLED, discos duros de estado sólido, video multiple simultáneo, microprocesadores con menor consumo de energía, etcétera).

3. Software con menos defectos. Desde la perspectiva de la programación, no hemos llegado al momento en donde el código se escriba libre de defectos. Hay reportes de errores que han sido resueltos nueve o más años posteriores a su reporte original. Lo que podemos esperar es la llegada del paradigma colaborativo a identificación de problemas. Una exce-

En el ámbito empresarial, un elemento fundamental será el Enterprise mashups, combinando los sistemas internos con el cómputo en la nube. La arquitectura social: hace transparente el acceso exterior a una red privada, no sólo para empleados, sino para colaboración externa. Muchos de estos elementos se agruparán bajo la categoría: capacidades avanzadas de TI.

54

FEB-ABR 2009

La casa y la oficina requieren esas mismas capacidades entregadas como servicio, pero aquí la clave continúan siendo las aplicaciones. Supongamos por un momento que el software es eficiente, está libre totalmente de defectos y es multi-cabeza.

El mayor obstáculo es el último: hacen falta las soluciones que sean construidas en la nueva arquitectura. Deseaba recomendarle a un amigo próximo a casarse un software para administrar bodas en donde él y ella colaboraran en las actividades desde sus propios dispositivos, pero no lo pude localizar. (Ver columna ‘Patrones para software de consumo’ SG Sep-Nov 2008). ¿Cuál es el impacto de las aplicaciones actuales? ¿El software educativo para escuelas primarias le da a los alumnos ventajas en el aprendizaje? Los niños de hoy se han beneficiado por una gran cantidad de medios, incluyendo mucho mejores programas de televisión, juegos educativos no electrónicos y los contenidos que acceden a través de Internet.

El aprendizaje realmente personalizado no existe aún (ver twurl.nl/ttk4r6) Pensemos en las 5 mil fotografías que pronto tendremos en nuestros discos duros. ¿Es fácil organizar las fotografías para encontrarlas cuando sea necesario? ¿Cuánto tiempo tardo en “subir” las imágenes a Internet para poderlas compartir en una forma visualmente rica (pruebe twurl.nl/nxg2pm )?

Conclusión: El futuro del software tiene que ver con resolver problemas claramente identificados del modelo actual, mejorar las herramientas y métodos para construir aplicaciones. Entender mejor los problemas que deben ser resueltos: Aquellos de alto impacto para las empresas y personas.

» Por Luis Daniel Soto www.sg.com.mx

www.sg.com.mx

FEB-ABR 2009

// fundamentos

La Fábula del Pastor y el Líder de Proyectos ¿Mito o Realidad?

Por Rodrigo Corral

Paseaba un día un líder de proyectos por el campo tras años de estar pegado al monitor.

Iba pensando en lo extraordinario del paisaje, la paz que se respiraba y lo lejos que estaba ahora de la reunión de “kick off ”, cuando vió un pastor de ovejas con un pequeño rebaño. No más de cincuenta recursos eran los que el pastor gestionaba.

En ese preciso instante el modesto pastor vio al líder y tomó un trago de su botella de mezcal. El pastor levantó la cabeza, miró a nuestro líder de proyecto y le ofreció un trago. El líder tomó la botella, le dió un trago que le supo bastante fuerte y se sentó junto al pastor. Y ya se sabe, un buen mezcal puede tener efectos alucinógenos. Sobre todo si no se ha probado en años… y no sale del supermercado más próximo.

Así que embriagado por el sabor, el líder de proyecto no pudo evitar decir: “señor pastor, lo suyo sí que es vida”. El pastor le miró, sin decir nada. “Todo el día dedicado a usted mismo, con sus fieles recursos que nunca se oponen a su voluntad, que saben lo que deben hacer sin que nadie se los diga, que no están todo el día exigiendo y pensando en irse a su hora a casa. Lo que daría yo por estar en su situación…” continuó el jefe.

El pastor le miró y con la simpleza que sólo da la verdadera sabiduría dijo: “no sabe usted de lo que habla, amigo”. Y tiró un largo trago de la botella. El jefe de proyecto no se iba a amedrentar, así que repuso: “Usted si que no sabe nada de lo duro que es mi trabajo, seguro que yo cuidaría mejor de sus ovejas, que usted de mi equipo de desarrolladores”. El pastor le miró fijamente y dijo “hecho, escriba aquí la dirección de su empresa y avise que voy”.

Le tendió la botella al líder de proyectos, en un gesto que decía claramente que si bebía, el trato estaba cerrado. Y claro, el líder bebió mientras pensaba, “que diablos, aquí el que tiene las certificaciones soy yo”.

El pastor silbó a su perro y le dijo, “dentro de una semana vuelvo, mientras, obedece al jefe.”…

Le dió el petate y marchó a conocer a su nuevo rebaño. El líder de proyecto pensó: “bueno se trata de gestionar recursos ¿no? Llevo

haciendo eso años. Seguro que las ovejas saben hacer mejor su trabajo que los desarrolladores. Tengo claro el objetivo, que den lana, y sólo necesito crear un plan y exigir su cumplimento”. Con un buen plan y mano férrea, seguro que lograba cumplir sus objetivos.

El líder respiró tranquilo cuando recordó que llevaba su PDA y que tenía Project y Excel versión súper mini. Todo estaba solucionado.

Dedicó esa noche a trazar un plan. Todo estaba bajo control, él tenía “el plan”, 50 recursos de tipo oveja, a 50 kilos de lana por recurso, 2,500 kilos de lana. Un proyecto rentable sin duda…

Al día siguiente reunió al rebaño. “Tengo un plan que nos va a llevar a completar el proyecto de manera exitosa. Ya me he comprometido con el alcalde y comerciante de lana a entregarle 2500 kilos de la mejor lana en el plazo de dos meses. El alcalde me ha mostrado su plena confianza en que conmigo al frente, gestor de recursos experto, el proyecto va a ser todo un éxito.” Las ovejas no entendían nada. Ellas sabían que el alcalde solía preocuparse más por la leche que por la lana, pero quizás las cosas habían cambiado, que sabían ellas, meros recursos productores de ¿lana? ¿leche?... Las ovejas, no habían nunca producido tanta lana en tan poco tiempo, pero con un buen gestor al mando quizás se obrase el milagro.

Pasaron veinte días, y el líder de proyecto reunió de nuevo a las ovejas. “Queridas ovejas, vamos retrasados respecto mi plan. No dudo que harán lo necesario para asegurar la producción al ritmo necesario. Ya he hablado con el alcalde y le he dicho que no se preocupe, que incrementaremos nuestro esfuerzo bovino y recuperaremos el tiempo perdido”. Las ovejas no entendían nada y llegaron a la conclusión de que el líder no era un animal muy listo. Al fin y al cabo no sabían cómo hacer crecer la lana más rápido… y parecía que él tampoco.

Otros veinte días después, el líder de proyecto reunió de nuevo al rebaño. “Malditas ovejas. Les pedí un esfuerzo y no han hecho nada. Yo hice el plan y ustedes están haciendo que fracase. Si no se aplican, se van a ir a la *@#& calle. Y ya saben, la crisis que hay… puedo encontrar cincuenta como ustedes’. La ovejas, una vez más, no entendieron nada. Ya le habían dicho al jefe de proyecto que no las metiera en el corral por las noches, y que cambiarlas de prado no era bueno para su lana. Habían pensado que tal vez si se movían por el campo, como hacían con el pastor, la producción de lana mejoraría. También sugerían que el jefe las ordeñase, sabían que el alcalde siempre quería leche...

Mr. Rodrigo Corral, MCAD, MCPD. Más de 12 años desarrollando software, como freelance y en varias empresas como Sisteplant, es líder técnico en proyectos realizado en plataforma .NET (C# 3.0 y ASP.NET). Responsable de grupos de desarrollo y analista-programador en Panda Software. Socio fundador de PlainConcetps donde se deaempeña como arquitecto de software y mentor en diversas materias como gestión de proyectos, Scrum, Team System, patrones de software, gestión de la configuración, diseño de arquitecturas distribuidas, implantación y desarrollo de Sharepoint, optimización y diseño de SQL Server

56

FEB-ABR 2009

www.sg.com.mx

“Estas ovejas, siempre quejándose de tonterías, ya sabía que no eran muy diferentes a los desarrolladores. Que sigan el plan y dejen de quejarse y pensar, para eso estoy yo. ¡No hay manera de hacer que trabajen!” había pensado el jefe de proyecto.

Veinte días después, el alcalde llegó y preguntó al jefe por su lana… el jefe sólo tenía 1,000 kilos, la ovejas resultaron no ser tan expertas como ponía en su curriculum, inaceptable… que podría haber hecho él… “No pasa nada jefe”, dijo el alcalde, “tendremos mucha leche entonces”. El jefe se puso rojo y dijo ¿leche? si en el contrato no decía nada de leche… El alcalde dijo, “No me importa lo que diga el contrato, lo de la leche se da por hecho, vaya fracaso del proyecto, no vas a ver un *@#& peso…”.

En eso llegó el pastor… seguro que él también se había equivocado… “¿Qué tal pastor? ¿Duro el trabajo?” dijo sarcástico. El pastor contestó, con su simpleza natural: “Todo ha ido sobre ruedas. Al fin y al cabo los desarrolladores son como ovejas, ¿no?

Seguro que a ti también te ha ido bien. Los desarrolladores incluso me han regalado un GPS para que marque dónde comen mejor mis ovejas… ¡y dónde hay setas! Creo que me han tomado cariño”.

El líder no salía de su asombro. Los recursos eran agradecidos y todo. ¡Cuéntame que has hecho! dijo al pastor.

“Ha sido fácil, los desarrolladores son mucho más comunicativos que las ovejas y cuesta menos reunirlos. Además, pensé, no pueden ser muy diferentes que las ovejas, son individualistas y gregarios a la vez. Seguro que si cuido de ellos como hago con mis ovejas, obtendré los resultados esperados y a eso me he dedicado estas semanas”.

“Me pidieron que les consiguiese un servidor de 64 bits para no se qué pruebas

www.sg.com.mx

de rendimiento y de compatibilidad. Yo no tenía ni idea de qué era eso, pero parecía importante para ellos, así que lo conseguí. ¿No busco los mejores pastos para mi ovejas? No es tan diferente…” El jefe de proyecto estaba atónito, ¿desde cuándo se logra algo de los recursos atendiendo a sus caprichos?…

“Un día, los desarrolladores dijeron que no lograban que el rendimiento fuese el adecuado, lo mejor era preguntar a un experto, dijeron.

Así que eso hice, busqué un experto que les ayudara y les formara. ¿No llevo a mis ovejas al veterinario cuando tienen problemas?”.

Ahora sí que el líder de proyecto no se lo podía creer, ¡formar a los recursos es caro! Y luego se van a la competencia en cuanto saben.

“Otro día los desarrolladores me contaron que no lograban avanzar. Eso me preocupó. ¿Se supone que los desarrolladores deben avanzar en la funcionalidad, es su lana y su leche, no? El problema es que los de ventas estaban continuamente exigiendo pequeñas modificaciones, visitas a clientes, que atendieran llamadas; parece que los lobos acechan, pensé yo. Así que puse un poco de orden y dejé claro que a mi rebaño no se le molesta”.

El pastor concluyo: “la verdad es que no he hecho mucho ¿no?. Los desarrolladores son como las ovejas, si dejas que hagan su trabajo y pones las condiciones para que lo hagan, al final puedes recoger los resultados”.

En eso despertó el líder de proyecto y pensó: “caramba, cómo pega el mezcal del pastor, vaya siesta y vaya sueño más raro”, mientras veía al pastor perderse por el horizonte con su rebaño.

Ya lo dijeron DeMarco y Lister en Peopleware; “el trabajo del gestor de proyectos no es hacer que la gente trabaje, sino construir el entorno en el que trabajar sea posible”.

FEB-ABR 2009

57

// TECNOLOGÍA

/*INFRAESTRUCTURA*/

Almacenamiento en Caché, Paralelismo y Escalabilidad La Ley de Moore ha muerto. Ahora rige la Ley de Amdahl por Manik Surtani

Desde hace unos años, la Ley de Moore dejó de tener importancia. Hoy en día, es mucho más aplicable la Ley de Amdahl, acuñada por Gene Amdahl. Esta ley sostiene que al añadir más procesadores para trabajar sobre un problema, no se logra la productividad global esperada calculada mediante la suma de la productividad individual de cada procesador. Lo que tendrá efecto en su productividad global será la capacidad de poder disgregar el problema original en subproblemas, que puedan distribuirse entre los diversos procesadores.

Esta ley es importante porque la estrategia actual para desarrollar computadoras más veloces consiste en aumentar los nodos de procesamiento paralelos, ya sea colocando más núcleos en chip, más chips en un servidor, y más servidores en un único cluster. Sin embargo, su software requiere ser escrito específicamente para aprovechar este paralelismo.

En el caso del software aplicativo del que tenemos el código fuente, es posible hacerle pequeños ajustes y utilizar librerías para ejecución paralela, que lo hagan más eficiente en este contexto. Sin embargo, ¿qué sucede con las bibliotecas y subsistemas que están fuera de nuestro control? Más específicamente, ¿qué sucede con las bases de datos que entran en contacto con discos que inherentemente involucran un procesamiento secuencial? Las bases de datos son sólo un ejemplo común de la serialización de procesos. La serialización sólo permitiría el funcionamiento de un único núcleo en un momento determinado en un sistema de múltiples núcleos, y limitaría la potencia de cálculo utilizable. La serialización es el gran enemigo en esta instancia porque contrarresta todos los avances en productividad que ofrece el paralelismo.

Aquí es donde el almacenamiento en caché cobra importancia. A diferencia de una base de datos que es inherentemente serial por naturaleza, una caché vive en la memoria y es altamente paralela debido a la naturaleza de los buses de memoria. Una memoria bien escrita minimizará los bloqueos o el uso de señalización entre unidades de ejecución, y utilizará técnicas modernas para garantizar la integridad de los datos de manera escalable.

Caché en cluster Las caché en cluster permiten que múltiples núcleos y servidores en un grid trabajen sobre los datos dispuestos en paralelo, aprovechando al máximo la potencia de cómputo disponible. El problema es cómo mantener la integridad de los datos entre los diferentes nodos.

Las caché en cluster utilizan diversos mecanismos para mantener la sincronización entre las caché y garantizar la validez de los datos: • Bloqueo pesimista del cluster completo.

Cuando un cache requiere modificar datos, obtiene un bloqueo para todo el cluster, hace los cambios que se replican a cada instancia de caché y luego liberará el bloqueo del cluster. Este enfoque es seguro y sencillo pero presenta problemas de escalabilidad.

• Bloqueoo optimista. Es aquél donde los conjuntos de datos se copian, se trabaja con ellos y, una vez terminada la tarea, se obtienen los bloqueos y se escribe el estado en las caché de todo el cluster. Brinda mayor escalabilidad pero presenta la necesidad de reintentar una operación en caso de colisión.

Distribución de datos Hasta ahora hemos hablado de las caché en cluster en el sentido de que cada caché es local pero consciente de sus pares y es capaz de sincronizar cambios con ellos. Si bien este enfoque funciona bien para la mayoría de las

aplicaciones, aun restringe la memoria accesible que pueden utilizar. Otro enfoque sería no reproducir los datos entre las caché, pero sumar la memoria utilizable de todas las caché en un cluster y distribuir los datos entre ellas.

Ubicar dónde se encuentran los datos podría implicar metadatos duplicados –una especie de mapa– o una función de búsqueda de registros compatible que apuntará a la instancia que contiene el registro que busca. Aunque distribuir datos de esta forma puede conllevar búsquedas innecesarias en la red, expone un espacio de memoria utilizable mayor para que sea ocupado por el sistema de caché. También hace que el sistema global sea más escalable.

Conclusión Las caché constituyen una herramienta importante para aprovechar el paralelismo y eliminar los obstáculos en la recuperación y cálculo de datos. Analizando la arquitectura de su aplicación y el volumen y los patrones de acceso de sus datos, podrá decidir si le conviene una caché local, en cluster o distribuida. Muchas estructuras o productos de almacenamiento en caché desarrollados le ofrecerán un abanico de modos operacionales que se adapten a su uso en particular. Pero como sucede con frecuencia, las caché no son soluciones milagrosas y no deberían utilizarse de manera indiscriminada. Como citó el experto en optimización de Java, Kirk Pepperdine: “Calcule, no adivine”.

Utilice un buen analista de perfiles e incorpore las caché sólo cuando sea necesario, cuando los problemas de recuperación o cálculo de datos estén frenando la escalabilidad.

Manik Surtani es ingeniero investigador en JBoss, una división de Red Hat corp. Actualmente dirige el proyecto JBossCache en el Centro de Investigación y Desarrollo de JBoss. Su área de especialidad es la inteligencia artificial y redes neuronales.

58

FEB-ABR 2009

www.sg.com.mx

www.sg.com.mx

FEB-ABR 2009

// tecnología

/*TENDENCIAS*/

La Virtualización y el Ahorro Sustentable Las Soluciones de TI Verde Por Rob Smoot

Mientras más se habla del ahorro de energía, las soluciones de TI “verde” se vuelven más populares, el incremento, tanto en el costo de la energía, como en el consumo de los Data Center y la importancia que tiene el ahorro sustentable permite desarrollar nuevos servicios de TI, que mantenienen corriendo los centros de datos, y con ahorro en el entorno, se convierten en focos que marcan el camino para las empresas y el mundo en general. La virtualización viene a apoyar dicha ideología, sin embargo, el cambio y los beneficios que propone, han sobrepasado la simple consolidación de servidores.

Dinamismo de cargas “Right Sizing” de la Virtual Infrastructure Algunas personas sugieren que la virtualización sea un beneficio, una vez que se quiten los servidores. ¿Qué hay después de la consolidación inicial?

La virtualización cambia el juego, convirtiendo los servidores físicos y su estado de ejecución, en archivos de software, que pueden ser copiados y movidos fácilmente, lo que hace al hardware, infinitamente más flexible. La creación de la virtualización para los servidores x86 fue en los años 90, pero tomó su flexibilidad neta más a futuro, permitiendo correr las máquinas virtuales que se emigraran de un servidor a otro sin la interrupción a las aplicaciones o, a los usuarios finales. Esta tecnología se llama VMotion, y desde su introducción al mercado en 2003, se ha ampliado, permitiendo a los clientes reequilibrar dinámicamente los servidores a través de un pool entero de servidores sobre una base en curso.

Los rebalanceos de las cargas de trabajo, se acomodan dinámicamente a través del centro de datos, y se pueden utilizar para optimizar el uso de la energía. Esta funcionalidad se llama Administración Distribuida del

Poder, y promete transformar el consumo de energía en el centro de datos. Esta característica contrae o expande automáticamente el pool de los servidores que funcionan en cualquier hora dada, sin la reducción de porcentajes de disponibilidad.

Trabaja supervisando la utilización de un pool de servidores y cuando existe exceso de la capacidad, mueve las máquinas virtuales corrientes sobre pocos servidores, y cierra automáticamente los servidores físicos innecesarios. Por lo que “el exceso de la capacidad consolidada” se controla por el usuario. Por ejemplo, esto puede incluir un almacenador intermediario de la capacidad para el recuperador de desastres automático, que es también una característica particular de la infraestructura virtual. Permitiendo que los clientes optimicen y reduzcan continuamente el consumo de energía del pool del hardware sin sacrificar la confiabilidad y la disponibilidad de la infraestructura de TI. El beneficio neto de los clientes es que pueden tener el correcto tamaño de su infraestructura de TI en tiempo real, de tal modo que maximizan la salida de TI mientras que consumen la menor energía posible.

Impacto ambiental del correcto tamaño de TI En el contexto de efecto y flexibilidad, hay algo que debe ser dicho sobre el impacto ambiental de la virtualización. Cada servidor que es virtualizado, ahorra electricidad 7.000 KVH y 4 toneladas de emisiones de CO2 por año. Con más de un millón de cargas de trabajo que funcionan en las máquinas virtuales, los ahorros de la energía agregados son hasta cerca de 8 mil millones KVH, que es más que la electricidad de la calefacción y la ventilación consumida en Nueva Inglaterra en un año. 1 Estos ahorros son sólo el comienzo gracias al exceso de provisión de hardware en la

industria. Para poner en perspectiva de tres años de exceso de capacidad en términos de consecuencias para el medio ambiente, con cuatro toneladas de CO2 producidos por el servidor, representa anualmente 80 millones de toneladas de emisiones de CO2, que es igual a las emisiones de la mitad de todos los países en América Latina. Solamente 5% de servidores físicos se han consolidado hasta la fecha, pero ahora que la virtualización ha llegado a ser de corriente, los pronósticos sugieren que se consolide a una mayoría de servidores, usando la virtualización en los próximos años. La consolidación del servidor y el volver a clasificar según el tamaño dinámico de TI tendrán un efecto económico y ambiental enorme.

Revolución del centro de datos La virtualización proporciona enormes ventajas de energía, y una línea de vida a los centros de datos que se están quedando sin poder, sin refrescarse o sin capacidad real. Sin embargo, esta ventaja no es generalmente la razón primaria para lo que funciona este software. Los ahorros de costos, la flexibilidad, la confiabilidad y la disponibilidad crecientes, han convencido al mercado, que la virtualización de centros de datos es una manera fundamental para entregar y administrar la infraestructura de TI. La virtualización para los servidores x86 y la innovación de virtualización en los últimos 10 años permiten que los centros de datos sean considerados como la infraestructura física estática. El centro de datos del futuro será virtualizado y de ambiente dinámico, el cual podrá constantemente tener el correcto tamaño para reducir al mínimo el consumo innecesario, el recuperador de desastres y la energía.

Referencias [ 1. eia.doe.gov/emeu/reps/enduse/er01_ new-eng_tab1.html ]

Rob Smoot es el responsable de Marketing de los productos de Administración de Virtualización para Data Center vCenter de VMware. Tiene más de 12 años de experiencia en marketing de software empresarial, fue Gerente Senior de Veritas Software, Gerente de Procesos de Negocio en Andersen. Cuenta con Posgrado en Administración de Negocios por la Universidad Brigham Young y Maestría en Administración de Negocios por la Wharton Business School de la Universidad de Pennsylvania.

60

FEB-ABR 2009

www.sg.com.mx

www.sg.com.mx

FEB-ABR 2009

59

// tecnología

/*gadgets*/

Research in Motion / Nextel

BlackBerry Curve 8350i Smartphone Bautizado como el gurú de los negocios, este pequeño, pero poderoso dispositivo es lo último en comunicación porque combina la rapidez de los sistemas de conexión directa push to talk de la red Nextel, con todas las características de un smartphone y capacidad Wi-Fi. Su teclado QWERTY más el tradicional trackball son prácticas herramientas para acceder de manera rápida al menú con las funciones típicas como correo electrónico, calendario, libreta de contactos o sistema GPS de navegación. Dentro del listado de cualidades del 8350i destacan una cámara digital de 2MP con zoom digital de 5x, flash y captura de video; software precargado para editar documentos en Word, Excel y Power Point, antena interna, altavoz, reproductor de medios para escuchar música, ver video o fotografías; memoria expandible a través de una ranura microSD, Bluetooth versión 2.0, y capacidad adicional para utilizar mensajeros instantáneos.

Sony

Vaio Serie P Con la etiqueta de Lifestyle PC, o lo que es lo mismo: “una compu con estilo”, la nuevísima Vaio Serie P nos recuerda aquel proyecto Origami y el intento un tanto fallido por lanzar al mercado la UMPC (UltraMobile PC) que luego de rumores, presentaciones y videos, quedó en el olvido. Ahora con la moda de las Netbooks, surge esta pequeñísima, práctica y completamente móvil computadora que ofrece todo lo que una de escritorio puede dar, pero en la comodidad de nuestros... ¿bolsillos? Con tan solo 1.4 libras de peso (635 gramos), la Vaio Lifestyle PC es tan ligera que se puede llevar en el bolso o incluso en una chaqueta o bolsillo amplio de un pantalón. Está disponible en cuatro colores, cuenta con diversos accesorios extra como un mouse láser Bluetooth, una funda de piel y una batería de alto rendimiento.

Sus características son las siguientes: pantalla de 1600 x 768 pixels, conectividad tanto por WiFi 802.11n como por red celular de banda ancha 3G, así como Bluetooth 2.0, procesador Intel de 1.33GHz, 60GB de disco duro hasta 128GB SSD, GPS, ranura para Memory Stick PRO (standard / duo), ranura de medios con funcionalidad MagicGate y SD. Así que estés donde estés y hagas lo que hagas es tiempo de olvidar la molesta mochila o el portafolio que pesa más que tu lap.

62

FEB-ABR 2009

Parrot

Conference El sistema Parrot Conference permite realizar conference calls utilizando ya sea la línea de tu teléfono celular, línea análoga o VoIP. El enlace al teléfono se realiza por medio de Bluetooth y es bastante sencillo.

Está diseñado para grandes salas de juntas ya que sus tres micrófonos de alta sensibilidad permiten que la voz y el sonido abarque 360 grados sin perder nitidez. Se puede mover de un lugar a otro gracias a sus tres baterías recargables de larga duración. La pantalla TFT de 160 X 120 pixeles muestra la información de los números que se marcan y por qué vía se enlaza la llamada. En general es un sistema de conferencia bastante amigable.

www.sg.com.mx

INDEX

DIRECTORIO

TENEMOS UN ESPACIO RESERVADO PARA TI

Anunciante Brio e-Quallity Gartner Gelattina IDC IT Institute JP Consultores Manpower Matersys Milestone Consulting NYCE P&M Consulting SafeNet SG Campus SG Revista Digital Tendencias

Pรกginas 57 49 61 25 63 13 39 7 2F, 1 4F 3F 37 11 17 55 59

Sitio www.brio.com.mx www.e-quallity.net www.gartner.com/mx/appint www.gelattina.com/alMaximo www.idc-eventos.com www.it-institute.org www.jpeconsultores.com www.manpowerprofessional.com.mx www.matersys.com.mx www.milestone.com.mx www.nyce.org.mx www.pmconsulting.com.mx www.safenet-inc.com www.sgcampus.com.mx www.sg.com.mx www.select.com.mx

Si deseas anunciarte contรกctanos en el (55) 5239 5502 o en publicidad@sg.com.mx www.sg.com.mx

FEB-ABR 2009

63

// COLUMNA

/*cátedra y más*/

La Otra Inteligencia de Negocios + Capital Intelectual Adecuado Dr. Raúl A. Trejo es profesor investigador del Instituto Tecnológico y de Estudios Superiores de Monterrey, campus Estado de México. Con especialidad en inteligencia artificial y apasionado de los lenguajes de programación, el Dr. Trejo ha encontrado en la administración del conocimiento y el desarrollo de negocios electrónicos un campo fértil para aplicar ambas disciplinas. En sus ratos libres es escritor de ficción.

Sus publicaciones tecnológicas se encuentran en www.tech-o-potamus.blogspot.com

E

l año que termina dibujó una situación difícil para la industria de tecnologías de información. Con presupuestos limitados, los recursos para innovación tecnológica estarán de seguro restringidos a lo esencial. Para muchas empresas, significa que muy probablemente la inversión tecnológica estará destinada a apoyar la operación con resultados de negocio más inmediatos. Y los consultores o directores tecnológicos promoverán sistemas orientados a dichas tareas.

Pero quizá el lector piense que es precisamente en épocas difíciles cuando se presenta la oportunidad de innovar, mejorar, y redefinir estrategias de mediano y largo plazo. Que quizá es justo en estos momentos, que la definición de estrategias fundadas en datos certeros determinará de manera importante el éxito, o incluso la supervivencia de la empresa.

Ciertamente, es un buen momento para incursionar en una iniciativa de inteligencia de negocios, o cimentar los objetivos de la iniciativa ya existente en la empresa. Y es que el costo de oportunidad de no realizar inteligencia de negocios resulta particularmente evidente ahora, lo cual, por supuesto, no nos distrae de lo enorme que resulta emprender una tarea de tal magnitud.

La inteligencia de negocios tiene demasiados componentes, y requiere de una sabia mezcla de directivos informados, expertos capacitados, consultores con visión; y software de punta.

Pero es también bajo esta situación particular, que debemos mencionar un componente fundamental para la consolidación de la iniciativa de inteligencia de negocios: necesitamos capital intelectual de primera. El ciclo de administración del conocimiento, empieza y termina con las personas que conforman la organización.

Y entonces, dada la problemática actual, se hacen indispensables dos actividades de inteligencia de negocios. La primera de ellas es mantener el capital intelectual. La identificación de mejores prácticas, la comunicación de modelos de optimización de procesos y el portal de conocimiento, no son de utilidad si no se cuenta con miembros de la organización que están al tanto de sus características corporativas y sus procedimientos, y que poseen en primera instancia, el conocimiento que da origen al ciclo de inteligencia de negocios.

En la situación actual, es una realidad que podemos perder capital intelectual valioso tanto por limitantes económicas como por simple ceguera de los mandos administrativos. Es ahora, más que nunca, que debemos cuidar nuestro capital intelectual. El tomador de decisiones, al verse ante la posibilidad de dejar ir a una persona, debería considerar lo siguiente: ¿deseo que lo que esta persona sabe, sea aprovechado por otra organización?

La segunda actividad concomitante al establecimiento de un esquema de inteligencia de negocios es, promover el capital intelectual. Es buen momento para acercarse a las universidades y explorar en busca de los nuevos talentos que se integrarán con facilidad a nuestras políticas y metodologías; así como para tomar a estos profesionistas y capacitarlos en nuestros procesos y habilidades, con modelos de negocio que promuevan su permanencia en la empresa.

Interesante reto el de los directores estratégicos y de tecnología; pero válido y vigente, dados los objetivos estratégicos de las empresas, donde la inteligencia de negocios jugará un rol determinante. » Por Raúl A. Trejo Ramírez

64

FEB-ABR 2009

www.sg.com.mx

No. 23

www.sg.com.mx

SG SOFTWARE GURU - CONOCIMIENTO EN PRﾃ，TICA

Febrero-Abril 2009