sg23 (febrero-abril 2009)

Software Guru CONOCIMIENTO EN PRÁCTICA

w

ww

.sg.

com

.mx

SG

SO

FT

WA

RE

GU

RU

- C

ON

OC

IMIE

NT

O E

N P

RÁ

CT

ICA

Feb

rero

-Abr

il 20

09

No.23 • Febrero - Abril 2009 • www.sg.com.mx

[ Tutorial ] JUnit 4Noticias • Eventos • Fundamentos • UML • Infraestructura • Tendencias

No.

23

• Aseguramiento de Calidad

• Casos de Uso

• Arquitectura Empresarial

México. $65 MXN

[ MEXICANOS EN EL EXTRANJERO ]

Miguel MaderoRodrigo GarcíaArie Grapa

[ Especial ]

Premios SG 2008

La Inteligencia de Negocioscomo herramienta estratégica

La Inteligencia de Negocios como herramienta estratégica

FEB-ABR 2009 www.sg.com.mx

Dirección EditorialPedro Galván

Dirección de OperacionesMara Ruvalcaba

Coordinación EditorialAlejandro Escamilla

Arte y DiseñoGrisel Otero

Desarrollo WebNathanael 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.

ColaboradoresGunnar 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érezLuis 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

[email protected]

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

directorio

Editorial

// CONTENIDO

02

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 introducir-lo en las PyMEs. Hasta hace unos años, la inteligencia de negocios era algo que sola-mente los grandes corporativos hacían. Sin embargo, conforme los sistemas de infor-mació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 te-ner una mejor idea de las herramientas y tecnologías más utilizados por los pro-fesionales de desarrollo de software en nuestra región.

En esta ocasión publicamos una pequeña entrevista con tres profesionistas de soft-ware de origen mexicano que actualmente laboran en el extranjero. Más allá de pre-sumir 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 siem-pre. Les deseamos lo mejor para este año.

» Equipo Editorial

FEB-ABR 2009www.sg.com.mx

Columnas

Tejiendo Nuestra Red 08por Hanna Oktaba

Mejora Continua 10por Luis Cuellar

Programar es un Modo 47de Vida por Gunnar Wolf

Prueba de Software 52por Luis Vinicio León

Tendencias en Software 54por Luis Daniel Soto

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

22

Productos

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

TUTORIAL 14JUnit 4.

Prácticas

ARQUITECTURA 38Enteprise ArchitectureLa arquitectura empresarial se encarga de alinear la estrategia, los procesos y la tecnología.

REQUERIMIENTOS 40Cuando los Casos de Uso no AlcanzanRecomendaciones sobre la correctaaplicación de los casos de uso.

PROCESOS 42COMPETISOFTMejora de procesos de software en Iberoamérica

ASEGURAMIENTO DE CALIDAD 44Implementación de Modelos deCalidadDiagnóstico de las empresas en México

UML 48Las Relaciones son ImportantesAprendamos a detallar relaciones en base a la infor-mación de diagramas de secuencia.

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

EN PORTADA

Inteligencia de Negocios 26La inteligencia de negocios comoherramienta estratégica.

Premios SG 2008 18

contenido feb - abr 2009

03

En Cada Número

NOTICIAS y EVENTOS 04

INDUSTRIA 06

FUNDAMENTOS 56

// CONTENIDO

PerfilesMiguel MaderoRodrigo GarcíaArie Grapa

INFRAESTRUCTURA 58

TENDENCIAS 60

GADGETS 62

26


// NOTICIAS

04

Microsoft PDC 2008Del 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 es-tará liberando en el futuro próximo. Entre los temas que más des-tacaron 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 estare-mos 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 Tec-nologías de Información, Gartner presentó una visión de las ten-dencias 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.0El Clúster de Tecnologías de Información de Baja California, A.C. (IT@baja), realizó por primera vez durante el pasado mes de No-viembre el evento “BajaTech Business Solutions 2.0”, un punto de encuentro entre las empresas proveedoras de soluciones tecnológi-cas 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 partici-pació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


// EVENTOS

05

GULEV 2008La paradisiaca playa de Cancún fue sede de la edición 2008 del Congreso Internacional de Software Libre GULEV, realiza-do 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

Arranca proyecto para desarrollo de Capital Humano

El proyecto dirigido por IMPULSA “Modelo de Vinculación Empresa-Academia-Gobierno para el Desarrollo en Capaci-dades 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.

17 al 19 de Febrero 2009CompuShow 2009Cintermex Monterrey, Nuevo LeónInfo: www.compushow.com.mxe-mail: [email protected]

24 de Febrero 2009Tendencias 2009SelectCentro Banamex, México, D.F.Info: www.select.com.mx/tendencias/tendencias09/index.htmle-mail: [email protected]

25 de Febrero 2009Information Management & BI 2.0ConferenceIDC MéxicoHacienda de los Morales, México, D.F.Info: www.idc-eventos.come-mail: [email protected]

26 al 28 de Febrero 2009SISCTITecnológico de Monterrey, Campus MonterreyInfo: www.siscti.come-mail: [email protected]

26 y 27 de Marzo 2009WebSec Conference 2009IDC MéxicoHacienda de los Morales, México, D.F.Info: www.idc-eventos.come-mail: [email protected]

28 y 29 de Abril 2009Gartner Enterprise Integration SummitCentro Banamex, México, D.F.Info: www.gartner.com/mx/appinte-mail: [email protected]

Empresas recientemente evaluadas en CMMI:

Empresa Evaluación Fecha Lead Appraiser Apoyado por SAITO CMMI Nivel 2 marzo 2008 José Enrique Pérez SIE CenterPLENUMSOFT CMMI Nivel 2 julio 2008 Enrique Morey SIE CenterGrupo Mnemo CMMI Nivel 3 agosto 2008 Mariana Pérez-Várgas AvantareVicerrectoría de RH y TI, Tec de MTY CMMI Nivel 2 diciembre 2008 José Enrique Pérez SIE CenterQualysis CMMI Nivel 3 enero 2009 Mariana Pérez-Várgas Avantare


• Contribuir a la identificación, definición y promoción de los estándares derivados del modelo MoProSoft. • Asesorar a empresas privadas, organis-mos gubernamentales y académicos sobre el buen uso del modelo. • Respaldar la correcta implementación del modelo mediante el sello de confian-za para proveedores de servicios. Trabajar coordinadamente con los organismos veri-ficadores oficiales.

Actualmente existen varios proyectos eje-cutándose en la Asociación, todos admi-nistrados 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 es-tándares derivados. Orientar a organismos sobre el valor del modelo.• Proyecto de Investigación. Investigar e incorporar guías para apoyar la implanta-ción del modelo.• Proyecto de Mejora. Identificar los hallaz-gos y proponer enmiendas a la norma. Me-jorar el modelo a partir de las buenas prác-ticas identificadas. Recopilar y publicar las mejores prácticas.

MoProSoft ha sido reconocido internacional-mente, siendo utilizado como base de diferen-tes normas y modelos. Las empresas mexica-nas debemos aprovechar que este modelo ha sido creado en México y tomar ventaja para lograr una industria más competitiva.

16

// INDUSTRIA

06

Mejorando la Industria

AdoptAndo MoproSoft

Como ya hemos visto anteriormente en es-tas 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 soft-ware el acceso a las prácticas de Ingeniería de Software y Administración de Proyectos. MoProSoft está basado en el modelo SW-CMM, 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 nues-tro país 85% de las empresas dedicadas al Desarrollo y Mantenimiento de Software son PyMES. Por su estructura, diseño, fácil com-prensión y aplicación, esta norma es adecua-da para implantar un programa de mejora.

La adopción de MoProSoft habilita la ob-tención de un certificado de la norma NMX-I-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 verificacio-nes formales, y actualmente ya contamos con más de 100 empresas verificadas en algún ni-vel 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 implan-tación de MoProSoft, aún no se cuenta con métricas cuantitativas suficientes que per-mitan conocer la mejora e impacto en las or-ganizaciones, pero sí contamos con un dato muy valioso, lo que sus usuarios opinan:

• La implementación del modelo tardó va-rios meses, pero bien valió la pena, ya que cumplió el objetivo de satisfacer las necesi-dades de los clientes.• Existe un cambio real en la cultura de la organización (cuestiones de horarios, com-promiso de las personas).• La definición e instrumentación de los objetivos organizacionales permite deli-near nuestras actividades.• Los procesos documentados funcionan como guías de las actividades que debe-mos realizar.

• 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 proyec-tos nos han ayudado a optimizar el manejo de recursos.• Se establecieron formatos base consen-suados 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 co-municación en la Organización.• La base de conocimiento concentra el cono-cimiento y experiencia acumulada que será útil para futuros proyectos.• Se formalizaron las funciones del área de Recursos Humanos.

ASUMEn 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 interesa-da en el modelo MoProSoft para promover su estudio, adopción, mejora y difusión a nivel nacional e internacional, represen-tando los intereses de los asociados ante los organismos e instituciones pertinentes. De igual manera, busca brindar a sus aso-ciados, conocimiento y dominio de MoPro-Soft, información actualizada, bibliografía, red de contactos, investigación, piloteo de proyectos, círculos de estudio y colabora-ción con otros organismos.

La ASUM se enfoca en los siguientes puntos: • Elevar el nivel de competitividad de la in-dustria 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 acti-vidades en conjunto con la industria, go-bierno y academia. • Intercambiar experiencias y colaborar con organizaciones afines nacionales e in-ternacionales.

Únete a la ASUM contacta:[email protected]

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

FEB-ABR 2009www.sg.com.mx 1707

FEB-ABR 2009 www.sg.com.mx08

Reunión del WG 24 en la Ciudad de MéxicoorgulloSoS AnfitrioneS

/*TEJIENDO NUESTRA RED*/// COLUMNA

Del 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 proyec-to 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 re-cibidos. 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 revi-saba 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 co-mer, 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

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 to-dos. 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, de-partamentos 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 perfi-les 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ác-ticas que tengan valor real para las empresas.

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.


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

Los días siguientes, Claudia, Blanca, Ana y yo nos dedicamos a in-corporar todas las correcciones aprobadas o aprobadas en princi-pio 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 pre-paració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 oca-sió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

/*TEJIENDO NUESTRA RED*/// COLUMNA

09

Terminamos la revisión de comentarios, y los demás pendientes, el jueves por la tarde. Esa misma noche NYCE, nuestro segundo patro-cinador, nos ofreció una agradable cena en WTC. Las palmas de la noche las llevó el grupo de mariachi que dejó a todos muy sonrien-tes 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


/*MEJORA CONTINUA*/// COLUMNA

2. Se ha demostrado que los seres humanos tendemos a repetir errores. Cuando nos equi-vocamos 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 equi-vocas 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 dife-rentes 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 impor-tante 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 defec-tos, la fase donde se generó el defecto y la fase donde finalmente se detectó.

2. Si acostumbramos repetir errores, enton-ces el utilizar checklists para hacer las revi-siones es la estrategia con mayor retorno de inversión y creo que de los menos utiliza-dos. 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 per-fecto”, Esto es cierto pero no debería ser una excusa para no trabajar lo mejor posi-ble. De alguna manera si queremos crecer y superarnos como industria es sumamen-te importante que nos hagamos responsa-bles de lo que hacemos y aprendamos de nuestros defectos.

» Por Luis Cuellar

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

En todas las industrias tanto de produc-tos 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 des-de 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 opera-tivos que salen a la venta bajo la premisa de que continuamente se liberaran parches para resolver todos los problemas que surjan, has-ta 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 pre-ocupación es la entrega a tiempo: gastamos una interminable cantidad de horas estiman-do el esfuerzo, planeando el proyecto, y dan-do seguimiento a cada paso. En mi experien-cia, 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 ge-neraran y se tienen que resolver.

El problema de la mediciónPuntos funcionales, líneas de código, números de módulos; existe gran can-tidad de formas de estimar un proyec-to, 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-

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 di-ferentes dependiendo del tipo y característi-cas de cada organización. Al crear una defi-nició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 de-finició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 granu-laridad 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 defectosLos 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 po-sibilidad 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 te-nemos un 90% del producto bien en cada paso, al final la posibilidad de terminar sin defectos es de 90%^5 = 59%. Si conside-ramos la cantidad de pasos que se llevan al desarrollar software, entenderemos lo dificil que es tener un sistema sin defectos.


/* LO QUE VIENE*/// PRODUCTOS

Spring + BlazeDSLo mejor de dos mundos

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

SpringSource también está desarrollando un adap-tador 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.springsource.org/spring-flex

ASP.Net MVCDesarrollo web civilizado

Una tecnología que está teniendo muy buena recepción en-tre 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

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.

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

Python 3Por fin llega

La comunidad de desarrolladores de Python liberó el pasado di-ciembre 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 impul-sado 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, intro-duce 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 satisfa-cer 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

Drools 5Integración de reglas de negocio, procesos ymanejo de eventos

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 ejecu-ció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


JUnit 4 - ¡A Toda Máquina!introducción A lA evolución y nuevAS cArActeríSticAS de Junit 4Por Erick Frausto

14

/*TUTORIAL*/// PRODUCTOS

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 JUnitJUnit es ya de por sí un framework que facilita en demasía el desa-rrollo 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.

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

Métodos de pruebaCon 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 propor-cionada por Java 5. Ejemplo:

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 ge-nerar nuestras propias convenciones de nombrado de pruebas.

Evolución de los métodos setUp() y tearDown()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 { private double x = 50.0; private double y = 20.0; @Test public void calculatePercentage() { double z = x * (y/100); assertEquals(10.0, z); } }

import junit.framework.TestCase;

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

import org.junit.Before;import org.junit.Test;import static org.junit.Assert.*;

public class CalculatePercentageTest2 { private double x; private double y; @Before public void initializeTest() { x = 50.0; y = 20.0; } @After public void finalizeTest() { } … }

Así haríamos la misma prueba con JUnit 3:



“ La nueva versión de Junit 4 simplifica eldesarrollo 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 cos-tosos en cuanto a desempeño al momento de abrir y/o cerrar.

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

Así haríamos la prueba con JUnit 3:

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

Ignorando pruebasYa no será necesario comentar un método de prueba cuando no que-ramos 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:

Ayuda en pruebas de desempeñoJUnit 4 proporciona ayuda para realizar pruebas de desempeño den-tro de las pruebas unitarias. Y aunque no resuelve de todo el tema de este tipo de pruebas por no ser su objetivo principal, sí proporcio-na una ayuda importante. Ejemplo:

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:

import org.junit.Test;

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

}

import junit.framework.TestCase;

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

}

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

public class ExceptionTest2 { private int[] array = new int[2]; private String str; … @Ignore public void ignoreTest() { str.contains(“a”); }

}

import org.junit.Test;

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

}



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 des-empeña como Arquitecto JEE. Erick invita a todos, a nunca dejar de soñar y luchar por hacer sus sueños realidad.

“JUnit 4 proporciona ayuda pararealizar pruebas de desempeño dentro de

las pruebas unitarias”.

Nuevas asercionesJUnit 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 em-bargo, 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:

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

PerformanceTest Failed – test timed out after 2000 milliseconds

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í po-derosa 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 co-sas 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, inten-tando 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 ]

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


Dado que estos son premios “elegidos por los lectores”, el mecanismo utilizado con-siste 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 Uru-guay. Resaltó que incluso las empresas pro-veedoras 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 te-ner 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 ca-tegoría, puedes visitar el wiki de premios SG en wiki.sg.com.mx

Veamos entonces los resultados ...

» Administración de datos1. MySQL Enterprise Monitor2. IBM Rational Data Architect3. EMS SQL Management Studio

En esta categoría participaron productos muy diversos, lo cual se refleja en los pro-ductos ganadores: MySQL Enterprise Mo-nitor es para monitorear el desempeño de bases de datos durante operación, mientras que IBM Rational Data Architect es para mo-delar los datos de una aplicación, y SQL Ma-nagement 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 Professional2. Eclipse3. 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 desa-rrollador. 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 dearquitectura1. IBM Rational Software Architect2. Microsoft Visual Studio Team SystemArchitecture Edition3. Sparx Enterprise Architect

Conforme los sistemas de información dis-tribuidos y las arquitecturas orientadas a servicios se vuelven más comunes en las or-ganizaciones, el rol de la arquitectura de sis-temas se ha convertido en algo crucial, y por

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

» ETL1. Oracle Warehouse Builder2. IBM Information Server3. Business Objects Data Integrator

Las herramientas ETL se utilizan para ex-traer información de una o más fuentes de datos, transformarla y depositarla en otro repositorio.

» Framework para desarrollo Web1. ASP .Net MVC2. Struts3. 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 aplicaciones1. Genexus2. PowerBuilder3. Clarion

Las herramientas para generar aplicaciones se mantienen vigentes y han evolucionado significativamente para responder a las nece-sidades 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 pro-ducto tan conocido como PowerBuilder.

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


» Gestión de la configuración1. Subversion2. Microsoft Team Foundation Server3. IBM Rational ClearCase

La categoría de gestión de la configuración es bastante amplia e involucra productos con funcionalidad muy va-riada. Aun así, el corazón de estas herramientas es el con-trol de versiones. Cabe notar que la votación en esta cate-gorí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 RequisitePro2. Microsoft Team Foundation Server3. Borland Caliber RM

Las herramientas para gestión de requerimientos ayu-dan 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 componentes1. Apache Commons2. NetAdvantage for .Net3. VCL – Delphi Visual Components

Es común recurrir a componentes previamente desa-rrollados para resolver problemas como graficación de datos, manejo de seguridad o manejo de bitácoras, en-tre otros. Muchas personas y organizaciones recurren a componentes desarrollados internamente, pero es bue-no saber que hay muchas opciones allá afuera, tanto de software libre como comercial.

» Modelado UML1. IBM Rational Software Modeler2. Visual Paradigm for UML3. Sparx Enterprise Architect

En el campo de las herramientas para modelado visual con UML, Rational Software Modeler, heredero del le-gendario Rational Rose se mantiene a la cabeza. Visual Paradigm es un producto que ha cobrado gran popula-ridad en los últimos años, principalmente debido a que ofrecer una versión gratuita.

» Gestión de pruebas1. IBM Rational Quality Manager2. HP Quality Center3. 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 he-rramientas 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

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

» Pruebas funcionales1. IBM Rational Functional Tester2. Borland SilkTest3. HP QuickTest Professional

Como su nombre lo indica, las herramientas para prue-bas funcionales permiten probar la funcionalidad de un software. Típicamente proveen “robots” para pruebas automatizadas y grabación de scripts que posteriormen-te 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 produc-tos que adquirió de Mercury.

» Pruebas de desempeño1. IBM Rational Performance Tester2. Apache JMeter3. 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 negocios1. IBM Cognos 82. Oracle Business Intelligence Suite3. Microsoft Business Intelligence Suite

En esta categoría apareció una gran cantidad de provee-dores tanto nacionales como internacionales así como de software libre. Al final, la votación fue dominada por los sospechosos comunes.

» Portal empresarial1. IBM WebSphere Portal2. Microsoft Sharepoint Server3. Apache JetSpeed

El segmento de portales empresariales está viviendo un momento interesante, conforme la oferta busca evo-lucionar 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ónempresarial1. Google Apps2. Microsoft Sharepoint3. IBM Lotus Connections

La nueva generación de portales empresariales está orien-tada hacia la colaboración. Capacidades como wikis, mash-


ups, edición de documentos colaborativa, re-des sociales intra/extra-empresa, mensajería instantánea integrada son el común denomina-dor. 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 fun-cional y robusta.

» Plataforma BPM1. IBM WebSphere2. JBoss jBPM3. Oracle BPA Suite

Hace un par de años, los BPMS (Business Process Management System) eran conside-rados “el futuro” de los sistemas de informa-ción. Actualmente ya no suenan tanto, pero no por ello pierden importancia. Simplemen-te, 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 SOA1. IBM WebSphere2. Microsoft SOA3. Apache ServiceMix

El año pasado vivimos la “fiebre de SOA”, donde prácticamente todos los proveedo-res de middleware aseguraban ser los non-plus-ultra del SOA y trataban de empujar su visión, generando mucha confusión. Afortu-nadamente dicha fiebre va de bajada, por lo que auguramos que conforme avance este

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

» Sistema para Gestión deContenido (CMS)1. Joomla2. Lotus Web Content Management3. Wordpress

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

» Servidor de base de datos1. Oracle Database2. Microsoft SQL Server3. MySQL

Después de los IDEs, ésta es la categoría que más votos recibió, lo cual es de espe-rarse ya que prácticamente todas las aplica-ciones 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óviles1. Sun Java Mobile Edition2. iPhone3. Windows Mobile

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.

» Respaldo y recuperación de datos1. IBM Tivoli Storage Manager2. Symantec NetBackup3. Sun StorageTek Enterprise Backup Software

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

ConclusiónCon esto terminamos el listado de ga-nadores 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.


// PERfILES

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 gen-te 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 con-tinuar con uno muy largo de trámite de visa de trabajo. Creo que la recomendación fue algo muy importante para agilizar el proce-so. El estar involucrado en proyectos open source y participar en comunidades de de-sarrollo 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-

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 inmi-grantes que hay. Por ejemplo, en mi actual proyecto trabajo con personas de 10 dis-tintas nacionalidades, sólo uno de ellos es australiano. Esto se ve reflejado en las tradi-ciones y especialmente en la comida.

¿Pretendes regresar a México? A corto plazo será sólo de visita, ya que segui-ré 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.

¿Recomendarías a un colega irse a trabajar a Australia? Sí, definitivamente. Vivir en otro país siem-pre te enriquece, y Australia es una gran opción. Por un lado está el aspecto profe-sional, 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.

He conocido a algunas personas que vie-nen 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 em-presas prefieren recibir correos por email o a través de su website. Si la compañía está dispuesta a contratar a alguien del extran-jero, tendrán los procesos adecuados para realizar todo el trámite de manera remota, incluyendo entrevistas y evaluaciones téc-

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

A quienes les interese, les recomiendo que visiten el blog de Toni-anne, gerente de re-cursos humanos de Readify (mother-toni-anne.spaces.live.com), tiene algunos posts respecto a la vida en Australia y buenas re-comendaciones.

¿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 pue-den ser una muestra sesgada en este pun-to, pero es mi percepción que, a diferen-cia de México, aquí no se habla de CMMI o procesos de madurez estructurados. En cambio, las metodologías ágiles en espe-cial SCRUM, son muy populares, inclusive en grandes corporaciones. De hecho, en Readify buena parte del trabajo que reali-zamos es consultoría y entrenamiento para implantación de métodos ágiles.

En el aspecto tecnológico, nos enfocamos en .NET, sin embargo, he tenido la oportuni-dad 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 importan-tes, como el TechEd, ReMix y JAOO. Existen tantas comunidades de desarrollo, que aun-que todas ofrecen algo interesante, hay que ser muy selectivo para tener tiempo de ir a los eventos más importantes y aún tener al-gunas tardes libres.

En cuanto a las personas, en esta industria tenemos un problema muy similar en Aus-tralia 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 universi-dades. 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 Fran-cia o Estados Unidos.

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

Miguel Madero


// PERfILES

¿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 presupues-to. Actualmente trabajamos con clientes de China, Asia, Europa y América.

¿Por qué aceptaste ir a China?El mercado de servicios en China está cre-ciendo 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 vacacio-nes y me gustó mucho Beijing. Es una ciu-dad totalmente cosmopolita, donde encuen-tras 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 Nearsho-re. La operación local da servicio a empresas dentro de China. Para esto tenemos oficinas en Beijing, Shangai, Xian y Xiamen ofrecien-do 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 no-ches y madrugadas.

Rodrigo García

¿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 comunica-mos a través del idioma oficial de la empre-sa 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 seg-mento 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 carre-ras 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 si-gue 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 den-tro de sus oficinas, y no están muy interesa-das en niveles de servicio y métricas, bus-can 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 aho-ra 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, sien-do 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 simi-lar en otras es algo invaluable. Como persona te abre los ojos, te ayuda a entender mejor el porqué otras culturas y sociedades se desa-rrollan 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 per-sonas 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 na-cionalidades que quieran venir a intercam-biar procesos, formas de trabajo y conoci-miento 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.

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 desarro-llo web, en 2005 fue nombrado Gerente de Producto de la oferta de desarrollo de aplicaciones y en 2007 inició su aventura en China.


// PERfILES

¿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. Fun-ciona como una gran red de bolsas de valo-res 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 mer-cado, 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 desarro-llo 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 Uni-dos, 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

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

No tengo una fórmula para que las empre-sas 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 des-cuentos en impuestos o en rentas de in-muebles. En otros lugares han construido grandes parques tecnológicos con infraes-tructura preestablecida y legislación espe-cial 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/desa-rrollo de empresas locales de tecnología?Creo que debemos tratar por ambos cami-nos, 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 ingenie-ros, y creo que en habilidades no hay dife-rencia 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_Insti-tutes_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 me-jorarlos. Estoy seguro de que hay muchas excepciones, pero en general creo que en estos países se hace más énfasis en la for-mació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 habi-lidades mentales que se nos facilitan y otras que se nos dificultan. La educación que recibi-mos y la práctica nos ayudan a reforzarlas y ser mejores en ellas. Al igual que con los múscu-los, 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.

Arie GrapaArie 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 fi-nales 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!


Los Retos de laInteligencia de Negocios

Por Héctor Franco Beltrán

Mucho 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 Sys-tems (EIS), Decision Support Systems (DSS), Corporate Performance Management (CPM), Bi-Predictive Analytics, BI 2.0, etc.; en fin, existen múltiples autores, ana-listas, 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í.


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

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

En el tema de los negocios también encon-tramos un sinfín de paradojas, pero me pa-rece 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 organiza-ción se llama empresa. También es la conse-cuencia 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 “Inte-ligencia de Negocios” y le da sentido es la estrategia, la táctica y la operación de las organizaciones como herramienta de super-vivencia. 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 negociosLa inteligencia de negocios es un área de co-nocimiento que nos brinda una gran oportu-nidad 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 disci-plinas derivadas, que sería imposible entrar en detalle en cada una de ellas en un solo artículo, ya que existen metodologías, ha-bilidades 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 Cor-porativo (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 efectivoLograr instrumentar una iniciativa de inteli-gencia 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 visua-lizará para la toma de decisiones. Tan impor-tante 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 mane-ra paranoica y desenfrenada. Las organi-zaciones 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 pa-labras… sobre todo de nuestros competido-res 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, infiltra-ciones, 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, infor-mación no estructurada, plataformas he-terogéneas. • Enfoque en reducir costos, mejorar proce-sos, 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 compo-nentes 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 oportu-nidad de mostrar las bondades de la inteli-gencia de negocios en el sector Gobierno.• Es inteligente utilizar y optimizar lo que ya se tiene para inteligencia de ne-gocios. ¡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. [email protected] www.tbii.org.mx


Minería de DatosDescubriendo 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 conside-rable mejora en el tratamiento de los datos estructurados y en la mejora de la toma de decisiones. Las bases de datos relaciona-les (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.


Minería de datosMinería de datos es un concepto que in-volucra la obtención de conocimiento en forma práctica, no en el sentido teórico. El punto de interés principal, es el de descu-brir y describir patrones encontrados en los datos. Pretende resolver problemas o pro-nosticar nuevos datos a partir de los datos ya presentes que se encuentren en el Data Warehouse corporativo. Por ejemplo: per-miten 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 aplicacio-nes orientadas al servicio.

Las técnicas de minería de datos al día de hoy se encuentran plenamente desarro-lladas, y para algunos tipos de análisis se encuentran en fase de maduración. Los métodos de minería de datos operan so-bre 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 necesa-rio que se realice previamente una prepa-ración sobre los datos, que les provea de la estructura necesaria para la técnica de minería a emplear.

Figura 3. Minería de datos

El proceso de descubrimiento de patrones puede ser automático o semiautomático, los patrones identificados deben ser signifi-cativos y aportar alguna ventaja, usualmen-te de tipo económico.

Aplicación de la mineríade datosLas técnicas empleadas en la minería de da-tos 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 pri-mer caso se conoce el tipo de decisión (cla-se) 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 presen-tan valores talesvv que las comparaciones en rangos tengan sentido, mientras que los

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.

Buscar relaciones ocultas(conocimiento)

Análisis del pasado

Histórica

Transaccional / Operacional

Know HowBI

BDR

MINERÍA

OLAP / OLTP

Data Warehouse / Data Marts

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

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

Cuál fue el total de ventasmensual de los últimos 5 años

con un detalle por estadoy punto de venta

Cuál fué el total de ventasmensual de los últimos 5 años

Cómo detectar y orientar lastendencias del mercadoBI

BDR

MINERÍA

OLAP / OLTP

Data Warehouse / Data Marts

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

OLAP Data Warehouse /Data Marts

Preparación de Datos

Minería


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 da-tos 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.

El dato que se pretende pronosticar es la marca. Es decir, si se presenta un nuevo in-dividuo 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 anterio-res, el método que emplearemos se conoce como ID3, éste es una estrategia que divide y conquista, que opera tratando de maxi-mizar 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 entro-pí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:

Edad Sexo Delegación Marca Tipo Motivo

41-50 F Azcapotzalco Ford Sedán Marca21-30 M Azcapotzalco Mazda Deportivo Gusto51-60 M Azcapotzalco Pontiac Sedán Precio41-50 F Gustavo A. Madero Chrysler Sedán Gusto31-40 F Tlalnepantla Chevrolet Sedán Precio31-41 M Tlalnepantla Chevrolet Camioneta Precio21-30 M C. Izcalli Chevrolet Sedán Precio41-50 F Gustavo A. Madero Toyota Camioneta Gusto41-50 F Gustavo A. Madero Ford Camioneta Tamaño41-50 F Naucalpan Ford Camioneta Tamaño41-50 M Naucalpan Mazda Camioneta Gusto51-60 F Naucalpan Toyota Sedán Servicios41-50 F Naucalpan Toyota Sedán Precio31-40 F Benito Juárez Toyota Sedán Gusto31-40 M Benito Juárez Chevrolet Camioneta Marca51-60 M Atizapán Honda Camioneta Gusto51-60 F Atizapán Chrysler Sedán Precio21-30 M Atizapán Susuki Compacto Precio21-30 F Atizapán Pontiac Sedán Gusto51-60 M Atizapán Pontiac Sedán Gusto51-60 M Álvaro Obregón Nissan Deportivo Gusto21-30 F Atizapán Seat Sedán Precio21-30 M Atizapán Pontiac Sedán Gusto51-60 F Atizapán Honda Camioneta Tamaño

Figura 6. Preferencias en compra de automóviles.

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

Esto nos da el primer nodo de nuestro árbol, el nodo seleccionado es aquel que presen-ta 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 da-tos. Éstas desarrollan técnicas de aprendi-zaje automatizado y permiten aplicarlas a problemas reales de minería de datos. Tam-bié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 mi-nería en el conjunto de datos seleccionados.En el árbol podemos observar que la dele-gación es el principal atributo que intervie-ne en la selección de una marca particular de vehículo, en el caso de las delegaciones, en particular los casos de Azcapotzalco y

Edad ElEmEntos ChEv Chry Ford honda mazda mErCEdEs nissan PontiaC sEat susuki toyota

21-30 6 1 0 0 0 1 0 0 2 1 1 031-40 4 3 0 0 0 0 0 0 0 0 0 141-50 7 0 1 3 0 1 0 0 0 0 0 151-60 8 0 1 0 2 0 1 1 2 0 0 1 25 4 2 3 2 2 1 1 4 1 1 4razondEoCurrEnCias 21-30 6 0.16 0 0 0 0.16 0 0 0.33 0.16 0.16 031-40 4 0.75 0 0 0 0 0 0 0 0 0 0.2541-50 7 0 0.14 0.42 0 0.14 0 0 0 0 0 0.1451-60 8 0 0.12 0 0.25 0 0.12 0.12 0.25 0 0 0.12 25 0.16 0.08 0.12 0.08 0.08 0.04 0.04 0.16 0.04 0.04 0.16logaritmodElarazondEoCurrEnCias 21-30 6 -2.58 -2.58 -1.58 -2.58 -2.58 31-40 4 -0.41 -241-50 7 -2.8 -1.22 -2.8 -2.851-60 8 -3 -2 -3 -3 -2 -3 25 -2.64 -3.64 -3.05 -3.64 -3.64 -4.64 -4.64 -2.64 -4.64 -4.64 -2.64EntroPia 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 Entropiasistema 1.953 Entropiaedad 1.299 Ganancia

Atributo Ganancia

Edad 1.29989551Sexo .65923654Delegación 1.7532697Tipo 1.1328787


Dafne Rosso ha participado desde 1998 en iniciativas orientadas a la implementación de soluciones basadas en inteligencia de negocio. Actual-mente 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.

Gustavo A. Madero, se observa que el siguien-te factor determinante es la edad de la perso-na, sin embargo, en Naulcalpan se observa que se tienen motivos particulares que mar-can 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 re-sultado será más aproximado a la realidad.

La minería de datos en este ejemplo nos per-mitió obtener conclusiones que, a simple vis-ta 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 cues-tiones 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é ac-tuando como un indicador del estilo de vida de las personas, lo que definitivamente influiría en la elección del auto a comprar. Esta inter-pretació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 empresaLas técnicas de minería de datos, pueden ser implementadas en las empresas para el descubrimiento de información, apor-tando 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

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

Las aportaciones que este tipo de tecnología puede hacer en las empresas, son encau-sadas a mantener el nivel competitivo de la empresa, los beneficios de la minería como la capacidad de identificar patrones, compor-tamientos, 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 ]

Figura 4. Ejemplo de un árbol de decisión resultante de la minería.

Azcapotzalco

41-50

41-50

Sedán Camioneta

31-40

51-60 21-30

Gustavo A. Madero Tlalnepantla Naucalpan

PrecioPrecio GustoMarcaServicios

Tamaño

41-50 31-40

Gusto Tamaño

Tamaño

F

M


Trabajando en un entorno cada vez más com-petitivo, las PyMEs ya no sólo interactúan de forma local, incluso se han aventurado en nue-vas 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 ba-sadas en información clave (presente).

Un sistema de monitoreo basado en indicado-res de gestión, implica la capacidad de proce-sar en tiempo real y a una gran velocidad, can-tidades 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 informa-ción, reduce el costo de hacer negocios y se convertirá en una nueva fuente de ingresos.

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

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 deci-siones de forma inoportuna o incorrecta.

Dificultades detectadas en la explotación de herramientas BI en las PyMEsMauro González, Director de Inteligencia de Negocios de AC Group Assembler Consul-tants, indicó que BI son potentes sistemas implementados en las empresas más exito-sas en el mundo, que resultan a veces, in-accesibles 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 herra-mientas BI anteriormente, se inclinan por las que ya conocen o se guían por recomen-daciones como las que se pudieran tomar de artículos como los publicados por Gartner;

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 explota-ción adecuada de las herramientas de BI ya implementadas son:• Uso nulo o escaso por parte de los usua-rios, ya sea por dificultad en su uso, por fal-ta de información requerida, porque no es confiable o porque al usuario no le gusta.• Se utiliza únicamente para extraer informa-ción aunque el análisis se haga manualmente.• Se utiliza únicamente como generadora de re-portes 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 tie-nen el conocimiento o el tiempo para usar estas herramientas.

de Utilizar BI en las PyMEs?Explotar los Beneficios de BI

Por Ma. Ernestina Ortíz

¿Cómo Surge la Necesidad


• 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 laadquisición de BIPara adquirir una solución BI se debe:• Identificar los beneficios que la informa-ció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 in-formació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 favo-recer la comunicación e interacción de las distintas entidades funcionales, para que la información generada fluya a todos los estra-tos 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, tecno-logía y arquitectura de cada opción, lo que definirá criterios técnicos y funcionales para su adquisición.

Alternativas de BI para PyMEsPara poder explotar los beneficios de la in-teligencia de negocios en las PyMEs, la al-ternativa 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 siste-mas de información (minería de datos) y mo-nitorear 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 Bu-siness y SAS Business Intelligence for Small to Midsize Business de SAS.

ConclusiónEn el mundo globalizado en el que se desem-peña la PYME, donde la competencia es fuerte y la posibilidad de subsistencia depende de las decisiones que se tomen por los ejecuti-vos, se requiere de herramientas que permi-tan procesar las grandes cantidades de infor-

Ma. Ernestina Ortíz García es Licenciada en Sistemas Computacionales Administrativos en la Universidad Veracruzana, Maestría en Administra-ción de Tecnologías de Información por parte de la Universidad Virtual del ITESM. Actualmente es Jefe del Departamento de Sistemas de la Univer-sidad 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.

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 re-quiere de grandes proyectos de reingeniería para alinear los distintos procesos del nego-cio. El error de automatizar o incorporar sis-temas en PyMEs donde aún no se han esta-blecido claras directrices del negocio, podría estar condenándolas al fracaso. En cambio, si se realiza un análisis minucioso de las capa-cidades de la empresa, sus necesidades, el presupuesto disponible y los beneficios de la herramienta, la implementación de una he-rramienta 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 ]


Business Intelligence yCambio Organizacional

Profundizando en la Perspectiva de AnálisisPor 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 plata-forma 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 pa-trocinador del proyecto en cuanto al cumpli-miento de sus expectativas de resultados.

En un principio no se encontró ningún pro-blema significativo ni en la operación, ni en el hardware, ni en las herramientas: la infor-mación estaba al día y “cuadraba”, el perfor-mance 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 cum-ple 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:

Expectativa Situación actual Causas

Mayor oportunidad en la entrega del reporte.

El reporte se sigue en-tregando 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 pro-duce bajo el formato antiguo de powerpoint y el pro-ceso de revisión y ajuste no se modificó.

Mayor exactitud en los datos.

Los datos finales de ven-tas 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 dis-ponible del equi-po de análisis

El esfuerzo de produc-ción del reporte se redu-jo en un 80% principal-mente por automatizar el proceso de datos.

Este beneficio no se ve con claridad ya que los tiem-pos de entrega no cambiaron.

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

FEB-ABR 2009


Business Intelligence yCambio Organizacional

Profundizando en la Perspectiva de AnálisisPor Francisco Vaca

Al estudiar las causas que provocaron que se lograra un proyecto técnicamente ade-cuado, 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 ex-periencia dentro de las tecnologías de infor-mación, el presupuesto provenía del área de sistemas, prácticamente todos los miembros del equipo tenían la misma orientación técni-ca que el líder, el proveedor de la tecnología aportó metodología y expertise de desarrollo.

95% del esfuerzo y de los recursos se dedica-ron a la tecnología: selección y puesta a pun-to del hardware, a la selección del proveedor de la tecnología, a los procesos de ETL.

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

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.

El enfoque metodológico se basó en deter-minar y resolver las necesidades de informa-ció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 pro-yecto pusieron muy poco énfasis en el uso de los datos, ya que el problema que se de-finió era la disponibilidad y oportunidad de los mismos. Se supuso que no habría pro-blema en el “uso” de los mismos.

No se tomaron en cuenta los cambios or-ganizacionales que necesariamente pro-vocaría la implementación del proyecto. El más importante de todos ellos consiste en que se trataba de una organización altamen-te “jerárquica”, y la disponibilidad genera-lizada de la información, suponía cambios en la estructura de poder que implicaba una redefinición de roles y responsabilidades.

En muchos casos, las personas tenían la in-formació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 ca-pacidad plena de las herramientas.

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.

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

Ampliar la perspectiva de análisis al consi-derar el contexto de toma de decisiones. El alcance del proyecto debe considerar aspec-tos de cambio organizacional, de forma que se puedan hacer ajustes en roles, responsa-bilidades y procesos de toma de decisiones.

• Definir los cambios en las estructuras for-males 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 alien-ten la toma de decisiones.• Demostrar que tomar decisiones basadas en hechos, reduce la incertidumbre en base a experiencias exitosas.

Alinear expectativas de los usuarios fina-les 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 conduc-ció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 herra-mientas. Tradicionalmente los resultados se muestran en “powerpoints”, pero ahora se puede presentar y analizar mediante la he-rramienta OLAP.

• Capacitar en el proceso de sesiones de análisis en tiempo real.• Capacitar en el uso de las funciones y ca-pacidades 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 am-pliamente. 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 comple-ja sino más simple, que no lleva más tiempo sino menos. Muchas personas que tengan una postura de escepticismo frente a la so-lución, pueden cambiarla al ver a otros tener éxito. Tratamos de publicar casos que ten-gan 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 decisio-nes 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

FEB-ABR 2009


// publireportaje

SEPG LA 2008MeMoria 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 conjun-to 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 “Com-binando Disciplina con Métodos Ágiles”, te-niendo como objetivo apoyar a las empresas para que sean capaces de ofrecer respues-tas ágiles a las necesidades de sus clientes y adaptarse rápidamente a las nuevas tec-nologí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 parti-cipació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ífi-cas (CIC), Miguel Ángel Calello, Presidente de la Cámara de Software y Servicios Infor-máticos (CESSI), Gerardo Renzetti, Director de Servicios del ESI Center Cono Sur y Jesús Salilllas, Chair Comité de Programa.

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

La audienciaEl SEPG LA es un congreso dirigido a pro-fesionistas implicados en actividades de mejora sistemática de personas, procesos y tecnologías en organizaciones donde el software es un elemento clave para la con-secución del éxito empresarial. Durante esta quinta edición pudimos ver desde reco-nocidos gurús, hasta profesionistas que se inician en temas de procesos de software y sistemas. Una situación peculiar que obser-vamos, fue que este congreso ha desarro-llado 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 agendaEl programa estuvo compuesto por confe-rencias magistrales, sesiones, paneles de discusión y seminarios sobre temas adap-tados a la realidad de América Latina: dis-ciplina con métodos ágiles, competitividad en el mercado global de TI, mejora de pro-cesos 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 uni-versidades, nos ofrecieron una agenda va-riada y de interés para todos los niveles.

La expoEl 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 socialAl término del primer día se ofreció un coc-tel 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 sabo-reamos la excelente comida argentina. Por si


// publireportaje

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

La sedeDurante las fechas de la conferencia, en la ciudad de Mar del Plata se llevó a cabo una muestra de cine, así como un evento deporti-vo 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 con-greso, quienes no se cansaron de atendernos y apoyarnos en todo lo necesario.

La participación del ESIEl ESI es una organización sin fines de lucro que se lanzó como una iniciativa de la Comi-sión Europea, con el apoyo de diversas organi-zaciones europeas de TI, y desde 2003 forma parte de Tecnalia, una de las principales cor-poraciones 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 Lati-na, y como parte de dicho esfuerzo, organiza anualmente la conferencia SEPG LA.

“La principal actividad del ESI se centra en apoyar a las empresas en sus objetivos de producir software de mayor calidad, con me-nor 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 investi-gación y desarrollo, actividades enfocadas a desarrollar productos que ayuden a las empresas a ser más maduras y produc-tivas. “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 empre-sas”, comentó Manu.

Entre sus productos más recientes se en-cuentra IT Mark, enfocado en mejorar los procesos de software en las empresas pe-queñas, cubriendo áreas como mercadotec-nia, comercialización y finanzas.

Para conocer más sobre esta conferencia vi-sita: www.esi.es/SEPGLA


/*arquitectura empresarial*/// prÁCtiCaS

Enterprise Architectureestrategia + negocio + tecnología

Por Jaime Ruíz

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

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 di-chos proyectos no logran cumplir los objeti-vos de negocio deseados. Esto típicamente se debe a falta de alineación entre la estra-tegia, los procesos de negocio, y las tecno-logías de información. Y justamente ese es el problema que busca resolver la disciplina de la Enterprise Architecture (EA), o arqui-tectura empresarial.

La arquitectura empresarial es la disciplina que define y mantiene los modelos e inicia-tivas 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 tecno-logía a las necesidades reales del negocio.

La ejecución adecuada de esta disciplina re-duce 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 arquitectu-ra 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 es-tratégicas efectivas para mejorar la calidad, efi-cacia y responsabilidad del negocio, así como responder de manera rápida y positiva a las oportunidades y desafíos del mercado, conso-lidaciones del sector y avances tecnológicos.

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 pro-cesos de negocio y sus interrelaciones con los dominios de estrategia y tecnología. Además,

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

Una arquitectura empresarial incluye: • Modelos de procesos de negocio, informa-ció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.

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.

Iniciativa Estratégica 1

Iniciativa Estratégica 2

Proceso 1

Proceso 2

Proceso 3

Flujode Datos

Diccionariode Datos

Reutilizaciónde Objeto

Sistemas

Servicios WebAplicaciones

Red deDatos

Red deVoz

Red deVideo

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

2Considerar

Vistas

3Crear ModeloArquitectónico

4Seleccionar

Servicios

5Confirmar

Objetivos deNegocios

DArquitecturaTecnológica

6Determinar

Criterios

8Análisis de

Brecha

1Crear

Baseline

Requerimientos

7Definir

Arquitectura

CSistemas deInformación

BArquitecturade Negocios

AVisión

Arquitectónica

Marco Preliminar

GImplementación

de Gobernabilidad

FPlaneación de

Migración

EOportunidadesy Soluciones

HGestión deCambios deArquitectura

Figura 2. Architecture Development Method (ADM).


/*arquitectura empresarial*/// prÁCtiCaS

El marco de referencia TOGAFEl marco de referencia TOGAF, desarrollado por The Open Group, se ha convertido en el paradigma con mayor aceptación para desa-rrollar arquitecturas empresariales. A diferen-cia 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.

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

Uso de herramientasSi vas a desarrollar y mantener la arqui-tectura empresarial de una organización no trivial, te recomiendo que utilices una herramienta especializada para esto. En el mercado existen herramientas que permi-ten utilizar métodos y técnicas de modelado estándar para generar un repositorio de mo-delos donde se administra la arquitectura empresarial de una organización.

Referencias[ TOGAF. opengroup.org/togaf ]

Figura 3. Modelado de EA con System Architect.

ConclusiónAunque EA no es la panacea de to-dos los males por los que una orga-nizació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 sen-tido estratégico y de beneficios reales a iniciativas de mejora de procesos, reingeniería y apego a estándares y nor-mas de la industria como son: CMMI, ITIL, COBIT y SOX entre otros.

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


/*requerimientos*/// prÁCtiCaS

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

Cuando los Casos de Uso no Alcanzanantipatrones 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 encon-trar en cualquier biblioteca, navegando por Internet o en una tienda electrónica como Amazon, decenas de artículos y bibliografía espe-cializada sobre el tema. De hecho, emplear casos de uso se ha vuel-to 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 cali-dad” 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 particulari-dades 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 va-rios consultores, e incluso personal de nuestros clientes, observa-mos 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 pre-domina 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 de-searí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 forzo-samente 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 especifi-cació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 utilizando 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...”


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

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.

2. Al desear que un solo asistente pretenda dispersar interna-mente 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 du-das, malas interpretaciones o conceptos aún no entendidos total-mente, esto es, se desvirtúan los conceptos al pasar de boca en boca sin un pleno dominio del tema.

• 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 pue-do 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 cos-tos y esfuerzo asociado.

• Tratar de tocar mas de un dominio, esto es, tratar de intervenir o co-nocer 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]

41

/*requerimientos*/// prÁCtiCaS

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

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

• Creer que los lineamientos que están descritos en un proceso so-bre 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).

• Y finalmente, lo que desde mi punto de vista es uno de los más grandes errores: Creer que la única forma de capturar requerimien-tos 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 sorpre-sa saber que muchos conceptos o prácticas que aplican tan vehe-mente en sus proyectos en realidad son errores, fallas o antipatro-nes comunes de concepción o aplicación.

Como éste artículo no pretende incendiar los ánimos para in-dicar 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 situacio-nes tales como cuando exista poca interacción actores-sistema o cuando se trata de interfases de usuarios ricas y complejas ma-nejadas 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, con-sideren 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á-

“La facilidad de concepción y diagramación han convertido a los CU en sinónimo de

hacer las cosas con calidad”.


/*meJora De procesos*/// prÁCtiCaS

COMPETISOFTMejora de procesos de software en iberoaMérica

Por Ma. Julia Orozco, et. al.

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

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

COMPETISOFTEs un proyecto financiado por CYTED, pro-grama internacional de cooperación cien-tí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, ajusta-do a sus necesidades específicas, llegue a ser la base sobre la que se pueda estable-cer un mecanismo de evaluación y certifica-ció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 reco-nocido de evaluación y certificación de la industria del software iberoamericana.

Marco metodológicoCOMPETISOFT es una iniciativa integra-dora que ha tomado como base a mode-los y mejores prácticas ya existentes, los cuales han sido mejorados y adaptados con las experiencias de los investigado-res, PyMEs y unidades gubernamentales. Considera un modelo de referencia de pro-cesos, 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.

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

Gerencia monitorea y retroalimenta a la ca-tegorí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 for-ma ágil los cambios solicitados a un producto de software de tal forma que no se pierda la consistencia, y que cumpla con las necesida-des 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-

Experiencia de lasunidades gubernamentales

MoProSoftEvalProSoft

Experiencia delas PyMEs

CMMIISO 15504ISO 12207

Métrica v3

Agile SPI mps Br.MARES

IMPACT

Experiencia delos investigadores

Modelo deMejora

Modelo deEvaluación

Modelo deReferencia

Modelo de procesos o modelo de referenciaEl 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 organi-zación: Alta Dirección, Gerencia y Operación. La categoría de Alta Dirección, establece la ra-zón de ser, lo que se desea alcanzar y las es-trategias para lograrlo en un plan estratégico.

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

Categoría

Categoría

Categoría

Gestión de Negocio

Gestión de ProcesosGestión de Cartera de ProyectosGestión de Recursos · Humanos · Bienes, Servicios e Infraestructura · Conocimiento

Administración del ProyectoDesarrollo de SoftwareMantenimiento de Software

Alta Dirección(DIR)

Gerencia(GER)

Operación(OPE)


/*meJora De procesos*/// prÁCtiCaS

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.

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

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 tra-bajo y mecanismos de comunicación. Una petición de modificación puede ser una solicitud de cambio (perfectivo, adaptati-vo y preventivo) o un informe de problema correctivo urgente, o no urgente.

Considera el mecanismo para recibir, ana-lizar 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 pro-blemas que puedan ocurrir dentro de su eje-cució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 organi-zación de software de una forma ágil, econó-mica, con pocos recursos y en poco tiempo.

Incluye un proceso de mejora denomina-do 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 enfo-que iterativo e incremental, de tal forma que se pueda tener una entrega temprana y con-tinua de mejoras que den visibilidad de los resultados a la Alta Dirección.

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

La guía del consultorPmCOMPETISOFTSe 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 im-plantados en una organización sin necesi-dad de los demás procesos.

Referencias[ 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-2006- SR-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 Indus- tria de Software - MoproSoft - Versión 1.3”. Agosto 2005. NMX-059/03-NYCE-2005. Ciudad de México, Organismo nacional de norma- lización y evaluación de la conformidad -NYCE. normalizacion-nyce.org.mx/php/ loader.php?c=interes.php&tema=21 ]

Las

itera

cio

nes

son

pri

ori

zad

as Iteración deMejora 1

Iteración deMejora 2

Iteración deMejora 3

Iteración deMejora n

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.


Propia 45.41% Métodos ágiles 41.25% Modelos establecidos 13.34%

44

/*aseguramiento De caliDaD*/// prÁCtiCaS

Implementación de Modelos de Calidaddiagnóstico de las eMpresas desarrolladoras de software en MéxicoPor Edna Gutiérrez, et. al.

Este artículo analiza el entorno de los modelos de calidad de soft-ware 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 co-nocimiento y uso de modelos de calidad en empresas desarrollado-ras de software. Este artículo presenta los resultados obtenidos en dicha investigación.

Acerca del instrumento de mediciónEl instrumento de medición utilizado fue un cuestionario donde se ob-tenía información sobre las características de la empresa, el proceso de desarrollo de software que aplican, la forma en que manejan las en-tregas, 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 des-cartadas debido a que no contestaron el cuestionario en su tota-lidad. El nivel de confianza resultó de 96%, con un error máximo admisible de 10%, considerando una población de 1,243 empre-sas, 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 encues-ta, 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 de-sarrolla 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.

El resultado muestra que son pocos los recursos humanos asigna-dos por las empresas para la ejecución del proceso de desarrollo y mantenimiento de software. Según la norma NMX-059/03-NYCE-2005 (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 concen-tración en actividades operativas, como la codificación del producto para cumplir con los requerimientos del cliente.

Proceso de desarrollo de software utilizadoDe 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 ajus-tarse 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 dis-tingue 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?

Menos de 5 36% 6 a 10 28% 11 a 20 15% Más de 20 21%

NúmerodepersoNas %deempresas

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

metodología %deempresas

Tabla 2. Metodología utilizada.

Calidad de la documentaciónLa 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 do-cumentació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 do-cumentación, por considerar que sus productos son pequeños. Finalmente, las que sí cuentan con ella argumentan que los do-cumentos generados en el proceso están desfasados contra la funcionalidad implantada en el producto.


Ninguno 30% Uno 34% De 2 a 4 30% 5 o más 6%

Ninguno 71% CMM/CMMI 22% MoProSoft 6% ISO 12207 1%

45


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 utilizadosLa tabla 3 refleja los modelos de calidad utilizados por las empresas encuestadas.

Si partimos del hecho que la condición de terminación de una itera-ció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 estableci-dos. Por lo tanto, a través de dicha estrategia, se reducen los defec-tos en la entrega final del producto de software.

Cantidad de productos que la empresa entregaDe 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.

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 producto64% 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, eficien-cia, portabilidad y usabilidad. Por otra parte, un 36% señala que desconoce los métodos de evaluación, por lo que no realiza eva-luació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.

modelo %deempresas

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 encuesta-das 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 op-ción, 26% por CMMI y el resto no refiere modelos.

Tiempos de entrega del producto74% de las empresas entrega un producto en un plazo de 3 a 5 me-ses, el 22% en un periodo de 6 a 12 meses, y finalmente el 4% lo en-trega 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 prototiposLa tabla 4 muestra la cantidad de prototipos que las empresas en-tregan por proyecto.

CaNtidaddeprototipos %deempresas

Tabla 4. Entrega de Prototipos.



En cuanto a los modelos y normas que utilizan para asegurar la ca-lidad 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 clienteEncontramos que 75% de las empresas encuestadas otorga una ga-rantía a sus clientes, mientras que 25% no lo hace. La garantía gene-ralmente 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 contem-pla los requerimientos no funcionales.

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 ]

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

ConclusiónEsta encuesta ha servido para detectar la necesidad de con-tar 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 tiem-pos cortos entre 3 y 5 meses, y a la medida del cliente.

Hay interés en contar con un modelo de procesos para el de-sarrollo 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. Adi-cionalmente, 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.

Tomando en consideración estas afirmaciones, se puntualiza que los modelos de calidad tanto de proceso como de pro-ducto para las empresas mexicanas de desarrollo de software, deben considerar lo siguiente:

• Adaptabilidad a equipos pequeños de desarrollo y a entre-gas de producto en plazos menores a tres meses.

• Definición de desarrollos iterativos y entregas de proto-tipos 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.

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


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.

La evolución del rol que cumplen los siste-mas en las organizaciones ha cambiado por completo –afortunadamente– el punto de vista que la mayor parte de los desarrolla-dores tiene con respecto a la seguridad.

Hace una o dos décadas, el tema de la se-guridad en cómputo era frecuentemente evitado. Y hasta era justificable: ¿Intrusos? ¿Integridad? ¿Validaciones? En ese enton-ces 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 den-tro 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 manipular-la, 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 nues-tros sistemas puede poner en jaque la inte-gridad de la información primaria.

Mantener la seguridad en los sistemas que desarrollamos implica un alto costo: los pro-gramadores 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 tiem-pos 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

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

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

A riesgo de que parezca que me limito a perogrulladas, un “sistema seguro” es sen-cillamente un sistema “que responde como debe”. Claro, hay que ver esto a la luz de va-rios criterios para que en verdad signifique algo. Intentemos nuevamente... un sistema seguro presenta: • Consistencia. Ante las mismas circunstan-cias, debe presentar el mismo comportamien-to. 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 ele-mentos que debería haber descartado. • Protección y separación. Los datos, instruc-ciones y espacio de memoria de un programa o usuario, no deben interferir ni permitir inter-ferencia de otros. Las condiciones anormales ocurridas en uno de los componentes (sean ac-cidentales 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 da-tos, 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 regis-trar, así como de notificar a quien sea necesario de cualquier anomalía o evento importante.

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 perjudi-cial 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 dispo-sitivo que genera cadenas de números que cambian periódicamente. Esto tiene senti-do 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 im-portante que, en toda etapa de la planeación, desarrollo, implantación y tiempo de vida de un sistema, recordemos que 100% de seguri-dad 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 can-tidad 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 apare-cen nuevas categorías de errores capaces de llevar a problemas de seguridad. Parte funda-mental de nuestra actuación como profesiona-les en nuestro campo, debe ser mantenernos al día con los últimos desarrollos y amenazas.

Dos de las organizaciones más influyen-tes en la investigación y respuesta a inci-dentes 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 fun-damental 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 fami-liarizarse con ellos.

» Por Gunnar Wolf

47

// Columna/*programar es un moDo De ViDa*/


Las reLaciones son importantesobteniendo diagraMas de clases

Por Charlie Macías

// uml

Dicen por ahí que “lo prometido es deuda”, así que en esta ocasión hablaremos del mo-delado 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 expusi-mos 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 apa-rezca 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 ver-se reflejado mediante algún tipo de relación (asociación binaria, agregación de tipo sha-red, agregación de tipo composite o depen-dencia) en el diagrama de clases.

En este artículo nos enfocaremos en la ter-cera 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.

Como podemos observar en el diagrama de se-cuencia (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 men-saje a la instancia de la clase RenglonVenta, así

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

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

La respuesta o respuestas cortas son: por-que la relación entre TPV y Venta no es es-tructural, mientras que la relación entre Venta y RenglonVenta sí lo es. O también po-drí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 explicar-lo 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.

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

Enlace transitorioSi 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 mis-mo 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 modela-mos 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 [email protected] www.milestone.com.mx

TPV

Venta

- fecha: Date - folio: String

+ agregarRenglonVenta(String) : void + registrarPago(double) : void + Venta(String)

RenglonVenta

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

renglonesVenta 1..x

cd Diagrama de Clases-Operaciones

tpv: TPV

nuevaVenta: Venta

rv: RenglonVenta

1.3 registrarPago(monto)

sd Punto de Venta

1.0 Venta(ventaXML)

1.1 agregarRenglonVenta(renglonesVentaXML)

1.2 RenglonVenta(cantidad, idProducto)

Figura 1. Diagrama de secuencia para registrar una venta.

Figura 2. Diagrama de clases derivado del diagrama

de secuencia.


// uml

49

ejemplo y apoyándonos en el siguiente frag-mento de código, podemos observar que en el método “registrarVenta” se crea una refe-rencia 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 permanenteSi el enlace entre los objetos trasciende ocu-rrencias de ejecución, entonces significa un enlace permanente y se modelará una aso-ciación (binaria, agregación shared o agre-gación composite) en el diagrama de clases. Para conseguir que un enlace trascienda ocu-rrencias de ejecución, es necesario alojar la referencia hacia el objeto en un atributo de la clase. En nuestro ejemplo podemos obser-var 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 programa-dor 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 agre-gación del tipo shared si nuestra decisión de diseño hubiera sido que el manejo de la co-lecció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 limi-tado a una sola instancia de sendas clases.

Las relaciones entre las clasesmanifiestan decisiones de diseñoFinalmente, 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 posi-bles soluciones, unas mejores que otras. Al-gunos criterios podrían ser los siguientes:• Si un objeto requiere de un enlace hacia otro objeto una y otra vez, es decir, que pa-rece permanecer relacionado al otro incluso a través de la ejecución de una o más ope-raciones, entonces probablemente una rela-ción de asociación sea lo más conveniente.• Si un objeto se enlaza con otro para consu-mir sus servicios, y después lo deshecha, en-tonces 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 esca-labilidad del sistema, descubrimos que nos sale más barato mantener un objeto en me-moria que creando y destruyendolo podría-mos decidir alojarlo en una variable de clase (atributo) y esto nos llevaría a escoger una asociación.

ConclusiónEn términos simples:• Si el enlace entre dos instancias de clases distintas que colaboran para alcanzar un objetivo es transitorio, en-tonces se modela una dependencia.• Si el enlace entre dos instancias de clases distintas que colaboran para al-canzar un objetivo es permanente (so-brevive 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 de-cisiones de diseño que se tomen al plantear la solución al problema.


// pm Corner

apLicanDo proJect manaGement aL Bide 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 facili-tar 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ía-mos 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 lanza-miento de nuevos productos o servicios basados en la segmenta-ció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 par-ticularidades 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.

EtapasNormalmente en la integración de los repositorios de informa-ción, a partir de datos de diversas fuentes, se usa un proceso conocido como ETL (Extraction, Transformation and Load). A con-tinuació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 crite-rios 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 defini-dos, de manera que la información es homologada, depurada y nor-malizada, 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 costoUn 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

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 importan-te tomar en cuenta las capacidades reales de la organización para considerar el costo completo.

La comunicación es claveEs también necesario contar con un Plan de Comunicación que plan-tee 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 comuni-quen de manera activa y proactiva.

Un proyecto de esta naturaleza puede durar varios meses o inclu-so 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 per-sonas 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, lle-gado 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, va-yan 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 deaprovecharloEl objetivo final de la inteligencia de negocios es poner a disposición de los usuarios, herramientas de explotación que les permitan analizar


// pm Corner

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

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 conoci-mientos 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 ti-pos 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 complicacionesComo 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 almace-namiento 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 benefi-cio de la corporación.

• El proyecto necesariamente requiere la participación de exper-tos externos a la organización y la selección de los mismos pue-de 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 experienciaEn un proyecto en el que participé hace algún tiempo, se buscaba integrar un almacén de datos con información de clientes. El proble-ma principal radicaba en que cada una de las líneas de negocio de la empresa, contaba con bases de datos independientes, con la in-formació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. Probablemen-te 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 registra-do 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émi-ca 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 nece-sario nombrar un responsable de administrar la información; en este caso, de personas. Pues aun y cuando pudiéramos hacer un exce-lente 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 sis-temas 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 con-taminada 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 quie-re implantar un buen marco de inteligencia de negocios que le sirva a la organización a largo plazo.

“Un proyecto de BI requiere que tanto elGerente de Proyecto así como su equipo,

y el patrocinador haga un análisis aconciencia del desafío que presenta”.


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

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

Elementos fundamentales de un MCEPHaciendo un análisis de nuestra experiencia en consultoría, diag-nosticando y ayudando a mejorar organizaciones de prueba, y de lo publicado en la literatura especializada, vemos que las áreas lis-tadas abajo son de las más relevantes y comunes a una proporción significativa de (MCEP):1. Proceso de prueba2. Estrategia de pruebas3. Punto de arranque de las pruebas4. Métricas

5. Personal del área de pruebas 6. Posición en el organigrama del área de prueba 7. Comunicación y reportes8. Administración de defectos9. Administración del testware10. Infraestructura tecnológica para probar

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 prue-ba de software, como comentamos en el número antepasado.

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 organiza-ción de prueba se encuentre dentro de una empresa de desarrollo de software, como el de que forme parte de una empresa especia-lizada 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).

52

// Columna /*prueBa De soFtWare*/

Modelos de Calidad para Prueba de SoftwareconstitUyentes 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 co-fundador. 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.

Figura 1. Estructura matricial.


Aplicación de esos elementos En nuestra experiencia en los diagnósticos y ayuda a mejorar or-ganizaciones 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.

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.

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 cuen-te con el personal suficiente en cantidad (aproximadamente 25% del total de los recursos asignados al desarrollo de software) y en cali-dad (selección y entrenamiento apropiados); de que se administre adecuadamente los insumos y productos de las pruebas (y evitar es-tar 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 sis-temá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 prue-bas 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.

Invitación En marzo tendremos como invitado en e-Quallity a un experto in-ternacional, con quien ofreceremos pláticas sobre temas relacio-nados con los MCEP en el D.F., Monterrey y Guadalajara. Si tienes interés en asistir, escribe a [email protected] con el encabe-zado “Plática con Expertos”.

¡Hazlo yá; hay cupo limitado!

» Por Luis Vinicio León / Berenice Ruíz

53

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

// Columna /*prueBa De soFtWare*/

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.

Figura 2. Áreas en capas.


/*tenDencias en soFtWare*/// Columna

El Software 2010-2015capacidades 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. [email protected] luisdans.com\Twitter

Hace tiempo, pasaba varias noches es-cribiendo 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 madu-ran 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:

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 per-mitirá emular exploradores más recientes, pero por otra, los avances en herramientas hará más fácil construir y acceder sitios des-de cualquier dispositivo. RIA para las masas, Internet extendido por sensores.

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 ele-mentos altamente interactivos simplificarán el uso de la computadora derribando las limi-tantes del teclado. Las aplicaciones deberán ser multicanal y llegar a gente que no tiene computadoras. (Ver twurl.nl/tf3mtw ).

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

lente charla es: twurl.nl/5zceki. La gran ambi-gü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 instrumenta-ció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.

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ácil-mente (twurl.nl/eqwn5d ). Este último con-cepto se denomina democratización de la creación de software. Incluye ampliar el ac-ceso a personas que hoy no tienen una PC, utilizar voz, terminales compartidas y objetos conectados a la red.

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

En el ámbito empresarial, un elemento funda-mental será el Enterprise mashups, combinan-do 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 exter-na. Muchos de estos elementos se agruparán bajo la categoría: capacidades avanzadas de TI.

La casa y la oficina requieren esas mismas capacidades entregadas como servicio, pero aquí la clave continúan siendo las aplicaciones. Supongamos por un momen-to 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 loca-lizar. (Ver columna ‘Patrones para software de consumo’ SG Sep-Nov 2008).

¿Cuál es el impacto de las aplicaciones ac-tuales? ¿El software educativo para escuelas primarias le da a los alumnos ventajas en el aprendizaje? Los niños de hoy se han bene-ficiado por una gran cantidad de medios, in-cluyendo mucho mejores programas de tele-visió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 po-derlas compartir en una forma visualmente rica (pruebe twurl.nl/nxg2pm )?

Conclusión:El futuro del software tiene que ver con resolver problemas claramen-te 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


La Fábula del Pastor y el Líder de Proyectos¿Mito o realidad?Por Rodrigo Corral

// fundamentoS

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 pro-yectos 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

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 respira-ba 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 aluci-nó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 re-cursos 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 sabidu-ría dijo: “no sabe usted de lo que habla, amigo”. Y tiró un largo tra-go 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 equi-po 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 cer-tificaciones soy yo”.

El pastor silbó a su perro y le dijo, “dentro de una semana vuelvo, mien-tras, 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 tra-bajo 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 comprometi-do 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 ex-perto, 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 ove-jas. “Queridas ovejas, vamos retrasados respecto mi plan. No dudo que harán lo necesario para asegurar la producción al ritmo necesa-rio. 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 con-clusió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 re-bañ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 encon-trar 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 ha-cí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...


// fundamentoS

“Estas ovejas, siempre quejándose de tonte-rí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 pre-guntó 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, in-aceptable… 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 tam-bién se había equivocado… “¿Qué tal pas-tor? ¿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 mu-cho 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. Se-guro 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 ser-vidor de 64 bits para no se qué pruebas

de rendimiento y de compatibilidad. Yo no tenía ni idea de qué era eso, pero parecía importante para ellos, así que lo conse-guí. ¿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 lo-graban 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 preocu-pó. ¿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 exi-giendo 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 traba-jo y pones las condiciones para que lo hagan, al final puedes recoger los resultados”.

En eso despertó el líder de proyecto y pen-só: “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 ho-rizonte con su rebaño.

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


// teCnoloGÍa /*inFraestructura*/

58

Almacenamiento en Caché, Paralelismoy Escalabilidadla ley de Moore ha MUerto. ahora rige la ley de aMdahlpor Manik Surtani

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.

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 so-bre un problema, no se logra la producti-vidad 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 en-tre los diversos procesadores.

Esta ley es importante porque la estrategia actual para desarrollar computadoras más ve-loces consiste en aumentar los nodos de pro-cesamiento 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 embar-go, su software requiere ser escrito específica-mente para aprovechar este paralelismo.

En el caso del software aplicativo del que te-nemos el código fuente, es posible hacerle pequeños ajustes y utilizar librerías para eje-cució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íficamen-te, ¿qué sucede con las bases de datos que entran en contacto con discos que inherente-mente involucran un procesamiento secuen-cial? Las bases de datos son sólo un ejemplo común de la serialización de procesos. La se-rialización sólo permitiría el funcionamiento de un único núcleo en un momento determi-nado 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 ins-tancia 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 clusterLas caché en cluster permiten que múltiples núcleos y servidores en un grid trabajen sobre los datos dispuestos en paralelo, aprovechan-do al máximo la potencia de cómputo disponi-ble. El problema es cómo mantener la integri-dad de los datos entre los diferentes nodos. Las caché en cluster utilizan diversos mecanis-mos 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 ins-tancia 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 obtie-nen los bloqueos y se escribe el estado en las caché de todo el cluster. Brinda mayor esca-labilidad pero presenta la necesidad de rein-tentar una operación en caso de colisión.

Distribución de datosHasta 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 accesi-ble que pueden utilizar. Otro enfoque sería no reproducir los datos entre las caché, pero su-mar 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 re-gistros 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ónLas caché constituyen una herramienta importante para aprovechar el para-lelismo y eliminar los obstáculos en la recuperación y cálculo de datos. Anali-zando 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 distribui-da. Muchas estructuras o productos de almacenamiento en caché desarrolla-dos 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.


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 millo-nes de toneladas de emisiones de CO2, que es igual a las emisiones de la mitad de to-dos los países en América Latina. Solamente 5% de servidores físicos se han consolidado hasta la fecha, pero ahora que la virtualiza-ción ha llegado a ser de corriente, los pro-nósticos sugieren que se consolide a una mayoría de servidores, usando la virtualiza-ció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 datosLa virtualización proporciona enormes ven-tajas 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 ge-neralmente 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 úl-timos 10 años permiten que los centros de datos sean considerados como la infraes-tructura física estática. El centro de datos del futuro será virtualizado y de ambiente dinámico, el cual podrá constantemente te-ner el correcto tamaño para reducir al míni-mo el consumo innecesario, el recuperador de desastres y la energía.

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

60

/*tenDencias*/// teCnoloGÍa

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.

La Virtualización y el Ahorro Sustentablelas solUciones de ti verde Por Rob Smoot

Mientras más se habla del ahorro de ener-gí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 co-rriendo los centros de datos, y con ahorro en el entorno, se convierten en focos que mar-can 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 sobrepasa-do la simple consolidación de servidores.

Dinamismo de cargas “RightSizing” de la Virtual InfrastructureAlgunas personas sugieren que la virtualiza-ción sea un beneficio, una vez que se quiten los servidores. ¿Qué hay después de la con-solidación inicial?

La virtualización cambia el juego, convir-tiendo 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 merca-do 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 cen-tro de datos, y se pueden utilizar para opti-mizar el uso de la energía. Esta funcionali-dad se llama Administración Distribuida del

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

Trabaja supervisando la utilización de un pool de servidores y cuando existe exceso de la capacidad, mueve las máquinas vir-tuales corrientes sobre pocos servidores, y cierra automáticamente los servidores físi-cos 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áti-co, que es también una característica parti-cular de la infraestructura virtual. Permitien-do que los clientes optimicen y reduzcan continuamente el consumo de energía del pool del hardware sin sacrificar la confiabili-dad y la disponibilidad de la infraestructura de TI. El beneficio neto de los clientes es que pueden tener el correcto tamaño de su infra-estructura de TI en tiempo real, de tal modo que maximizan la salida de TI mientras que consumen la menor energía posible.

Impacto ambiental delcorrecto tamaño de TIEn el contexto de efecto y flexibilidad, hay algo que debe ser dicho sobre el impacto ambien-tal 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 fun-cionan 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 electrici-dad de la calefacción y la ventilación consumi-da 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


/*gaDgets*/// teCnoloGÍa

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 nave-gació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 fo-tografías; memoria expandible a través de una ranura microSD, Bluetooth versión 2.0, y capacidad adicional para utilizar mensajeros instantáneos.

Parrot

ConferenceEl sistema Parrot Conference permite realizar confe-rence 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 niti-dez. Se puede mover de un lugar a otro gracias a sus tres baterías recargables de larga duración. La pan-talla 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.

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 Origa-mi y el intento un tanto fallido por lanzar al mercado la UMPC (Ultra-Mobile PC) que luego de rumores, presentaciones y videos, quedó en el olvido. Ahora con la moda de las Netbooks, surge esta pequeñísi-ma, 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 Lifes-tyle 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.


INDEX

Anunciante Páginas Sitio

Brio 57 www.brio.com.mxe-Quallity 49 www.e-quallity.netGartner 61 www.gartner.com/mx/appintGelattina 25 www.gelattina.com/alMaximoIDC 63 www.idc-eventos.com IT Institute 13 www.it-institute.orgJP Consultores 39 www.jpeconsultores.comManpower 7 www.manpowerprofessional.com.mxMatersys 2F, 1 www.matersys.com.mxMilestone Consulting 4F www.milestone.com.mxNYCE 3F www.nyce.org.mxP&M Consulting 37 www.pmconsulting.com.mxSafeNet 11 www.safenet-inc.comSG Campus 17 www.sgcampus.com.mxSG Revista Digital 55 www.sg.com.mxTendencias 59 www.select.com.mx

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

DIRECTORIO


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

El 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 restringi-dos a lo esencial. Para muchas empresas, significa que muy pro-bablemente la inversión tecnológica estará destinada a apoyar la operación con resultados de negocio más inmediatos. Y los con-sultores o directores tecnológicos promoverán sistemas orienta-dos 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 in-cluso la supervivencia de la empresa.

Ciertamente, es un buen momento para incursionar en una ini-ciativa de inteligencia de negocios, o cimentar los objetivos de la iniciativa ya existente en la empresa. Y es que el costo de opor-tunidad de no realizar inteligencia de negocios resulta particu-larmente 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 re-quiere 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 men-cionar un componente fundamental para la consolidación de la ini-ciativa 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 pro-cesos 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 ca-pital 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 to-mador 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 es-quema de inteligencia de negocios es, promover el capital inte-lectual. 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 to-mar a estos profesionistas y capacitarlos en nuestros procesos y habilidades, con modelos de negocio que promuevan su perma-nencia 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 empre-sas, donde la inteligencia de negocios jugará un rol determinante.

» Por Raúl A. Trejo Ramírez

w

ww

.sg.

com

.mx

SG

SO

FT

WA

RE

GU

RU

- C

ON

OC

IMIE

NT

O E

N P

RÁ

CT

ICA

Feb

rero

-Abr

il 20

09

No.

23

sg23 (febrero-abril 2009)

Documents