CAMBIO, - Delia Esquer Meléndez -...

• Análisis de Puntos de Función

• Casos de Uso

Software Guru CONOCIMIENTO EN PRÁCTICA

Año

01

No.

04

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

J

ulio

-Ago

sto

2005

Año 01 No.04 • Julio-Agosto 2005

ENTREVISTA:Carlos GonzálezDirector de Sistemas de TMM

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

CAMBIO,LA ÚNICA CONSTANTEPrepárate para BPM

TECNOLOGÍA:WiMAX

CASO DE ESTUDIO:Active Intelligence

DIRECTORIO

02 JUL-AGO 2005 www.softwareguru.com.mx 03JUL-AGO 2005www.softwareguru.com.mx

Edición EjecutivaPedro Galván

Coordinación EditorialMara Ruvalcaba

Edición y ProducciónEdgardo Domínguez

Dirección de ArteOscar Sámano

IlustraciónOmar 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

ColaboradoresAriel 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

Webmasterwww.aguilahosting.com

[email protected]+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: 04-2004-090212091400-102. Certificado de licitud de tí-tulo: 12999. Certificado de licitud de contenido:10572. ISSN: 1870-0888. Registro Postal: PP15-5106. Se imprimió en junio de 2005 en Litográfica Roma. Distribuido por Sepomex y Thunder Mail

Durante una conferencia a la que atendimos recientemente, uno de los participan-tes 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 ne-gocio. 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 respon-den a las necesidades del negocio, y no viceversa. Es una iniciativa orientada a desarrollar empresas ágiles, soportadas por sistemas de información flexibles y ajustables en tiempo real, sin necesidad del personal de sistemas.

Esto no significa que los de sistemas nos vayamos a quedar sin trabajo. Sin em-bargo, 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 [email protected]

Equipo Editorial

A >

EDITORIAL

contenido jul-ago 2005 número 04

EN PORTADABusiness Process Management (BPM)Ha llegado una nueva plataforma de misión crítica para los sistemasempresariales, los sistemas BPM. Conozcamos de que se trata estatendencia y preparémonos para el cambio.

20

Productos

LO QUE VIENE 10Problem Resolution Toolkit, BEA Aqualogic, iBolt

REPORTE DE MERCADO 12BPMS

TUTORIAL 14Ingeniería en Reversa de DB2

Prácticas

ADMINISTRACIÓN DE PROYECTOS 34Análisis de Puntos FunciónEn 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 38BPM Aplicado al Desarrollo de SWBPM se puede utilizar para diferentes tipos de procesos. En este artículo, Axel Nissim analiza su aplicación en procesos de desarrollo de SW

UML 42Casos de UsoUna 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.

Columnas

Tejiendo Nuestra Red 06por Hanna Oktaba

Mejora Continua 08por Luis Cuellar

Innovaciones en Software 41por Luis Daniel Soto

Prueba de Software 44por Luis Vinicio León

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

En Cada Número

Noticias y Eventos 04Fundamentos 48Tecnología 50Biblioteca 54Carrera 56


Entrevista 18 Carlos González, CIO de TMM

Caso de Estudio 30 Active Intelligence


NOTICIAS

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, cali-dad y alcance. El certificado en nivel 3 de CMM, coloca a Praxis como una empresa de competitividad internacional, consoli-dando nuestra capacidad para el eficiente manejo de grandes proyectos”, comentó Edmundo Robert, CEO de Praxis. La eva-luación fue realizada por José Guerrero, SEI – Authorized Lead Assessor, de la em-presa chilena América XXI.

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ér-minos de costo, tiempo, calidad y alcance.

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

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 activida-des del programa Acelera.Prosoft 2005, que tiene como objetivo principal mejorar el des-empeñ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 desa-rrolladores, 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 Secreta-rí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 mexi-cano 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

IT Outsourcing Conference 2005 - IDCEl pasado jueves 26 de Mayo se llevó acabo la 2da. edición de la Con-ferencia 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 creci-miento 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éxi-co, en realidad el outsourcing es parte de la madurez de las acti-vidades de sistemas y de la misma industria de TI”

Noticias

Inauguran Centro de Excelencia Tecnológica en Mexicali

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 prime-ra 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.

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


Julio-Agosto 2005Eventos24-26 Agosto 2005Top Software ShowMayen Project ManagementWorld Trade CenterCiudad de MéxicoInfo: www.mayen-project.com.mxTel: (55) 5536 4120Email: [email protected]

25 Agosto y 31 Agosto 2005Seminario Gratuito “Administración Integral de Tecnologías de Información y ¿Que papel juega TI con el requerimiento de Ley Sarbanes Oxley?”Itera25 Agosto - Cd. de México, 31 Agosto - Monterrey, N.L.Info: www.itera.com.mxTel. (55) 5281 7670 Email: [email protected]

31 Agosto – 2 Septiembre 2005VI Conferencia Anual “The Future of IT: La Justificación Económica de la TI”GartnerCentro BanamexCiudad de MéxicoInfo: www.gartner.com/mx/econitTel: (55) 5207 2695Email: [email protected]

11-13 Agosto 2005Xpo Linux 2005Centro BanamexCiudad de MéxicoInfo: www.expolinux.org Tel: (001) 210 8920930Email: [email protected]

11 - 13 Agosto 20051er Foro Regional Innovación y Tenden-cias TecnológicasGrand Hotel TijuanaTijuana y Ensenada, Baja CaliforniaInfo: www.tendenciastecnologicas.comTel: (664) 686-2227Email: [email protected]

24 Agosto 2005Security & Business ContinuityConference 2005IDCCentro BanamexCiudad de MéxicoInfo: www.idc-eventos.comTel: (55) 5661 3791 o 01800 504 1529Email: [email protected]

Datos de la IndustriaEmpresas mexicanas que cuentan con la evaluación Capability Maturity Model para Software* (CMM), o con la evaluación Capability Matu-rity Model Integration (CMMI), otorgada por el SEI (Software Engineering Institute)

NOMBRE

NEORIS

AZERTIA

EDS

SOFTTEK -Nearshore

ULTRASIST

SIGMA TAO

IBM - AMS

IDS

ACTIVEINTELLIGENCE

TELEPRO

PRAXIS

UBICACIÓN

MTY

DF

JUAREZ

MTY

DF

QRO

GDL

DF

AGS

DF

DF

NO. PERSONAS

600

150

200

1250

30

450

950

350

50

25

350

NIVEL CMM o CMMI

CMM 3

CMM 2

CMM 5

CMM 5

CMM 4

CMM 5

CMMI 5

CMM 3

CMM 3

CMM 2

CMM 3

FECHA

Oct-03

Feb-04

Feb-04

Abr-04

Jul-04

Nov-04

Dic-04

Dic-04

Mar-05

Jun-05

Jun-05

LEAD ASSESSOR

Mariana Pérez-Vargas, Avantare

Iñigo Garro, ESI

No reportado

Richard Storch, Dick Storch & Associates


Richard Storch, Dick Storch & Associates

Luciano Guerrero – Canada

Cecilia Montero Mejía - Empeiria Quality Services



Jose Guerrero- America XXI

Fuen

te: R

ecop

ilaci

ón d

e co

mun

icad

os d

e pr

ensa

y s

itio

s w

eb d

e ca

da e

mpr

esa.

*El m

odel

o CM

M y

a no

es

sopo

rtad

o po

r el S

EI.

**O

tras

em

pres

as e

n M

éxic

o ha

n ob

teni

do e

stas

eva

luac

ione

s, p

ero

actu

alm

ente

no

oper

an.

En mayo de 2005 se reunió por tercera vez el Inter-national 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 pue-do 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”.

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ítico-económico-tecnológicas en los próximos diez años. Una vez identificados los escenarios, se procederá a analizar el po-sible 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 pa-sadas, y se nos pidió que escogiéramos las que nos pare-cieran 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 software3. 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 pa-res 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 vo-lá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, co-mentaban que dentro de diez años el Software Engineering Institute va dedicarse a la promoción de modelos de proce-sos chinos para América. Otro tema que les preocupa es la estabilidad de las grandes empresas, en particular las tras-nacionales. 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 esque-mas 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 tra-vés de la creación de las integradoras que empiezan a multipli-carse 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 aca-lorada sobre “¿qué es proceso?”, y que conste que allí par-ticipa 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 razona-ble 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 traba-jar 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

CO

LUM

NA

06 JUL-AGO 2005 www.softwareguru.com.mx

Moda y TendenciasTercera Reunión del IPRC

TEJIENDO NUESTRA RED

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

TEJIENDO NUESTRA RED

Hace algunas semanas participé en una plática con var-ias 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 com-promiso 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 comp-rensible 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. Desafortun-adamente, 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 efi-ciencia, respeto por el trabajo bien hecho y mejora continua.

El Diablo está en los detallesOK, entonces si la certificación no es la meta, ¿cómo po-demos expresar una meta más adecuada? El principal ele-mento a tomar en cuenta es que buscar una certificación es un proceso que genera un cambio en toda la organi-zación. Normalmente requiere una reestructura de roles, actividades, forma de trabajo, y tal vez hasta una redefi-nición de los servicios ofrecidos. La idea común de “pon-gamos 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á. Imagine-mos un escenario en el que tenemos que certificarnos en seis meses, pero también debemos entregar un proyec-to 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? ¿Re-negociar 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 cam-bio no son lo suficientemente fuertes para lograrlo.

Certificarse es solamente unproducto secundarioEn 1979, Philip B. Crosby escribió un libro cuyo tema princi-pal 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 certi-ficación deben de estar íntimamente ligadas a los proble-mas más importantes que vive la organización: ¿se están barriendo los proyectos?, ¿generamos demasiados defec-tos?, ¿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 gana-rí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 certi-ficació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 prioriza-ron de acuerdo a su impacto en productividad. Como activi-dad 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 incen-tivo 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 objeti-vo 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

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.


CO

LUM

NA

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

MEJORA CONTINUA

MEJORA CONTINUA

PRODUCTOS


PR

OD

UC

TO

S

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 ren-dimiento de las aplicaciones mientras están en funcionamiento, rastreando y guardan-do detalles cuando identifica problemas de rendimiento. El Problem Resolution Toolkit permite acceder esta información, para que los desarrolladores puedan identificar rápi-damente la fuente de los problemas, minimi-zando 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 po-sibles causas y resoluciones. Este es uno de los primeros frutos del esfuerzo de “cómpu-to 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 Eclip-se, su comunicación e integración es trans-parente para el usuario.

Primeros frutos de cooperacion entre Rational y TivoliDetecció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 de-tección y reparación de errores en aplicaciones empresariales: el Problem Resolution Toolkit para IBM Rational Application Developer y el Performance Op-timization Toolkit para Rational Performance Tester.

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 in-fraestructura IT. iBolt también posee capacidades de BPM, así que las empresas pueden desarrollar nuevos procesos de negocio, crear nuevas aplicaciones compuestas e imple-mentar 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, topo-logí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 Busi-ness ONE, que integra todas las capacidades de iBolt en esta plataforma.

LO QUE VIENE

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 mo-mento 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 segu-ridad 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 cambia-do su logo y slogan, el cual ahora es “think liquid” (piensa líquido).

PR

OD

UC

TO

S

BPMSAumentando las Expectativas

El 2005 muy probablemente será recordado como el año en que los sistemas BPM despegaron. De acuerdo con encuestas realizadas en Estados Uni-

dos, BPM ha tomado el primer lugar en la lista de priorida-des de los directores de sistemas, por encima de iniciati-vas 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 comence-mos a monitorear este mercado.

HistoriaEl mercado de los sistemas BPM es relativamente nuevo. Los expertos del tema concuerdan en que los primeros pro-ductos 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 mo-nitorear 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.

TamañoDe acuerdo con información reportada por IDC en el estu-dio previamente mencionado, el tamaño de este mercado en México en el 2004 fue de 3.9 millones de dls., lo cual re-presenta 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 re-fieren exclusivamente a licencias de software.

EvoluciónEste mercado actualmente cruza un momento muy importan-te. Las expectativas están en un nivel muy alto, lo cual provo-ca que todos los proveedores quieran “subirse al barco”. Una enorme cantidad de proveedores están desarrollando “capaci-dades BPM” dentro de sus productos, y otros tantos han he-cho 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 exage-ració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 indus-tria empiece a poner atención en la tecnología en cuestió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 experimen-tación, por fin se aclara el verdadero potencial, beneficios y riesgos.• Meseta de productividad – Los beneficios reales se de-muestran 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 Esta-dos Unidos como en México.

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 expec-tativas en realidad. Los analistas consideran que los BPMS alcanzarán la meseta de la productividad en Estados Uni-dos durante el 2007. Nosotros creemos que en México ésta se alcanzará de 18 a 24 meses después.

IndustriasEl sector donde mayor adopción están teniendo los siste-mas 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 go-bierno y grandes tiendas de autoservicio (retail).


REPORTE DE MERCADO

REPORTE DE MERCADO

Carnot (www.carnot-usa.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án-dares, le da gran flexibilidad. Por ejemplo, puede funcionar sobre diversos servidores de aplicación y manejadores de base de datos. Horbis (www.hor-bis.com) es distribuidor de Carnot en México.

Fuego (www.fuego.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).

Handysoft (www.handysoft.com)BizFlow es otro BPM puro y multiplataforma. Su en-foque 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-the-box” para lograr cumplimiento de Sarbanes Oxley. Grupo Ecce (www.grupoecce.com) es distribuidor de Handysoft en México.

IBM (www.ibm.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 im-pulsores de estándares para lenguajes de descrip-ción de procesos de negocio, como BPEL. Así que este gigante está presente en todos los frentes: estándares, middleware y productos finales.

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

Software AG (www.softwareag.com)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.

Sterling Commerce(www.sterlingcommerce.com)Como parte de su plataforma MESA (Multi Enter-prise Services Architecture) para colaboración inter-empresarial, Sterling Commerce ofrece el Gentran Integration Suite. La suite está orientada a auto-matizar procesos de negocio colaborativos a lo largo de su interacción entre clientes, proveedores y otros socios de negocio.

Ultimus (www.ultimus.com)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, ge-neran y distribuyen documentos de Office.

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

www.softwareguru.com.mx

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

Hay ocasiones en las que ne-cesitamos hacer ingeniería inversa a una base de datos

existente para poder conocerla, en-tendarla y posiblemente modificarla. Esto suele suceder cuando hereda-mos una base de datos de un siste-ma legado. Veamos entonces cómo podemos utilizar Rational XDE para realizar la ingeniería inversa y gene-rar 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 ins-talació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.

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 con-tenga 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 conecta-mos 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 principalmen-te. 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.

Pasos1. En la vista del Explorador de Modelos, que se encuentra ya abierta en la pers-pectiva 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 nece-sitamos 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 ma-nualmente 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.


PR

OD

UC

TO

S

Ingeniería en Reversa de DB2 iSeriesUtilizando XDEPor Amaury Quintero

TUTORIAL

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


PR

OD

UC

TO

S

Ingeniería en Reversa de DB2 iSeriesUtilizando XDEPor Amaury Quintero

TUTORIAL

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


PR

OD

UC

TO

STUTORIAL

2. Si el servidor de aplicaciones se encuentra en otra máquina, enton-ces necesitamos un driver JDBC, de preferencia el que viene con el IBM Toolbox para Java. Este es un mane-jador 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 utilizan-do sockets sin pasar por la capa de ODBC. La clase que lo implementa es com.ibm.as400.access.AS400JDBCDriver

ConclusiónA través del modelado visual pode-mos entender mejor la estructura de una base de datos, así como sus dependencias. El modelado visual es una de las mejores prac-ticas del desarrollo de de soft-ware 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 visuali-zar 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 de-talles de manera correcta.

Referencias• IBM Developerworks www-136.ibm.com/developerworks/• iSeries Information Centerpublib.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

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.

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, posicionan-dose 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 senten-cias 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ó men-sajes de error, si es asi corrijalos y continue la ejecución.

Drivers para producciónSi 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 aplicacio-nes 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 De-veloper 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

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

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.

ENTREVISTA

Carlos GonzálezDirector de Sistemas de TMM

18 JUL-AGO 2005

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 empre-sas 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 exter-na, 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.

¿Qué te hizo regresar a TMM cuando ya te habías ido?Ahí hay una cuestión medio filosófica. Cuando me fui de ins-tructor 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.

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 por-que 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 experien-cia antes de llegar a un puesto directivo, ya que con esto será más fácil asumir una responsabilidad y lidiar con la incertidum-bre. 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 pro-yectos 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 cade-nas de suministro con nuestros clientes y proveedores para tener una interacción mu-cho más directa y eficiente.

Durante 2004 TMM redujo significativa-mente 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, don-de se está ganando dinero de manera conti-nua, 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 inefi-ciencias 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 bus-car maneras creativas de resolver las cosas. Por ejemplo, que pasa si en lugar de adqui-rir 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 pro-gramadores ahí sentados, nos apoyamos en proveedores externos.

¿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 ni-vel, 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 sufi-cientemente 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 definir-lo y justificarlo. Hoy en día ya estamos hablan-do 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 princi-palmente 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 organiza-ció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á consaber 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 ne-gocio. 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 or-questación de procesos entre sistemas era imposible, ya que tenías que meterte a las tripas de cada sistema y desarrollar procedi-mientos y llamadas a nivel de sistema ope-rativo, 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 coti-zan en el mercado de valores de Nueva York, como nosotros. Esto significa básicamente tener una definición de controles lo suficien-temente robusta para permitir a los audito-res 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é opor-tunidades 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 co-nocimiento más importante es el de ti mis-mo. 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 institucio-nes educativas y las empresas para desar-rollar la industria de software?Al gobierno, apoyo para facilitar el esta-blecimiento de nuevas empresas. A las instituciones educativas, que generen pro-fesionistas más completos, que además de habilidades técnicas cuenten con habilida-des complementarias para que puedan ha-cer una presentación, administrar el tiempo, comunicarse adecuadamente, etc. A las em-presas, mayor determinación e innovación. Frecuentemente, en México, cuando hay oportunidades que involucran riesgo, sim-plemente no le entramos. Esperamos a que llegue alguien más y lo haga. Creo que debe-mos 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 intere-santes. 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 proce-so completo de desarrollo de software.

Carlos González

19JUL-AGO 2005www.softwareguru.com.mx

20 JUL-AGO 2005

EN PORTADA

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 situa-ció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 retener-los. Por si esto no fuera poco, los mercados y las con-diciones cambian continuamente, requiriendo de las empresas rapidez de adaptación y una mayor flexibi-lidad para el cambio.

BPMUna Herramienta de CompetitividadPor Francisco López Lira

21JUL-AGO 2005

Muchas han sido las iniciativas que a lo largo de los años se han propuesto para que las empre-sas 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 Ba-lanced 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 Ge-renciales (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 re-sultados 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 tecnolo-gí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 Go-bernanza de TI (IT Governance).

¿Por qué estos esfuerzos no han tenido el éxito espe-rado? Un estudio sobre la utilización de 200 herra-mientas 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: estra-tegia, cultura, estructura y ejecución, independien-temente 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 per-mitir alcanzar los objetivos, al igual que debe crear-se 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 es-trategias: los proyectos y los procesos. Recorde-mos 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 trascen-dente 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 ca-dena 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 pre-dijo que BPM sería el siguiente gran fenómeno, y posteriormente comentó que “BPM gana la tri-ple corona por ahorrar dinero, ahorrar tiempo y añadir valor”. Otro estudio realizado por el BPM Institute arrojó que 96% de los encuestados indi-caron 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 auto-matización del flujo de trabajo, conocidas como Business Process Management Systems o BPMS. Aunque algunos opinan que BPM no necesaria-mente involucra un BPMS, en mi opinión esto le resta potencial a la solución y no permite distin-guirla fácilmente de otras propuestas como Kai-zen, por ejemplo.

El ciclo de vida de un proceso cubre su concep-tualizació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 planea-ción, seguimiento, monitoreo y control.

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


EN PORTADA

BPMSPara 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. Adi-cionalmente 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 PaquetesLos proveedores de paquetes y aplicaciones em-presariales acostumbran argumentar que sus

productos cubren prácticamente todas las nece-sidades de una organización. Sin embargo, sabe-mos que esto dista de ser verdad. Según Gartner, un ERP cubre en promedio únicamente 30% de la funcionalidad requerida en las empresas. Adi-cionalmente, existen muchas actividades que in-volucran 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 siste-mas, se crean islas de automatización que obli-gan a las personas a utilizar papel o paquetería de oficina para pasar de una “isla” a otra. Son famo-sas 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á cen-trada 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 par-ticipantes de procesos. Esto cambia el enfoque de centrado-en-datos a centrado-en-procesos.

Impacto al área de TIBPM tiene una repercusión importante para los roles relacionados con el software. Los pro-yectos 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 debe-rá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 ad-ministradores de redes deberán incluir en su administración servidores de procesos y consi-derar 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 deriva-dos. 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 debe-rán ahora brindar seguridad a todo el proceso.

Pero no todo es mayor trabajo para el perso-nal 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. Exis-ten otros modelos, como SCOR para cadena de suministro (Supply Chain), ITIL para ser-vicio tecnológico, o COBIT para el control de los objetivos. Todos ellos se basan en procesos y considera en menor o mayor grado su ad-ministración. Las diferencias cruciales, quizá sean que BPM primero lleva estos conceptos a toda la organización, y además, tomando ven-taja explícita de la tecnología para crear pro-cesos 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 pro-yectos, 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, Presiden-te 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 [email protected]

BeneficiosEn su reporte Technology Focus: Busi-ness 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 justifi-ca el costo de la solución.

BPM es la convergencia de iniciativas ad-ministrativas anteriores: toma el concepto de enfoque de procesos y de mejora conti-nua 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.

Desde hace varios años las organizaciones (empresas privadas o instituciones públicas) han ido incremen-tando 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án-dar de procesos (CRM, ERP, SCM), modelos de ges-tión del desempeño empresarial (BalancedScorecard), modelos de calidad (ISO9000:2000, TQM), métodos de mejo-ra de procesos (Six Sigma, BPR),modelos de referencia de madurezy capacidad de procesos (CMMI,SPICE), modelos de procesosespecíficos (RUP, SPEM, ITIL), entre otros.


En la actualidad, los proveedores requieren acele-rar la entrega de más valor a sus clientes y al mis-mo 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).

BPMSLa Nueva Plataforma de Misión CríticaPor Roberto Silva


EN PORTADA

A finales de la década pasada aparecieron los pri-meros Sistemas de Administración de Procesos de Negocio o BPMS (Business Process Manage-ment Systems) que permiten a las organizacio-nes mapear, integrar, liberar, medir, monitorizar, controlar, analizar y optimizar procesos de nego-cio 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 lo-gro 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 am-biente complejo de cambios constantes[1].

FundamentosConsiderando que los proveedores de soft-ware o sus representantes son especialistas en generar confusión alrededor de productos in-novadores 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 co-loca al proceso de negocio al centro de su uni-verso, es la manera moderna de administrar un negocio, donde su propósito es asegurar la mejora continua del desempeño organizacio-nal en un ambiente de cambios constantes.

Una empresa que practica BPM entiende y vive tanto la operación como el desarrollo or-ganizacional en términos de procesos de nego-cio integral y naturalmente. Los procesos de negocio son las unidades de sincronización de cambios, de generación de valor para los clien-tes, y de logro de objetivos estratégicos, más adelante ahondaré al respecto en el bloque de pensamiento sistémico.

En una organización hay tres tipos básicos de procesos de negocio. Los centrales son aque-llos procesos cuyo cliente es el beneficiario de la oferta de valor de la organización: los clien-tes 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ér-minos, por ejemplo, de mejores profesionales o mejores sistemas de información; finalmen-te 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 impor-tante en BPM. Los procesos de negocio em-presariales o EBP (Enterprise Business Process) son los vitales, ya que corresponden a las gran-des cadenas de generación de valor que invo-lucran varias entidades internas y externas a la organización (atraviesan varios departamentos funcionales, requieren el uso de diversos sis-temas y aplicaciones de software, involucran proveedores y muchas veces aliados de nego-cio) 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 or-ganizacionales) 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 para-digma del pensamiento funcional.

¿Qué es un BPMS?Desde el punto de vista BPM, un BPMS es el principal facilitador para implantar un pro-grama permanente de mejora continua en la práctica, ya que es imposible administrar sistemas tan complejos como lo son los pro-cesos 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 siste-ma 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 infraes-tructura tecnológica existente en un ambiente Web que, a su vez, permite preservar los be-neficios 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 so-luciones 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, don-de por un lado TI se enfoca al desarrollo de la infraestructura tecnológica centrada en pro-cesos 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 me-canismos internos a los sistemas o los maneja-dores 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 funcio-nales. 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 apli-caciones de software.

La Importancia del Pensamiento SistémicoDesde hace muchos años, W. Edward De-ming, 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


lado a lado son sistemas dinámicos, pero des-afortunadamente 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 tie-nen 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 pro-cesos ha sido sorteado, ya que cada proceso de negocio será entendido, ejecutado y administra-do 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 nues-tro 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, plan-teando un trayecto más amplio. ¿La segunda lista tiene algún elemento? Ahora repitamos el ejercicio, pero esta vez imaginen que se han

subido a un helicóptero y se han elevado unos 50 metros sobre el punto donde hace un mo-mento se encontraban, en este caso les propon-go 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 tradicio-nales de pensamiento funcional es que el reto de acelerar la generación de cada vez más va-lor 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, sim-plemente 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 correcta-mente para poder obtener todos sus potencia-les beneficios que a continuación abordaré. El otro elemento clave es el piloto del helicópte-ro, es decir, el pensamiento sistémico.

Plataforma de SoftwareCentrada en ProcesosLa plataforma de misión crítica predominan-te 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 mo-dificació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 sus-tituimos 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 relacio-nales. Para el caso de los BPMS su éxito tiene el mismo nivel de sustento en la misma cien-cia, 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. BPMSEn 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 gene-ral 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 repor-tes 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

Figura 1. Infraestructura de

Software de Misión de Crítica


EN PORTADA

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 exclusiva-mente 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.

el paradigma tradicional del pensamiento fun-cional que ha mantenido separados a los de-partamentos 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 ne-gocio 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 tra-bajo que ejecutan procesos, fortaleciendo el en-tendimiento, la comunicación y su aportación al logro de la estrategia organizacional.

Dimensiones de un BPMSEl motor de procesos (corazón de un BPMS) es representado por un cubo, donde la cara superior representa la dimensión correspon-diente a la capacidad central de orquestación de procesos de negocio, la cara izquierda re-presenta 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 or-ganización.

La orquestación de procesos de negocio es la capacidad de coordinar la ejecución de cade-nas 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 gene-ración de resultados tangibles para un clien-te 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 proce-sos es la capacidad de integrar sistemas exis-tentes, 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 des-acopladas entre sí, es decir, ya no se comuni-can 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 aso-ciados son minimizados, de hecho, esta es la base conceptual de SOA.

La dimensión de colaboración representa la capacidad organizacional para ser parte inte-gral de cadenas de generación de valor más amplias donde nuestros procesos de negocio empresariales pasan a ser subprocesos de pro-cesos de negocio intercompañía con un po-tencial mucho mayor. La disponibilidad de

Figura 2. Administración de Procesos de Software Orquestados

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 Em-presarial Centrada en ProcesosEl 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 en-foque 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 pro-cesos. 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 me-jora continua de las capacidades organizacio-nales requeridas para afrontar estos retos con éxito. Especialmente es destacada su aporta-ción directa para el desarrollo de las capacida-des “agilidad” y “adaptación”.

Referencias1. Roberto Silva, “Negocios Ágiles”. Impulsare e-zine. www.impulsare.com2. Howard Smith and Peter Fingar, Business Process Management: The Third Wave, Meghan-Kniffer 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.org5. OASIS. www.oasis-open.org


Por más de 15 años me he dedicado al desarrollo de sis-temas con lenguajes de pro-gramació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.

BPMDesde la Perspectiva de

un DesarrolladorPor Ernesto Méndez Solís


EN PORTADA

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

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 en-cargan de la administración y metodología del proyecto, otros más del análisis, diseño, mode-lació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 pro-ceso administrativo de una empresa dedicada a la comercialización, industria perteneciente al sector conocido como retail.

Así que me integré al equipo, que estaba con-formado por tres diferentes empresas y fui asig-nado a la fase de desarrollo. Solo requería tener conocimientos básicos de programación orien-tada 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 he-rramienta de desarrollo, es un ambiente de tra-bajo. 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, administra-dor de componentes, administrador de la or-ganizació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 com-plicado preparar el ambiente de operación y desarrollo, inclusive el de desarrollo se puede preparar en un solo equipo para poder traba-jar en forma independiente y aislada para pos-teriormente poder desplegar el proceso en el ambiente de producción.

Recuerdo que en alguna ocasión me tocó pro-gramar aplicaciones del tipo “flujo de trabajo”

utilizando lenguajes de programación conven-cionales. Esto representó un reto algo diferen-te al de cualquier otro tipo de desarrollo, pero nada que impidiera alcanzar finalmente el éxito y la automatización del proceso correspondien-te. Sin embargo, los BPMS están específica-mente 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 tra-dicionales enfrentan al pretender automatizar un proceso. En este caso, la clave es “mode-lar 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 proce-so 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 funda-mental a considerar al momento de modelar es lo que se denomina una “instancia”. Las ins-tancias 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 fi-nal. Paralelamente, el sistema almacena la in-formació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 fac-tores 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 parale-los que permitan posteriormente la reintegra-ción de la instancia en una actividad posterior.

Considerar todos estos factores para poder mo-delar un proceso, resulta ser una tarea no muy fácil cuando no se tiene experiencia y se esta

acostumbrado al proceso tradicional de desa-rrollo 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 con-ceptualización y análisis cuando se utilizan herramientas BPMS. Para contextualizar, equivale al cambio de paradigma que los pro-gramadores de la vieja guardia tuvimos que hacer cuando pasamos de la programación es-tructurada a la programación orientada a ob-jetos. 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 al-terno. 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 enten-der el concepto de modelado de procesos.

Una vez superada esta primera fase del proce-so, 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 cier-ta 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 len-guaje 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 cual-quiera 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-

formación mucho más complicados en forma relativamente sencilla para solicitar informa-ción al operador e ir automatizando el proce-so 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 inter-cambiar información o lanzar procedimientos externos para conseguir automatizar en mayor medida el proceso. Por ejemplo, se puede cap-turar información desde una de estas panta-llas (incluyendo sus procesos de validación) y posteriormente ejecutar un sistema “legacy” el cual requiere de la información recién captu-rada, la que le es enviada de forma transparen-te. Este tipo de actividades, consiguen que los operadores o participantes del proceso, inte-ractúen con un solo sistema sin necesidad de tener que usar diferentes aplicaciones e inter-faces 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 pre-cisamente cumple con el objetivo fundamen-tal 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 siguien-do el flujo de una instancia e ir evaluando las diferentes variables que intervienen en el proceso, facilitando sustancialmente la libe-ración de procesos libres de errores. Cuando pudiera parecer que la automatización del proceso ha terminado, ésta solo ha inicia-do en realidad. Cuando un proceso esta en producción, la fase más importante es pre-cisamente la de evaluación para entonces detectar mejoras, cuellos de botella y la justi-ficación de reingenierías de proceso.

El ambiente colaborativo bajo el que operan este tipo de desarrollos, intranets y/o extra-nets, ofrece interfaces nítidas y claras para to-dos los involucrados, fáciles de operar y con una curva de aprendizaje muy corta que per-mite en muy poco tiempo poder administrar eficientemente los procesos. Desarrollar una aplicación que permita realizar todas estas ta-reas y controles utilizando lenguajes de pro-gramación tradicionales resulta en proyectos muy costosos, de muy difícil mantenimiento,

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

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.

ConclusiónEl 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 he-rramientas exige a sus diseñadores y desarro-lladores, 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 dis-ponible hoy en día en el mercado.

CASO DE ESTUDIO


En tiempos donde los márgenes de utilidad se ven amenazados cada día mas y la competencia contra proveedores mundiales de software se ha convertido en una guerra de precios interminable, Active Intelligence, una compa-ñía con 50 integrantes y un año de historia, consigue el reconoci-miento de nivel 3 basados en el modelo SW-CMM®

La historia de Active Intelligence es una his-toria que vale la pena contar, pues muestra como al enfocar el esfuerzo en lo que es im-portante, los resultados que se pueden ob-tener son muy buenos, además pone el dedo en el renglón para que más compañías mexi-

canas con recursos económicos limitados, tomen la decisión de marcar una diferencia en la manera en como se construye software en México, contribuyendo a poner a todo el país en el mapa para los mercados globales.

¿Cómo se logró?Sin duda el esfuerzo bien enfocado detrás de cualquier iniciativa es la clave para obte-ner los resultados esperados. Este caso no es la excepción, sin embargo, vale la pena desmenuzar un poco la estrategia y carac-terí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,

convencimiento y entusiasmo del personal y los procesos enfocados y adaptados a la forma de trabajar de Active Intelligence.

La historiaActive Intelligence nació en Aguascalientes, fundada y dirigida por Humberto Sánchez Sandoval y Abraham Ramírez Basurto; el objetivo organizacional es la proveeduría de servicios de exportación de segunda capa en modalidad de fábrica de software y tiene como principal objetivo el ofrecer desarro-llo de soluciones de software a distancia. El Ing. Sánchez, cofundador en 1988 de Dde-mesis (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-

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

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.

sis fue vendida, ocasionando un movimiento importante de profesionales buscando nue-vas 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 co-laboradores con experiencia en la implemen-tació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 vincula-ción importante y selectiva con las Universi-dades de Aguascalientes; de este modo se formó el equipo de trabajo que actualmente figura entre las filas de la compañía.

La visiónLos 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 pro-ductos 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 delprograma de mejoraBasados en esta visión, se inició el progra-ma de mejora como un proyecto cuyo objeti-vo era definir e implantar procesos basados en el modelo SW-CMM® hasta el nivel 3; sin embargo, no se contaba con recursos espe-cí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 obten-drían no sólo a nivel de cada proyecto sino a nivel organizacional, mientras el segundo, era una persona sin experiencia, ni entrena-miento en el modelo, mucho menos en pro-cesos 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 me-jora en Active Intelligence y se bautizó como AMM (Active Maturity Model). El camino se veía complicado.


Se buscó el apoyo del Gobierno Federal mediante el programa ProSoft y se recibieron ayudas económicas para formación de personal.

Después del entrenamiento interno inicial, se planeó la forma en que la meta se cubri-ría. Se iniciaron las actividades de definición y se preparó el entrenamiento para los cola-boradores. 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 di-ficultades en la implantación, sin mucho que obtener a cambio. Estábamos atorados.

La tormenta pasó, sin lugar a dudas el apo-yo de la dirección fue pieza clave en la re-solució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.

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 Pro-Soft 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 pro-grama de calidad tenía nuevas y más retadoras metas. Los recursos permi-tieron tener acceso a la consultoría ex-terna, y además la implantación no se quedaría solo en eso, pues se busca-ría el reconocimien-to formal del nivel 3. La compañía estaba entusiasmada.

Dada la buena expe-riencia en Ddemesis y su reconocida ca-pacidad, Avantare fue elegida para

formar parte del proyecto, con ellos se hicie-ron revisiones documentales a los procesos, verificación de la implantación en los pro-yectos, evaluaciones informales (simulando actividades de la evaluación formal) y forma-ció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 evaluaciónMariana Pérez-Vargas, Directora General de Avantare, fue el Lead Assessor de la evalua-ció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 finalmen-te había muchas cosas que dependían de un resultado positivo en la evaluación CBA-IPI®, (CMM Based Appraisal for Internal Process Im-provement) 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 opor-tunidades de mejora podían afectar de manera

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 cul-tura organizacional. El entusiasmo en las re-visiones 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 organiza-ción está no solo con sus clientes, si no también con todos aquellos que de alguna forma colabo-raron 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 compartirSin lugar a dudas el caso de Active Intelli-gence 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 referen-cia a seguir. Sin embargo, ahora que Rafael les ha contado la historia y evolución de la implantación de SW CMM en Active Inte-lligence, a mi me gustaría compartirles al-gunos factores, desde el punto de vista de Avantare y como consultor en programas de mejora, que me parece importante enfati-zar 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án-chez 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 organizacio-nes, sobre todo cuando se trata de organi-zaciones 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 nece-sita. En Active Intelligence, el grupo de mejo-ra buscó ante todo, que los procesos fueran funcionales para el trabajo diario de los pro-yectos. 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 permi-tieran cumplir con las exigencias del mode-lo, 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 ha-cí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 lo-grando 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 impor-tancia 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 compro-metidos 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 inmedia-tas, sino para aquéllas que vendrían después, mas allá de la evaluación, manteniéndose in-mersos en un proceso de mejora que les exigi-rí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 me-jora de Active Intelligence, donde todo el per-sonal, 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 cum-plir, siempre hay niveles, marcas y records que lograr. Cuando se con-junta el liderazgo, el equipo, la mo-tivació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 verificación de productos de software y mejora de procesos para la industria de TI.

En 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ónEsta métrica se define como una métrica funcional, dado que se en-foca 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 sis-temas informáticos basada en la cantidad de funcionalidad requeri-da 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 usua-rio pueda realizar transacciones (lectura, escritura, etc.) y guardar datos. Si analizamos a detalle, con estos elementos podemos des-cribir 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 ISOLa 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í po-derla usar a nivel industria. Poder comparar la productividad (Puntos Función por Persona Mes) de una empresa con los datos de la indus-


PRÁCTICAS

ADMINISTRACIÓN DE PROYECTOS

Por Sergio Durán

MÉTRICASDE TAMAÑO DE SW BASADAS EN FUNCIONALIDADParte 2: Análisis de Puntos Funció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 con-ceptos de una métrica de tamaño basada en la funcionalidad y las características que debe cumplir un método para estar homolo-gado al estándar y ser considerado una me-dida del tamaño de la funcionalidad.

Existen varios métodos de conteo para es-tablecer la cantidad de Puntos Función que tiene una aplicación. En general, todos esta-blecen 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 va-riantes surgen al buscar conteos más preci-sos en Puntos Función conforme al tipo de aplicación. Por ejemplo, un sistema en tiem-po real tiene una complejidad muy distinta a un sistema tradicional de negocio o a un sis-tema 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 enginee-ring - 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 certifica-do 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.


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, simplifican-do 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 measure-ment method. Este método ha sido definido por el Common Software Measurement Inter-national Consortium, integrado por expertos de Australia, Canadá, Finlandia, Alemania, Irlanda, Italia, Japón, Holanda y el Reino Uni-do. La idea principal es adecuarse mejor a la medición de sistemas en tiempo real.

El Método de Análisis de Puntos FunciónLa 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 gru-pos 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 componen-te 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 con-ceptos mencionados y conocer su simplicidad.

Procedimiento

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

Paso 3. Contar las funciones de datos. Este paso consiste en identificar y contar la capa-cidad de almacenamiento de los datos. Se distinguen dos tipos de funciones de datos:

Archivo Lógico Interno.- Es un grupo de da-tos 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 da-tos relacionados y referenciados pero no mante-nido por alguna transacción dentro del conteo. A cada componente identificado se le asigna una complejidad (baja, media o alta) conside-rando 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 distin-guen tres tipos de funciones transaccionales:

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

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

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

Bajo Medio Alto

EI 3 4 6 EO 4 5 7 EQ 3 4 6 ILF 7 10 15 EIF 5 7 10

Paso 6. Determinar el valor del factor de ajuste. El factor de ajuste se obtiene su-mando 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 ajus-tados. Para determinar los puntos función ajustados se consideran los puntos función no ajustados por el factor de ajuste.

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

En nuestro caso, Puntos Función está enfoca-do a medir sistemas informáticos completos, no programas. En este sentido no tiene un nivel de precisión suficiente para medir el ta-mañ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.

Otro punto que se le ha criticado a las métri-cas 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 pro-grama 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 cer-tificación como el del IFPUG, donde hay una evaluación formal de la teoría y casos prác-ticos. 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 pro-yectos o aplicaciones completas, entonces las pequeñas variaciones en un conteo, no van a ser significativas para los indicadores o datos relacionados que obtengamos.

Comprar SW por Puntos FunciónLas compras de SW son en muchos casos desarrollos a la medida. Pero ¿cómo com-prar si todavía no se tiene el diseño? Una opción que habilita una métrica como Pun-tos 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 Gobier-no, la ley de adquisiciones permite hacer compras basadas en estándares internacio-nales, que como vimos, ya existen en este te-rreno. 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 ne-cesarias 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 pro-yectos de SW va a empezar a cambiar en la medida que los compradores lo exijan. Es por eso muy importante que los comprado-res analicen que sólo comprar por precio sin distinguir tamaño de las aplicaciones para escoger a un proveedor que tenga ex-periencia con esa complejidad o indicado-res 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 pre-supuesto o, en el peor de los casos, nunca llegan a operación.

Se requiere un modelo que permita iden-tificar capacidades de los proveedores, para entonces poder comparar propuestas de proveedores de capacidad similar. “Los proyectos nacionales en informática re-quieren de empresas con capacidades rea-les y funcionarios/ejecutivos competentes y exigentes”.

Ya empieza a haber proyectos que, como parte de sus bases para invitar a provee-dores, 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 es-tá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.

PRÁCTICAS



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


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.

Uno 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 estra-tegia 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 embar-go, 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 den-tro 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 desarro-llo 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 ar-quitecto 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 retroa-limentación, hacen esfuerzos heroicos para adi-vinar 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, con-tengan 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 flu-jo 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 de-berá 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 indispensa-ble), y eficientes. La implementación de CMM tiene como resultado la eficientización de los procesos, identificando las áreas clave, cue-llos 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éra-mos pensar que los proyectos de TI fracasa-dos 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 tra-bajo es el empleo de metodologías BPM den-tro 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 traba-jo para el desarrollo de software se centran en la documentación extensa y el modelado, siendo éste una extensión misma de la docu-mentación. El modelo es el sistema, la docu-mentació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 solu-ción incluye una herramienta gráfica de diseño y navegación de procesos, capacidades de simu-lació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 co-múnmente se definen a partir de los diferen-tes milestones o hitos a los que va llegando el proyecto, los cuales a su vez se definen a partir de los artefactos programados para

Por Axel Nissim

BPMAPLICADO AL DESARROLLO DE SOFTWARE

PRÁCTICAS

PROCESOS

cada fase. La realidad es que en el desarro-llo 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.

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 has-ta 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

proyectos se basan en un enfoque jerarqui-zado 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 eficiencia de los procesos en el desarrollo de software queda incompleta aún imple-mentá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 per-mita 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 competen-cias de cada individuo, sus habilidades, inte-reses y hasta sus metas particulares.

BPM es un esfuerzo encaminado a la flexibi-lidad y el tiempo de respuesta ante condicio-nes 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 comprado-res del sistema) y nuestros clientes internos (las personas trabajando en otros módulos o fases del desarrollo del sistema).

El modelo es el sistema, la documentación es el sistema y, por supuesto, el código es el sistema.

¿Qué pasa si a la mitad del análisis nos da-mos cuenta que uno de los artefactos sim-plemente 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 inme-diata o esperada? Los verdaderos posee-dores 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 ma-nera colectiva— el mantenimiento de una base de conocimientos común que permita el intercambio sin fronteras de la informa-ción hacia adentro. El mantenimiento de los vínculos para la fluidez de esta información, es responsabilidad de los arquitectos, admi-nistradores 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 soft-ware, sólo comparable en importancia con nuestros recursos humanos calificados. Es por esto que toda implementación que pla-nee hacer uso de las herramientas de BPM en el ámbito del desarrollo de sistemas, dependerá primordialmente del nivel de so-porte a las comunicaciones inteligentes y la transferencia del conocimiento entre diver-sos “keyplayers” en diferentes áreas.

Lo ideal, en el sentido de la comunicación, serían herramientas que fueran indepen-dientes 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 herra-mienta deberá ser sensible socialmente a las relaciones mantenidas por parte de los dife-

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 movili-dad 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 hipervin-culado, 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 res-ponsabilidad no sea congruente. Siempre habrá posibilidad de que el administrador de la configuración reciba un reporte de incon-gruencias 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 co-hesivas 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 lue-go simulaciones, o viceversa. Nuestras herra-mientas 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ánda-res documentales que nos permitirán obte-ner 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 tiem-po, 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 comu-nicación organizacional, y sin tener que pasar por muchos eslabones redundantes que única-mente fiscalizan el proceso sin aportar nuevos conocimientos o valor.

Los elementos necesarios mínimos que debe de incluir una solución BPM para el desarro-llo de software son los siguientes, sin un or-den 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 docu-mentación estandarizada.

• Formación de equipos de trabajo cohesi-vos 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 defini-ción de procesos.

• Herramientas de reporteo y seguimiento de los procesos en tiempo real.

• Middleware que permita conectar las di-ferentes partes, sistemas, y equipos de tra-bajo, con un enfoque orientado a procesos dinámicos.

• Herramientas de comunicación colaborati-va 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 trans-parente, independiente de organigramas, y que busquen la participación indistinta de las perso-nas que poseen el conocimiento.

PRÁCTICAS

PROCESOS


La comunicación es, por mucho, el activo más valioso dentro del desarrollo de software

CO

LUM

NALa “Revolución” del BPM

Pasado, Presente y Futuro

La forma de hacer negocios cambia constantemente. Los Procesos que soportan la or-

ganización son altamente dinámicos. Gartner piensa que el futuro de la con-strucció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.

PasadoEn un principio se pensó que los proce-sos 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 mu-chos Workflow Management Systems (WFMS) lograron rebasar la vista cen-trada en documentos, el problema prin-cipal 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 aun-que 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?

Claramente los distintos WFMS traba-jan en formas diferentes, aun cuando la Workflow Management Coallition (WfMC.org) ha tratado de unificar las normas. Este hecho ha limitado fuer-temente 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.

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

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

PresenteRecientemente ha aparecido una nueva categoría de software, los Bu-siness Process Management Systems (BPMS), como el WFMS o Relatio-nal Database Management Systems (RDBMS).

Los BPMS son la búsqueda de una maquinaria universal de procesos. Hoy por ejemplo, los WFMS no pue-den sustituir el correo electrónico. Ex-traño porque el correo electrónico se puede considerar un proceso muy co-mún hoy en día: es un proceso simple de recibir y enviar con el que adqui-rimos 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.

Otro factor no considerado en los WFMS es la movilidad, como lo de-mostró 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 cu-yas relaciones y vínculos evolucionan como resultado, determinando qué se conoce, quiénes se conocen y qué se ha encontrado.

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

de cualquier tipo y que no se basa en comunicaciones sino en transforma-ciones a sí mismo.

El BPMS se compone de herramien-tas de modelado, maquinaria de eje-cución, herramientas de agilidad para alterar procesos, herramientas para monitorear y administrar los proce-sos, y herramientas de análisis que permitan medir la eficiencia de los procesos (ahí la relación con Six Sig-ma y procesos de mejora continua). Intalio fue el primer proveedor en im-plementar este modelo.

FuturoEs claro que, dada la capacidad de co-municació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 propie-dad, administración y operación de un proceso a un tercero: Quien mon-ta una nueva empresa puede preferir enviar al exterior un proceso de re-cursos humanos en lugar de hacerlo ellos mismos. Ese proceso debe ser de excelencia pero no se desea reali-zar 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 opera-ció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

Luis Daniel SotoMaldonado es Direc-tor de Evangelización en Nuevas Tecno-logías en Microsoft México. Entre sus fun-ciones actuales están la administración de la relación con el Go-bierno 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 INDAU-TOR/SEP y fundador de diversas asocia-ciones de Tecnolo-gías de Información (TI) relacionadas a inteligencia competiti-va, administración del conocimiento y cons-trucción de software. Luis Daniel Soto es Ingeniero en Sistemas de la Fundación Arturo Rosenblueth y ganó el primer lugar en el concurso na-cional para software de exportación en 1989. blogs.msdn.com/luisdans


INNOVACIONES EN SOFTWARE

¿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 com-plicado 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 desa-rrollo 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ónde RequerimientosUna 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 tie-nen el éxito que deberían, se debe a una mala administración de requerimientos. Esto gene-ralmente se da por falta ya sea de habilidades en el personal responsable o de técnicas apro-piadas 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 cam-bios. 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 re-querimientos 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ára-mos a lo primero, entonces en lugar de llamarle consultoría a nuestro trabajo, deberíamos lla-marle manufactura de software, donde uno im-plementa las funciones exactamente como se las solicita el cliente, cuestionando nada o muy poco, tal como se haría en una planta manufac-turera donde se reciben las especificaciones del producto a construir.

El Sistema y su MisiónSi queremos desarrollar el mejor sistema po-sible, 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 Acto-res (más adelante veremos otros tipos de Actores que también tendremos que identificar).

Buscando los Beneficiosdel SistemaUna vez identificados los usuarios del sistema (actores primarios) habrá que preguntarles en qué situaciones valdrá la pena para ellos utilizar-lo. 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 situa-ciones. Ejemplo: un vendedor en cierto sistema de ventas querrá “Registrar venta”, “Registrar

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

Diagrama de casos de uso para el sistema de venta.

Los Requerimientos FuncionalesNormalmente 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 sim-ple como elegir una opción en el sistema, y con-tinú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 fun-cionalidad del sistema para alcanzar objetivos

PRÁCTICAS

UML


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

Y EL VALOR DEL SISTEMACASOS DE USO Por Sergio Orozco

importantes. Lo que estamos obteniendo así es una especificación de requerimientos funciona-les mediante un análisis top-down (de lo gene-ral 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 relevan-tes para alcanzar la misión del sistema.

Pasos para recopilar los requerimientos funcionales adecuados del sistema medi-ante 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 SistemaHay otro tipo de actores que también hay que modelar; los actores secundarios. Sue-len ser otros sistemas, componentes exter-nos 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 nues-tro 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 SecundarioNuestro sistema de ventas podría re-querir enviarle información al sistema de contabilidad cuando se ejecuta la funcionalidad del caso de uso “Gene-rar 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 po-cos 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 comunica-ción entre quienes solicitan el sistema y los que participan en su desarrollo. En otras oportunidades veremos ele-mentos 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 elemen-tos más básicos.

CASOS DE USO

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

Las descripciones de algunos conceptos que expon-dré en el presente, si bien son generalizables, estarán enunciados desde la perspectiva de la técnica denomi-nada “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 com-plejidad innecesaria.

DefinicionesComplementando nuestro primer acercamiento a una defi-nició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 fa-llas detectadas [1].

Precisemos cada uno de los conceptos de esta definición. Intuitivamente, un proceso puede verse como una secuen-cia de actividades, cada una de las cuales genera produc-tos, 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 se-ría el siguiente, que refinaremos en números subsiguientes:

1. Establecer alcances, entregables y criterios de éxito2. Estimar el esfuerzo de prueba3. Planear el proyecto

4. Reproducir el contexto del SUT5. Hacer

a) Diseñar casos de prueba b) Aplicar casos de prueba c) Reportar métricas y dar seguimientod) 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 ante-riores son cobijados bajo el acrónimo CAST (Computer Aided Software Testing).

En cuanto a los casos de prueba, es deseable que presen-ten 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 eviden-cia 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ónLos 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

CO

LUM

NA


Fundamentos de la Prueba de SoftwareConceptos, Justificación y Alcance

PRUEBA DE SOFTWARE

Luis Vinicio León Carrillo es profesor-in-vestigador del Departa-mento 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 forma-les 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 eficiente y efectiva la prueba de software. Luis Vinicio es co-fun-dador del Capítulo Gua-dalajara de la AMCIS y su Secretario actual.

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 certidum-bre en el comprador de software, y mini-miza riesgos.• Disminuir la penosa y costosa labor de soporte a usuarios insatisfechos, conse-cuencia de liberar un producto inmaduro. Esto puede mejorar la imagen de la orga-nizació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. seguimien-to a estándares, legibilidad del código, in-tegració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 de-sarrolladores (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 pro-yecto se salga del tiempo y presupuesto planeado, pues se podrán detectar más problemas originados en las fases tem-pranas del proceso, que son los que ma-yor impacto tienen.

AlcanceLa prueba de software tiene limitantes, tan-to 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

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 sen-cillamente inmanejable; es necesario entonces utilizar técnicas adecuadas para maximizar la cantidad de fallas im-portantes encontradas con los recursos asignados. Cada método que se utilice para detectar defectos deja un residuo de defectos más sutiles contra los cua-les 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 pro-yectos 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

Referencias1. www.e-quallity.net pestaña Defi-niciones - Conceptos2. Pressman, R.: Ingeniería de Software. Un Enfoque práctico. McGraw-Hill; 19933. Kit, E.: Software Testing in the Real World. ACM Press, 1995


Los negocios o empresas hoy en día están preocupados por lograr la eficiencia organiza-

cional 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. 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 em-bargo, 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 poste-riormente automatizar dichos procesos en una aplicación computacional y fi-nalmente proveer a los gerentes del ne-gocio con la posibilidad de monitorear y analizar la operación de dichos pro-cesos. Esto permite resolver problemas en el momento en que ocurren. Resulta muy importante que una pla-taforma 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 auto-matización de procesos. Los negocios están inmersos cotidianamente en cambios constantes, tanto por activi-dades internas como externas, por lo que una plataforma de administración de procesos de negocios debe ser ca-paz de responder a estos cambios.

La administración de procesos de ne-gocio es llevada a cabo con diferentes herramientas utilizadas para captu-rar, modelar, diseñar, integrar, probar,

implantar, medir y mantener diversos procesos de negocio en una empresa. Los procesos de negocio centrales de-finen el negocio y proporcionan la po-sibilidad de satisfacer y retener a los clientes, de maximizar las alianzas con otras empresas y de obtener resultados extraordinarios con respecto a la com-petencia. Al administrar los procesos de negocio se evitan prácticas inconsis-tentes de peticiones de cambio en apli-caciones computacionales, se asignan roles que ayudan a los clientes a definir los permisos de uso y acceso a la infor-mación, junto con las aprobaciones a los cambios en cada proyecto.

BPM permite definir colectivamente los procesos de negocios, implantarlos en forma de aplicaciones computacio-nales, de tal forma que los adminis-tradores puedan monitorear, analizar, controlar o mejorar la ejecución de di-chos procesos en tiempo real. Para im-plantar BPM se requiere entender en forma detallada la interacción de los diversos procesos de negocio existen-tes, así como poseer el conocimiento acerca de cómo fueron desarrolladas las aplicaciones computacionales co-rrespondientes. 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 repre-sentantes de los procesos de negocios y de las aplicaciones computaciona-les, y esta interacción continúa aún después de la implantación, ya que debe proveerse mantenimiento a di-chas aplicaciones. Por ejemplo, aque-llas personas que realizan diagramas de flujo con herramientas como Visio o PowerPoint, también deben ser capa-ces de modelar procesos de negocio usando un BPMS. Luego se debe de poder comentar el proceso de nego-cio y pasarlo a los técnicos para su implantación. La habilidad de definir procesos con sus reglas de negocio, integrar aplicaciones computaciona-les 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 ne-gocio se les dificulta la comprensión de los detalles o la perspectiva de la tecnologías de la información —po-tencial de uso y funcionalidad—, y a los técnicos se les dificulta el apre-ciar 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 op-timizació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 represen-tatividad en el equipo formado con tal fin, que garantice el desarrollo de una aplicación computacional que efecti-vamente apoye objetivos de negocio, que estén sustentados en procesos de negocios auténticos, y que ayuden en el monitoreo. Dicho personal debe de-mostrar tener experiencia de campo, con usuarios por un lado y con las apli-caciones computacionales por otro.

-Dr. Ralf Eder L.

CO

LUM

NA


BPMEl Impacto en el Desarrollo de Software Aplicativo

CÁTEDRA Y MÁS

El Dr. Ralf Eder Lange es Profesor Consultor-Extensionista del Depar-tamento de Sistemas de Información en el Tec de Monterrey, Cam-pus Estado de México, donde ha sido Director de los Programas de Graduados en Ciencias Computacionales y Sistemas de Informa-ción, y Director del Centro de Investigación en Informática. Sus áreas de especialidad incluyen Reingeniería de Procesos y Administra-ción de la Innovación Tecnológica. Ralf es miembro fundador de la Asociación Latinoame-ricana y del Caribe de Sistemas de Informa-ción (LACAIS).

Referencias• Learn Data Modelingwww.learndatamodeling.com/b_manage.htm• Serena Software - BPMwww.serena.com/business_pro-cess_management.html• Savvion - BPMwww.savvion.com/business_pro-cess_management.php

CÁTEDRA Y MÁS

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 (Pro-ject Management Institute). Algunos años después, en 1986, se publicó como un libro que contenía la estructura general que cono-cemos 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 Fundamen-tos de la Dirección de Proyectos general-mente reconocido como buenas prácticas”. —PMBOK pág. 3

Grupos de ProcesosLos Grupos de Procesos son guías para apli-car 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 in-dustria o aplicación. El PMBOK define cinco grupos de procesos:Iniciación.- Aquí se define y autoriza el pro-yecto 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 cos-to del proyecto o fase del mismo.

Ejecución.- En este grupo de procesos se in-tegra 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 correcti-vas o preventivas cuando sea necesario para cumplir con los objetivos del proyecto. Aquí se lleva el control de los cambios al proyec-to que asegura que los mismos son benéfi-cos 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 produc-to, 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 es-tán clasificados por Área de Conocimiento.

Áreas de ConocimientoPara 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 so-breponer una sobre la otra o interactuar entre sí de maneras muy diversas. Las Áreas de Co-nocimiento definidas en el PMBOK son:Gestión de la Integración del Proyecto.- In-cluye los procesos y actividades necesarios para identificar, definir, combinar, unificar y coordinar los distintos procesos y activi-dades de dirección de proyectos dentro de los Grupos de Procesos de Dirección de Pro-yectos. La necesidad de integración se hace evidente en situaciones donde procesos in-dividuales interactúan.Gestión del Alcance del Proyecto.- Incluye los procesos necesarios para asegurarse que el proyecto incluya todo el trabajo requeri-

Como su nombre lo indíca, el PMBOK (Project Management Body of Knowledge) Guide es un documento que reúne el co-nocimiento relacionado con la Dirección de Proyectos. La ver-sió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 ac-tualmente en su tercera edición, liberada a finales del 2004.


FUN

DA

ME

NTO

S

PMBOK GuideGuía de los Fundamentos de la Dirección de ProyectosPor Ramón Hernández

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 financiero. Ramón es PMP certificado desde 1999 y colabora en el capítulo del PMI en la Ciudad de México.

Iniciación

Planificación

Control Ejecución

Cierre

Grupos de Procesos

do, y sólo el trabajo requerido, para terminar un proyecto de manera satisfactoria, básica-mente es controlar lo que está incluido en el proyecto y lo que quedará fuera del mismo. Aquí se desarrolla la especificación del tra-bajo, 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 acti-vidad y la duración de las mismas. El produc-to 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 pro-yecto, 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 acti-vidades que determinan las políticas, objeti-vos y responsabilidades relacionadas con la calidad del proyecto que satisfaga las nece-sidades por las cuales se originó.Gestión de los Recursos Humanos del Proyec-to.- 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 Proyec-to.- 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 des-tinar 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.

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 con-trarios al éxito del proyecto. Los riesgos son eventos o condiciones inciertos que, en caso de ocurrir, tienen un efecto positivo o negati-vo sobre alguno de los objetivos del proyecto, ya sean tiempo, costo, alcance o calidad.Gestión de las Adquisiciones del Proyec-tos.- 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 le-gal entre un comprador y un proveedor, asu-miendo que el comprador forma parte del equipo del proyecto y el proveedor no.

ConclusiónDe 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 necesi-dades de los clientes. Si mezclamos el SWEBOK (ver sección Funda-mentos de SG Año 01 No.01) con el PMBOK, tendremos dos excelentes documentos que nos permitirán es-tablecer 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


Qué esperar de una red WiMAXWiMAX es una nueva alternativa para la construcción de redes inalámbricas, pero con mayores beneficios. Algunas venta-jas 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 Ether-net, Token Ring, FDDI, Cable MODEM, etc.

En su primera etapa de implantación, WiMAX sólo estará disponible para los carriers, (compañías que ofrecen servicios de tele-comunicaciones como telefónicas e ISPs) y grandes corporativos, para que puedan me-jorar el servicio que ofrecen a sus clientes. La cobertura de la tecnología WiMAX se me-dirá 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 ininte-rrumpido en toda una ciudad.

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 es-tación base. Obviamente esto disminuye el


TECNOLOGÍA

WiMAX, del inglés Worldwide Interoperability for Microwave Access, es un estándar para transmisión ina-lá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.

WiMAXEl siguiente paso en redes inalámbricasPor Ariel García

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

Las ventajas de WiMAXLa tecnología podría proveer accesos com-partidos de hasta 70Mbit/s. Esta capacidad es suficiente para soportar más de 60 enla-ces 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 cali-dad de servicio al balancear la asignación de ancho de banda en base a las necesidades de cada subscriptor de la estación; por ejem-plo, si algún suscriptor está realizando una descarga de archivos que tiene una veloci-dad promedio de 80Kb/s y tiene contratado un enlace de 256Kb/s, la estación base sólo

Bandas (Mhz) Actuales y Autorizaciones Vigentes* Nuevas Aplicaciones (Diseñadas para convivir con atribuciones previas)

2400-2483.5 ICM (aplicaciones industriales, 802.11b/11Mbps, científicas y médicas), teléfonos inalám- 802.11g/54Mbps, bricos, enlaces p-p y p-mp (espectro 802.20/1 Mbps/movilidad, disperso), telemetría, sistemas Bluetooth, Home RF multiacceso telefonía rural, tx de datos, ps/movilidad, hornos y enlaces de microondas. 802.16/70 Mbps/movilidad.

5150-5350 Enlaces p-p y p-mp (espectro disperso y 802.11ª/54Mbps, modulación digital), MOVIL 802.11i, 802.16/70 Mbps/ movilidad, 802.20/1 Mbps/movilidad.

5470-5725 Radio Navegación marítima, Radiolocalización movil, radioaficionados. 802.16/70 Mbps/movilidad, 802.20/1 Mbps/movilidad

5725-5850 ICM (aplicaciones industriales, científicas 802.11ª/54Mbps y médicas), Detección, identificadores, 802.16/70 Mbps/Movilidad, telemetría, telecomando y enlaces p-p y 802.20/1 Mbps/movilidad. p-mp (espectro disperso)

* Incluye permisos, concesiones, autorizaciones y registros.

vicios, las administraciones consideren diferentes e innovadoras formas de uti-lizar el espectro radioeléctrico en vez de asignarlo a un único dueño, lo que limita la cobertura y desarrollo de infraestructu-ra, 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 benefi-cio que ofrecen estas tecnologías. Hoy en día estas bandas de frecuencias presen-tan 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, de-terminen 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 cos-to, desaprovechar o demorar esta magnifica oportunidad, significaría perder la oportuni-dad que brindan las TIC para aportar al creci-miento y desarrollo sustentable del país.

ConclusionesLa tecnología WiMAX es una nueva solución para implementación de redes de acceso inalámbrico dentro de un área metropolita-na. 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ám-brico pueden expandir sus áreas de cober-tura 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 don-de se provee la conectividad a la Internet. En ese punto colocamos nuestra estación base WiMAX de donde tendremos un radio de co-bertura 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 comu-nicaciones consolidadas. Una vez que este mercado sea cubierto, los costos habrán bajado y seremos nosotros, los usuarios fi-nales, 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 estu-diar, 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 ina-lá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

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

Dónde adquirir unasolución WiMAXActualmente en ciudades como Los Ange-les, Nueva York, y Seattle en EUA; y Dalian, Chengdu en China, ya hay implementacio-nes de redes que funcionan con esta tec-nología, pero no están certificadas por el WiMAX Forum (ver recuadro), es por esto que se les conoce como pre-WiMAX. Actual-mente 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 cons-truir soluciones que puedan trabajar con cualquier equipo “WiMAX certified” sin im-portar la marca o el fabricante del chipset.

Se espera que para finales del 2007 aparez-can los primeros dispositivos WiMAX para usuarios finales, con los que una persona se podrá conectar a Internet por WiMAX a velo-cidades de 4Mbps. Posteriormente, a finales del 2008, aparecerían las primeras laptops “WiMAX-ready”.

¿Existen otras tecnologíastipo WiMax?El competidor equivalente de WiMAX en Eu-ropa es HIPERMAN. Actualmente el WiMAX Forum está trabajando en métodos para que WiMax y HIPERMAN pueden interoperar de forma transparente. La industria de teleco-municaciones de Corea también ha desa-rrollado su propio estándar: WiBro. El año pasado Intel y LG acordaron una interopera-bilidad entre WiBro y WiMAX.

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


PalmOne

Tungsten E2Orientada a los nuevos usuarios, la E2 incorpora toda la uti-lidad de una PDA con la más reciente versión de PalmOS, el Garnet v5.4, de interfaz sencilla y familiar. Todas las aplica-ciones de organización (contactos, calendario, administra-dor 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 Multimedia-Card, SD y SDIO, el software palmOne media, y RealPlayer, hacen de esta Tungsten la compañera perfecta para un viaje-ro, 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, actua-lizable para contar con la última información en mapas para trazado de rutas.

Sony

Vaio Notebook Serie FCon un diseño más delgado y ligero, la recientemente presen-tada 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 vi-sibles, 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 computado-ras portátiles de alta capacidad y tamaño reducido.


TECNOLOGÍA

nVIDIA

GeForce 7800La nueva tarjeta aceleradora de video de nVIDIA presenta la ar-quitectura 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 me-jores texturas y efectos de iluminación en tiempo real, concre-tando 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 impre-sos. 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.

02 In Search of BPM Excellence: Straight

from the Thought LeadersBusiness Process Management Group (BPMG)Meghan Kiffer Press, 2005

Existen muchos libros de BPM. Sin em-bargo, 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 lec-ciones aprendidas. Es por ello que en este número les recomendamos “In Search of BPM Excellence”, ya que es uno de los po-cos libros de BPM que no sólo hablan del qué, sino también del cómo.

Este libro fue creado por el Business Pro-cess Management Group (BPMG) y reúne el pensamiento de algunos de los person-ajes más importantes de este movimiento. Es un compendio de artículos que tratan

temas como el pasado, presente y futuro de BPM, frameworks de implantación (8 Omega Framework), y criterios para se-leccionar un BPMS. También hay artículos muy interesantes que abordan temas de negocio tales como estrategia, ventaja competitiva y cambio organizacional, des-de 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.

BIBLIOTECA


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 qui-eres 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 ([email protected]).

01 As the Future Catches You: How Genomics & Other Forces Are Changing Your Life, Work, Health & WealthJuan Enríquez CabotCrown Business, 2001

Alvin Toffler 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”). Toffler 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

Recomienda un libro para esta sección, escribe a: [email protected]

INDEX

Anunciante Páginas SitioAlpha Consultoría 49 www.alpha-hardin.comAMCIS 55 www.amcis.org.mxAvantare 45 www.avantare.comcertum 35 www.certum.come-Quallity 43 www.e-quallity.netGopac 29 www.gopac.com.mxGrupo STI 13 www.gsti.com.mxHorbis 39 www.horbis.comIBM F4 www.ibm.com/mxItera 53 www.itera.com.mxMGE 37 www.mgeups.comMicrosoft F2-1 www.microsoft.com/mexicoMilestone 11 www.milestone.com.mxOracle 07 www.oracle.com/global/mxRoca Sistemas 47 www.rocasistemas.com.mxSafeNet 17 www.la.safenet-inc.comSsistemas 15 www.ssistemas.comSoftware AG 33 www.softwareag.comTop SW Show 09 www.mayen-project.com.mxXpoLinux F3 www.expolinux.com

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

DIRECTORIO



CA

RR

ER

A

El Arquitecto de SoftwareHabilidades Necesarias

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, inclu-yendo open source.11. Conocimientos del hardware ysus capacidades.12. Procesos de desarrollo de software moder-nos, como el Proceso Unificado.Es importante notar que los arquitectos no cons-truyen sus planos desde cero, sino que apro-vechan el conocimiento y experiencia de otros, plasmado en patrones y frameworks.

Habilidades.- Además de este conocimien-to, requiere contar con habilidades como las siguientes:• Capacidad de abstracción, creatividad, li-derazgo, comunicación oral y escrita; nego-ciació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, po-demos entender porqué el programador se puede ver tentado a seguir “el lado oscuro de la fuerza” en lugar de seguir esta carrera.

Si el analista de sistemas es el respon-sable de identificar y especificar las ne-cesidades 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 tecnolo-gí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 ca-lidad 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. In-cluso generan un impacto directo sobre la eco-nomía del proyecto, pues debería de ser capaz de sacarle el máximo provecho a la tecnología

El término “arquitectura de software” y el rol de “arquitecto de software” parecen es-tar 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 ma-nera, 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 representan-do 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 co-menzaba 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.

existente, en especial cuando ésta represen-ta una restricción del proyecto, como ocurre cuando el cliente no se puede dar el lujo de invertir en nuevo equipo o tecnología adicio-nal al que ya tiene.

Dominio.- Sus decisiones sobre la estructu-ra y dinámica de la aplicación son plasma-das en notación formal. Para hacer esto los arquitectos modernos requieren dominar UML, sobre todo si piensan usar nuevas tec-nologías y en especial aquellas orientadas a objetos. A pesar de esto, no creerían la can-tidad de alumnos que han llegado a nues-tros 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 cul-parlos, ya que existe un desconocimiento generalizado acerca del perfil de dicho rol. El conocimiento y experiencia del arquitecto moderno pueden resumirse en los siguien-tes puntos:1. UML y el uso de por lo menos una herra-mienta de modelado.2. Análisis, Diseño y Programación Orienta-da a Objetos.

Por Sergio Orozco y Carlos Macías

Sergio Orozco es director general, consultor e instructor senior de Milestone Consulting, certificado en UML por la OMG. Carlos Macías es arquitecto en jefe, consultor e ins-tructor 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á[email protected] / www.milestone.com.mx

Año

01

No.

04

w

ww

.sof

twar

egur

u.co

m.m

xS

OFT

WA

RE

GU

RU

CO

NO

CIM

IEN

TO

EN

PR

ÁC

TIC

A

J

ulio

-Ago

sto

2005

CAMBIO, - Delia Esquer Meléndez -...

Documents

Transcript of CAMBIO, - Delia Esquer Meléndez -...