Software Guru Julio 2005 by ROSA IMELDA GARCIA CHI

• Análisis de Puntos de Función • Casos de Uso

Software Guru CONOCIMIENTO EN PRÁCTICA Año 01 No.04 • Julio-Agosto 2005

ENTREVISTA:

Carlos González

Director de Sistemas de TMM

CASO DE ESTUDIO:

Active Intelligence

CAMBIO, LA ÚNICA CONSTANTE Prepárate para BPM

Además: Noticias • Eventos • Fundamentos • Biblioteca • Tecnología • Carrera

TECNOLOGÍA:

WiMAX

DIRECTORIO Edición Ejecutiva Pedro Galván

EDITORIAL

Coordinación Editorial Mara Ruvalcaba Edición y Producción Edgardo Domínguez Dirección de Arte Oscar Sámano

Durante una conferencia a la que atendimos recientemente, uno de los participantes preguntó para qué se estaba hablando de procesos de negocio durante una conferencia de TI. Como se podrán imaginar, la mayoría de los asistentes puso cara de “¿cómo se le ocurre preguntar eso?”. Se trata de una pregunta válida, si es que no se tiene clara la razón. Desde hace varios años, las áreas de sistemas en las empresas han estado sufriendo un cambio muy importante; están dejando de ser áreas técnicas, para convertirse en áreas de soporte y habilitación del negocio. Bajo el argumento de que “lo único constante es el cambio”, las empresas están siendo obligadas a ser ágiles y adaptarse rápidamente a los cambios en su entorno. Y lo primero de que se están dando cuenta, es que sus sistemas de información actuales no promueven la agilidad, al contrario, la inhiben. Es por ello que hemos destinado este número a hablar sobre Business Process Management (BPM), que es probáblemente la iniciativa más importante que se ve en esta industria hacia los próximos diez años por lo menos. Esta importancia se debe a que es una iniciativa dirigida por negocio, donde los sistemas responden a las necesidades del negocio, y no viceversa. Es una iniciativa orientada a desarrollar empresas ágiles, soportadas por sistemas de información ﬂexibles y ajustables en tiempo real, sin necesidad del personal de sistemas. Esto no signiﬁca que los de sistemas nos vayamos a quedar sin trabajo. Sin embargo, es un hecho que el trabajo que hacemos está cambiando, y debemos estar preparados para este cambio. Después de todo, el cambio es la única constante. Agradecemos a Carlos González por haber compartido con nosotros su visión sobre este tema. Aún siendo un directivo de una importante empresa, Carlos se mantiene como una persona sencilla y con los pies en la tierra. Por último y no por ello menos importante, damos las gracias a todos los colaboradores que han hecho posible este número de Software Guru. A todos los lectores les pedimos que por favor nos hagan llegar su retroalimentación y comentarios a través del sitio web, o en editorial@softwareguru.com.mx

Equipo Editorial

JUL-AGO 2005

Ilustración Omar Ruvalcaba Consejo Editorial Francisco Camargo, Guillermo Rodríguez, Ralf Eder y Raúl Trejo, ITESM CEM; Hanna Oktaba, UNAM-AMCIS; Luis Cuellar, Softtek.; Luis Vinicio León, e-Quallity - ITESO Colaboradores Ariel García, Jorge Palacios, Antonio Reyes, Paulina Olivares, Amaury Quintero, Francisco López Lira, Roberto Silva, Ernesto Méndez, Rafael Muñoz, Elizabeth Almeraz, Sergio Durán, Axel Nissim, Sergio Orozco, Carlos Macías, Ramón Hernández, Luis Daniel Soto. Ventas Claudia Perea Marketing Natalia Sánchez Webmaster www.aguilahosting.com Contacto info@softwareguru.com.mx +52 55 5239 5502 Software Guru es una publicación bimestral editada por Brainworx S.A. de C.V., Malinche no. 6, Col. El Parque, C.P. 53398, Naucalpan, México. Prohibida la reproducción total o parcial del contenido sin previo aviso por escrito de los editores. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: 042004-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 junio de 2005 en Litográfica Roma. Distribuido por Sepomex y Thunder Mail

www.softwareguru.com.mx

contenido jul-ago 2005

número 04

EN PORTADA

Business Process Management (BPM)

Ha llegado una nueva plataforma de misión crítica para los sistemas empresariales, los sistemas BPM. Conozcamos de que se trata esta tendencia y preparémonos para el cambio.

Productos

Prácticas

LO QUE VIENE Problem Resolution Toolkit, BEA Aqualogic, iBolt

REPORTE DE MERCADO BPMS

TUTORIAL Ingeniería en Reversa de DB2

ADMINISTRACIÓN DE PROYECTOS Análisis de Puntos Función

Entrevista

18 Carlos González, CIO de TMM

En la segunda parte de este artículo, Sergio Durán nos explica como se determina el tamaño de un sistema utilizando la métrica de los Puntos Función (FPs).

PROCESOS 38 BPM Aplicado al Desarrollo de SW BPM se puede utilizar para diferentes tipos de procesos. En este artículo, Axel Nissim analiza su aplicación en procesos de desarrollo de SW

Columnas Tejiendo Nuestra Red por Hanna Oktaba

Mejora Continua por Luis Cuellar

Innovaciones en Software por Luis Daniel Soto

Prueba de Software por Luis Vinicio León

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

www.softwareguru.com.mx

UML Casos de Uso

Una de las principales causas de fracaso en los proyectos de SW es un mal manejo de los requerimientos. Sergio Orozco nos habla sobre los fundamentos de la administración de requerimientos basada en casos de uso.

Caso de Estudio

Active Intelligence

En Cada Número Noticias y Eventos Fundamentos Tecnología Biblioteca Carrera

04 48 50 54 56

JUL-AGO 2005

NOTICIAS

Noticias IT Outsourcing Conference 2005 - IDC El pasado jueves 26 de Mayo se llevó acabo la 2da. edición de la Conferencia IT Outsourcing 2005, realizada por IDC México, en el Centro Banamex. El objetivo de dicha conferencia fue el dar respuestas clave acerca del outsourcing y el Business Process Outsourcing. De acuerdo con IDC, los servicios de outsourcing tendrán un crecimiento en México, para 2005, de 13.6%, y para 2006, de 13.1%. Hay que recordar que la industria de TI, crecerá 8.1% en 2005, y 6.3% en 2006. Por tanto, el outsourcing es uno de los segmentos que tendrá las mayores tasas de crecimiento en dichos periodos. Alejandro Floreán, Gerente del Programa de Investigación de TI y Mercados Verticales en IDC México, comentó que “esto no es más que un indicio de que la madurez del mercado mexicano está comenzando. Los outsourcers no han llegado tarde a México, en realidad el outsourcing es parte de la madurez de las actividades de sistemas y de la misma industria de TI”

Praxis obtiene el nivel 3 del modelo Capability Maturity Model (CMM) para desarrollo de Software Praxis, empresa de consultoría, desarrollo e integración de sistemas de información, aprobó la evaluación CMM nivel 3 para el desarrollo de Software que otorga el SEI (Software Engineering Institute), después de un proceso de evaluación que califica a su Fábrica de Software. “En Praxis entregamos soluciones de TI que cumplen con las expectativas de nuestros clientes en tiempo, costo, calidad y alcance. El certificado en nivel 3 de CMM, coloca a Praxis como una empresa de competitividad internacional, consolidando nuestra capacidad para el eficiente manejo de grandes proyectos”, comentó Edmundo Robert, CEO de Praxis. La evaluación fue realizada por José Guerrero, SEI – Authorized Lead Assessor, de la empresa chilena América XXI.

Secretaría de Economía en conjunto con AMITI y Microsoft inician actividades del Programa Acelera.Prosoft 2005 La Secretaría de Economía en conjunto con AMITI y Microsoft anuncian el inicio de actividades del programa Acelera.Prosoft 2005, que tiene como objetivo principal mejorar el desempeño de la industria nacional de desarrollo de software, fortaleciendo las capacidades técnicas e incrementando los resultados de negocio de las empresas afiliadas mediante la estrecha colaboración de las empresas Visionaria, Avantare e InterSoftware. Con más de 100 empresas registradas en el programa y beneficios directos a cerca de 600 desarrolladores, Acelera.Prosoft 2005 cubre un amplio rango de empresas dedicadas al desarrollo de software, ofreciendo esquemas de capacitación flexibles, así como asesoría de negocios a empresas con iniciativas de fábricas de software entre otras. Con la reciente disponibilidad de la versión Beta de Kuali, herramienta propiedad de la Secretaría de Economía, una de las herramientas de Moprosoft, disponible en el portal software.net.mx (http://foros.software.net.mx/kuali/), se busca reforzar la competitividad del ecosistema mexicano de desarrollo de aplicaciones mediante el acceso a documentos que facilitan el desarrollo, empleando mejores prácticas y acercando a las empresas a los estándares de clase mundial. Para mayor información visita: www.software.net.mx

Inauguran Centro de Excelencia Tecnológica en Mexicali

El modelo de gestión de Praxis está basado en las metodologías y procesos de mayor aceptación a nivel internacional. Con esta evaluación, Praxis asegura a sus clientes el cumplimiento de sus proyectos en los términos de costo, tiempo, calidad y alcance.

El gobierno de Baja California, IBM y el Centro de Enseñanza Técnica y Superior (CETyS), crearon el primer Centro de Excelencia Tecnológica en Estándares Abiertos del país, que tiene el objetivo de impulsar el desarrollo de sistemas de información abiertos, con la finalidad de especializarse en la creación de software. Este proyecto tendrá como primera fase la capacitación de 25 estudiantes por un periodo de nueve meses, y el siguiente paso será la creación de empresas que proporcionen soporte a las plataformas abiertas como Linux y Java.

Para mayor información visita: www.praxis.com.mx

Baja California cuenta también con el proyecto de IT@Baja, grupo de 30 empresas dedicadas al desarrollo de software, y con el proyecto del parque tecnológico “Silicon Border”.

JUL-AGO 2005

www.softwareguru.com.mx

Eventos

Julio-Agosto 2005 24-26 Agosto 2005

Top Software Show Mayen Project Management World Trade Center Ciudad de México Info: www.mayen-project.com.mx Tel: (55) 5536 4120 Email: contacto@mayen-project.com.mx

11-13 Agosto 2005

Xpo Linux 2005 Centro Banamex Ciudad de México Info: www.expolinux.org Tel: (001) 210 8920930 Email: dgranados@expolinux.org

25 Agosto y 31 Agosto 2005

Seminario Gratuito “Administración Integral de Tecnologías de Información y ¿Que papel juega TI con el requerimiento de Ley Sarbanes Oxley?”

11 - 13 Agosto 2005

1er Foro Regional Innovación y Tendencias Tecnológicas

Itera 25 Agosto - Cd. de México, 31 Agosto - Monterrey, N.L. Info: www.itera.com.mx Tel. (55) 5281 7670 Email: contactsalescenter@itera.com.mx

Grand Hotel Tijuana Tijuana y Ensenada, Baja California Info: www.tendenciastecnologicas.com Tel: (664) 686-2227 Email: registro@tendenciastecnologicas.com

31 Agosto – 2 Septiembre 2005

VI Conferencia Anual “The Future of IT: La Justificación Económica de la TI”

24 Agosto 2005

Security & Business Continuity Conference 2005

Gartner Centro Banamex Ciudad de México Info: www.gartner.com/mx/econit Tel: (55) 5207 2695 Email: latin.america@gartner.com

IDC Centro Banamex Ciudad de México Info: www.idc-eventos.com Tel: (55) 5661 3791 o 01800 504 1529 Email: idc@apsis.org.mx

Datos de la Industria

NOMBRE

UBICACIÓN

NO. PERSONAS

NIVEL CMM o CMMI

FECHA

LEAD ASSESSOR

NEORIS

MTY

600

CMM 3

Oct-03

Mariana Pérez-Vargas, Avantare

AZERTIA

150

CMM 2

Feb-04

Iñigo Garro, ESI

EDS

JUAREZ

200

CMM 5

Feb-04

No reportado

SOFTTEK Nearshore

MTY

1250

CMM 5

Abr-04

Richard Storch, Dick Storch & Associates

ULTRASIST

CMM 4

Jul-04

Mariana Pérez-Vargas, Avantare

SIGMA TAO

QRO

450

CMM 5

Nov-04

Richard Storch, Dick Storch & Associates

IBM - AMS

GDL

950

CMMI 5

Dic-04

Luciano Guerrero – Canada

IDS

350

CMM 3

Dic-04

Cecilia Montero Mejía - Empeiria Quality Services

ACTIVE INTELLIGENCE

AGS

CMM 3

Mar-05

Mariana Pérez-Vargas, Avantare

TELEPRO

CMM 2

Jun-05

Mariana Pérez-Vargas, Avantare

PRAXIS

350

CMM 3

Jun-05

Jose Guerrero- America XXI

www.softwareguru.com.mx

Fuente: Recopilación de comunicados de prensa y sitios web de cada empresa. *El modelo CMM ya no es soportado por el SEI. **Otras empresas en México han obtenido estas evaluaciones, pero actualmente no operan.

Empresas mexicanas que cuentan con la evaluación Capability Maturity Model para Software* (CMM), o con la evaluación Capability Maturity Model Integration (CMMI), otorgada por el SEI (Software Engineering Institute)

JUL-AGO 2005

COLUMNA

TEJIENDO NUESTRA RED

Moda y Tendencias Tercera Reunión del IPRC

n mayo de 2005 se reunió por tercera vez el International Process Research Consortium (IPRC). En esta ocasión nos tocó sufrir los primeros calores de una de las capitales de la moda mundial, que es Milán. Para los interesados en el tema —el de la moda—, les puedo comentar que en las tiendas reinaban los colores puros de arco iris, pero en las calles, las mismas fachas que en el DF, con el único detalle de lentes obscuros tipo “mosca”.

La Dra. Hanna Oktaba es profesora en la Facultad de Ciencias de la UNAM. Es fundadora y vicepresidenta de la Asociación Mexicana para la Calidad en la Ingeniería de Software. Actualmente dirige el proyecto para la creación de una norma mexicana para la industria de software.

Cambiando del tema, y regresando al objetivo de mi relato, la reunión del consorcio estaba dedicada a identificar los posibles escenarios de las tendencias mundiales políticoeconómico-tecnológicas en los próximos diez años. Una vez identificados los escenarios, se procederá a analizar el posible impacto que éstos tendrán en la forma en que se va a desarrollar el software y, en consecuencia, en los procesos. Al inicio se nos proporcionó una lista de 116 elementos de tendencias, que hemos identificado en las reuniones pasadas, y se nos pidió que escogiéramos las que nos parecieran las más inciertas. Entre ellas estuvieron: 1. El cambio demográfico de los desarrolladores (jóvenes o maduros, occidentales o asiáticos, etc.) 2. Legislación y regulaciones sobre uso de software 3. Globalización (predominación occidental o asiática) 4. Demanda de calidad y seguridad (incremento o resignación) 5. Tipo de cadena de valor (centralizada o volátil) 6. Innovación tecnológica (incremental o perturbadora) Nos dividieron en cuatro grupos y para que cruzáramos los pares de estas incertidumbres con sus extremos y tratáramos de imaginarnos la vida en cada uno de los cuadrantes. Mi grupo escogió cruzar la innovación tecnológica con la estabilidad de la cadena de valor. El mundo más sencillo de imaginar fue el de cadena de valor más o menos estable, como ahora, y los cambios tecnológicos de poquito a poquito. Lo más retador fue imaginarse el mundo donde las cadenas de valor son volátiles y los cambios tecnológicos totalmente inesperados,

como en su tiempo fueron la invención de Internet o del teléfono celular. Fue bastante divertido participar con mis colegas en este juego intelectual y observar cómo la imaginación o los miedos personales salen a flote y se vuelven colectivos. La impresión general que saqué de esta sesión fue que esta gente ve una gran probabilidad de que en los próximos años la supremacía tecnológica pase a manos de China, India y Japón, que ya en gran medida la tienen. Y como la mayoría de los participantes del consorcio proviene de occidente, esto les causa bastante preocupación. Medio en broma, comentaban que dentro de diez años el Software Engineering Institute va dedicarse a la promoción de modelos de procesos chinos para América. Otro tema que les preocupa es la estabilidad de las grandes empresas, en particular las trasnacionales. Por ejemplo, los proyectos de código abierto y los servicios en línea son nuevas formas de organizarse que rompen los esquemas tradicionales. Estos nuevos esquemas ofrecen a los clientes mayor flexibilidad, menor costo y, por lo general, buena calidad. Esto empieza a contrastar con la rigidez y relativa lentitud de grandes consorcios. En México también estamos observando este fenómeno a través de la creación de las integradoras que empiezan a multiplicarse en los estados. Será interesante observar su impacto en el mercado local y de exportación en los próximos años. Por último, les quiero comentar sobre algo curioso en un consorcio sobre procesos. Se armó una discusión muy acalorada sobre “¿qué es proceso?”, y que conste que allí participa la gente que sabe del tema. A mí me dio mucho gusto que surgió esta pregunta porque, desde que empezamos a trabajar sobre MoProSoft, buscamos una definición razonable de proceso y la mera verdad ninguna nos gustaba. Nos quedamos con una inventada por nosotros. Y aquí salió que las mismas dificultades tiene la gente para quienes esto es “su mero mole”. Por supuesto no se pusieron de acuerdo. Formaron un grupo que se va a encargar de presentarnos en la próxima reunión una propuesta. Lo que ya se acordó es que habrá que distinguir entre los procesos del lado de la demanda, los procesos de gestión y los técnicos. En MoProSoft ya tenemos los dos últimos, nos falta trabajar los primeros, los del lado de los compradores, para que ambas partes se entiendan mejor. Por este medio abro la convocatoria a los que quieren aportar su conocimiento y talento para definir los procesos complementarios a MoProSoft para la parte de adquisición. Favor mandar las propuestas a Software Guru. Hasta la próxima. - Hanna Oktaba

JUL-AGO 2005

www.softwareguru.com.mx

COLUMNA

MEJORA CONTINUA

La Calidad no Cuesta... Pero, ¿Cuál es el Retorno de mi Inversión?

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 CMM5 y Six Sigma a través de las diferentes áreas del centro de desarrollo de Softtek.

ace algunas semanas participé en una plática con varias compañías que están buscando su certificación de CMMi. Todas ellas compartieron sus experiencias sobre los problemas que viven y los beneficios obtenidos con el avance que se llevaba. Dentro de la conversación se tocó el tema de porqué buscar una certificación. Las respuestas fueron varias, en el orden de: “para competir en el futuro”, “entrar al mercado americano”, o “demostrar nuestro compromiso con la calidad”. Al escuchar estas respuestas, me pareció preocupante lo enfocado que están estos esfuerzos en obtener una certificación, más que en obtener beneficios específicos a corto plazo para la organización. Esto es comprensible tomando en cuenta que la certificación es una meta alcanzable (por lo menos más de uno lo ha hecho antes), fácilmente medible y principalmente muy clara de vender y comunicar dentro y fuera de la organización. Desafortunadamente, manejar la certificación como la única meta de un esfuerzo de calidad no necesariamente es lo más acertado, principalmente si lo que se busca es crear una cultura de eficiencia, respeto por el trabajo bien hecho y mejora continua.

El Diablo está en los detalles OK, entonces si la certificación no es la meta, ¿cómo podemos expresar una meta más adecuada? El principal elemento a tomar en cuenta es que buscar una certificación es un proceso que genera un cambio en toda la organización. Normalmente requiere una reestructura de roles, actividades, forma de trabajo, y tal vez hasta una redefinición de los servicios ofrecidos. La idea común de “pongamos a alguien que esté desocupado a definir procesos para que después le digamos a todos que los sigan”, sólo lleva a la frustración y malos resultados. La organización va a cambiar, junto con la forma en que todos hacemos las cosas. Para lograr ese cambio se necesita una razón lo suficientemente importante, clara, y poderosa como para generar ese cambio y mantenerlo a largo plazo. El problema de basar las estrategias de calidad en obtener algo como un documento de certificación, es la cantidad de pequeños problemas que se encuentran todos los días y que nos empujan a mantener todo como está. Imaginemos un escenario en el que tenemos que certificarnos en seis meses, pero también debemos entregar un proyecto para un cliente. Sucede que para entregar a tiempo el proyecto, tendríamos que saltarnos las pruebas unitarias. ¿Qué decisión tomaría la dirección de la compañía? ¿Renegociar con el cliente las fechas diciéndole que nos urge certificarnos?, o ¿entregar a tiempo pero sin las pruebas? Si la respuesta es esta última, el mensaje a la organización es claro: “si te ves en problemas, entonces no sigas los procesos”. En este caso, las razones para generar un cambio no son lo suficientemente fuertes para lograrlo.

JUL-AGO 2005

Certificarse es solamente un producto secundario En 1979, Philip B. Crosby escribió un libro cuyo tema principal se resume en: “el esfuerzo que se le dedica a la calidad no cuesta”. Lo que Crosby quería decir en este libro es que los beneficios obtenidos por las estrategias de calidad son mayores al costo de los mismos. Así las metas de la certificación deben de estar íntimamente ligadas a los problemas más importantes que vive la organización: ¿se están barriendo los proyectos?, ¿generamos demasiados defectos?, ¿somos demasiado caros? Si seguimos trabajando con nuestro nivel de costos, ¿cuánto tiempo podríamos seguir compitiendo? Si resolviéramos estos problemas, ¿cuánto dejaríamos de perder?, ¿cuánto adicional ganaríamos?, ¿dónde se vería reflejado este beneficio?, ¿Qué tanto lo queremos?, ¿estamos dispuestos a sacrificar una ganancia el día de hoy para lograr un ingreso mayor el día de mañana? Estas son las preguntas que necesitamos responder, estos son los beneficios que debemos de dar seguimiento y asegurar que se cumplan. Hace algunos años participé en la planeación de la certificación de una compañía mexicana. Al iniciar con el plan de certificación lo principal fue investigar las razones de la certificación. Después de algunas preguntas se llegó a la conclusión de que la organización buscaba ser 10% más productiva el próximo año, debido a que tenía anticipado un recorte de presupuesto y se requería que los individuos siguieran con la misma carga de trabajo. De ahí lo primero que se estableció en el plan fue la definición de las métricas de productividad, y todas las demás actividades se priorizaron de acuerdo a su impacto en productividad. Como actividad secundaria se definió el análisis de implementación, el cierre de la brecha y la preparación de la certificación. Estos objetivos no sólo le dan a la organización un incentivo claro para seguir adelante, sino que también sirve como base para aclarar qué es lo que se espera de las áreas de definición de procesos. Si lo que queremos es reducir nuestros tiempos de entrega, no podemos definir demasiados documentos, si lo que queremos es mantener el cambio durante un crecimiento acelerado, necesitamos un proceso sencillo que sea fácil de entrenar. En conclusión, la certificación no debería ser un objetivo sino una consecuencia secundaria de una mejora que queremos lograr como organización. Entre mejor relación exista entre los objetivos de calidad con los objetivos de negocio, más beneficios podemos lograr de nuestros esfuerzos de calidad a corto, mediano y largo plazo. - Luis Cuellar www.softwareguru.com.mx

PRODUCTOS

LO QUE VIENE

Primeros frutos de cooperacion entre Rational y Tivoli Detección y reparación de errores en sistemas empresariales

Durante su conferencia anual para usuarios, IBM Rational mostró dos nuevos productos para acelerar y facilitar la detección y reparación de errores en aplicaciones empresariales: el Problem Resolution Toolkit para IBM Rational Application Developer y el Performance Optimization Toolkit para Rational Performance Tester.

Estos productos integran capacidades del suite para administración de aplicaciones Tivoli, para mejorar la detección y solución de problemas en aplicaciones J2EE, middleware de integración y sistemas legacy. Las herramientas funcionan de la siguiente manera: el software Tivoli monitorea el rendimiento de las aplicaciones mientras están en funcionamiento, rastreando y guardando detalles cuando identifica problemas de rendimiento. El Problem Resolution Toolkit permite acceder esta información, para que los desarrolladores puedan identificar rápidamente la fuente de los problemas, minimizando el tiempo de caída de los sistemas.

Por su parte, el Performance Optimization Toolkit proporciona colectores de datos, también basados en software Tivoli, que se ejecutan durante el proceso de prueba. Al encontrar un problema, el toolkit sugiere posibles causas y resoluciones. Este es uno de los primeros frutos del esfuerzo de “cómputo autonómico” de IBM para crear sistemas que se reparen a sí mismos. Dado que las herramientas de Rational y Tivoli están basadas en la plataforma Eclipse, su comunicación e integración es transparente para el usuario.

PRODUCTOS

BEA Aqualogic Cómputo Líquido

BEA Systems recientemente lanzó su nueva familia de productos, AquaLogic. El propósito de estos productos es proveer lo que BEA llama una infraestructura de servicios. Esta infraestructura consiste en una especie de contenedor donde los servicios – sin importar la plataforma en que fueron desarrollados –, puedan ser descubiertos, ensamblados y administrados de manera fácil, rápida y segura. Los productos de esta familia que se han dado a conocer hasta el momento son: • BEA AquaLogic Service Bus, para la integración y administración de servicios web en ambientes heterogéneos. • BEA AquaLogic Data Services Platform, permite acceder de manera unificada los datos de diversas fuentes disponibles en la empresa. • BEA AquaLogic Enterprise Security, una infraestructura de seguridad orientada a servicios para proveer seguridad a aplicaciones distribuidas. Ademas de estos, se espera que en un futuro próximo se agreguen nuevos productos a esta familia. Al parecer, la nueva visión de BEA está completamente comprometida con AquaLogic y el concepto del cómputo líquido. Incluso ha cambiado su logo y slogan, el cual ahora es “think liquid” (piensa líquido).

JUL-AGO 2005

Integración Dirigida por Negocio

Recientemente Magic Software liberó la versión 2.5 del iBolt Business Integration Suite, una plataforma de integración empresarial. Utilizando iBOLT, las empresas pueden alinear rápida y fácilmente sus necesidades del negocio con su infraestructura IT. iBolt también posee capacidades de BPM, así que las empresas pueden desarrollar nuevos procesos de negocio, crear nuevas aplicaciones compuestas e implementar de manera más flexible las Arquitecturas Orientadas a Servicios. El suite está formado por los siguientes componentes: • iBolt Studio – Herramienta para modelar y desarrollar visualmente los procesos, flujos, conectores, datos, topologías, etc. • iBolt Server – El engine o ambiente de ejecución para proyectos creados en iBolt Studio. • iBolt Monitor – Herramienta para monitorear en tiempo real la ejecución de procesos de negocio. Adicionalmente existe la Special Edition (SE) de iBolt, que es una edición especialmente diseñada para SAP Business ONE, que integra todas las capacidades de iBolt en esta plataforma.

www.softwareguru.com.mx

PRODUCTOS

REPORTE DE MERCADO

BPMS

Aumentando las Expectativas

l 2005 muy probablemente será recordado como el año en que los sistemas BPM despegaron. De acuerdo con encuestas realizadas en Estados Unidos, BPM ha tomado el primer lugar en la lista de prioridades de los directores de sistemas, por encima de iniciativas como outsourcing y seguridad en TI. En México todavía falta tiempo para llegar a esto, pero es de esperarse que pronto lo haremos, así que es importante que comencemos a monitorear este mercado.

Historia El mercado de los sistemas BPM es relativamente nuevo. Los expertos del tema concuerdan en que los primeros productos que realmente pueden ser considerados como BPMS hicieron su aparición entre 1999 y el 2000. En México, los analistas de la industria apenas este año comenzaron a monitorear el mercado de estos productos. Tal es el caso de IDC, quienes en su “Mexico Semiannual Software Tracker 2004”, consideraron el rubro de BPM por primera ocasión.

• Cumbre de expectativas – Evangelización y proyectos iniciales. El entusiasmo llega a su punto mayor. • Valle de desilusión – Escepticismo generado cuando la tecnología no cumple con todo lo que había anunciado, o no se logra en el tiempo que se esperaba. • Pendiente de claridad – Con el mayor uso y experimentación, por fin se aclara el verdadero potencial, beneficios y riesgos. • Meseta de productividad – Los beneficios reales se demuestran y reciben aceptación general. Las herramientas relacionadas con la tecnología se estabilizan y maduran incrementalmente. En la gráfica 1, mostramos los puntos donde creemos que actualmente se encuentra esta tecnología tanto en Estados Unidos como en México.

Tamaño De acuerdo con información reportada por IDC en el estudio previamente mencionado, el tamaño de este mercado en México en el 2004 fue de 3.9 millones de dls., lo cual representa tan sólo 2.1% del segmento de back office (182.1 millones dls.). Sin embargo, se espera que este mercado crezca en dobles dígitos anuales durante los próximos tres o cuatro años. Vale la pena recalcar que estas cifras se refieren exclusivamente a licencias de software.

Evolución Este mercado actualmente cruza un momento muy importante. Las expectativas están en un nivel muy alto, lo cual provoca que todos los proveedores quieran “subirse al barco”. Una enorme cantidad de proveedores están desarrollando “capacidades BPM” dentro de sus productos, y otros tantos han hecho adquisiciones de empresas especializadas en tecnología BPM, para integrarlas dentro de su oferta. De acuerdo con Jim Sinur, analista de Gartner, existen más de 225 proveedores cuya oferta tecnológica abarca diferentes aspectos de BPM. Es evidente que poco a poco este mercado se irá consolidando, y la oferta quedará reducida a unos cuantos proveedores. Al igual que la mayoría de las tendencias tecnológicas, los BPMS están sujetos a una curva de evolución o madurez. Una manera de representar esta evolución, es apoyándose en el modelo del “Hype Cycle” (ciclo de expectativas, o de exageración), creado por Gartner. De acuerdo con este modelo, las tendencias tecnológicas típicamente siguen cinco etapas: • Lanzamiento – El disparo inicial generado por un lanzamiento, demostración pública, u otro evento que provoca que la industria empiece a poner atención en la tecnología en cuestión.

JUL-AGO 2005

Como podemos apreciar, en México todavía estamos en el ascenso hacia la cumbre de expectativas. Esto significa que durante los próximos meses seguiremos escuchando mucho respecto a este tema. Mientras tanto, parece que en Estados Unidos el punto máximo de expectativas ya se alcanzó, y ahora se está buscando convertir estas expectativas en realidad. Los analistas consideran que los BPMS alcanzarán la meseta de la productividad en Estados Unidos durante el 2007. Nosotros creemos que en México ésta se alcanzará de 18 a 24 meses después.

Industrias El sector donde mayor adopción están teniendo los sistemas BPM hasta el momento, es el financiero. De acuerdo con cifras en Estados Unidos, 46% de los proyectos de BPM son en este sector, seguido por telecomunicaciones (12%), salud (10%), y gobierno (8%). Aunque datos como estos todavía no están disponibles en México, y realmente son muy pocos los proyectos de BPM hasta el momento, es de esperarse que la mayor adopción también se dé en el sector financiero y de aseguradoras, seguido por gobierno y grandes tiendas de autoservicio (retail). www.softwareguru.com.mx

Estos son algunos de los principales proveedores de tecnología BPM con representación en nuestro país, listados en orden alfabético.

Carnot (www.carnot-usa.com)

Magic Software (www.magicsoftware.com)

El Carnot Process Engine es uno de los productos que podemos llamar “BPM puro”, ya que se limita a proveer la funcionalidad exclusiva de un BPM. Esto, en conjunto con su arquitectura basada en estándares, le da gran flexibilidad. Por ejemplo, puede funcionar sobre diversos servidores de aplicación y manejadores de base de datos. Horbis (www.horbis.com) es distribuidor de Carnot en México.

Su producto iBolt, es una plataforma de integración empresarial que ha evolucionado y ahora incluye capacidades BPM. Al usarlo en conjunto con eDeveloper —un producto de la misma empresa para desarrollar aplicaciones visualmente sin necesidad de programar—, ofrece una solución conveniente para integrar y desarrollar aplicaciones dirigidas por negocio. Roca Sistemas (www.rocasistemas.com.mx) es el distribuidor de Magic Software en México.

Fuego (www.fuego.com)

Software AG (www.softwareag.com)

La Fuego BPM Suite puede ser calificada como una solución de “gran escala”. Está orientada a grandes empresas con ambientes heterogéneos y grandes volúmenes de operación. La oficina de contacto para Latinoamérica se encuentra en Miami, pero en México se puede adquirir a través de Axxis (www.axxis.com.mx).

La empresa alemana creadora de productos como Natural, Adabas y Tamino XML Server, recientemente lanzó un producto BPM llamado Interstage Enterprise Process Manager, el cual es resultado de una alianza entre Software AG y Fujitsu.

Handysoft (www.handysoft.com)

Sterling Commerce (www.sterlingcommerce.com)

BizFlow es otro BPM puro y multiplataforma. Su enfoque está en la facilidad de uso y administración. En conjunto con el SOXA Accelerator (otro producto de la misma empresa), brinda una solución “out-of-thebox” para lograr cumplimiento de Sarbanes Oxley. Grupo Ecce (www.grupoecce.com) es distribuidor de Handysoft en México.

Como parte de su plataforma MESA (Multi Enterprise Services Architecture) para colaboración interempresarial, Sterling Commerce ofrece el Gentran Integration Suite. La suite está orientada a automatizar procesos de negocio colaborativos a lo largo de su interacción entre clientes, proveedores y otros socios de negocio.

IBM (www.ibm.com)

Ultimus (www.ultimus.com)

IBM acostumbra estar presente en todo lo que se refiere a TI, y esta no es la excepción. Su suite para BPM lleva el nombre de Websphere Business Integration. Estos productos descansan sobre la capa de middleware provista por otros productos como Websphere Application Server y Websphere MQ. IBM también es uno de los principales impulsores de estándares para lenguajes de descripción de procesos de negocio, como BPEL. Así que este gigante está presente en todos los frentes: estándares, middleware y productos finales.

Ultimus es una de las empresas pioneras en BPM. Una de sus principales fortalezas de su Ultimus BPM Suite es su integración avanzada con tecnología de Microsoft. Por ejemplo, usa unos componentes llamados “flobots”, que son agentes que automáticamente interpretan, generan y distribuyen documentos de Office.

www.softwareguru.com.mx

PRODUCTOS

TUTORIAL

Ingeniería en Reversa de DB2 iSeries Utilizando XDE Por Amaury Quintero

En este artículo veremos cómo utilizar Rational XDE para hacer la ingeniería inversa de una base de datos DB2 albergada en un servidor iSeries o AS/400e. XDE es un ambiente integrado para desarrollo de software (IDE), que incluye capacidades para modelado visual con UML.

ay ocasiones en las que necesitamos hacer ingeniería inversa a una base de datos existente para poder conocerla, entendarla y posiblemente modificarla. Esto suele suceder cuando heredamos una base de datos de un sistema legado. Veamos entonces cómo podemos utilizar Rational XDE para realizar la ingeniería inversa y generar el modelo correspondiente. Para realizar esta práctica vamos a necesitar el IBM Toolbox para Java. Este es un conjunto de clases Java que nos permite accesar los datos en servidores iSeries y AS/400e. En caso que el servidor no contase con el IBM Toolbox para Java es necesaria su instalación. Para instalar este conjunto de utilidades haga lo siguiente: • Desde la línea de comandos escriba GO MENU (LICPGM) y presione [ENTER]. • Selecione 11. Install licensed program. • Seleccione 5722-JC1 IBM Toolbox for Java.

UML y el modelo Entidad-Relación (E/R) XDE no maneja directamente los diagramas EntidadRelación tradicionales. Lo que hace es utilizar diagramas de clases, complementados con el perfil de UML para bases de datos. Este perfil incluye estereotipos para modelar los elementos de un diagrama entidadrelación. Por ejemplo, las tablas se representan como clases con el estereotipo <<Table>> mientras que las relaciones se representan como asociaciones entre clases. Las columnas de las tablas se representan como si fueran atributos de clase, y los constraints como operaciones.

JUL-AGO 2005

Para comenzar, creamos un nuevo proyecto en el XDE y seleccionamos alguno de los tipos de modelos predeterminados para realizar el modelado de datos. En nuestro caso utilizaremos el DB2 iSeries Data Model, el cual nos van a permitir albergar los elementos que esten dentro de la base de datos DB2. Para realizar la ingeniería inversa podemos partir de un script DDL que contenga las sentencias SQL de la estructura de la base de datos, o nos podemos conectar directamente a la base de datos y obtener esta información. El script se puede generar con el IBM iSeries Navigator, a través del cual nos conectamos a la base de datos, seleccionamos los esquemas deseados y generamos el archivo. Para conectarnos a la base de datos desde XDE, podemos utilizar DB2 Connect. Esta es la herramienta de selección cuando necesitamos tener acceso a DB2 ya sea de la plataforma zSeries, iSeries y AS/400 principalmente. Sin embargo, desde XDE también podemos accesar una gran variedad de manejadores de bases de datos sobre diferentes plataformas. Una vez que XDE haya importado el contenido de la base de datos (ya sea a través del DDL o por conexión directa), se procede a generar diagramas donde se puede modelar visualmente los elementos de la base de datos.

Pasos 1. En la vista del Explorador de Modelos, que se encuentra ya abierta en la perspectiva de modelado, seleccionar el modelo que recibirá la ingeniería inversa. 2. Activar el asistente de ingenieria en reversa haciendo click derecho sobre el modelo de datos y seleccionando Data Modeler > Reverse Engineer (Fig. 1). Seleccionamos la opción de DDL Script, el tipo de base de datos IBM DB2 iSeries 5.x y el archivo con las sentencias SQL que nos proporcionó el iSeries Operation Navigator. 3. Luego debemos filtrar los elementos de la base de datos que necesitamos conocer (índices, procedimientos almacenados, vistas, tablas, etc) y con esto terminamos la operación. Siempre debemos verificar en la vista de Output de XDE que no se hayan reportado problemas a la hora de leer el script, de ser asi, debemos revisar los errores y corregirlos manualmente en el archivo con sentencias SQL. Esto evita que algún detalle de la base de datos sea omitido. Una vez que el asistente es ejecutado, XDE hace una correspondencia entre el DDL y el perfil UML, por ejemplo; cada sentencia CREATE TABLE es transformada a una tabla del modelo relacional y cada CREATE DISTINCT TYPE es convertido a una columna del dominio dentro del modelo del dominio. www.softwareguru.com.mx

Fig. 1. Invocando al asistente para ejecutar la ingeniería en reversa.

Terminado esto, pasamos a revisar el contenido del modelo generado en el Explorador de Modelos, podemos modificar el nombre de la base de datos, por uno más representativo. El Nombre RDB (Relational Database Name) es el nombre de la base de datos en el servidor (Fig. 2) y se puede obtener con el comando de línea WRKRDBDIRE.

Fig. 2. Representación de la base de datos del servidor y tablas de los esquemas seleccionados.

Utilizando los diagramas de clases o de formato libre de XDE podemos crear algunos que nos den una idea de cómo están asociadas las diferentes entidades de nuestro modelo de www.softwareguru.com.mx

PRODUCTOS

TUTORIAL

A través del modelado visual podemos entender mejor la estructura de una base de datos, así como sus dependencias.

datos (Fig. 3), lo cual nos brinda una forma sencilla de visualizar el modelo. También podemos revisar la correspondencia que efectuó XDE entre los datos de DB/2 UDB iSeries y el perfil UML para base de datos consultando la ayuda de XDE.

2. Si el servidor de aplicaciones se encuentra en otra máquina, entonces necesitamos un driver JDBC, de preferencia el que viene con el IBM Toolbox para Java. Este es un manejador tipo 4, que es un manejador de protocolo nativo que provee un mejor rendimiento que los drivers del tipo 1 y 2, ya que se comunica directamente con el host utilizando sockets sin pasar por la capa de ODBC. La clase que lo implementa es com.ibm.as400.access. AS400JDBCDriver

Conclusión

Fig. 3. Diagrama de clases visualizando la relación entre los componentes del modelo de datos.

Luego de conocer nuestro dominio y ejecutar cambios sobre este, el diseñador puede pasar a aplicar estos cambios a la base de datos, posicionandose sobre uno de los esquemas modificados y nuevamente haciendo click derecho Data Modeler > Forward Engineer, seleccionamos los elementos que queremos actualizar y el nuevo archivo donde se guardarán las sentencias SQL con las modificaciones a la base de datos. Para hacer los cambios efectivos, este archivo tenemos que ejecutarlo sobre el iSeries Operation Navigator como un script SQL. Asegurese que la ejecución no le arrojó mensajes de error, si es asi corrijalos y continue la ejecución.

A través del modelado visual podemos entender mejor la estructura de una base de datos, así como sus dependencias. El modelado visual es una de las mejores practicas del desarrollo de de software que contribuyen a aumentar la probabilidad de la ejecucuión exitosa de proyectos de software. Hay que recordar que la ingenieria en reversa debe ser considerada una herramienta que nos asiste en el proceso de entender y visualizar una configuración existente, y no como una fuente de verdad irrefutable. El resultado debe ser revisado para asegurarnos que la herramienta ha capturado los detalles de manera correcta.

Drivers para producción Si fuese el caso que los cambios serán puestos en producción, tenemos dos opciones para conectarnos a la base de datos desde el servidor de aplicaciones de Java, dependiendo de donde se encuentre instalado éste: 1. Si el servidor de aplicaciones se encuentra en la misma máquina que la base de datos, conviene utilizar el driver nativo, que viene dentro del AS/400 Developer Kit, que es más rápido y está implementado con la clase com.ibm. db2.jdbc.app.DB2Driver. Este driver también lo podemos obtener directamente del mismo servidor AS/400, el archivo que deben buscar es /QIBM/ProdData/http/Public/jt400/lib/jt400.jar

Referencias • IBM Developerworks www-136.ibm.com/developerworks/ • iSeries Information Center publib.boulder.ibm.com/iseries/ v5r2/ic2924/ • JDBC Drivers: How Do You Know What You Need? archive.devx.com/dbzone/articles/ dd_jdbc/sosinsky-1.asp

Amaury Quintero es consultor de Itera especializado en Análisis y Diseño, donde se encarga de la iniciativa de Nuevas Herramientas de IBM Rational. Es graduado de Cibernética-Matemática en la Universidad de La Habana, Cuba y actualmente cursa la Maestría en Ciencias de la Computación en el CIC del IPN.

JUL-AGO 2005

www.softwareguru.com.mx

ENTREVISTA

Ing. en Computación de la UNAM y con 38 años de edad, Carlos González es director de sistemas de Grupo TMM, una de las empresas más importantes del país. Carlos inició su carrera profesional en Oracle, como consultor. Después llegó a TMM, donde coordinó los esfuerzos de ingeniería de software durante un par de años. En 1999 decidió dedicarse a dar cursos y consultoría de manera externa, pero pronto regresó a TMM para apoyar en la definición de los procesos operativos del área. Un par de años después, en el 2001, asumió la dirección de sistemas.

Carlos González Director de Sistemas de TMM

¿Qué te hizo regresar a TMM cuando ya te habías ido? Ahí hay una cuestión medio filosófica. Cuando me fui de instructor esos siete meses, durante un taller hicimos un ejercicio en el que me pusieron el símil de la escalera. Se supone que tu camino en la vida es una escalera, así que si quieres llegar a algún lugar, tienes que pensar en si lo que estás haciendo hoy en día te está ayudando a subir escalones o no. Yo lo pensé y me di cuenta que lo que yo quería era ser director de sistemas, así que por eso me regresé. Siento que hice una buena decisión porque estoy haciendo algo que me apasiona.

JUL-AGO 2005

Tu camino a la dirección de sistemas fue a través de las áreas de procesos y metodología. ¿Crees que este es un buen camino? Sí, porque al trabajar en esta área también conoces los procesos del negocio. Yo creo que este es el camino más adecuado, no porque yo haya pasado por ahí, sino porque me he topado con otras personas que no han tenido esa progresión, y carecen de las herramientas suficientes. También es importante captar suficiente experiencia antes de llegar a un puesto directivo, ya que con esto será más fácil asumir una responsabilidad y lidiar con la incertidumbre. Porque estar en un puesto directivo es lidiar continuamente con la incertidumbre, la ambigüedad completa. ¿Cuáles son los principales proyectos que tienen en curso en TMM? Al igual que muchas otras empresas en México, TMM tuvo una época difícil en los últimos dos o tres años. Esto nos obligó a detener un poco ciertas iniciativas que traíamos. Al día de hoy, los principales proyectos que tenemos son en términos de actualización de infraestructura, seguridad, etc. El siguiente paso que queremos dar es desarrollar una arquitectura de servicios que nos permita ofrecer nuevos y mejores servicios a los clientes. Esta arquitectura también nos permitirá ligar nuestras cadenas de suministro con nuestros clientes y proveedores para tener una interacción mucho más directa y eficiente. Durante 2004 TMM redujo significativamente sus costos administrativos. ¿Fue tijeretazo o en realidad hubo mejoras en eficiencia? ¿Qué papel jugaron las TI? Usualmente en la mayoría de las empresas con una dinámica de negocio normal, donde se está ganando dinero de manera continua, se empieza a dar un desperdicio. Esto pasa siempre, y no es evidente hasta que el desperdicio es demasiado. Lo que nosotros hicimos fue analizar nuestros procesos, y entonces nos dimos cuenta que había ineficiencias como pasos duplicados, sistemas que hacían lo mismo, áreas que trabajaban con la misma información pero de diferente manera. Así que al corregir esto mejoramos nuestra eficiencia. Lo otro que hicimos fue acercarnos a nuestros proveedores y buscar maneras creativas de resolver las cosas. Por ejemplo, que pasa si en lugar de adquirir y despreciar los activos empezamos a arrendarlos en un esquema de demanda, o si en lugar de comprar licencias rentamos servicios, o si en lugar de tener a los programadores ahí sentados, nos apoyamos en proveedores externos. www.softwareguru.com.mx

¿Qué criterios de evaluación utilizas para escoger proveedores de servicios de TI? Más que nada nos fijamos en el nivel de la gente. Normalmente cuando tú encuentras un despacho que trae elementos de buen nivel, eso habla mucho de la empresa y cómo escoge a su personal. ¿Cuáles consideras que son los principales retos que viven los CIOs hoy en día? Uno de los mayores retos es la alineación de TI con el negocio, lograr tener esa visión lo suficientemente profunda para entender cómo es que la tecnología afecta la operación central del negocio. Hoy ya no es como antes, cuando el contador te decía “necesito un sistema para llevar la contabilidad”, así que era fácil definirlo y justificarlo. Hoy en día ya estamos hablando de iniciativas mucho más complejas, como por ejemplo, Business Process Management. Entender estos conceptos requiere madurez no sólo en términos de tecnología, sino principalmente de la operación del negocio. ¿Cómo ha evolucionado el rol de las áreas de sistemas y hacia dónde va? En los 90s el rol del área de sistemas era una cuestión eminentemente técnica. Ese periodo ya pasó y hoy más que nada lo que hacen es administrar la tecnología como un recurso. Esto significa que cada peso que la organización destina a los sistemas debe ser lo más inteligentemente gastado, para que de ser posible pueda devolver dos pesos. Hacia el futuro, creo que esta área deberá estar mucho más involucrada en el negocio, para proveer una visión “tecnologizada” de éste. Como parte de esta visión, su responsabilidad será proponer iniciativas que mejoren el negocio o lo habiliten hacia nuevas oportunidades. ¿Entonces ya no bastará con saber programar? Así es. Cualquiera puede programar hoy en día. El único diferenciador que puedes tener es el conocimiento de negocio. El saber hacer negocio con la tecnología es muy relevante. ¿Crees que BPM sea una moda o que sea real? BPM a fin de cuentas es un concepto, cuyos fundamentos están en la operación del negocio. No es algo nuevo, lo que sucede es que hace muchos años las herramientas que había eran poco adecuadas, y estaban completamente desligadas entre sí. La orquestación de procesos entre sistemas era imposible, ya que tenías que meterte a las tripas de cada sistema y desarrollar procedimientos y llamadas a nivel de sistema operativo, entonces esto era muy poco práctico. Hoy en día la tecnología ya evolucionó, y todo esto es mucho más natural.

¿Nos puedes contar algo sobre su proyecto para cumplimiento de Sarbanes Oxley? La ley de Sarbanes Oxley es un mandato para todas las empresas públicas que cotizan en el mercado de valores de Nueva York, como nosotros. Esto significa básicamente tener una definición de controles lo suficientemente robusta para permitir a los auditores hacer una atestiguación de que estás controlando adecuadamente la empresa y no estás defraudando a los inversionistas. ¿Crees que Sarbanes Oxley trae beneficios más allá de cumplir con el mandato? Sí. Cualquier empresa debe tener idea de qué hace, cómo lo hace, cuándo lo hace, y qué oportunidades tiene de mejorarlo. Y la única forma de lograr esto es teniendo clara la definición de los procesos. No hay mejora si no hay procesos. ¿Cuáles son las principales habilidades y conocimientos que necesita tener un CIO? Al igual que para cualquier profesión, el conocimiento más importante es el de ti mismo. Hay que saber cómo es que aprendes, cómo resuelves problemas, cómo enseñas. Esto te hace ver tus principales fortalezas y debilidades, y a final de cuentas te permite mostrar una imagen auténtica de ti. ¿Qué características consideras importantes en una persona que quieres reclutar? La actitud es lo más importante. La gente debe estar dispuesta a aprender, crecer, y entrarle a la chamba difícil. El conocimiento es secundario porque se puede adquirir. ¿Qué le pedirías al gobierno, las instituciones educativas y las empresas para desarrollar la industria de software? Al gobierno, apoyo para facilitar el establecimiento de nuevas empresas. A las instituciones educativas, que generen profesionistas más completos, que además de habilidades técnicas cuenten con habilidades complementarias para que puedan hacer una presentación, administrar el tiempo, comunicarse adecuadamente, etc. A las empresas, mayor determinación e innovación. Frecuentemente, en México, cuando hay oportunidades que involucran riesgo, simplemente no le entramos. Esperamos a que llegue alguien más y lo haga. Creo que debemos aventarnos a vivir el sueño, en lugar de seguirlo soñando. ¿Qué mensaje le dejas a nuestros lectores? Que lean la revista, tiene cosas muy interesantes. Mucha gente está más pegada al rollo de los lenguajes de programación y los bits y los bytes, que en tratar de entender el proceso completo de desarrollo de software. JUL-AGO 2005

EN PORTADA

BPM Una Herramienta de Competitividad Por Francisco López Lira

Las empresas enfrentan un entorno complicado. Por un lado, la competencia es global y se hace contra países con sueldos menores, lo que implica que las empresas deben reducir sus costos o crear mayores diferenciadores para competir. Por el otro, la situación económica adversa ha hecho que se disponga de menor cantidad de recursos y ahora es necesario hacer más con menos. Además, los clientes están más informados y cuentan con mayor poder de elección, lo cual genera más presión para venderles y retenerlos. Por si esto no fuera poco, los mercados y las condiciones cambian continuamente, requiriendo de las empresas rapidez de adaptación y una mayor flexibilidad para el cambio.

JUL-AGO 2005

“Hay un método en esta locura” —Horacio

uchas han sido las iniciativas que a lo largo de los años se han propuesto para que las empresas puedan afrontar estos retos. Desde la Gestión de Calidad Total (TQM) hasta Six Sigma (6σ), pasando por Reingeniería de Procesos de Negocio (BPR), Just in Time (JIT), Costeo Basado en Actividades (ABC), Kaizen, Supply Chain Management (SCM) y Balanced Scorecard (BSC), por nombrar algunas. Por supuesto, la tecnología de información ha estado presente con propuestas propias, que se remontan a la promesa de los Sistemas de Información Gerenciales (MIS) y la tecnología Cliente/Servidor hasta llegar a los ERP y los CRM, sin olvidar las soluciones Business to Business (B2B). Tristemente, estas iniciativas no siempre han dado los resultados esperados. Muchas fueron las empresas que con gran ilusión se embarcaron en la ola de Reingeniería de los 90’s, obteniendo resultados muy por debajo de lo esperado. Según el propio Michael Hammer, 70% de estos proyectos resultaron en fracasos. Esto ha dado lugar a un gran escepticismo y ha creado el síndrome de cure du jour. Por el lado de los proyectos de tecnología de información, los fracasos acumulados en la industria han dado lugar a que los Directores de Sistemas enfrenten ahora una creciente presión para (a) probar que la tecnología de información entrega valor a la organización, (b) involucrar a las diferentes áreas en las decisiones tecnológicas, (c) reducir costos, y (d) mantener bajo control los riesgos, lo cual ha dado lugar al concepto de Gobernanza de TI (IT Governance). ¿Por qué estos esfuerzos no han tenido el éxito esperado? Un estudio sobre la utilización de 200 herramientas administrativas en 160 empresas durante un lapso de diez años, encontró que las empresas que alcanzan un desempeño superior son las que dominan cuatro elementos fundamentales: estrategia, cultura, estructura y ejecución, independientemente de la herramienta utilizada. Esto implica que las organizaciones, primero, deben de elaborar una estrategia adecuada, que permita aprovechar las condiciones externas y las capacidades internas. Una vez que se cuenta con ésta, la cultura —los supuestos compartidos— debe alinearse para permitir alcanzar los objetivos, al igual que debe crearse una estructura organizacional que soporte las iniciativas dentro de la organización. Ahora bien, ¿cómo pueden las organizaciones ejecutar adecuadamente? Las organizaciones sólo

cuentan con dos formas de instrumentar las estrategias: los proyectos y los procesos. Recordemos que un proyecto es “un esfuerzo temporal que se lleva a cabo para crear un producto o servicio único”, mientras que un proceso puede definirse como “un conjunto de actividades que transforman insumos en productos de valor para un cliente”. Es importante hacer notar que los proyectos, a su vez, están formados por procesos y que 80% del fracaso o éxito de los proyectos está relacionado con una buena administración. Los elementos clave para la ejecución son pues, los procesos y su administración. Si repasamos las iniciativas citadas, veremos que en todas los procesos tienen un papel clave: son un área importante dentro de un esfuerzo de TQM, son el foco central de BPR, Kaizen y 6σ, y son cruciales en JIT, ABC y BSC. Los procesos también ocupan un lugar trascendente en las iniciativas tecnológicas. Por ejemplo, ¿quién puede negar su importancia en un ERP o B2B? Los procesos son importantes porque es a través de ellos que la organización genera valor para sus clientes, integrando la participación de diferentes áreas funcionales a través de toda la cadena de valor. En este contexto, surge con mucha fuerza una iniciativa llamada Business Process Management (BPM) que puede ayudar a consolidar todos los esfuerzos anteriores. En el año 2000, Gartner predijo que BPM sería el siguiente gran fenómeno, y posteriormente comentó que “BPM gana la triple corona por ahorrar dinero, ahorrar tiempo y añadir valor”. Otro estudio realizado por el BPM Institute arrojó que 96% de los encuestados indicaron que un enfoque centrado en procesos era crítico para el éxito de su compañía.

¿Qué es BPM?

BPM consiste administrar el ciclo de vida de los procesos, apoyándose en herramientas de automatización del flujo de trabajo, conocidas como Business Process Management Systems o BPMS. Aunque algunos opinan que BPM no necesariamente involucra un BPMS, en mi opinión esto le resta potencial a la solución y no permite distinguirla fácilmente de otras propuestas como Kaizen, por ejemplo. El ciclo de vida de un proceso cubre su conceptualización, representación (gráfica y/o textual), optimización, automatización, simulación y prueba, e implantación en la organización. Por otro lado, la administración incluye la planeación, seguimiento, monitoreo y control. JUL-AGO 2005

EN PORTADA

Beneficios

En su reporte Technology Focus: Business Process Management, Doculabs lista como beneficios para las organizaciones la reducción de costos, mejor servicio al cliente, reducción de riesgos y una rápida respuesta a las condiciones cambiantes. De acuerdo con un estudio de Gartner, 78% de los proyectos de BPM arrojaron una tasa interna de retorno mayor a 15%, y algunos llegaron a 360%, lo cual justifica el costo de la solución. BPM es la convergencia de iniciativas administrativas anteriores: toma el concepto de enfoque de procesos y de mejora continua de Kaizen y TQM, la posibilidad de innovar radicalmente los procesos de BPR, el enfoque en la mejora con base en datos estadísticos de 6σ, la idea de operación en línea de JIT, el costeo de procesos de ABC, la integración de procesos de SCM y la idea de un tablero de control de BSC. Los BPMS, por otro lado, aprovechan nuevas tecnologías como XML y web services, pero —maravillosamente— habilitando la integración con sistemas legados, ERPs, CRMs y herramientas de BI. Todo esto sin perder de vista el proceso desde el punto de vista del negocio.

BPMS

Para entender lo que es un BPMS, enlistemos sus componentes funcionales típicos: • Modelador de procesos.- Ayuda a descubrir y modelar los procesos. • Herramientas de desarrollo.- Diseñador de formas y editor de reglas. • Integración.- Habilita la integración para interactuar con otras aplicaciones. • Máquina de procesos.- El motor que habilita la ejecución de procesos. Ejecuta instancias de procesos en base al estado de los objetos y las reglas definidas. • Repositorio.- Almacena meta-definiciones de procesos, participantes e integración. • Gestión.- Provee registros de auditoría. Adicionalmente habilita la intervención manual para redirigir, abortar o modificar la instancia de un proceso en caso de emergencia. • Reporte y Análisis.- Permite visualizar y analizar la ejecución de los procesos.

Contraste con Paquetes

Los proveedores de paquetes y aplicaciones empresariales acostumbran argumentar que sus

productos cubren prácticamente todas las necesidades de una organización. Sin embargo, sabemos que esto dista de ser verdad. Según Gartner, un ERP cubre en promedio únicamente 30% de la funcionalidad requerida en las empresas. Adicionalmente, existen muchas actividades que involucran participación y toma de decisiones por parte de las personas. Cuando estas actividades no están incluidas en las aplicaciones, se crean actividades fuera del proceso automatizado. Si el proceso requiere la intervención de varios sistemas, se crean islas de automatización que obligan a las personas a utilizar papel o paquetería de oficina para pasar de una “isla” a otra. Son famosas las historias de cómo las personas se ingenian para usar una hoja de cálculo y “darle la vuelta” a un ERP. Aún cuando a un paquete se le integre una máquina de procesos, la solución está centrada en los “recursos” o “los clientes” y no en los procesos de negocio. Así como un manejador de bases de datos está hecho para manejar bases de datos, tablas, columnas e índices, un BPMS está diseñado para manejar procesos, instancias, versiones y variantes, componentes, reglas y participantes de procesos. Esto cambia el enfoque de centrado-en-datos a centrado-en-procesos.

Impacto al área de TI

BPM tiene una repercusión importante para los roles relacionados con el software. Los proyectos de BPM serán parte del portafolio de proyectos de las áreas de Sistemas y deberán ser controlados por el Director. Los desarrollos de software a la medida incluirán cada vez más la identificación y modelado de los procesos de negocio. Los desarrollos de software basados en un BPMS requerirán que los desarrolladores entiendan los procesos de negocio y sepan usar la herramienta. Los analistas de sistemas deberán aprender sobre análisis de procesos, al igual que los usuarios. Los testers deberán realizar pruebas con una visión del proceso completo. Los administradores de bases de datos deberán incorporar bases de datos de procesos. Los administradores de redes deberán incluir en su administración servidores de procesos y considerar el ancho de banda necesario para asegurar el tráfico de la información de los procesos, no sólo a través de la organización sino también con los socios de negocio. Los administradores de configuración tendrán que considerar entre sus ítems a los procesos y sus objetos derivados. Los administradores de proyectos deberán

entender las implicaciones de la participación de los usuarios de negocio y de los analistas de procesos. Los especialistas en seguridad deberán ahora brindar seguridad a todo el proceso. Pero no todo es mayor trabajo para el personal de Sistemas. En retribución, los sistemas desarrollados tendrán una mayor visibilidad y una mayor participación de las áreas usuarias. Será posible reanimar sistemas “muertos” o poco utilizados. Los usuarios podrán contar con una interfaz común sin importar si detrás está un ERP o un sistema legado. Quizá lo más importante para nuestra industria es que se aprovecha y potencía la inversión existente en tecnología de información. ¿Cómo se relaciona BPM con los esfuerzos de mejora de procesos basados en modelos? ¿No son BPM también? Los modelos como CMMI o MoProSoft son un gran avance ya que llevan el concepto de administración de procesos a las organizaciones de sistemas/software. Existen otros modelos, como SCOR para cadena de suministro (Supply Chain), ITIL para servicio tecnológico, o COBIT para el control de los objetivos. Todos ellos se basan en procesos y considera en menor o mayor grado su administración. Las diferencias cruciales, quizá sean que BPM primero lleva estos conceptos a toda la organización, y además, tomando ventaja explícita de la tecnología para crear procesos digitalizados. Esto no significa que los esfuerzos basados en estos modelos compitan con BPM. Más bien, son un paso importante en el sentido de lo que se buscan con BPM. Por último, más no por menos, es importante mencionar que además del expertise técnico en BPM, un esfuerzo exitoso de este tipo requiere incluir una administración efectiva de los proyectos, administrar el cambio organizacional, obtener el patrocinio suficiente, y alinearse con los objetivos estratégicos del negocio. Referencias: • William Joyce, Nitin Noria, Bruce Robertson. “What Really Works”. Harvard Business Review. Julio 2003 • Jim Sinur, Jess Thompson. “The Business Process Management Scenario.” Gartner Research. Junio 2003 • Thompson, Michael. “Requirements for effective BPM”, Butler Group. Junio 2003

Francisco José López Lira e Hinojo es Director Operativo de Process & Project Health Services, firma dedicada a la consultoría en BPM y mejora de proyectos, Presidente de la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS) y Vicepresidente de la Asociación BPM de México. Su correo es flopezlira@pp-hs.com

JUL-AGO 2005

www.softwareguru.com.mx

Desde hace varios años las organizaciones (empresas privadas o instituciones públicas) han ido incrementando el uso de procesos con el objeto de mejorar su desempeño y mantener su operación. Podemos ver reflejada esta megatendencia en muchos contextos donde el proceso es una entidad relevante: paquetes empresariales de software basados en modelos estándar de procesos (CRM, ERP, SCM), modelos de gestión del desempeño empresarial (Balanced Scorecard), modelos de calidad (ISO 9000:2000, TQM), métodos de mejora de procesos (Six Sigma, BPR), modelos de referencia de madurez y capacidad de procesos (CMMI, SPICE), modelos de procesos específicos (RUP, SPEM, ITIL), entre otros.

BPMS La Nueva Plataforma de Misión Crítica Por Roberto Silva

En la actualidad, los proveedores requieren acelerar la entrega de más valor a sus clientes y al mismo tiempo disminuir sus costos. Sin embargo, las organizaciones no han comprendido la naturaleza básica de los procesos y aún no han encontrado una infraestructura de TI que signifique valor real para el negocio en términos financieros (para las organizaciones no lucrativas varía la unidad pero no el concepto de valor). www.softwareguru.com.mx

JUL-AGO 2005

EN PORTADA

A finales de la década pasada aparecieron los primeros Sistemas de Administración de Procesos de Negocio o BPMS (Business Process Management Systems) que permiten a las organizaciones mapear, integrar, liberar, medir, monitorizar, controlar, analizar y optimizar procesos de negocio de misión crítica que requieren ser integradas en una verdadera cadena de generación de valor para un cliente final y ligada directamente al logro de objetivos estratégicos. El objetivo de este artículo es dejar claro qué es un BPMS, qué podemos hacer con él, pero sobre todo, entender porqué es la plataforma de misión crítica para toda organización que pretenda sustentar el logro de sus objetivos y mantener sus ventajas competitivas en un ambiente complejo de cambios constantes[1].

Fundamentos

Considerando que los proveedores de software o sus representantes son especialistas en generar confusión alrededor de productos innovadores en el afán de venderlos, considero muy importante aclarar que la Dirección de Procesos de Negocio o BPM (Business Process Management) al igual que, por ejemplo, CRM (Customer Relationship Management), no son términos acotados únicamente a un paquete de software especializado ni tampoco es una meta que puede ser alcanzada en un cierto plazo ejecutando una serie de proyectos, es una manera de vida.

¿Qué es BPM?

BPM es toda una filosofía de trabajo que coloca al proceso de negocio al centro de su universo, es la manera moderna de administrar un negocio, donde su propósito es asegurar la mejora continua del desempeño organizacional en un ambiente de cambios constantes. Una empresa que practica BPM entiende y vive tanto la operación como el desarrollo organizacional en términos de procesos de negocio integral y naturalmente. Los procesos de negocio son las unidades de sincronización de cambios, de generación de valor para los clientes, y de logro de objetivos estratégicos, más adelante ahondaré al respecto en el bloque de pensamiento sistémico.

JUL-AGO 2005

En una organización hay tres tipos básicos de procesos de negocio. Los centrales son aquellos procesos cuyo cliente es el beneficiario de la oferta de valor de la organización: los clientes comercialmente hablando; los estratégicos son aquellos cuyo cliente es la organización como un todo, ya que el valor obtenido es mejor infraestructura organizacional en términos, por ejemplo, de mejores profesionales o mejores sistemas de información; finalmente los procesos de soporte son aquellos cuyo cliente es otro proceso de negocio, ya que el valor que recibe es una entrada necesaria para poder lograr su objetivo particular. Sin embargo, un cuarto tipo es el más importante en BPM. Los procesos de negocio empresariales o EBP (Enterprise Business Process) son los vitales, ya que corresponden a las grandes cadenas de generación de valor que involucran varias entidades internas y externas a la organización (atraviesan varios departamentos funcionales, requieren el uso de diversos sistemas y aplicaciones de software, involucran proveedores y muchas veces aliados de negocio) cuyo alto desempeño significa el logro de objetivos estratégicos. El BPMG[3] define a un EBP como: “la coordinación de lado a lado (a través de departamentos o inclusive fronteras organizacionales) de las actividades de trabajo que genera y entrega valor real a clientes”. El gran reto es desarrollar esta nueva capacidad que requiere, como primer paso, romper el paradigma del pensamiento funcional.

¿Qué es un BPMS?

Desde el punto de vista BPM, un BPMS es el principal facilitador para implantar un programa permanente de mejora continua en la práctica, ya que es imposible administrar sistemas tan complejos como lo son los procesos de negocio empresariales, simplemente, ¿cómo podríamos medirlos y monitorizarlos en tiempo real? Desde el punto de vista organizacional, un BPMS es el medio de organización, alineación y sincronización de las entidades (recursos) de negocio más importantes en un mismo sistema integral y coordinado: personas, reglas de negocio, datos, sistemas informáticos existen-

tes y aplicaciones de software (especialmente servicios) nuevas sin importar su ubicación ni alcance, ya que las personas pueden pertenecer a diferentes departamentos u organizaciones y estar en diferente piso o país, siempre que el BPMS esté basado en estándares. Desde el punto de vista técnico, un BPMS es una plataforma que permite integrar la infraestructura tecnológica existente en un ambiente Web que, a su vez, permite preservar los beneficios específicos de aplicaciones legadas. Al mismo tiempo, es un bloque de construcción esencial para un nuevo tipo de arquitectura aplicativa, basada en estándares y orientada a servicios (SOA). Soporta además procesos B2X (B2B, B2C, B2P, B2E, etc.) y permite a los diseñadores de aplicaciones construir soluciones orientadas a procesos de una manera muy rentable y efectiva. Desde el punto de vista del negocio, un BPMS es el medio que finalmente permitirá integrar Negocio y TI con un sentido estratégico, donde por un lado TI se enfoca al desarrollo de la infraestructura tecnológica centrada en procesos y arquitecturas aplicativas orientadas a servicios (SOA) y por otro lado le regresa el control del negocio al negocio: extrayendo las reglas de negocio implantadas mediante mecanismos internos a los sistemas o los manejadores de datos. Según Gartner, las tecnologías de información son el principal impedimento para la agilidad organizacional, ya que han sido enfocadas a la mejora de necesidades funcionales. Además, si consideramos que 80% de los requerimientos de cambio corresponden a reglas de negocio (también según Gartner), regresar el control significa manejar las reglas de negocio como parte integral de los procesos de negocio modelados y administrados dentro del BPMS de manera independiente a las aplicaciones de software.

La Importancia del Pensamiento Sistémico

Desde hace muchos años, W. Edward Deming, el padre del movimiento de la calidad, puntualizó que el problema es el “sistema”. Los procesos de negocio empresariales que atraviesan las organizaciones funcionales de www.softwareguru.com.mx

Figura 1. Infraestructura de Software de Misión de Crítica

lado a lado son sistemas dinámicos, pero desafortunadamente los profesionales que dirigen y ejecutan los procesos generalmente no están entrenados en el pensamiento sistémico. Lo común es que su perspectiva esté restringida a prácticas de negocio de muy bajo nivel de abstracción (procedimientos muy específicos y rígidos), realmente pocos profesionales tienen una perspectiva amplia de su contexto más amplio dentro de la organización. Hoy día es evidente que conforme avanza el tiempo tanto el entorno como el interior de las empresas se van volviendo más complejos y de hecho la tendencia es hacia ambientes cuya dinámica será progresivamente más compleja. Afortunadamente ya tenemos la respuesta a la interrogante: ¿cómo hacerle? Precisamente el manejo de esta complejidad es el objetivo del pensamiento sistémico. Este se enfoca en el todo, no en las partes, de un sistema complejo. Se concentra en las interfaces y las fronteras de componentes, en sus conexiones y organización, hacia una búsqueda de sistemas holísticos que potencialmente generen resultados con mucho más impacto que el de la suma de sus partes. Cuando el pensamiento sistémico es dominado, podemos afirmar que el mayor obstáculo para construir organizaciones administradas por procesos ha sido sorteado, ya que cada proceso de negocio será entendido, ejecutado y administrado como un sistema completo. Es por esto que la competencia central más importante que debe tener una organización para aprovechar los beneficios de BPM es el pensamiento sistémico o “process thinking”. Los invito a hacer un ejercicio mental muy sencillo, dediquen unos 20 segundos a mirar con detenimiento a su alrededor y después unos 30 segundos más a elaborar una lista de los cinco elementos más relevantes que se les quedaron grabados considerando que nuestro objetivo es trasladarnos de un punto A hacia un punto B, seleccionados por ustedes en el entorno visible. Ahora traten de hacer lo mismo pero enfocados en toda la colonia o entorno mayor en el que se encuentren, planteando un trayecto más amplio. ¿La segunda lista tiene algún elemento? Ahora repitamos el ejercicio, pero esta vez imaginen que se han www.softwareguru.com.mx

subido a un helicóptero y se han elevado unos 50 metros sobre el punto donde hace un momento se encontraban, en este caso les propongo dos preguntas: ¿qué pueden ver si están a 50 metros de altura a un nivel todavía más amplio, digamos a nivel de la delegación, municipio o inclusive país en el que se encuentran? Desde esta perspectiva, ¿qué impacto relativo tienen en su vista los cinco elementos originales que teníamos a la mano a nivel del piso? El problema para las organizaciones tradicionales de pensamiento funcional es que el reto de acelerar la generación de cada vez más valor para sus clientes finales y al mismo tiempo disminuir costos está como a 1,000 metros de altura. El helicóptero es el BPMS, por eso son necesarios para una organización que quiera sobrevivir, crecer o destacar en un entorno de cambios constantes, pero no hay que perder de vista que no es suficiente, no por subirnos al helicóptero ya resolvimos el problema, simplemente estamos en condiciones de aspirar a ello con mucho mayor probabilidad, ya que en el fondo un BPMS sólo es una herramienta muy poderosa que debe ser utilizada correctamente para poder obtener todos sus potenciales beneficios que a continuación abordaré. El otro elemento clave es el piloto del helicóptero, es decir, el pensamiento sistémico.

Plataforma de Software Centrada en Procesos

La plataforma de misión crítica predominante durante ya varios años son los RDBMS, con los cuales administramos el ciclo de vida completo de datos de negocio, establecemos y mantenemos las relaciones y estructura de los datos de negocio, controlamos el acceso y modificación de los datos de negocio en función a privilegios, hacemos consultas en función a criterios que se aplican al repositorio de datos

de negocio, entre otras capacidades. Si sustituimos la palabra “datos” por “procesos”, estaremos hablando de un BPMS. Por cierto, el fundamento del éxito de los RDBMS es ni más ni menos que las matemáticas, el álgebra relacional como la base de los motores relacionales. Para el caso de los BPMS su éxito tiene el mismo nivel de sustento en la misma ciencia, sólo que en este caso es teoría de procesos como la base de los motores de procesos, que es el corazón de un BPMS.

RDBMS vs. BPMS

En el caso de la plataforma de misión crítica del pasado (para muchos todavía el presente), los sistemas informáticos son las entidades que llevan el control de las actividades y en general determinan el cuándo, el cómo, y el quién hará uso de los servicios del DBMS. En el caso de la nueva plataforma de misión crítica del presente y del futuro, los procesos de negocio en sí mismos son las unidades de negocio que llevan el control de la ejecución y en general determinan cuándo, cómo, y quién hará uso de los servicios del BPMS (ver Figura 1). En el fondo, lo que estamos consiguiendo es contar con una plataforma de mayor nivel de abstracción y por lo tanto de mucho mayor impacto y visibilidad a nivel negocio. Es por esto que muchos consideran a los BPMS como una herramienta más orientada al negocio que a TI. De hecho, Delphi Group, en sus reportes anuales acerca del estado y tendencias en el mercado de software BPM a nivel mundial, ha confirmado en más de una ocasión, que dos de cada tres decisiones positivas para adquirir un BPMS son realizadas por algún ejecutivo de negocio ajeno al departamento de TI. Esta percepción es muy simplista, superficial y errónea. Como ya lo he dicho, debemos romper JUL-AGO 2005

EN PORTADA estándares como el Xf-XML del WFMC[4] en combinación con el XPDL del mismo WFMC o el WS-BPEL de OASIS[5] hacen posible la colaboración entre instancias bajo esquemas de seguridad confiables y donde inclusive cada parte podría tener un BPMS distinto (ver Figura 1).

Infraestructura de Software Empresarial Centrada en Procesos

Figura 2. Administración de Procesos de Software Orquestados

el paradigma tradicional del pensamiento funcional que ha mantenido separados a los departamentos de las empresas, especialmente a Negocio y TI, cuando debemos entender que TI es una parte fundamental (subsistema) del negocio (sistema). De hecho, con la inclusión de un BPMS en la arquitectura de TI estamos logrando que por fin la aportación de TI al negocio sea visible a todo lo largo de las cadenas de generación de valor medible en términos financieros y alineables a objetivos de negocio. Por si fuera poco, incrementa la visibilidad del valor generado por cada uno de equipos de trabajo que ejecutan procesos, fortaleciendo el entendimiento, la comunicación y su aportación al logro de la estrategia organizacional.

Dimensiones de un BPMS

El motor de procesos (corazón de un BPMS) es representado por un cubo, donde la cara superior representa la dimensión correspondiente a la capacidad central de orquestación de procesos de negocio, la cara izquierda representa la dimensión correspondiente a la integración tecnológica realizada hacia el interior de la organización, y la cara derecha representa la dimensión correspondiente a la colaboración con entidades externas a la organización. La orquestación de procesos de negocio es la capacidad de coordinar la ejecución de cadenas de generación de valor al grado de llegar a conseguir una armonía sistémica orientada

a la optimización del uso de recursos y generación de resultados tangibles para un cliente final común en el menor tiempo y costo posibles. Los elementos primarios que son coordinados son los flujos de tareas, reglas de negocio, roles de negocio (responsabilidades definidas en tiempo de diseño), y personas (usuarios en tiempo de ejecución a través de su mapeo a roles de negocio). La integración tecnológica orientada a procesos es la capacidad de integrar sistemas existentes, aplicaciones nuevas, datos de negocio, directorios y archivos al nivel de abstracción del proceso de negocio en el que participan, es decir, al nivel de la cadena de generación de valor a la que pertenecen. Una ventaja muy relevante es que las aplicaciones quedan desacopladas entre sí, es decir, ya no se comunican directamente con el enfoque tradicional de integración de aplicaciones punto a punto, lo que simplifica enormemente el desarrollo y mantenimiento de software con valor real para el negocio y por lo tanto sus costos asociados son minimizados, de hecho, esta es la base conceptual de SOA. La dimensión de colaboración representa la capacidad organizacional para ser parte integral de cadenas de generación de valor más amplias donde nuestros procesos de negocio empresariales pasan a ser subprocesos de procesos de negocio intercompañía con un potencial mucho mayor. La disponibilidad de

El beneficio directo de un BPMS es que permite asegurar la mejora continua del desempeño del propio proceso de dirección de procesos de negocio. Es decir, un BPMS permite aterrizar la filosofía BPM como un proceso estratégico cuyo resultado de valor son procesos de negocio de alto desempeño, donde el cliente es la organización como un todo. Al ver BPM como un proceso podemos administrar su ciclo de vida completo con el soporte de la nueva plataforma de misión crítica (ver Figura 2). El Business Process Management Group[3] (BPMG) ha establecido que BPM es “el enfoque deliberado y colaborativo para manejar sistemáticamente todos los procesos de negocio de una organización” donde sus dos facilitadores fundamentales son el pensamiento sistémico y las tecnologías de información centradas en procesos. Este mismo consorcio ha puntualizado los dieciséis grandes retos que enfrentan las empresas en la actualidad (para sobrevivir, crecer o destacar en un mundo complejo donde lo único constante y seguro son los cambios[1]) durante el proceso de adopción de BPM y en trece de ellos el BPMS es la pieza fundamental para soportar el desarrollo y mejora continua de las capacidades organizacionales requeridas para afrontar estos retos con éxito. Especialmente es destacada su aportación directa para el desarrollo de las capacidades “agilidad” y “adaptación”. Referencias 1. Roberto Silva, “Negocios Ágiles”. Impulsare e-zine. www.impulsare.com 2. Howard Smith and Peter Fingar, Business Process Management: The Third Wave, MeghanKniffer Press, 1st Edition 2003. 3. The Business Process Management Group, In Search of BPM Excellence: Straight from Thought Leaders, Meghan-Kniffer Press, 2005. 4. WFMC: The Workflow Management Coalition www.wfmc.org 5. OASIS. www.oasis-open.org

Roberto Silva es Socio Fundador de Impulsare, empresa dedicada a la educación y consultoría en integración de negocios. Es Director de Horbis, enfocada exclusivamente al diseño e implantación de soluciones de integración de cadenas de valor centradas en procesos. Tiene nueve años de experiencia como empresario y catorce años como consultor en el desarrollo e integración de sistemas de negocio y software para diversos sectores en México y América Latina. Es Consultor Asociado de la Fundación Mexicana para la Innovación Gubernamental y Empresarial y miembro activo del Business Process Management Group.

JUL-AGO 2005

www.softwareguru.com.mx

Por más de 15 años me he dedicado al desarrollo de sistemas con lenguajes de programación estructurado, no estructurados, y orientados a objetos. Estos siempre habían sido mis herramientas de trabajo en la programación para automatizar procesos. A continuación les presento mi experiencia realizando este mismo trabajo bajo un nuevo paradigma.

BPM

Desde la Perspectiva de un Desarrollador Por Ernesto Méndez Solís

www.softwareguru.com.mx

JUL-AGO 2005

EN PORTADA

Como consultor en el desarrollo de software, es muy común ser asignado a proyectos en los que participan consultores de otras empresas formando de esta manera equipos de trabajo interdisciplinarios y multiempresa; unos se encargan de la administración y metodología del proyecto, otros más del análisis, diseño, modelación, desarrollo, documentación y pruebas, por mencionar solo algunas de las diferentes tareas involucradas. Fue de esta manera que fui asignado a participar en un proyecto en el que había que automatizar el flujo de un proceso administrativo de una empresa dedicada a la comercialización, industria perteneciente al sector conocido como retail. Así que me integré al equipo, que estaba conformado por tres diferentes empresas y fui asignado a la fase de desarrollo. Solo requería tener conocimientos básicos de programación orientada a objetos y experiencia en el análisis, diseño y desarrollo de sistemas. La herramienta que se iba a utilizar para este desarrollo se llamaba Fuego. En mi vida había oído hablar de esta herramienta, por supuesto que no se requería experiencia, se dedicaría un periodo inicial para capacitar a los desarrolladores antes de iniciar formalmente el proyecto. Así fue como conocí el concepto BPM. Fuego, es mas que una herramienta de desarrollo, es un ambiente de trabajo. Este ambiente de trabajo, se puede dividir a su vez en dos: el ambiente de producción y el ambiente de desarrollo y configuración. Estos están basados en aplicaciones comunes a los ambientes de sistemas: navegadores, servidores web, servidores de bases de datos y servicios de directorio, por mencionar algunos. Algunas aplicaciones propias de Fuego complementan el ambiente de producción y desarrollo: motor de orquestación, portal de trabajo, administrador de componentes, administrador de la organización, diseñador de procesos, consola de ejecución y el analizador de procesos. Aunque pudieran parecer una gran cantidad de aplicaciones, realmente no es tan complicado preparar el ambiente de operación y desarrollo, inclusive el de desarrollo se puede preparar en un solo equipo para poder trabajar en forma independiente y aislada para posteriormente poder desplegar el proceso en el ambiente de producción. Recuerdo que en alguna ocasión me tocó programar aplicaciones del tipo “flujo de trabajo”

utilizando lenguajes de programación convencionales. Esto representó un reto algo diferente al de cualquier otro tipo de desarrollo, pero nada que impidiera alcanzar finalmente el éxito y la automatización del proceso correspondiente. Sin embargo, los BPMS están específicamente diseñados para automatizar en forma sencilla este tipo de procesos. La clave del éxito de este tipo de ambientes de desarrollo es el denominado “diseñador de procesos”, la herramienta central del BPMS. Al mismo tiempo, representa el mayor de los retos que los programadores de lenguajes tradicionales enfrentan al pretender automatizar un proceso. En este caso, la clave es “modelar el proceso” tal como se desarrolla en la práctica; lo que implica primero, identificar los diferentes pasos que el proceso incluye para posteriormente, apoyado en una serie de íconos para el modelado, representarlo gráficamente en el diseñador, considerando los participantes en el proceso y los conectores que comunican las actividades o pasos. Aunque esta representación gráfica del proceso esta diseñada para que cualquier analista de negocio e inclusive ejecutivo participante del proceso lo pueda entender, la construcción o modelado del proceso requiere de un nivel de abstracción adicional al requerido simplemente para su entendimiento. Un elemento fundamental a considerar al momento de modelar es lo que se denomina una “instancia”. Las instancias son las ejecuciones individuales de un proceso. Cada vez que se inicia un proceso, se crea una instancia y el sistema mantendrá un estricto control de ésta mientras fluye por cada una de las actividades hasta llegar al punto final. Paralelamente, el sistema almacena la información de la instancia en la base de datos para poder conocer el detalle particular de su flujo, en función de la actividad particular en la que se encuentre. Todavía hay un par de factores más a considerar en el modelado de un proceso: la transformación o característica que agrega cada una de las actividades a la instancia y la descomposición de una instancia en dos o más partes para poder realizar procesos paralelos que permitan posteriormente la reintegración de la instancia en una actividad posterior. Considerar todos estos factores para poder modelar un proceso, resulta ser una tarea no muy fácil cuando no se tiene experiencia y se esta

acostumbrado al proceso tradicional de desarrollo de aplicaciones. Por instinto uno quiere aplicar sus conocimientos de programación al modelado de procesos, lo cual solo crea gran frustración y largas horas de reproceso. Desde mi punto de vista, esto requiere de un cambio de paradigma en el proceso de conceptualización y análisis cuando se utilizan herramientas BPMS. Para contextualizar, equivale al cambio de paradigma que los programadores de la vieja guardia tuvimos que hacer cuando pasamos de la programación estructurada a la programación orientada a objetos. Se dice en forma muy sencilla, pero este cambio de paradigma resulta bastante difícil de realizar. Sin embargo, cuando una persona que aprende a programar, lo hace inicialmente bajo el paradigma de objetos, se le facilita ya que no está acostumbrada a un paradigma alterno. Lo mismo aplica en el caso de los BPM, los consultores que normalmente no realizan las tareas de análisis, diseño y codificación de sistemas, se les facilita un poco más el entender el concepto de modelado de procesos. Una vez superada esta primera fase del proceso, la modelación, sigue la fase con la que los programadores estamos más familiarizados, la codificación. Cada una de las actividades modeladas, lleva intrínsicamente una cierta funcionalidad, la cual es posible expandir utilizando un lenguaje script, fácil de usar y que permite configurar las actividades a la necesidad particular del negocio. Algunas de las características comunes de configurar en las actividades son por ejemplo: el tiempo máximo que puede permanecer una instancia en la actividad, y el manejo de excepciones y envío de notificaciones a otros integrantes del proceso entre las más importantes. Con el lenguaje script se puede conseguir funcionalidad adicional como: presentación de mensajes en pantalla, acceso a la base de datos, manejo de variables, expresiones condicionales, bucles y manejo de sentencias de entrada para obtener información de parte del operador. Cuando la funcionalidad requerida en cualquiera de las actividades va mucho mas allá de lo que se puede lograr con el lenguaje script, se puede desarrollar un componente que posteriormente se puede mandar ejecutar desde cualquier actividad. Los componentes permiten realizar formatos de captura de in-

El Ing. Ernesto Méndez Solís es consultor independiente especializado en administración y liderazgo de proyectos de desarrollo de software. Ha trabajado para varias empresas relacionadas con el desarrollo de software como: Siga Desarrollos, Arthur Andersen e Interfaces. emendezsolis@infosel.net.mx

JUL-AGO 2005

www.softwareguru.com.mx

formación mucho más complicados en forma relativamente sencilla para solicitar información al operador e ir automatizando el proceso según sus requerimientos particulares. Otra característica interesante que se puede obtener de los componentes es la posibilidad de interactuar con otros sistemas para intercambiar información o lanzar procedimientos externos para conseguir automatizar en mayor medida el proceso. Por ejemplo, se puede capturar información desde una de estas pantallas (incluyendo sus procesos de validación) y posteriormente ejecutar un sistema “legacy” el cual requiere de la información recién capturada, la que le es enviada de forma transparente. Este tipo de actividades, consiguen que los operadores o participantes del proceso, interactúen con un solo sistema sin necesidad de tener que usar diferentes aplicaciones e interfaces para conseguir cerrar el flujo del proceso. Esta característica es una de las más poderosas que se pueden obtener de un BPM y que precisamente cumple con el objetivo fundamental de este tipo de sistemas: la administración de los procesos de negocio.

Antes de realizar el proceso de despliegue en producción, la herramienta permite realizar tareas de depuración para poder ir siguiendo el flujo de una instancia e ir evaluando las diferentes variables que intervienen en el proceso, facilitando sustancialmente la liberación de procesos libres de errores. Cuando pudiera parecer que la automatización del proceso ha terminado, ésta solo ha iniciado en realidad. Cuando un proceso esta en producción, la fase más importante es precisamente la de evaluación para entonces detectar mejoras, cuellos de botella y la justificación de reingenierías de proceso.

poco susceptibles de poder ser mejorados en función de la experiencia y que normalmente se quedan cortos en cuanto al alcance inicialmente programado.

El ambiente colaborativo bajo el que operan este tipo de desarrollos, intranets y/o extranets, ofrece interfaces nítidas y claras para todos los involucrados, fáciles de operar y con una curva de aprendizaje muy corta que permite en muy poco tiempo poder administrar eficientemente los procesos. Desarrollar una aplicación que permita realizar todas estas tareas y controles utilizando lenguajes de programación tradicionales resulta en proyectos muy costosos, de muy difícil mantenimiento,

Conclusión

Los ambientes de desarrollo y producción de los sistemas BPM ofrecen una extraordinaria alternativa para la automatización y mejora de procesos, se convierten en herramientas de vital importancia en la operación de las empresas ya que permiten adecuar y adaptar los procesos en forma rápida a los dinámicos cambios del medio ambiente de negocios que vivimos hoy en día. El esfuerzo requerido para establecer un BPMS, la capacitación de consultores para la automatización de procesos, así como el cambio de paradigma que este tipo de herramientas exige a sus diseñadores y desarrolladores, bien vale la pena realizarlo ya que los resultados que se pueden obtener son sencillamente espectaculares y no se pueden obtener con ninguna otra herramienta disponible hoy en día en el mercado.

CASO DE ESTUDIO

El Camino a CMM® nivel 3 Active Intelligence Comparte su Experiencia Por Rafael Muñoz y Elizabeth Almeraz

En tiempos donde los márgenes canas con recursos económicos limitados, convencimiento y entusiasmo del personal de utilidad se ven amenazados tomen la decisión de marcar una diferencia y los procesos enfocados y adaptados a la cada día mas y la competencia en la manera en como se construye software forma de trabajar de Active Intelligence. contra proveedores mundiales de en México, contribuyendo a poner a todo el software se ha convertido en una país en el mapa para los mercados globales. La historia guerra de precios interminable, Active Intelligence nació en Aguascalientes, fundada y dirigida por Humberto Sánchez Active Intelligence, una compa- ¿Cómo se logró? ñía con 50 integrantes y un año Sin duda el esfuerzo bien enfocado detrás Sandoval y Abraham Ramírez Basurto; el de historia, consigue el reconoci- de cualquier iniciativa es la clave para obte- objetivo organizacional es la proveeduría de miento de nivel 3 basados en el ner los resultados esperados. Este caso no servicios de exportación de segunda capa es la excepción, sin embargo, vale la pena en modalidad de fábrica de software y tiene modelo SW-CMM® La historia de Active Intelligence es una historia que vale la pena contar, pues muestra como al enfocar el esfuerzo en lo que es importante, los resultados que se pueden obtener son muy buenos, además pone el dedo en el renglón para que más compañías mexi-

desmenuzar un poco la estrategia y características que se juntaron para que la meta fuera posible. Especialmente es importante remarcar la importancia en tres factores críticos que permitieron que la adopción de un modelo de procesos, se hiciera en un tiempo récord: El apoyo de la dirección, la actitud,

como principal objetivo el ofrecer desarrollo de soluciones de software a distancia. El Ing. Sánchez, cofundador en 1988 de Ddemesis (que fue reconocida como nivel 3 de SW-CMM® en 2001) aprovechó un momento extraordinario en el mercado de exportación de TI desde Aguascalientes. En 2003 Ddeme-

Rafael Muñoz es egresado de la carrera de Matemáticas Aplicadas y Computación de la UNAM. Actualmente es líder de Active Intelligence y tiene a su cargo las iniciativas de calidad de esta empresa. Él y su equipo se encuentran actualmente trabajando en la implementación del modelo CMMi en esta compañía. Ha trabajado en el área de TI por más de diez años, liderando proyectos para grandes compañías nacionales e internacionales.

JUL-AGO 2005

www.softwareguru.com.mx

Se buscó el apoyo del Gobierno Federal mediante el programa ProSoft y se recibieron ayudas económicas para formación de personal. sis fue vendida, ocasionando un movimiento importante de profesionales buscando nuevas opciones laborales, en ese momento de cambios Active Intelligence surgió como una opción interesante para ellos. Active Intelligence tuvo la visión de buscar colaboradores con experiencia en la implementación de procesos, Six Sigma y SW-CMM®, además de las habilidades de tecnología que el mercado requería, como .NET, que es la principal herramienta tecnológica utilizada. Adicionalmente pudo conformar un equipo con mucha energía a través de una vinculación importante y selectiva con las Universidades de Aguascalientes; de este modo se formó el equipo de trabajo que actualmente figura entre las filas de la compañía.

La visión Los beneficios en prestigio y participación de mercado, que traería la adopción del modelo siempre fueron un motivador importante de la compañía, sin embargo, existe también en la operación y gerencia, un compromiso pleno con la calidad y la capacidad de entregar productos que satisfagan las necesidades de los clientes, motivándolos a seguir invirtiendo en tecnologías de información. Esta visión de las direcciones general y de operaciones, ha sido clave en el logro de las metas trazadas, pues el compromiso no es solamente de un equipo, si no de la organización completa.

El desarrollo del programa de mejora Basados en esta visión, se inició el programa de mejora como un proyecto cuyo objetivo era definir e implantar procesos basados en el modelo SW-CMM® hasta el nivel 3; sin embargo, no se contaba con recursos específicos para conseguirlo y mucho menos se pensaba en considerar consultoría externa para apoyar la definición e implantación de procesos. El equipo original asignado fue formado por dos personas, el primero con experiencia en este tipo de procesos y convencido de los beneficios que se obtendrían no sólo a nivel de cada proyecto sino a nivel organizacional, mientras el segundo, era una persona sin experiencia, ni entrenamiento en el modelo, mucho menos en procesos y estándares mundiales, pero eso sí con muchas ganas de aprender y a mejorar el trabajo de la empresa. Así, con muchas desventajas, vio la luz el programa de mejora en Active Intelligence y se bautizó como AMM (Active Maturity Model). El camino se veía complicado. www.softwareguru.com.mx

Después del entrenamiento interno inicial, se planeó la forma en que la meta se cubriría. Se iniciaron las actividades de definición y se preparó el entrenamiento para los colaboradores. Este primer paso fue difícil, pues los procesos no fueron muy bien recibidos desde el inicio, había muchas dudas, los proyectos que lo implantarían ya tenían otra forma de trabajo, la implantación implicaba tareas extras en los planes de proyecto ya comprometidos, por lo que solo se veían dificultades en la implantación, sin mucho que obtener a cambio. Estábamos atorados.

formar parte del proyecto, con ellos se hicieron revisiones documentales a los procesos, verificación de la implantación en los proyectos, evaluaciones informales (simulando actividades de la evaluación formal) y formación práctica del grupo de SQA para ejecutar sus actividades (pieza clave para apoyar la implantación de las prácticas), todo esto ayudó a acelerar la adopción completa de la iniciativa, además que el grado de confianza en los procesos ya implantados se mejoró considerablemente. Ya estábamos listos.

La tormenta pasó, sin lugar a dudas el apoyo de la dirección fue pieza clave en la resolución de estos problemas, además del compromiso del equipo de implantación. Para incrementar la motivación y remarcar la importancia en el uso de los procesos, un requerimiento clave llegó, el requerimiento solicitaba el uso y conocimiento del modelo SW-CMM® y finalmente, el trabajo que ya se había hecho en este sentido, fue un factor decisivo para ganarlo. Los procesos son un valor agregado importante.

Mariana Pérez-Vargas, Directora General de Avantare, fue el Lead Assessor de la evaluación, se trabajó con ella, un consultor más de apoyo de Avantare y los miembros de Active Intelligence elegidos para formar parte del equipo de evaluación. El ambiente, aunque agradable, era de nerviosismo pues finalmente había muchas cosas que dependían de un resultado positivo en la evaluación CBA-IPI®, (CMM Based Appraisal for Internal Process Improvement) a pesar de esto, el equipo formado en su mayoría por gente muy joven, respondió como se esperaba a las exigencias del método de evaluación. Se aplicaron cuestionarios, se hicieron las entrevistas y las consolidaciones necesarias, hasta que llegó el momento de la puntuación final, una a una las fortalezas y oportunidades de mejora detectadas durante cada una de las revisiones y/o entrevistas, se fueron revisando y discutiendo entre todo el equipo, ya que las decisiones debían tomarse por consenso. Debíamos analizar si las oportunidades de mejora podían afectar de manera

La necesidad de robustecer los procesos con la ayuda de algún externo se hizo más palpable y entonces se buscó apoyo del Gobierno Federal mediante el programa ProSoft y se recibieron ayudas económicas para formación de personal por el Gobierno del Estado de Aguascalientes; se trabajó duro para conseguir una oportunidad real y por supuesto, los recursos requeridos. Al ser otorgados los recursos, la visión se amplió acorde a la nueva situación y el programa de calidad tenía nuevas y más retadoras metas. Los recursos permitieron tener acceso a la consultoría externa, y además la implantación no se quedaría solo en eso, pues se buscaría el reconocimiento formal del nivel 3. La compañía estaba entusiasmada.

La evaluación

Dada la buena experiencia en Ddemesis y su reconocida capacidad, Avantare fue elegida para JUL-AGO 2005

CASO DE ESTUDIO

significativa a las metas relacionadas ... y así una a una, cada meta se alcanzó, dando como resultado alcanzar el nivel de madurez 3 de SW CMM®.Todo el esfuerzo invertido, se redujo a una alegría y satisfacción que difícilmente se pueden describir. Hoy día la evaluación quedó atrás, y lo mas importante es que hay un cambio en la cultura organizacional. El entusiasmo en las revisiones es igual al que se notaba antes de la evaluación, el interés de los colaboradores en los procesos y en la mejora continua de las herramientas que se han definido sigue ahí y va en aumento. Después del resultado, más personas están interesadas en formar parte del equipo de calidad y más gente aprecia el trabajo que esta área realiza. Se confirma una frase que por méritos propios se ha convertido en el lema del programa de mejora: “AMM es el ADN de nuestra compañía”. Las metas de este año tienen que ver con el cambio de modelo (CMMi®) y el crecimiento de nivel, el equipo está nuevamente organizado y trabajando como el año anterior con una nueva meta en la mente, buscando nuevas formas de mejorar y aprovechar la experiencia ganada con el primer paso. El compromiso de la organización está no solo con sus clientes, si no también con todos aquellos que de alguna forma colaboraron al logro de la meta que empezó como un sueño y que ahora puede servir como muestra de que cuando se reúne al equipo adecuado, un asesor experimentado, una idea clara llevada a un proyecto viable, y un programa inteligente de apoyo a la industria, los resultados pueden ser “de clase mundial”. Active Intelligence ya exporta el 68% de sus Servicios.

Algunas reflexiones que vale la pena compartir Sin lugar a dudas el caso de Active Intelligence es un ejemplo a seguir por muchas

otras empresas que están poniendo la mira en el establecimiento de un programa de mejora, sea cual sea, el modelo de referencia a seguir. Sin embargo, ahora que Rafael les ha contado la historia y evolución de la implantación de SW CMM en Active Intelligence, a mi me gustaría compartirles algunos factores, desde el punto de vista de Avantare y como consultor en programas de mejora, que me parece importante enfatizar ya que marcaron la diferencia entre un “buen deseo” y “un realidad que da frutos y beneficios” y que pueden ayudar a otras Organizaciones en el establecimiento de su programa de mejora. Así pues los factores críticos de éxito, en el caso de Active Intelligence, que quisiera compartirles fueron: 1. El compromiso directivo. Sin este compromiso y el convencimiento tanto del Ing. Humberto Sánchez como del Ing. Abraham Ramírez (el director de operaciones), de que los procesos rendirían frutos, cualquier esfuerzo por establecer mejores formas de trabajo se quedan en el tintero. 2. Procesos adecuados a la empresa y la forma de trabajo. Es fundamental establecer procesos “a la medida” de las organizaciones, sobre todo cuando se trata de organizaciones pequeñas, donde si bien es vital el establecimiento de procesos, también es vital que éstos sean ágiles para soportar el desempeño y operación que una PyME necesita. En Active Intelligence, el grupo de mejora buscó ante todo, que los procesos fueran funcionales para el trabajo diario de los proyectos. Esto representó no sólo un reto para el grupo de implantación, sino también para Avantare como consultor, pues hubo que buscar soluciones innovadoras que permitieran cumplir con las exigencias del modelo, sin sobrecargar a la operación.

3. Una cultura Organizacional de procesos. La primera vez que como Avantare realizamos revisiones presenciales en Active Intelligence, se notaba que la gente había visto buenos resultados al aplicar los procesos, lo cual hacía que fueran muy abiertos para realizar las acciones de mejora solicitadas, e incluso en proponer ellos mismos mejoras. Cuando la gente está convencida de los beneficios que los procesos le traen en su trabajo diario, aporta para que estos procesos se mejoren logrando una sinergia real entre los procesos, la gente y la productividad. Es entonces cuando vemos que la mejora continua “se vive” y no sólo “está escrita”. No hay cosa mas linda que una mejora continua viva. Cuando esto se ha logrado, el consultor está mas seguro de que sus recomendaciones caerán en tierra fértil y el progreso se notará a pasos agigantados. 4. La visión a largo plazo. Es de vital importancia lograr el compromiso a largo plazo, no buscar sólo la obtención de un cierto nivel de madurez, el reconocimiento público, o bien los ahorros inmediatos, sino estar comprometidos con la calidad de los servicios y los productos que se ofrecen. Sin duda Active Intelligence, estuvo muy consciente de que al establecer un programa de mejora, estaba invirtiendo no para las recompensas inmediatas, sino para aquéllas que vendrían después, mas allá de la evaluación, manteniéndose inmersos en un proceso de mejora que les exigiría cada vez más de ellos mismos. 5. El trabajo en equipo. Este fue sin duda un factor clave para el éxito del programa de mejora de Active Intelligence, donde todo el personal, de alguna u otra manera participó en la definición, revisión, asesoría y evaluación de los procesos del programa de mejora. Cada uno sabe que su participación es importante, y que es un proyecto importante que los involucra a todos y cada uno de ellos. Realmente hubo un equipo entre Avantare y Active Intelligence.

Siempre hay nuevos retos que cumplir, siempre hay niveles, marcas y records que lograr. Cuando se conjunta el liderazgo, el equipo, la motivación y los fondos adecuados, los resultados suelen ser increíbles.

Elizabeth Almeraz es pionera en México en la realización de actividades de Aseguramiento de Calidad del Software (SQA), participando en el primer grupo de SQA que ayudó a lograr una evaluación CMM en México. Actualmente es consultor de Avantare y especialista en las áreas de técnicas de veriﬁcación de productos de software y mejora de procesos para la industria de TI.

JUL-AGO 2005

www.softwareguru.com.mx

PRÁCTICAS ADMINISTRACIÓN DE PROYECTOS

MÉTRICAS DE TAMAÑO DE SW BASADAS EN FUNCIONALIDAD Parte 2: Análisis de Puntos Función

n el número anterior hablamos sobre la importancia de contar con una métrica funcional estándar para determinar el tamaño de un sistema de software. Los Puntos Función o Function Points (FPs) son una excelente herramienta para este propósito.

La Métrica de Puntos Función Esta métrica se define como una métrica funcional, dado que se enfoca a la funcionalidad que un producto de software proporciona a sus usuarios. “Es una métrica para establecer el tamaño y complejidad de los sistemas informáticos basada en la cantidad de funcionalidad requerida y entregada a los usuarios”. Partamos de esta definición para entender las características de la métrica: Tamaño.– Es una métrica de tamaño, no de la calidad con la que se hizo ese SW, o del valor de ese producto, o del esfuerzo requerido para desarrollarlo, etc. Aplicaciones.– Mide las aplicaciones de SW, no considera el HW que utilizará, ni la administración del proyecto, ni la documentación, etc. Funcionalidad.– Se refiere a la capacidad del SW para que un usuario pueda realizar transacciones (lectura, escritura, etc.) y guardar datos. Si analizamos a detalle, con estos elementos podemos describir cualquier sistema. Usuario.– Quien lo va a usar y no quien lo desarrolló o quien lo diseñó. Así como existe el metro lineal para medir longitudes, Puntos Función es “el metro” para medir tamaño de una aplicación de software.

Estándar Internacional ISO La medición de la funcionalidad con la que cuenta un sistema informático ha sido desde hace años una preocupación de la industria. No es suficiente contar con una métrica, sino que sea estándar, para así poderla usar a nivel industria. Poder comparar la productividad (Puntos Función por Persona Mes) de una empresa con los datos de la indus-

Por Sergio Durán

tria, es fundamental en los planes de mejora. Es por eso que a través de la International Organization for Standardization (ISO) se ha desarrollado un estándar internacional: ISO/IEC 14143 – Information Technology – Software Measurement – Functional Size Measurement. Este estándar define los conceptos de una métrica de tamaño basada en la funcionalidad y las características que debe cumplir un método para estar homologado al estándar y ser considerado una medida del tamaño de la funcionalidad. Existen varios métodos de conteo para establecer la cantidad de Puntos Función que tiene una aplicación. En general, todos establecen un conteo basado en la identificación del tipo de funciones que tiene la aplicación, y a cada una le asocia un número de puntos tomando en cuenta su complejidad. Las variantes surgen al buscar conteos más precisos en Puntos Función conforme al tipo de aplicación. Por ejemplo, un sistema en tiempo real tiene una complejidad muy distinta a un sistema tradicional de negocio o a un sistema operativo o a una aplicación científica que realiza muchos cálculos pero el resultado puede ser un solo dato. Estos son algunos de los métodos homologados con el ISO 14143: ISO/IEC 20926:2003 - Software engineering - IFPUG 4.1 Unadjusted functional size measurement method. Este método ha sido definido por el International Function Point Users Group (IFPUG) y evolucionado a partir de la propuesta original de Allan Albrecht en IBM, por lo que es el más conocido y más

Sergio Eduardo Durán Rubio se desempeña como Director de Proyectos en certum. En 1996 se convirtió en el primer especialista de América Latina certificado por el International Function Point Users Group en Conteo de Puntos Función, y en miembro representante de México ante la ISO/IEC JTC1/SC7. Sergio es Ingeniero en Sistemas Computacionales de la UDLA-P, Maestro en Tecnologías de Información y Administración del ITAM y Mastère Spécialisé en Réseaux Et Systèmes D ‘information pour Les Entreprises de la ENST de Bretagne France.

JUL-AGO 2005

www.softwareguru.com.mx

Puntos función está orientado a medir sistemas de información completos. utilizado. Esto es muy importante porque se está convirtiendo en el estándar de facto en la industria. ISO/IEC 20968:2002 - Software engineering - Mk II Function Point Analysis. Este método ha sido desarrollado por la United Kingdom Software Metrics Association, simplificando el método y haciéndolo compatible con ideas de análisis y diseño estructurado. ISO/IEC 19761:2003 - Software engineering - COSMIC-FFP - A functional size measurement method. Este método ha sido definido por el Common Software Measurement International Consortium, integrado por expertos de Australia, Canadá, Finlandia, Alemania, Irlanda, Italia, Japón, Holanda y el Reino Unido. La idea principal es adecuarse mejor a la medición de sistemas en tiempo real.

Paso 1. Determinar el tipo de conteo. Este paso consiste en definir el tipo de conteo entre desarrollo, mantenimiento o de una aplicación ya instalada. Esta es una forma de determinar el objetivo del conteo. Paso 2. Identificar los alcances de la medición y los límites de la aplicación. El propósito de una medición consiste en dar una respuesta a un problema de negocio. El alcance de la medición define la funcionalidad que va a ser incluida en una medición específica y puede abarcar más de una aplicación.

El Método de Análisis de Puntos Función La versión actual de éste metodo es la 4.1.1, cuyo manual de prácticas de conteo se puede encontrar tanto en inglés como en español. El método de conteo se basa principalmente en la identificación de los componentes del sistema informático en términos de transacciones y grupos de datos lógicos que son relevantes para el usuario en su negocio. A cada uno de estos componentes les asigna un número de puntos por función basándose en el tipo de componente y su complejidad; y la sumatoria de esto nos da los puntos de función sin ajustar. El ajuste es un paso final basándose en las características generales de todo el sistema informático que se está contando. Veamos un poco más a detalle el procedimiento, para entender mejor los conceptos mencionados y conocer su simplicidad.

Procedimiento

Paso 3. Contar las funciones de datos. Este paso consiste en identificar y contar la capacidad de almacenamiento de los datos. Se distinguen dos tipos de funciones de datos: Archivo Lógico Interno.- Es un grupo de datos relacionados que el usuario identifica, cuyo propósito principal es almacenar datos mantenidos a través de alguna transacción que se está considerando en el conteo. Archivo de Interfaz Externo.- Es un grupo de datos relacionados y referenciados pero no mantenido por alguna transacción dentro del conteo. A cada componente identificado se le asigna una complejidad (baja, media o alta) considerando principalmente el número de datos. Paso 4. Contar las funciones transaccionales. Este paso consiste en identificar y contar la capacidad de realizar operaciones. Se distinguen tres tipos de funciones transaccionales:

www.softwareguru.com.mx

PRÁCTICAS ADMINISTRACIÓN DE PROYECTOS

Entrada Externa.– Es un proceso cuyo propósito principal es mantener uno o más archivos lógicos internos. Salida Externa.– Es un proceso cuyo propósito principal es presentar información al usuario mediante un proceso lógico diferente al de sólo recuperar los datos. Consulta Externa.– Es un proceso cuyo propósito principal es presentar información al usuario leída de uno o más grupos de datos.

En nuestro caso, Puntos Función está enfocado a medir sistemas informáticos completos, no programas. En este sentido no tiene un nivel de precisión suficiente para medir el tamaño de programas individuales. El nivel de granularidad que puede medir la métrica no es muy pequeño. Adicionalmente el término programa depende de la tecnología, y eso va en contra del criterio de que esta métrica es independiente de la tecnología que se use.

A cada componente identificado se le asigna una complejidad (baja, media o alta) considerando el número de datos utilizado en el proceso y los archivos referenciados.

Otro punto que se le ha criticado a las métricas funcionales es que requieren que alguien “identifique” la funcionalidad y “evalúe” la complejidad basándose en los criterios y reglas establecidas; no puedo hacer un programa que cuente automáticamente. Debido a esto, distintas personas podrían llegar a un conteo diferente. Para resolver esto, se han venido depurando las reglas de conteo para eliminar posibles ambigüedades y cada vez hay más material de apoyo con ejemplos. Aunado a lo anterior, hay esquemas de certificación como el del IFPUG, donde hay una evaluación formal de la teoría y casos prácticos. Estos elementos buscan reducir las posibles variaciones en un conteo hecho por diferentes personas. Si tomamos en cuenta que la métrica está pensada para contar proyectos o aplicaciones completas, entonces las pequeñas variaciones en un conteo, no van a ser significativas para los indicadores o datos relacionados que obtengamos.

Paso 5. Determinar los puntos de función no ajustados. Este paso consiste en sumar el número de componentes de cada tipo conforme a la complejidad asignada, y multiplicarlo por el factor indicado en la siguiente tabla para obtener el total.

EI EO EQ ILF EIF

Bajo

Medio

Alto

3 4 3 7 5

4 5 4 10 7

6 7 6 15 10

Paso 6. Determinar el valor del factor de ajuste. El factor de ajuste se obtiene sumando 0.65 a la sumatoria de los grados de influencia de las 14 características generales del sistema, multiplicado por 0.01. Dentro de las características hay criterios como: complejidad del proceso, facilidad de instalación, entrada de datos en línea, etc. Paso 7. Determinar los puntos función ajustados. Para determinar los puntos función ajustados se consideran los puntos función no ajustados por el factor de ajuste.

Cualquier Métrica tiene un Alcance Definido Cualquier métrica tiene un ámbito de acción y alcance definido que hay que entender para usarla correctamente. Así, por ejemplo, el metro lineal no es lo mejor para medir grandes distancias en el mar.

JUL-AGO 2005

Comprar SW por Puntos Función Las compras de SW son en muchos casos desarrollos a la medida. Pero ¿cómo comprar si todavía no se tiene el diseño? Una opción que habilita una métrica como Puntos Función es comprar por “metro” de SW a una empresa que tenga una productividad mínima establecida, conforme al tamaño de las aplicaciones que requiero. Ya durante el proyecto puedo ir solicitando esos Puntos Función que compré, en las aplicaciones que requiero. Por ejemplo, en el caso de Gobierno, la ley de adquisiciones permite hacer compras basadas en estándares internacionales, que como vimos, ya existen en este terreno. Adicionalmente, en el Programa para el Desarrollo de la Industria del Software de la Secretaría de Economía (ProSoft), hay un punto específico que ayudará en este tema: “Promover que se elaboren las normas necesarias para que se cumpla el Reglamento de la Ley de Adquisiciones, Arrendamientos

y Servicios del Sector Público en lo que se refiere a la existencia de normas nacionales o internacionales en las adquisiciones de software”. En mi opinión, el uso de métricas en los proyectos de SW va a empezar a cambiar en la medida que los compradores lo exijan. Es por eso muy importante que los compradores analicen que sólo comprar por precio sin distinguir tamaño de las aplicaciones para escoger a un proveedor que tenga experiencia con esa complejidad o indicadores como productividad o calidad, nos va a seguir llevando a las historias que hemos oído de grandes proyectos que no terminan a tiempo o que exceden por mucho el presupuesto o, en el peor de los casos, nunca llegan a operación. Se requiere un modelo que permita identificar capacidades de los proveedores, para entonces poder comparar propuestas de proveedores de capacidad similar. “Los proyectos nacionales en informática requieren de empresas con capacidades reales y funcionarios/ejecutivos competentes y exigentes”. Ya empieza a haber proyectos que, como parte de sus bases para invitar a proveedores, solicitan contar con métricas y con registros históricos que fundamenten los estimados en esfuerzo y tiempo, para tener mejor certeza en que el proyecto que están comprando va a llegar a buen término, a tiempo y en presupuesto. Próximamente empezaremos a ver los primeros resultados y alguno de estos casos de éxito será motivo de un siguiente artículo.

Referencias • IFPUG. “Manual para la Medición de Puntos Función”. Versión 4.1.1. 1999 • Alberto Balderas, Arnoldo Díaz. “Fábrica de software. Un modelo de negocio certificable basado en Estructura y Capacidades”. Soluciones Avanzadas. No. 59

www.softwareguru.com.mx

PRÁCTICAS PROCESOS

BPM APLICADO AL DESARROLLO DE SOFTWARE Por Axel Nissim

no de los errores más comunes dentro del entendimiento de BPM por parte de los desarrolladores de SW, es la creencia de que BPM se limita a una estrategia tecnológica. Es cierto que plataformas como J2EE nos proporcionan herramientas para implementar estrategias BPM, y también es cierto que existen varios BPMS “Out of the Box” que nos permiten modelar procesos de negocios, y llevar su seguimiento. Sin embargo, lo que es esencial entender es que BPM es una estrategia de negocios, no tecnológica, y que se sirve de la tecnología para alcanzar sus metas. BPM es el resultado de una tendencia mundial hacia la claridad y transparencia dentro de los procesos, aportando flexibilidad al mismo tiempo y acabando con los órdenes monolíticos dentro de los flujos de trabajo, que hacen imposible a la empresa adaptarse rápidamente a las condiciones eternamente cambiantes del mercado. En una empresa que gira en torno a la tecnología y al desarrollo de software, también existen procesos de negocio, flujos de trabajo que deberían estar definidos; materia difusa e intangible para la mayoría, y que sólo vive en la cabeza del arquitecto o del líder de proyecto. La mayoría de las personas que representan los roles en el desarrollo de SW, a pesar de su alta necesidad de conectividad, interacción y retroalimentación, hacen esfuerzos heroicos para adivinar exactamente cuál es el tipo de información

que se requerirá para los siguientes pasos del flujo de desarrollo, y a la vez, ruegan todos los días para que los artefactos que lleguen a sus manos, provenientes de fases anteriores, contengan toda la información necesaria. Claro, existen metodologías estructuradas, como RUP, que nos dicen lo que entra y lo que sale de cada una de las etapas de nuestro proyecto, pero de ninguna manera estas son soluciones definitivas a los problemas de flujo de trabajo, puesto que al final el proyecto mismo es quien decide la estrategia que se ha de tomar. A veces los artefactos escogidos no son los adecuados, los requerimientos no se estabilizan, o la gente se da cuenta de que “el sistema” no es la piedra angular, y que deberá adaptarse al negocio, sin importar si la metodología dice tal o cual cosa. También en el desarrollo de sistemas, los procesos de negocio deben de ser medibles, colaborativos, finitos (de manera indispensable), y eficientes. La implementación de CMM tiene como resultado la eficientización de los procesos, identificando las áreas clave, cuellos de botella, y a la vez atajando uno a uno los riesgos y minimizándolos. ¿Es esto una solución total? Si esto fuera cierto, pudiéramos pensar que los proyectos de TI fracasados son una historia de terror del pasado. Sin embargo, la triste y a la vez prometedora realidad, es que aún tenemos mucho trabajo

que hacer, y precisamente parte de este trabajo es el empleo de metodologías BPM dentro del desarrollo de software, y a la vez, el desarrollo de herramientas que nos permitan mapear, seguir de cerca y medir los procesos de desarrollo, así como comunicar y reutilizar el conocimiento generado dentro de éstos. Las metodologías actuales de flujo de trabajo para el desarrollo de software se centran en la documentación extensa y el modelado, siendo éste una extensión misma de la documentación. El modelo es el sistema, la documentación es el sistema y, por supuesto, el código es el sistema, en una representación que varía en su grado de granularidad de acuerdo a la fase en que nos encontremos. ¿En qué consiste una solución de BPM? La tecnología detrás de los sistemas BPM es el software que automatiza y hace más directos y eficientes los procesos. Típicamente, la solución incluye una herramienta gráfica de diseño y navegación de procesos, capacidades de simulación, software de integración y middleware, así como capacidades de monitoreo y reporteo de cada uno de los procesos. Los procesos del desarrollo de software comúnmente se definen a partir de los diferentes milestones o hitos a los que va llegando el proyecto, los cuales a su vez se definen a partir de los artefactos programados para

Axel Nissim es Director de entrempresarios.com, un portal y startup de Internet con la meta de desarrollar herramientas colaborativas basadas en el Social Networking. Axel es Licenciado en Sistemas Computacionales Administrativos por la Universidad de las Américas, y ha laborado como consultor en algoritmos para seguridad e inteligencia artificial. Actualmente trabaja de manera estratégica en la definición de metodologías y herramientas de workflow en megaproyectos basadas en redes sociales, planeando sacar al mercado el producto resultante.

JUL-AGO 2005

www.softwareguru.com.mx

El modelo es el sistema, la documentación es el sistema y, por supuesto, el código es el sistema. cada fase. La realidad es que en el desarrollo de software los procesos se entrelazan de maneras inesperadas, y muy al pesar de los metodólogos, aún dependen del heroísmo personal de los participantes del proyecto.

proyectos se basan en un enfoque jerarquizado que les permite mantener cierto control de la información, basado en la restricción de los roles y artefactos, sin tomar en cuenta las oportunidades y la eficiencia.

La visión centrada en artefactos y asociada a roles del RUP, es muy útil en el sentido de la estandarización de procesos, y como un checklist en base a los entregables que se deben de conseguir. Lo que el RUP no toma en cuenta es la interacción humana y el alto grado de entropía en los proyectos, donde los artefactos se transforman, cambian hasta sus raíces y finalmente son usados para propósitos diferentes a los de su concepción. Los encargados de la administración de los

La eficiencia de los procesos en el desarrollo de software queda incompleta aún implementándola dentro del marco de las mejores prácticas de desarrollo y hasta de procesos de negocio. Lo que se necesita es una solución más completa, y que sea capaz de armonizar los conceptos de BPM con las metodologías formales de desarrollo como XP o RUP, todo esto dentro de un marco de colaboración en capas, indistinto de organigramas y que permita aislar y atacar las oportunidades y siner-

gias no sólo en cuanto a los roles dentro de los procesos, sino en cuanto a las competencias de cada individuo, sus habilidades, intereses y hasta sus metas particulares. BPM es un esfuerzo encaminado a la flexibilidad y el tiempo de respuesta ante condiciones cambiantes. Las condiciones cambiantes en un megaproyecto de desarrollo son una realidad que va más allá del simple cambio de requerimientos, y que tienen que ver más con la falta de unificación de criterios de negocio que nos permiten conocer las necesidades reales de los clientes externos (los compradores del sistema) y nuestros clientes internos (las personas trabajando en otros módulos o fases del desarrollo del sistema).

PRÁCTICAS PROCESOS

La comunicación es, por mucho, el activo más valioso dentro del desarrollo de software ¿Qué pasa si a la mitad del análisis nos damos cuenta que uno de los artefactos simplemente no tiene relevancia de acuerdo al problema atacado? ¿Quién se da cuenta de esto? Obviamente no es el arquitecto, ni el líder de proyecto, ambos encerrados en sus actividades de control. ¿Qué uso se le da a la información que no generó utilidad inmediata o esperada? Los verdaderos poseedores de la información y los que perciben de manera instantánea sus incongruencias son los que trabajan directamente con ella: analistas, programadores, testers y demás, por tanto en ellos debe de recaer —de manera colectiva— el mantenimiento de una base de conocimientos común que permita el intercambio sin fronteras de la información hacia adentro. El mantenimiento de los vínculos para la fluidez de esta información, es responsabilidad de los arquitectos, administradores de la configuración, y en última instancia del líder de proyecto, que además debe facilitar estos mismos vínculos a los “stakeholders”, usuarios y consultores de negocio de los proyectos, para cerrar el ciclo de comunicación. La comunicación es, por mucho, el activo más valioso dentro del desarrollo de software, sólo comparable en importancia con nuestros recursos humanos calificados. Es por esto que toda implementación que planee hacer uso de las herramientas de BPM en el ámbito del desarrollo de sistemas, dependerá primordialmente del nivel de soporte a las comunicaciones inteligentes y la transferencia del conocimiento entre diversos “keyplayers” en diferentes áreas. Lo ideal, en el sentido de la comunicación, serían herramientas que fueran independientes del organigrama en el sentido del intercambio positivo de la información no clasificada, y que además fuese sensible a estas mismas estructuras organizacionales para poder intercambiar de manera segura la información confidencial que no es de interés para todos los miembros del equipo. La herramienta deberá ser sensible socialmente a las relaciones mantenidas por parte de los dife-

JUL-AGO 2005

rentes miembros de los equipos, para poder aprovechar los canales de comunicación mas eficientes, y que no deben de fallar a causa de las altas tasas de rotación de personal, ni a las condiciones cambiantes de movilidad organizacional. Nuestras herramientas y conocimiento deben de estar a la mano de quien lo necesita, independientemente de si el dueño de la información dejó de trabajar en la empresa, recibió un ascenso, cambió su rol o cambió de proyecto. El manejo del conocimiento debe ser contextual e hipervinculado, así como modificable por cada uno de los miembros que posea la información necesaria para hacer aportaciones positivas, aún y cuando aparentemente su área de responsabilidad no sea congruente. Siempre habrá posibilidad de que el administrador de la configuración reciba un reporte de incongruencias en la edición de un documento, y simplemente aplique un Rollback a la última versión estable de la documentación. La organización en células de trabajo cohesivas internamente y modulares hacia el exterior, nos permitirá hacer un intercambio dinámico de recursos, independientemente de si el proceso actual o requerimiento dicta que primero llevemos a cabo el análisis y luego simulaciones, o viceversa. Nuestras herramientas flexibles de BPM deberán permitir el acoplamiento de nuestros flujos de trabajo a situaciones variadas en las que los procesos puedan tomar formas iterativas, en cascada, aleatorias y hasta caóticas, pero siempre sin perder de vista el alto grado de comunicación necesaria y el mantenimiento de los estándares documentales que nos permitirán obtener retornos sobre cada una de las fases de nuestros proyectos. La comunicación deberá de ser sensible a las personas y sus maneras naturales de agruparse en cuanto a intereses, habilidades, conocimientos y hasta amistades, y no solamente en cuanto a células de trabajo bien estructuradas, dado que sabemos que el trabajo en desarrollo de sistemas no permite que estas células sean persistentes en el tiempo, en cambio el conocimiento permanece ahí, en esa área gris representada por los vínculos sociales entre las personas. Nuestros recursos

humanos podrán aprovechar conocimientos generados en diferentes células y hacerlo con el menor costo posible en términos de comunicación organizacional, y sin tener que pasar por muchos eslabones redundantes que únicamente fiscalizan el proceso sin aportar nuevos conocimientos o valor. Los elementos necesarios mínimos que debe de incluir una solución BPM para el desarrollo de software son los siguientes, sin un orden particular de importancia: • Definición y administración dinámica de procesos, independiente de metodologías formales (se deberá poder implementar cualquier metodología, según se considere conveniente). • Enfoque de producción basado en documentación estandarizada. • Formación de equipos de trabajo cohesivos internamente y modulares hacia fuera, con un enfoque particular en sus procesos propios, pero permitiendo la participación en los procesos ajenos. • Herramientas de modelado visual y definición de procesos. • Herramientas de reporteo y seguimiento de los procesos en tiempo real. • Middleware que permita conectar las diferentes partes, sistemas, y equipos de trabajo, con un enfoque orientado a procesos dinámicos. • Herramientas de comunicación colaborativa sensibles a la competencia, habilidades y relaciones sociales de los recursos humanos del proyecto. • Herramientas colaborativas inteligentes de administración del conocimiento, que permitan el flujo de información seguro y a la vez transparente, independiente de organigramas, y que busquen la participación indistinta de las personas que poseen el conocimiento. www.softwareguru.com.mx

INNOVACIONES EN SOFTWARE

COLUMNA

La “Revolución” del BPM Pasado, Presente y Futuro

a forma de hacer negocios cambia constantemente. Los Procesos que soportan la organización son altamente dinámicos. Gartner piensa que el futuro de la construcción de software será, en parte, la composición de piezas en modeladores visuales, alterando instantáneamente el comportamiento de la organización —una labor realizada por los mismos dueños de los negocios.

Pasado En un principio se pensó que los procesos de negocio podrían ser soportados por Flujos de Trabajo, ya que era posible enviar documentos, formas en rutas establecidas de manera automática usando reglas del negocio. Aunque muchos Workflow Management Systems (WFMS) lograron rebasar la vista centrada en documentos, el problema principal fue que codifican un metamodelo de procesos que limita la capacidad de resolver los problemas del mundo real. Hoy las aplicaciones de negocio como SAP R/3 incluyen componentes WFMS convirtiendo a los ERPS en plataformas de construcción de software. Pero aunque estas tecnologías existen, no se han utilizado ampliamente. Si todo se puede desarrollar de esta forma, ¿por qué no dejar de usar .NET y Java?

humano es sólo una forma de pensar en procesos. En la vida real los sistemas de flujo de trabajo limitan fuertemente los procesos de negocio que se desean modelar. Aquellos que han implantado estos sistemas conocen bien estas limitaciones.

Presente Recientemente ha aparecido una nueva categoría de software, los Business Process Management Systems (BPMS), como el WFMS o Relational Database Management Systems (RDBMS). Los BPMS son la búsqueda de una maquinaria universal de procesos. Hoy por ejemplo, los WFMS no pueden sustituir el correo electrónico. Extraño porque el correo electrónico se puede considerar un proceso muy común hoy en día: es un proceso simple de recibir y enviar con el que adquirimos la capacidad de comunicarnos con otros mediante una dirección electrónica. Es irónico que los WFMS no puedan modelar este escenario tan simple.

Claramente los distintos WFMS trabajan en formas diferentes, aun cuando la Workflow Management Coallition (WfMC.org) ha tratado de unificar las normas. Este hecho ha limitado fuertemente la penetración al mercado de tecnologías de automatización de procesos, porque los directores de sistemas se tienen que comprometer con un proveedor.

Otro factor no considerado en los WFMS es la movilidad, como lo demostró el ganador del premio ACM Turing, Robin Milner, quién desarrolló una teoría formal de procesos móviles llamada Cálculo Pi. El término movilidad se refiere a la forma en que los procesos transcurren mientras se ejecutan, mediante el intercambio de información entre participantes cuyas relaciones y vínculos evolucionan como resultado, determinando qué se conoce, quiénes se conocen y qué se ha encontrado.

Pero hay razones adicionales de porqué los WFMS no pueden ser un modelo para ejecutar todos los procesos de software. El flujo de trabajo

Una explicación detallada de estos conceptos está fuera del alcance de esta columna, pero se puede resumir como un proceso para crear procesos

www.softwareguru.com.mx

de cualquier tipo y que no se basa en comunicaciones sino en transformaciones a sí mismo. El BPMS se compone de herramientas de modelado, maquinaria de ejecución, herramientas de agilidad para alterar procesos, herramientas para monitorear y administrar los procesos, y herramientas de análisis que permitan medir la eficiencia de los procesos (ahí la relación con Six Sigma y procesos de mejora continua). Intalio fue el primer proveedor en implementar este modelo.

Futuro Es claro que, dada la capacidad de comunicación que Internet ofrece, hoy es posible implementar procesos que salgan de la organización uniendo a proveedores, empresas pequeñas y usuarios finales. El Business Process Outsourcing (BPO) consiste en delegar la propiedad, administración y operación de un proceso a un tercero: Quien monta una nueva empresa puede preferir enviar al exterior un proceso de recursos humanos en lugar de hacerlo ellos mismos. Ese proceso debe ser de excelencia pero no se desea realizar el esfuerzo en lograrlo. En el futuro las “experiencias” permitirán integrar procesos entre industrias distintas. Por ejemplo, la contratación de un empleado en una organización puede provocar que al concretar la operación en el sistema de administración de recursos humanos se disparen procesos como compra del automóvil, apertura de cuenta, contratación del seguro, registros en el gobierno y otros procesos que hoy se realizan en forma manual, sean verdaderamente automatizados.

Luis Daniel Soto Maldonado es Director de Evangelización en Nuevas Tecnologías en Microsoft México. Entre sus funciones actuales están la administración de la relación con el Gobierno Mexicano para el desarrollo de la industria de software (ProSoft). Luis Daniel es jurado del “Gran Orden de Honor al Mérito Autoral” en software del INDAUTOR/SEP y fundador de diversas asociaciones de Tecnologías de Información (TI) relacionadas a inteligencia competitiva, administración del conocimiento y construcción de software. Luis Daniel Soto es Ingeniero en Sistemas de la Fundación Arturo Rosenblueth y ganó el primer lugar en el concurso nacional para software de exportación en 1989. blogs.msdn. com/luisdans

- Luis Daniel Soto

JUL-AGO 2005

PRÁCTICAS UML

CASOS DE USO Y EL VALOR DEL SISTEMA Por Sergio Orozco

A quién no le ha pasado que compra algo sólo para terminar con ese producto en un rincón sin jamás ser utilizado? Nos pudo haber pasado porque no alcanzó nuestras expectativas, o porque resultó demasiado complicado de utilizar, o porque en realidad no era una verdadera necesidad sino simplemente un capricho. Sea cual fuera la razón, la realidad es que hicimos un gasto inútil e innecesario. Con el software, y en particular con el desarrollo de software a la medida, ocurre con bastante frecuencia algo similar. No es raro encontrarse con empresas que contratan un desarrollo de software sólo para darse cuenta de que desperdiciaron su dinero y su tiempo, pues no obtuvieron lo que ellos esperaban o necesitaban. En otras palabras, no obtuvieron el valor que esperaban recibir para su negocio con el software adquirido.

La Administración de Requerimientos Una de las razones principales por las cuales se da esta situación, y de hecho, una de las causas principales por las cuales los proyectos de desarrollo fracasan o por lo menos no tienen el éxito que deberían, se debe a una mala administración de requerimientos. Esto generalmente se da por falta ya sea de habilidades en el personal responsable o de técnicas apropiadas utilizadas para llevar a cabo esta labor. La administración de requerimientos, de acuerdo a CMM, abarca actividades como la recopilación, documentación, validación y control de los requerimientos y sus cambios. UML, como estándar integrador de las buenas prácticas de desarrollo nos ofrece en este sentido los casos de uso como una técnica excelente para administrar los requerimientos de nuestros proyectos.

¿Consultoría o Manufactura? Si queremos realizar una verdadera consultoría de software, entonces nos corresponde algo más que escuchar la lista de funciones que el cliente cree que debería de tener su sistema (a menos que nuestro cliente tenga un área con la capacidad de realizar una buena recopilación y análisis de requerimientos). Si nos limitáramos a lo primero, entonces en lugar de llamarle consultoría a nuestro trabajo, deberíamos llamarle manufactura de software, donde uno implementa las funciones exactamente como se las solicita el cliente, cuestionando nada o muy poco, tal como se haría en una planta manufacturera donde se reciben las especificaciones del producto a construir.

pedido”, “Consultar comisiones”, “Administrar prospectos”, “Generar factura” y “Administrar clientes”. Todas ellas son ejemplos de situaciones u objetivos importante que podría necesitar un vendedor para llevar a cabo su trabajo, conocidas y modeladas como casos de uso en UML, tal como se muestra en el diagrama.

El Sistema y su Misión Si queremos desarrollar el mejor sistema posible, debemos realizar un trabajo serio para identificar, en primer lugar, cuál es el valor que el sistema debe proporcionar al negocio, para lo cual habrá que preguntárselo a las personas que obtendrán alguna clase de beneficio cuando se ponga en operación. Una buena parte de estas personas probablemente vayan a ser usuarios del sistema; en UML los conocemos como Actores (más adelante veremos otros tipos de Actores que también tendremos que identificar).

Buscando los Beneficios del Sistema Una vez identificados los usuarios del sistema (actores primarios) habrá que preguntarles en qué situaciones valdrá la pena para ellos utilizarlo. La lista identificada de dichas situaciones no debería de tener pequeñas funciones, sino flujos completos que le proporcionen suficiente valor tanto a ellos como al negocio, de manera que “valga la pena usar el sistema” en dichas situaciones. Ejemplo: un vendedor en cierto sistema de ventas querrá “Registrar venta”, “Registrar

Diagrama de casos de uso para el sistema de venta.

Los Requerimientos Funcionales Normalmente los casos de uso son iniciados por algún actor, conocido como actor primario. Lo inicia con algún evento, que podría ser tan simple como elegir una opción en el sistema, y continúa como una serie de eventos o interacciones entre actores y sistema, hasta que el objetivo del caso de uso se cumple (el objetivo principal del caso de uso es lo que le da el nombre al mismo). Por lo tanto los casos de uso describen la funcionalidad del sistema para alcanzar objetivos

Sergio Orozco es director general e instructor senior en Milestone Consulting, empresa especializada en capacitación práctica y consultoría en UML, CMM y orientación a objetos. info@milestone.com.mx.

JUL-AGO 2005

www.softwareguru.com.mx

importantes. Lo que estamos obteniendo así es una especificación de requerimientos funcionales mediante un análisis top-down (de lo general a lo particular), es decir, primero obtenemos los objetivos que hay que cumplir en el sistema descritos con el nombre del caso de uso (p. ej: Realizar una venta) y después buscamos cuáles son las funciones o requerimientos funcionales precisos y ordenados para que el actor cumpla dicho objetivo al utilizar sistema. Esto nos lleva a identificar requerimientos realmente relevantes para alcanzar la misión del sistema. Pasos para recopilar los requerimientos funcionales adecuados del sistema mediante casos de uso: 1. Especificar la misión del sistema. 2. Identificar quiénes utilizarán el sistema (actores primarios). 3. Averiguar cuáles objetivos desean cumplir los actores al usar el sistema (casos de uso). 4. Identificar los pasos o eventos de cada caso de uso (especificación del caso de uso).

Las Interfaces del Sistema Hay otro tipo de actores que también hay que modelar; los actores secundarios. Suelen ser otros sistemas, componentes externos o dispositivos con los cuales interactúa nuestro sistema. A diferencia de los actores primarios, éstos no son los que inician o requieren del caso de uso, sino que nuestro sistema, al llevar a cabo un caso de uso requiere tener algún tipo de interacción con él. En el diagrama de casos de uso también suele ser apropiado mostrar a este tipo de actores, en cuyo caso aparecerán asociados a los casos de uso durante los cuales tienen que intervenir con algún tipo de interacción con el sistema a modelar. Ejemplo de Actor Secundario Nuestro sistema de ventas podría requerir enviarle información al sistema de contabilidad cuando se ejecuta la funcionalidad del caso de uso “Generar factura”. En dicha situación el sis-

tema de contabilidad aparecerá como un actor secundario asociado a dicho caso de uso. De esta forma estamos mostrando las interfases requeridas con otros sistemas en cada momento. Por experiencia sabemos que, en los modelos de UML, el buen uso de pocos elementos da mejores resultados que el uso de muchos elementos mal aplicados. La esencia de los modelos radica en la simplicidad, ya que facilita el análisis, entendimiento y comunicación entre quienes solicitan el sistema y los que participan en su desarrollo. En otras oportunidades veremos elementos adicionales para modelar los casos de uso, pero podemos asegurar que la sencillez es parte importante del modelado, y esto implica que en ocasiones, y sobre todo cuando el analista no tiene tanta experiencia en UML, es mejor limitarnos a los elementos más básicos.

COLUMNA

PRUEBA DE SOFTWARE

Fundamentos de la Prueba de Software Conceptos, Justiﬁcación y Alcance

n el número anterior hablamos sobre el contexto de la prueba de software. En esta ocasión, nos concentraremos en definir algunas definiciones relacionadas con la prueba de software, así como su justificación y alcance.

Luis Vinicio León Carrillo es profesor-investigador del Departamento de Electrónica, Sistemas e Informática del ITESO, y director general de e-Quallity S.A. de C.V., empresa especializada en prueba de software. Luis Vinicio es doctorando por la Universidad Técnica de Clausthal, Alemania; su trabajo predoctoral giró alrededor a la aplicación de los lenguajes formales en la Ingeniería de Software. Es coautor de un marco tecnológico que hoy permite a e-Quallity desarrollar empresas de prueba de software. Su tesis doctoral está enfocada en la aplicación de métodos y lenguajes formales para hacer más eﬁciente y efectiva la prueba de software. Luis Vinicio es co-fundador del Capítulo Guadalajara de la AMCIS y su Secretario actual.

Las descripciones de algunos conceptos que expondré en el presente, si bien son generalizables, estarán enunciados desde la perspectiva de la técnica denominada “prueba de caja negra”, consistente en ejecutar el sistema a probar revisando los requerimientos, con la consigna de detectar insatisfacción de los mismos. La razón es que facilita la exposición sin introducir complejidad innecesaria.

Definiciones Complementando nuestro primer acercamiento a una definición, que tuvimos en el número anterior, podemos argüir que la prueba de software: Es un proceso en el que se revisa el sistema a probar (el SUT) bajo condiciones definidas explícitamente, y se le aplica (eventualmente con apoyo de software especializado de tipo CAST) un conjunto de estímulos (los casos de prueba) diseñados de manera sistemática utilizando técnicas apropiadas, con el objetivo de detectar niveles inadecuados de calidad. Este proceso debe llevarse a cabo disciplinadamente, y respaldarse en métricas bien definidas. Todas estas actividades y sus resultados son documentados, en especial las fallas detectadas [1]. Precisemos cada uno de los conceptos de esta definición. Intuitivamente, un proceso puede verse como una secuencia de actividades, cada una de las cuales genera productos, tiene insumos asociados, e involucra gente (roles) y otros recursos (v.gr. hardware y software). Un primer bosquejo del proceso de prueba de caja negra sería el siguiente, que refinaremos en números subsiguientes: 1. Establecer alcances, entregables y criterios de éxito 2. Estimar el esfuerzo de prueba 3. Planear el proyecto

JUL-AGO 2005

4. Reproducir el contexto del SUT 5. Hacer a) Diseñar casos de prueba b) Aplicar casos de prueba c) Reportar métricas y dar seguimiento d) Reportar análisis de resultados Mientras no (criterio de terminación) 6. Hacer el cierre del proyecto El SUT (System Under Testing) se refiere en general al elemento a probar. Por otro lado, las herramientas que utiliza el tester para llevar a cabo las actividades anteriores son cobijados bajo el acrónimo CAST (Computer Aided Software Testing). En cuanto a los casos de prueba, es deseable que presenten las siguientes características: • Ortogonalidad. No tener casos que incluyan segmentos de otros • Efectividad. Que detecten fallas. • Ejemplaridad. Que “con poco se pruebe mucho”. • Claridad. Que evidencien fallas de manera clara. Con calidad nos referimos a [2]: • El grado en que el producto satisface los requerimientos funcionales y no-funcionales explícitamente establecidos. • El nivel al que se siguieron los estándares de desarrollo explícitos y documentados. • Que el producto muestre las características implícitas que se espera de todo software desarrollado profesionalmente. Una equivocación es una acción incorrecta cometida por un humano (v.gr. no presionar [shift]), que ocasiona que se genere una falta (sin el [shift], queda “<” en vez de “>” en el código fuente); al ser ejecutada, la falta se evidencia en forma de lo que llamamos una falla. El error es la magnitud de la diferencia entre el resultado esperado y el obtenido [3].

Justificación Los principales objetivos que se buscan con la prueba de software suelen ser: • Conocer el nivel de calidad de productos intermedios, para actuar a tiempo (v.gr. rehacer un componente); esto www.softwareguru.com.mx

facilita una administración realista del time to market del producto en cuestión. • No pagar por un producto de software sino hasta que alcance el nivel de calidad pactado; esto eleva el nivel de certidumbre en el comprador de software, y minimiza riesgos. • Disminuir la penosa y costosa labor de soporte a usuarios insatisfechos, consecuencia de liberar un producto inmaduro. Esto puede mejorar la imagen de la organización desarrolladora (y la credibilidad en ella). • Reducir costos de mantenimiento (la fase más costosa del desarrollo de software), mediante el diagnóstico oportuno de los componentes del sistema (v.gr. seguimiento a estándares, legibilidad del código, integración adecuada de los componentes, rendimiento apropiado, nivel y calidad del reuso, calidad de la documentación, etc.). • Obtener información concreta acerca de fallas, que pueda usarse como apoyo en la mejora de procesos, y en la de los desarrolladores (v.gr. capacitación en áreas de oportunidad). Entre más pronto se apliquen mecanismos de prueba en el proceso de desarrollo, más fácilmente podrá evitarse que el proyecto se salga del tiempo y presupuesto planeado, pues se podrán detectar más problemas originados en las fases tempranas del proceso, que son los que mayor impacto tienen.

Alcance La prueba de software tiene limitantes, tanto teóricos como prácticos. Desde el punto de vista teórico, la prueba es un problema que llamamos no-decidible; esto implica, grosso modo, que no podemos escribir un programa que pruebe los programas sin intervención humana. Sin embargo, como www.softwareguru.com.mx

mencionábamos anteriormente, la prueba sí es automatizable en muchos aspectos. Desde el punto de vista práctico, la cantidad de posibilidades para probar exhaustivamente un sistema es sencillamente inmanejable; es necesario entonces utilizar técnicas adecuadas para maximizar la cantidad de fallas importantes encontradas con los recursos asignados. Cada método que se utilice para detectar defectos deja un residuo de defectos más sutiles contra los cuales ese método es ineficaz (la llamada “Paradoja del Pesticida”). La prueba de software implica pues, la aplicación de técnicas y herramientas apropiadas en el marco de un proceso bien definido, determinado por el tipo de proyectos de desarrollo de software que se abordan. En el siguiente número veremos con mayor detalle las principales técnicas de prueba de software. - Luis Vinicio León

Referencias 1. www.e-quallity.net pestaña Definiciones - Conceptos 2. Pressman, R.: Ingeniería de Software. Un Enfoque práctico. McGraw-Hill; 1993 3. Kit, E.: Software Testing in the Real World. ACM Press, 1995

COLUMNA

CÁTEDRA Y MÁS

BPM El Impacto en el Desarrollo de Software Aplicativo

os negocios o empresas hoy en día están preocupados por lograr la eficiencia organizacional al estandarizar los procesos de negocios en forma consistente en toda la compañía. La Administración de Procesos de Negocios (BPM) se enfoca en las prácticas inconsistentes de negocios. Cada quién realiza las actividades de forma diferente, con resultados poco homogéneos.

El Dr. Ralf Eder Lange es Profesor ConsultorExtensionista del Departamento de Sistemas de Información en el Tec de Monterrey, Campus Estado de México, donde ha sido Director de los Programas de Graduados en Ciencias Computacionales y Sistemas de Información, y Director del Centro de Investigación en Informática. Sus áreas de especialidad incluyen Reingeniería de Procesos y Administración de la Innovación Tecnológica. Ralf es miembro fundador de la Asociación Latinoamericana y del Caribe de Sistemas de Información (LACAIS).

Muchas empresas proveedoras de software se encuentran evaluando el replanteo de sus productos, usando, por ejemplo, soluciones CRM, cuando este acrónimo apareció en la escena. Lo mismo ha ocurrido con BPM, sin embargo, los productos que ofrecen los proveedores varían dramáticamente en capacidad y funcionalidad. BPM brinda la posibilidad de definir los procesos de negocio a nivel estratégico, para posteriormente automatizar dichos procesos en una aplicación computacional y finalmente proveer a los gerentes del negocio con la posibilidad de monitorear y analizar la operación de dichos procesos. Esto permite resolver problemas en el momento en que ocurren. Resulta muy importante que una plataforma de BPM permita especificar procesos que abarquen múltiples compañías, usando varios sistemas aplicativos en forma rápida, para luego implantarla en seguida. De lo contrario, dicha plataforma ofrece muy poco valor, al referirse a la automatización de procesos. Los negocios están inmersos cotidianamente en cambios constantes, tanto por actividades internas como externas, por lo que una plataforma de administración de procesos de negocios debe ser capaz de responder a estos cambios. La administración de procesos de negocio es llevada a cabo con diferentes herramientas utilizadas para capturar, modelar, diseñar, integrar, probar,

JUL-AGO 2005

implantar, medir y mantener diversos procesos de negocio en una empresa. Los procesos de negocio centrales definen el negocio y proporcionan la posibilidad de satisfacer y retener a los clientes, de maximizar las alianzas con otras empresas y de obtener resultados extraordinarios con respecto a la competencia. Al administrar los procesos de negocio se evitan prácticas inconsistentes de peticiones de cambio en aplicaciones computacionales, se asignan roles que ayudan a los clientes a definir los permisos de uso y acceso a la información, junto con las aprobaciones a los cambios en cada proyecto. BPM permite definir colectivamente los procesos de negocios, implantarlos en forma de aplicaciones computacionales, de tal forma que los administradores puedan monitorear, analizar, controlar o mejorar la ejecución de dichos procesos en tiempo real. Para implantar BPM se requiere entender en forma detallada la interacción de los diversos procesos de negocio existentes, así como poseer el conocimiento acerca de cómo fueron desarrolladas las aplicaciones computacionales correspondientes. Esto resulta ser un gran reto para todas las empresas, ya que al especificar la solución y diseñar el proyecto de BPM debe haber representantes de los procesos de negocios y de las aplicaciones computacionales, y esta interacción continúa aún después de la implantación, ya que debe proveerse mantenimiento a dichas aplicaciones. Por ejemplo, aquellas personas que realizan diagramas de flujo con herramientas como Visio o PowerPoint, también deben ser capaces de modelar procesos de negocio usando un BPMS. Luego se debe de poder comentar el proceso de negocio y pasarlo a los técnicos para su implantación. La habilidad de definir procesos con sus reglas de negocio, integrar aplicaciones computacionales e implantarlas, es necesaria para

mejorar la productividad del negocio, pero por sí sola no es suficiente. Por esto la importancia de la habilidad de monitorear la ejecución de procesos en tiempo real, conociendo su impacto de ejecución y controlarlos en virtud de los cambios en las condiciones de negocio. A las personas con habilidades de negocio se les dificulta la comprensión de los detalles o la perspectiva de la tecnologías de la información —potencial de uso y funcionalidad—, y a los técnicos se les dificulta el apreciar los requerimientos —legales, económicos, organizacionales—, tal como se plasman en los procesos de negocio. Bajo estos puntos de vista divergentes, resulta difícil lograr la optimización del diseño propuesto, así como la implantación y la solución de problemas. El punto crucial, desde mi punto de vista como administrador de un proyecto de BPM, es la asignación de personal para que haya representatividad en el equipo formado con tal fin, que garantice el desarrollo de una aplicación computacional que efectivamente apoye objetivos de negocio, que estén sustentados en procesos de negocios auténticos, y que ayuden en el monitoreo. Dicho personal debe demostrar tener experiencia de campo, con usuarios por un lado y con las aplicaciones computacionales por otro. -Dr. Ralf Eder L.

Referencias • Learn Data Modeling www.learndatamodeling.com/b_ manage.htm • Serena Software - BPM www.serena.com/business_process_management.html • Savvion - BPM www.savvion.com/business_process_management.php

www.softwareguru.com.mx

FUNDAMENTOS

PMBOK Guide

Guía de los Fundamentos de la Dirección de Proyectos Por Ramón Hernández

Como su nombre lo indíca, el PMBOK (Project Management Body of Knowledge) Guide es un documento que reúne el conocimiento relacionado con la Dirección de Proyectos. La versión en español lleva el título “Guía de los Fundamentos de la Dirección de Proyectos (Guía del PMBOK®)”, y se encuentra actualmente en su tercera edición, liberada a finales del 2004.

La primera versión del PMBOK se publicó como un artículo especial en el año de 1983 en una revista especializada del PMI (Project Management Institute). Algunos años después, en 1986, se publicó como un libro que contenía la estructura general que conocemos hasta el día de hoy (nueve áreas del conocimiento y cinco grupos de procesos). En el año 2000 se publicó una actualización, así como la primera traducción oficial al español. Finalmente en el 2004 se publicó la tercera edición de este libro. Prueba de la difusión de este documento como un estándar mundial, fue el hecho de que se publicó de manera simultánea en once idiomas: inglés, árabe, chino simplificado, francés, alemán, italiano, japonés, coreano, portugués, ruso y español. “La finalidad principal de la Guía del PMBOK es identificar el subconjunto de Fundamentos de la Dirección de Proyectos generalmente reconocido como buenas prácticas”. —PMBOK pág. 3

Iniciación

Planificación

Control

Ejecución

Cierre Grupos de Procesos

Ejecución.- En este grupo de procesos se integra a personas y otros recursos para llevar a cabo el plan de proyecto, así como realizar los cambios aprobados para el proyecto. Seguimiento y Control.- Mide y supervisa regularmente el avance, a fin de identificar desviaciones respecto al plan de proyecto, de tal forma que se tomen medidas correctivas o preventivas cuando sea necesario para cumplir con los objetivos del proyecto. Aquí se lleva el control de los cambios al proyecto que asegura que los mismos son benéficos para el proyecto, el control de calidad del proyecto y la recopilación y distribución acerca del rendimiento del proyecto. Cierre.- Formaliza la aceptación del producto, servicio o resultado, y termina de manera ordenada el proyecto o una fase del mismo, o cierra un proyecto cancelado. Los cinco grupos de procesos agrupan a 44 procesos de dirección de proyectos que están clasificados por Área de Conocimiento.

Grupos de Procesos

Áreas de Conocimiento

Los Grupos de Procesos son guías para aplicar los conocimientos y habilidades relativas a la Dirección de Proyectos. Los Grupos de Procesos tienen dependencias claras y se realizan siguiendo la misma secuencia para cada proyecto, son independientes de la industria o aplicación. El PMBOK define cinco grupos de procesos: Iniciación.- Aquí se define y autoriza el proyecto o una fase del mismo. La repetición de estos procesos permite que el proyecto sea detenido si deja de existir la necesidad de negocio o si se considera que el proyecto no puede satisfacer esa necesidad. Planificación.- Define y refina los objetivos, y planifica el curso de acción requerido para lograr los objetivos y el alcance pretendido del proyecto. Aquí se define el alcance y costo del proyecto o fase del mismo.

Para poder estudiar todos los procesos de la Dirección de Proyectos, se agruparon en Áreas de Conocimiento, ya que en la vida real, estas Áreas de Conocimiento se pueden sobreponer una sobre la otra o interactuar entre sí de maneras muy diversas. Las Áreas de Conocimiento definidas en el PMBOK son: Gestión de la Integración del Proyecto.- Incluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los distintos procesos y actividades de dirección de proyectos dentro de los Grupos de Procesos de Dirección de Proyectos. La necesidad de integración se hace evidente en situaciones donde procesos individuales interactúan. Gestión del Alcance del Proyecto.- Incluye los procesos necesarios para asegurarse que el proyecto incluya todo el trabajo requeri-

Ramón Hernández es Gerente de proyecto con más de diez años de experiencia en Tecnología de Información concentrado en proyectos para el sistema ﬁnanciero. Ramón es PMP certiﬁcado desde 1999 y colabora en el capítulo del PMI en la Ciudad de México.

JUL-AGO 2005

www.softwareguru.com.mx

do, y sólo el trabajo requerido, para terminar un proyecto de manera satisfactoria, básicamente es controlar lo que está incluido en el proyecto y lo que quedará fuera del mismo. Aquí se desarrolla la especificación del trabajo, o Statement of Work (SOW). Gestión del Tiempo del Proyecto.- Tiene todos los procesos necesarios para lograr terminar el proyecto en tiempo, como son la definición y secuencia de las actividades, así como los recursos necesarios para cada actividad y la duración de las mismas. El producto principal es el Cronograma del proyecto. Gestión de los Costos del Proyecto.- Aquí se tienen todos los procesos que permiten que el proyecto termine dentro del presupuesto aprobado. Se menciona que no sólo se debe poner énfasis en los costos del proyecto, sino en la repercusión que éstos pueden tener en el cliente, por ejemplo, disminuir el número de revisiones de aseguramiento de calidad al proyecto puede reducir el costo del proyecto, pero puede incrementar los costos que tendrá que pagar el cliente por tener un producto que no cumpla sus necesidades de acuerdo a lo pactado en el proyecto. Gestión de la Calidad del Proyecto.- Esta área de conocimiento incluye todas las actividades que determinan las políticas, objetivos y responsabilidades relacionadas con la calidad del proyecto que satisfaga las necesidades por las cuales se originó. Gestión de los Recursos Humanos del Proyecto.- Incluye todos los procesos que coordinan los trabajos de un equipo de proyecto en el cual se han definido roles y responsabilidades. Gestión de las Comunicaciones del Proyecto.- Es el área de conocimiento que incluye los procesos necesarios para asegurar que la información del proyecto sea entregada en tiempo y forma a todos los involucrados en el proyecto, algunos señalan que es en esta área donde el Gerente de Proyecto debe destinar la mayor parte de su tiempo. Se debe definir para cada involucrado en el proyecto el tipo y la frecuencia con que debe recibir información del proyecto, se debe informar a todos los niveles, hacia arriba, hacia abajo y hacia los lados. www.softwareguru.com.mx

Gestión de los Riesgos del Proyecto.- Aquí se realiza la planificación de la gestión de riegos, la identificación y análisis de riegos, las respuestas a los riegos, y el seguimiento y control de los riesgos de un proyecto, se pretende con esto aumentar la probabilidad e impacto de los eventos positivos, y disminuir la probabilidad e impacto de los eventos contrarios al éxito del proyecto. Los riesgos son eventos o condiciones inciertos que, en caso de ocurrir, tienen un efecto positivo o negativo sobre alguno de los objetivos del proyecto, ya sean tiempo, costo, alcance o calidad. Gestión de las Adquisiciones del Proyectos.- En esta última Área de Conocimiento se incluyen todos los procesos de comprar o adquirir productos o servicios externos al equipo de proyecto necesarios para realizar el trabajo. Se incluye la administración de cualquier contrato, que es un documento legal entre un comprador y un proveedor, asumiendo que el comprador forma parte del equipo del proyecto y el proveedor no.

Conclusión De una manera breve se muestra cómo está estructurado el PMBOK; para aquellos relacionados con la Ingeniería de Software puede ser un complemento interesante y un libro de consulta por excelencia que permita desarrollar proyectos de software cumpliendo con las necesidades de los clientes. Si mezclamos el SWEBOK (ver sección Fundamentos de SG Año 01 No.01) con el PMBOK, tendremos dos excelentes documentos que nos permitirán establecer el marco de referencia para desarrollar software de calidad.

Referencias • Guía de los Fundamentos de la Dirección de Proyectos. Project Management Institute. 3era Edición, 2004. • “Fundamentos: Ingeniería de Software”. Revista SG Año 01 No.01 JUL-AGO 2005

TECNOLOGÍA

WiMAX

El siguiente paso en redes inalámbricas Por Ariel García

WiMAX, del inglés Worldwide Interoperability for Microwave Access, es un estándar para transmisión inalámbrica de datos en redes de área metropolitana (MAN). Es una certificación para productos que cumplen con las pruebas de interoperabilidad de los estándares de IEEE 802.16, que tienen su área de especialidad en conexiones inalámbricas punto multipunto. Qué esperar de una red WiMAX WiMAX es una nueva alternativa para la construcción de redes inalámbricas, pero con mayores beneficios. Algunas ventajas son el manejo de velocidades de hasta 70Mbps y coberturas de hasta 50km. Esto no significa que WiMAX venga a sustituir la tecnología Wi-Fi, al contrario, está diseñada para complementar e interoperar con esta solución, al igual que con otras como Ethernet, Token Ring, FDDI, Cable MODEM, etc.

Bandas (Mhz)

Actuales y Autorizaciones Vigentes*

Nuevas Aplicaciones (Diseñadas para convivir con atribuciones previas)

2400-2483.5

ICM (aplicaciones industriales, científicas y médicas), teléfonos inalámbricos, enlaces p-p y p-mp (espectro disperso), telemetría, sistemas multiacceso telefonía rural, tx de datos, hornos y enlaces de microondas.

802.11b/11Mbps, 802.11g/54Mbps, 802.20/1 Mbps/movilidad, Bluetooth, Home RF ps/movilidad, 802.16/70 Mbps/movilidad.

En su primera etapa de implantación, WiMAX sólo estará disponible para los carriers, (compañías que ofrecen servicios de telecomunicaciones como telefónicas e ISPs) y grandes corporativos, para que puedan mejorar el servicio que ofrecen a sus clientes. La cobertura de la tecnología WiMAX se medirá en kilómetros cuadrados (Wi-Fi lo hace en metros cuadrados). Esto implica que en el área de cobertura de una estación base de WiMAX, se podrían habilitar soluciones de acceso a Internet de alta velocidad para hogares y oficinas en un radio de hasta 50km. Estas estaciones base eventualmente podrían cubrir toda una zona metropolitana, habilitando un acceso inalámbrico ininterrumpido en toda una ciudad.

5150-5350

Enlaces p-p y p-mp (espectro disperso y modulación digital), MOVIL

802.11ª/54Mbps, 802.11i, 802.16/70 Mbps/ movilidad, 802.20/1 Mbps/movilidad.

5470-5725

Radio Navegación marítima, Radiolocalización movil, radioaficionados.

El estándar de WiMAX trabaja en el espectro entre 2 y 11GHz y supera las limitaciones de Wi-Fi al proveer anchos de banda de mayor velocidad y una encripción más robusta. Otra característica importante de WiMAX es su capacidad de proveer acceso al medio sin necesidad de línea de vista directa a la estación base. Obviamente esto disminuye el

JUL-AGO 2005

5725-5850

ICM (aplicaciones industriales, científicas y médicas), Detección, identificadores, telemetría, telecomando y enlaces p-p y p-mp (espectro disperso)

802.16/70 Mbps/movilidad, 802.20/1 Mbps/movilidad 802.11ª/54Mbps 802.16/70 Mbps/Movilidad, 802.20/1 Mbps/movilidad.

* Incluye permisos, concesiones, autorizaciones y registros.

alcance, pero aún así WiMAX hace un muy buen trabajo en este tipo de situaciones.

Las ventajas de WiMAX La tecnología podría proveer accesos compartidos de hasta 70Mbit/s. Esta capacidad es suficiente para soportar más de 60 enlaces tipo T1, o varios cientos de hogares con accesos DSL de 1Mbit/s. WiMAX tiene un manejo optimizado y de mayor eficiencia del

ancho de banda, en base a sus algoritmos de control de acceso al medio. Estos algoritmos permiten a la estación base controlar la calidad de servicio al balancear la asignación de ancho de banda en base a las necesidades de cada subscriptor de la estación; por ejemplo, si algún suscriptor está realizando una descarga de archivos que tiene una velocidad promedio de 80Kb/s y tiene contratado un enlace de 256Kb/s, la estación base sólo

www.softwareguru.com.mx

asignará los 80Kb/s que está demandando y pueda aprovechar el resto del ancho para otros suscriptores que lo necesiten.

Dónde adquirir una solución WiMAX Actualmente en ciudades como Los Angeles, Nueva York, y Seattle en EUA; y Dalian, Chengdu en China, ya hay implementaciones de redes que funcionan con esta tecnología, pero no están certificadas por el WiMAX Forum (ver recuadro), es por esto que se les conoce como pre-WiMAX. Actualmente el WiMAX Forum tiene su programa de certificación en curso, y se espera que las primeras soluciones WiMax certificadas aparezcan a principios del 2006. Una vez liberada la certificación podremos obtener productos que nos permitan construir soluciones que puedan trabajar con cualquier equipo “WiMAX certified” sin importar la marca o el fabricante del chipset. Se espera que para finales del 2007 aparezcan los primeros dispositivos WiMAX para usuarios finales, con los que una persona se podrá conectar a Internet por WiMAX a velocidades de 4Mbps. Posteriormente, a finales del 2008, aparecerían las primeras laptops “WiMAX-ready”.

¿Existen otras tecnologías tipo WiMax? El competidor equivalente de WiMAX en Europa es HIPERMAN. Actualmente el WiMAX Forum está trabajando en métodos para que WiMax y HIPERMAN pueden interoperar de forma transparente. La industria de telecomunicaciones de Corea también ha desarrollado su propio estándar: WiBro. El año pasado Intel y LG acordaron una interoperabilidad entre WiBro y WiMAX.

Regulación del Espectro Los usos de tecnologías como WiMax o WiFi permiten compartir el espectro, haciendo un uso más eficiente. Es fundamental que para promover estos ser-

www.softwareguru.com.mx

vicios, las administraciones consideren diferentes e innovadoras formas de utilizar el espectro radioeléctrico en vez de asignarlo a un único dueño, lo que limita la cobertura y desarrollo de infraestructura, dando paso a un cambio de paradigma, en que el espectro puede ser compartido y donde bajo un marco mínimo de criterios operativos, se puede dar oportunidad a la sociedad e industria de acceder al beneficio que ofrecen estas tecnologías. Hoy en día estas bandas de frecuencias presentan una problemática en México, ya que su utilización libre para acceder Internet esta sujeta a autorización. En tal contexto, es necesario que el Estado mexicano en conjunto con la industria, determinen la mejor manera de aprovechar las modernas tecnologías en uso en las bandas de 2.4 y 5 GHz, a fin de promover el acceso de la mayor parte de la población. La SCT tiene hoy ante sí la decisión de masificar el acceso a Internet y sus servicios, las tecnologías ya están disponibles y las economías de escala permiten tener dispositivos de muy bajo costo, desaprovechar o demorar esta magnifica oportunidad, significaría perder la oportunidad que brindan las TIC para aportar al crecimiento y desarrollo sustentable del país.

Conclusiones La tecnología WiMAX es una nueva solución para implementación de redes de acceso inalámbrico dentro de un área metropolitana. Esto no viene a competir con soluciones existentes como fibra óptica, satélite, Wi-Fi,

etc. Al contrario, nos ayuda a complementar cada una de estas soluciones. Ejemplos: • Para aquellas compañías que cuentan con enlaces de fibra óptica y buscaba soluciones para un enlace de respaldo a bajo costo, WiMAX es una buena opción. • Aquellos proveedores que se encuentran dando servicios de acceso Internet inalámbrico pueden expandir sus áreas de cobertura o iniciar nuevas implementaciones en otras ciudades con esta tecnología. • Tomemos el caso de la Sierra Tarahumara. No existen soluciones de conectividad por cableado de ningún tipo. Mediante un enlace satelital podríamos colocar una antena donde se provee la conectividad a la Internet. En ese punto colocamos nuestra estación base WiMAX de donde tendremos un radio de cobertura de hasta 50 kilómetros para habilitar servicios de telefonía IP. Podemos colocar hotspots Wi-Fi para poder brindar servicios de Internet o educación a distancia, etc. WiMAX iniciará su crecimiento dentro de los grandes corporativos y empresas de comunicaciones consolidadas. Una vez que este mercado sea cubierto, los costos habrán bajado y seremos nosotros, los usuarios finales, quienes comenzaremos a poder tener accesos directo a esta tecnología con sus respectivos beneficios. *Agradecemos a Pedro Cerecer de Intel por la información provista para la generación de este artículo.

Qué es el WiMAX Forum? El WiMAX Forum es un consorcio de empresas (inicialmente 67 y actualmente más de 100), dedicadas a diseñar los parámetros y estándares de esta tecnología, y a estudiar, analizar y probar los desarrollos implementados. En principio se podría pensar que esta tecnología supone una grave amenaza para el negocio de tecnologías inalámbricas de acceso de corto alcance en que se basan muchas empresas, pero hay compañías muy importantes detrás del proyecto. Las principales firmas de telefonía móvil también están desarrollando terminales capaces de conectarse a estas nuevas redes. Mayor información sobre el WiMAX Forum en www.wimaxforum.org

JUL-AGO 2005

TECNOLOGÍA

Sony

Vaio Notebook Serie F Con un diseño más delgado y ligero, la recientemente presentada Serie F de Vaio combina rendimiento y comodidad. En tan sólo 2.5cm de ancho, y 2.8kg, la Serie F integra procesador Pentium M a 1.60GHz, 512MB (escalables a 1GB) de memoria RAM, disco duro de hasta 60GB, pantalla de 15.4 pulgadas visibles, unidad DVD+RW/-RW/CD-RW y Windows XP Home. Lo mejor del software propietario de multimedia de Sony, Vaio Zone, es la capacidad de manipular el contenido de varias computadoras enlazadas en una red local, lo que convierte a la Serie F en un centro de control de entretenimiento ideal. Con un precio bastante accesible y todas las características enlistadas, la Serie F es una excelente opción en computadoras portátiles de alta capacidad y tamaño reducido.

nVIDIA

GeForce 7800

La nueva tarjeta aceleradora de video de nVIDIA presenta la arquitectura de siguiente generación, con una unidad de vértices de sombreado independiente que recorta dramáticamente el tiempo de rendereado de geometría compleja. El motor gráfico CineFX 4.0 procesa el doble de operaciones de punto flotante que las tarjetas de la generación anterior, obteniendo las mejores texturas y efectos de iluminación en tiempo real, concretando el motor cinematográfico prometido desde hace más de cuatro años. 256MB de memoria y un procesador central de 128 bits, brindan la gama más amplia de profundidad de color en 32 bits, así como un radio de actualización de 85Hz en monitores de hasta 2048x1536 pixeles de resolución. La tecnología Digital Vibrance Control 3.0 permite al usuario manipular fácilmente la calibración de color de sus monitores, para ofrecer igualación precisa en el área de trabajo, ya sea en medios digitales o impresos. La GeForce 7800 es para edición de video, rendereo de imágenes en 3D y juegos, por supuesto, permitiendo correr títulos como Doom 3 en todo su potencial.

JUL-AGO 2005

PalmOne

Tungsten E2 Orientada a los nuevos usuarios, la E2 incorpora toda la utilidad de una PDA con la más reciente versión de PalmOS, el Garnet v5.4, de interfaz sencilla y familiar. Todas las aplicaciones de organización (contactos, calendario, administrador de citas y correo electrónico), y el fabuloso Documents To Go, con el que se pueden leer y modificar documentos de Excel, PowerPoint y Word, garantizan la productividad en cualquier lugar. La pantalla a color de 320x320 pixeles de resolución, ranuras de expansión para tarjetas MultimediaCard, SD y SDIO, el software palmOne media, y RealPlayer, hacen de esta Tungsten la compañera perfecta para un viajero, convirtiéndose en un centro multimedia, reproductor de MP3, fotografías y video. Puertos Bluetooth, infrarrojo y USB permiten sincronizar la información e intercambiar contactos con otros dispositivos sin complicaciones. Los accesorios disponibles incluyen un teclado y el GPS Navigator, actualizable para contar con la última información en mapas para trazado de rutas. www.softwareguru.com.mx

BIBLIOTECA

As the Future Catches You: How Genomics & Other Forces Are Changing Your Life, Work, Health & Wealth Juan Enríquez Cabot Crown Business, 2001

Alvin Tofﬂer escribió en 1970 un inquietante libro titulado “El shock del futuro”, en el cual relata un futuro por llegar, y que cuando llegó a muchos nos tomó desprevenidos. En el año 2000, Juan Enríquez Cabot publicó el libro “As the future catches you” (también disponible en español con el nombre “Mientras el futuro te alcanza”). Tofﬂer y Cabot hablan de la tecnología que se fraguaba en su momento y sobre los impactos que tendría en nuestra sociedad. Cabot establece y explica premisas como las siguientes: • Roger Bacon predijo hace 4 siglos: “El conocimiento es poder”. • Las fronteras se derrumban a gran velocidad, porque pocos entienden el impacto de la tecnología y el conocimiento. • Cuando México contaba con bibliotecas e imprentas, en EU los inmigrantes talaban árboles para construir sus cabañas. Sin embargo, EU apostó por la educación de su pueblo y por la tecnología. • En 1960, “Hecho en Japón”, era sinónimo de mala calidad, y en el 2005 es todo lo contrario. Adivinen qué hizo Japón. • En enero de 2000, Microsoft estaba valuada en 592 mil millones de dólares. Diez veces lo que Brasil exportaba en 1998, o cinco veces lo que México exportaba. Pero, ¡ojo!, Brasil tenía 171 millones de habitantes, México 100 y Microsoft empleaba a sólo ¡32,000 personas! Cabot pone todos estos ejemplos para llegar al tema central del libro: la nueva revolución impulsada por la nanotecnología. Esta ya no estará dominada por los 0’s y 1’s (digital), sino por lo que pueda escribirse con las letras ATCG (Adenina, Tiamina, Citosina y Guanina). El futuro nos depara un mercado en el cual podrás adquirir una manzana para controlar la diabetes, una pera contra la gripe, mosquitos que te inyectarán vitaminas, y así sucesivamente. ¿Sorprendente?, bueno si realmente te quieres sorprender, no dejes de leer este impactante libro, escrito con un formato que ha sido aclamado a nivel mundial. Reseña proporcionada por Armando Sánchez Rodríguez (a_sanrod@yahoo.com).

In Search of BPM 02 Excellence: Straight from the Thought Leaders Business Process Management Group (BPMG) Meghan Kiffer Press, 2005 Existen muchos libros de BPM. Sin embargo, la mayoría solamente habla sobre lo grandioso que es BPM y los beneficios que traerá a las empresas, pero muy pocos realmente hablan acerca de cómo hacerlo una realidad y mucho menos sobre lecciones aprendidas. Es por ello que en este número les recomendamos “In Search of BPM Excellence”, ya que es uno de los pocos libros de BPM que no sólo hablan del qué, sino también del cómo. Este libro fue creado por el Business Process Management Group (BPMG) y reúne el pensamiento de algunos de los personajes más importantes de este movimiento. Es un compendio de artículos que tratan

JUL-AGO 2005

temas como el pasado, presente y futuro de BPM, frameworks de implantación (8 Omega Framework), y criterios para seleccionar un BPMS. También hay artículos muy interesantes que abordan temas de negocio tales como estrategia, ventaja competitiva y cambio organizacional, desde la perspectiva de BPM. Dado su reciente publicación (mayo de 2005), es muy probable que todavía no hayan escuchado mucho sobre este libro. Sin embargo, confiamos en que pronto se convierta en una de las lecturas obligadas sobre el tema.

Recomienda un libro para esta sección, escribe a: biblioteca@softwareguru.com.mx

www.softwareguru.com.mx

INDEX

DIRECTORIO

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

www.softwareguru.com.mx

Anunciante

Páginas

Sitio

Alpha Consultoría AMCIS Avantare certum e-Quallity Gopac Grupo STI Horbis IBM Itera MGE Microsoft Milestone Oracle Roca Sistemas SafeNet Ssistemas Software AG Top SW Show XpoLinux

49 55 45 35 43 29 13 39 F4 53 37 F2-1 11 07 47 17 15 33 09 F3

www.alpha-hardin.com www.amcis.org.mx www.avantare.com www.certum.com www.e-quallity.net www.gopac.com.mx www.gsti.com.mx www.horbis.com www.ibm.com/mx www.itera.com.mx www.mgeups.com www.microsoft.com/mexico www.milestone.com.mx www.oracle.com/global/mx www.rocasistemas.com.mx www.la.safenet-inc.com www.ssistemas.com www.softwareag.com www.mayen-project.com.mx www.expolinux.com JUL-AGO 2005

CARRERA

El Arquitecto de Software Habilidades Necesarias Por Sergio Orozco y Carlos Macías

l término “arquitectura de software” y el rol de “arquitecto de software” parecen estar cada día más de moda en nuestra industria. Sólo basta asomarnos a la trama de películas de ciencia ficción como The Matrix: Revolutions donde el arquitecto aparece como un Dios Todopoderoso, responsable de la creación de ese mundo virtual. De igual manera, existe una caricatura donde se hace la analogía entre un programador representando a un padawan (aprendiz de Jedi en la saga Star Wars) y un arquitecto de software representando a un maestro Jedi. El aprendiz no podía creer la cantidad de habilidades y conocimiento que requería para convertirse en un Jedi (o arquitecto según esta analogía), por lo que comenzaba a dudar si sería mejor irse por el lado oscuro de la fuerza.

¿Qué es la Arquitectura de Software? La arquitectura es el conjunto de decisiones relevantes acerca de la organización de un sistema de software, la selección de los elementos estructurales y las interfases que lo componen, junto con el comportamiento según se especifica en la colaboración entre sus elementos, la composición de dichos elementos estructurales y de comportamiento en subsistemas cada vez mayores, así como el estilo arquitectónico que dirige su organización. — La Guía de Usuario de UML, Booch-Jacobson-Rumbaugh, 1999.

Si el analista de sistemas es el responsable de identificar y especificar las necesidades y requerimientos del usuario, entonces el arquitecto es el responsable de tomar las decisiones más relevantes en cuanto a la forma más óptima en que se explotará la tecnología para implementar dichos requerimientos. ¿Qué es lo que se necesita para dominar los principios que pueden transformar a un desarrollador común en un arquitecto de software? Influencia en los Proyectos.- Es conveniente que domine la mayor cantidad de tecnologías de software para ser capaz de ofrecer las mejores recomendaciones tecnológicas en beneficio del proyecto. Sus decisiones tienen un impacto al corto, mediano y largo plazo. Características importantes que definen la calidad de la aplicación, como son el desempeño, reuso, robustez, portabilidad, flexibilidad, escalabilidad y mantenibilidad dependen en gran medida de las decisiones que tome. Incluso generan un impacto directo sobre la economía del proyecto, pues debería de ser capaz de sacarle el máximo provecho a la tecnología

existente, en especial cuando ésta representa una restricción del proyecto, como ocurre cuando el cliente no se puede dar el lujo de invertir en nuevo equipo o tecnología adicional al que ya tiene. Dominio.- Sus decisiones sobre la estructura y dinámica de la aplicación son plasmadas en notación formal. Para hacer esto los arquitectos modernos requieren dominar UML, sobre todo si piensan usar nuevas tecnologías y en especial aquellas orientadas a objetos. A pesar de esto, no creerían la cantidad de alumnos que han llegado a nuestros cursos a aprender UML, creyendo ser “arquitectos de software”, cuando les falta algo tan básico como el dominio de dicha nomenclatura. Claro que no hay que culparlos, ya que existe un desconocimiento generalizado acerca del perfil de dicho rol. El conocimiento y experiencia del arquitecto moderno pueden resumirse en los siguientes puntos: 1. UML y el uso de por lo menos una herramienta de modelado. 2. Análisis, Diseño y Programación Orientada a Objetos.

3. Ventajas, desventajas y particularidades entre los principales lenguajes y tecnologías disponibles: Java, C#, .Net, J2EE, etc. 4. Bases de datos. 5. Desarrollo basado en componentes. 6. Patrones de diseño. 7. Patrones de arquitectura. 8. Estilos de arquitectura. 9. Frameworks. 10. Nuevas tecnologías y plataformas, incluyendo open source. 11. Conocimientos del hardware y sus capacidades. 12. Procesos de desarrollo de software modernos, como el Proceso Unificado. Es importante notar que los arquitectos no construyen sus planos desde cero, sino que aprovechan el conocimiento y experiencia de otros, plasmado en patrones y frameworks. Habilidades.- Además de este conocimiento, requiere contar con habilidades como las siguientes: • Capacidad de abstracción, creatividad, liderazgo, comunicación oral y escrita; negociación, disciplina y ser autodidacta. Si usted cumple con todos estos requisitos, probablemente ya es, o está muy cerca de convertirse en un arquitecto de software. Después de ver todo lo que se requiere, podemos entender porqué el programador se puede ver tentado a seguir “el lado oscuro de la fuerza” en lugar de seguir esta carrera.

Sergio Orozco es director general, consultor e instructor senior de Milestone Consulting, certiﬁcado en UML por la OMG. Carlos Macías es arquitecto en jefe, consultor e instructor senior de la misma empresa. Milestone Consulting es la primer empresa mexicana miembro de la OMG, especializada en servicios relacionados con UML: capacitación, consultoría y distribución de herramientas de modelado con dicho estándar. info@milestone.com.mx / www.milestone.com.mx

JUL-AGO 2005

www.softwareguru.com.mx

Aﾃｱo 01 No. 04

www.softwareguru.com.mx

SOFTWARE GURU CONOCIMIENTO EN PRﾃ，TICA

Julio-Agosto 2005