JUL-AGO 2005

Transcription

JUL-AGO 2005

• Análisis de
Puntos de Función
• Casos de Uso
Software Guru CONOCIMIENTO EN PRÁCTICA
Año 01 No.04 • Julio-Agosto 2005
ENTREVISTA:
Carlos González
Director de Sistemas de TMM
CASO DE ESTUDIO:
Active Intelligence
CAMBIO,
LA ÚNICA CONSTANTE
Prepárate para BPM
Además: Noticias • Eventos • Fundamentos • Biblioteca • Tecnología • Carrera
TECNOLOGÍA:
WiMAX
DIRECTORIO
Edición Ejecutiva
Pedro Galván
A>
EDITORIAL
Coordinación Editorial
Mara Ruvalcaba
Edición y Producción
Edgardo Domínguez
Dirección de Arte
Oscar Sámano
Durante una conferencia a la que atendimos recientemente, uno de los participantes preguntó para qué se estaba hablando de procesos de negocio durante una
conferencia de TI. Como se podrán imaginar, la mayoría de los asistentes puso
cara de “¿cómo se le ocurre preguntar eso?”. Se trata de una pregunta válida, si
es que no se tiene clara la razón. Desde hace varios años, las áreas de sistemas
en las empresas han estado sufriendo un cambio muy importante; están dejando
de ser áreas técnicas, para convertirse en áreas de soporte y habilitación del negocio. Bajo el argumento de que “lo único constante es el cambio”, las empresas
están siendo obligadas a ser ágiles y adaptarse rápidamente a los cambios en
su entorno. Y lo primero de que se están dando cuenta, es que sus sistemas de
información actuales no promueven la agilidad, al contrario, la inhiben.
Es por ello que hemos destinado este número a hablar sobre Business Process
Management (BPM), que es probáblemente la iniciativa más importante que se
ve en esta industria hacia los próximos diez años por lo menos. Esta importancia
se debe a que es una iniciativa dirigida por negocio, donde los sistemas responden a las necesidades del negocio, y no viceversa. Es una iniciativa orientada a
desarrollar empresas ágiles, soportadas por sistemas de información 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 embargo, es un hecho que el trabajo que hacemos está cambiando, y debemos estar
preparados para este cambio. Después de todo, el cambio es la única constante.
Agradecemos a Carlos González por haber compartido con nosotros su visión
sobre este tema. Aún siendo un directivo de una importante empresa, Carlos se
mantiene como una persona sencilla y con los pies en la tierra.
Por último y no por ello menos importante, damos las gracias a todos los
colaboradores que han hecho posible este número de Software Guru. A todos
los lectores les pedimos que por favor nos hagan llegar su retroalimentación y
comentarios a través del sitio web, o en [email protected]
Equipo Editorial
02
JUL-AGO 2005
Ilustración
Omar Ruvalcaba
Consejo Editorial
Francisco Camargo, Guillermo Rodríguez,
Ralf Eder y Raúl Trejo, ITESM CEM;
Hanna Oktaba, UNAM-AMCIS;
Luis Cuellar, Softtek.;
Luis Vinicio León, e-Quallity - ITESO
Colaboradores
Ariel García, Jorge Palacios, Antonio Reyes,
Paulina Olivares, Amaury Quintero,
Francisco López Lira, Roberto Silva,
Ernesto Méndez, Rafael Muñoz,
Elizabeth Almeraz, Sergio Durán,
Axel Nissim, Sergio Orozco, Carlos Macías,
Ramón Hernández, Luis Daniel Soto.
Ventas
Claudia Perea
Marketing
Natalia Sánchez
Webmaster
www.aguilahosting.com
Contacto
[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: 042004-090212091400-102. Certificado de licitud de título: 12999. Certificado de licitud de contenido:10572.
ISSN: 1870-0888. Registro Postal: PP15-5106. Se
imprimió en junio de 2005 en Litográfica Roma.
Distribuido por Sepomex y Thunder Mail
www.softwareguru.com.mx
contenido jul-ago 2005
número 04
EN PORTADA
Business Process Management (BPM)
Ha llegado una nueva plataforma de misión crítica para los sistemas
empresariales, los sistemas BPM. Conozcamos de que se trata esta
tendencia y preparémonos para el cambio.
Productos
Prácticas
LO QUE VIENE
Problem Resolution Toolkit,
BEA Aqualogic, iBolt
10
REPORTE DE MERCADO
BPMS
12
TUTORIAL
Ingeniería en Reversa de DB2
14
ADMINISTRACIÓN DE PROYECTOS
Análisis de Puntos Función
34
Entrevista
18
Carlos González, CIO de TMM
En la segunda parte de este artículo,
Sergio Durán nos explica como se determina
el tamaño de un sistema utilizando la métrica
de los Puntos Función (FPs).
PROCESOS
38
BPM Aplicado al Desarrollo de SW
BPM se puede utilizar para diferentes tipos de
procesos. En este artículo, Axel Nissim analiza
su aplicación en procesos de desarrollo de SW
Columnas
Tejiendo Nuestra Red
por Hanna Oktaba
06
Mejora Continua
por Luis Cuellar
08
Innovaciones en Software
por Luis Daniel Soto
41
Prueba de Software
por Luis Vinicio León
44
Cátedra y Más
por Raúl Trejo
46
20
UML
Casos de Uso
42
Una de las principales causas de fracaso en
los proyectos de SW es un mal manejo de los
requerimientos. Sergio Orozco nos habla sobre
los fundamentos de la administración de
requerimientos basada en casos de uso.
Caso de Estudio
30
Active Intelligence
En Cada Número
Noticias y Eventos
Fundamentos
Tecnología
Biblioteca
Carrera
04
48
50
54
56
JUL-AGO 2005
03
NOTICIAS
Noticias
IT Outsourcing Conference 2005 - IDC
El pasado jueves 26 de Mayo se llevó acabo la 2da. edición de la Conferencia IT Outsourcing 2005, realizada por IDC México, en el Centro
Banamex. El objetivo de dicha conferencia fue el dar respuestas clave
acerca del outsourcing y el Business Process Outsourcing.
De acuerdo con IDC, los servicios de outsourcing tendrán un crecimiento en México, para 2005, de 13.6%, y para 2006, de 13.1%. Hay
que recordar que la industria de TI, crecerá 8.1% en 2005, y 6.3% en
2006. Por tanto, el outsourcing es uno de los segmentos que tendrá
las mayores tasas de crecimiento en dichos periodos.
Alejandro Floreán, Gerente del Programa de Investigación de TI
y Mercados Verticales en IDC México, comentó que “esto no es
más que un indicio de que la madurez del mercado mexicano
está comenzando. Los outsourcers no han llegado tarde a México, en realidad el outsourcing es parte de la madurez de las actividades de sistemas y de la misma industria de TI”
Praxis obtiene el nivel 3 del
modelo Capability Maturity
Model (CMM) para desarrollo
de Software
Praxis, empresa de consultoría, desarrollo
e integración de sistemas de información,
aprobó la evaluación CMM nivel 3 para el
desarrollo de Software que otorga el SEI
(Software Engineering Institute), después
de un proceso de evaluación que califica a
su Fábrica de Software.
“En Praxis entregamos soluciones de
TI que cumplen con las expectativas de
nuestros clientes en tiempo, costo, calidad y alcance. El certificado en nivel 3 de
CMM, coloca a Praxis como una empresa
de competitividad internacional, consolidando nuestra capacidad para el eficiente
manejo de grandes proyectos”, comentó
Edmundo Robert, CEO de Praxis. La evaluación fue realizada por José Guerrero,
SEI – Authorized Lead Assessor, de la empresa chilena América XXI.
Secretaría de Economía en conjunto con AMITI y Microsoft inician
actividades del Programa Acelera.Prosoft 2005
La Secretaría de Economía en conjunto con AMITI y Microsoft anuncian el inicio de actividades del programa Acelera.Prosoft 2005, que tiene como objetivo principal mejorar el desempeño de la industria nacional de desarrollo de software, fortaleciendo las capacidades
técnicas e incrementando los resultados de negocio de las empresas afiliadas mediante la
estrecha colaboración de las empresas Visionaria, Avantare e InterSoftware.
Con más de 100 empresas registradas en el programa y beneficios directos a cerca de 600 desarrolladores, Acelera.Prosoft 2005 cubre un amplio rango de empresas dedicadas al desarrollo
de software, ofreciendo esquemas de capacitación flexibles, así como asesoría de negocios a
empresas con iniciativas de fábricas de software entre otras.
Con la reciente disponibilidad de la versión Beta de Kuali, herramienta propiedad de la Secretaría de Economía, una de las herramientas de Moprosoft, disponible en el portal software.net.mx
(http://foros.software.net.mx/kuali/), se busca reforzar la competitividad del ecosistema mexicano de desarrollo de aplicaciones mediante el acceso a documentos que facilitan el desarrollo,
empleando mejores prácticas y acercando a las empresas a los estándares de clase mundial.
Para mayor información visita: www.software.net.mx
Inauguran Centro de Excelencia Tecnológica en Mexicali
El modelo de gestión de Praxis está basado
en las metodologías y procesos de mayor
aceptación a nivel internacional. Con esta
evaluación, Praxis asegura a sus clientes el
cumplimiento de sus proyectos en los términos de costo, tiempo, calidad y alcance.
El gobierno de Baja California, IBM y el Centro de Enseñanza Técnica y Superior (CETyS),
crearon el primer Centro de Excelencia Tecnológica en Estándares Abiertos del país, que
tiene el objetivo de impulsar el desarrollo de sistemas de información abiertos, con la
finalidad de especializarse en la creación de software. Este proyecto tendrá como primera fase la capacitación de 25 estudiantes por un periodo de nueve meses, y el siguiente
paso será la creación de empresas que proporcionen soporte a las plataformas abiertas
como Linux y Java.
Para mayor información visita:
www.praxis.com.mx
Baja California cuenta también con el proyecto de IT@Baja, grupo de 30 empresas dedicadas
al desarrollo de software, y con el proyecto del parque tecnológico “Silicon Border”.
04
JUL-AGO 2005
Eventos
Julio-Agosto 2005
24-26 Agosto 2005
Top Software Show
Mayen Project Management
World Trade Center
Ciudad de México
Info: www.mayen-project.com.mx
Tel: (55) 5536 4120
Email: [email protected]
11-13 Agosto 2005
Xpo Linux 2005
Centro Banamex
Ciudad de México
Info: www.expolinux.org
Tel: (001) 210 8920930
25 Agosto y 31 Agosto 2005
Seminario Gratuito “Administración
Integral de Tecnologías de Información y
¿Que papel juega TI con el requerimiento
de Ley Sarbanes Oxley?”
11 - 13 Agosto 2005
1er Foro Regional Innovación y Tendencias Tecnológicas
Itera
25 Agosto - Cd. de México, 31 Agosto - Monterrey, N.L.
Info: www.itera.com.mx
Tel. (55) 5281 7670
Grand Hotel Tijuana
Tijuana y Ensenada, Baja California
Info: www.tendenciastecnologicas.com
Tel: (664) 686-2227
31 Agosto – 2 Septiembre 2005
VI Conferencia Anual “The Future of IT:
La Justificación Económica de la TI”
24 Agosto 2005
Security & Business Continuity
Conference 2005
Gartner
Centro Banamex
Ciudad de México
Info: www.gartner.com/mx/econit
Tel: (55) 5207 2695
IDC
Centro Banamex
Ciudad de México
Info: www.idc-eventos.com
Tel: (55) 5661 3791 o 01800 504 1529
Datos de la Industria
NOMBRE
UBICACIÓN
NO. PERSONAS
NIVEL CMM o CMMI
FECHA
LEAD ASSESSOR
NEORIS
MTY
600
CMM 3
Oct-03
Mariana Pérez-Vargas, Avantare
AZERTIA
DF
150
CMM 2
Feb-04
Iñigo Garro, ESI
EDS
JUAREZ
200
CMM 5
Feb-04
No reportado
SOFTTEK Nearshore
MTY
1250
CMM 5
Abr-04
Richard Storch, Dick Storch & Associates
ULTRASIST
DF
30
CMM 4
Jul-04
SIGMA TAO
QRO
450
CMM 5
Nov-04
Richard Storch, Dick Storch & Associates
IBM - AMS
GDL
950
CMMI 5
Dic-04
Luciano Guerrero – Canada
IDS
DF
350
CMM 3
Dic-04
Cecilia Montero Mejía - Empeiria Quality Services
ACTIVE
INTELLIGENCE
AGS
50
CMM 3
Mar-05
TELEPRO
DF
25
CMM 2
Jun-05
PRAXIS
DF
350
CMM 3
Jun-05
Jose Guerrero- America XXI
Fuente: Recopilación de comunicados de prensa y sitios web de cada empresa.
*El modelo CMM ya no es soportado por el SEI.
**Otras empresas en México han obtenido estas evaluaciones, pero actualmente no operan.
Empresas mexicanas que cuentan con la evaluación Capability Maturity Model para Software* (CMM), o con la evaluación Capability Maturity Model Integration (CMMI), otorgada por el SEI (Software Engineering Institute)
JUL-AGO 2005
05
COLUMNA
TEJIENDO NUESTRA RED
Moda y Tendencias
Tercera Reunión del IPRC
E
n mayo de 2005 se reunió por tercera vez el International Process Research Consortium (IPRC). En
esta ocasión nos tocó sufrir los primeros calores
de una de las capitales de la moda mundial, que es Milán.
Para los interesados en el tema —el de la moda—, les puedo comentar que en las tiendas reinaban los colores puros
de arco iris, pero en las calles, las mismas fachas que en el
DF, con el único detalle de lentes obscuros tipo “mosca”.
La Dra. Hanna
Oktaba es profesora
en la Facultad de
Ciencias de la UNAM.
Es fundadora y vicepresidenta de la Asociación
Mexicana para la
Calidad en la Ingeniería
de Software. Actualmente dirige el proyecto
para la creación de una
norma mexicana para la
industria de software.
Cambiando del tema, y regresando al objetivo de mi relato,
la reunión del consorcio estaba dedicada a identificar los
posibles escenarios de las tendencias mundiales políticoeconómico-tecnológicas en los próximos diez años. Una vez
identificados los escenarios, se procederá a analizar el posible impacto que éstos tendrán en la forma en que se va a
desarrollar el software y, en consecuencia, en los procesos.
Al inicio se nos proporcionó una lista de 116 elementos de
tendencias, que hemos identificado en las reuniones pasadas, y se nos pidió que escogiéramos las que nos parecieran las más inciertas. Entre ellas estuvieron:
1. El cambio demográfico de los desarrolladores (jóvenes
o maduros, occidentales o asiáticos, etc.)
2. Legislación y regulaciones sobre uso de software
3. Globalización (predominación occidental o asiática)
4. Demanda de calidad y seguridad (incremento o resignación)
5. Tipo de cadena de valor (centralizada o volátil)
6. Innovación tecnológica (incremental o perturbadora)
Nos dividieron en cuatro grupos y para que cruzáramos los pares de estas incertidumbres con sus extremos y tratáramos de
imaginarnos la vida en cada uno de los cuadrantes. Mi grupo
escogió cruzar la innovación tecnológica con la estabilidad de
la cadena de valor. El mundo más sencillo de imaginar fue el
de cadena de valor más o menos estable, como ahora, y los
cambios tecnológicos de poquito a poquito. Lo más retador
fue imaginarse el mundo donde las cadenas de valor son volátiles y los cambios tecnológicos totalmente inesperados,
como en su tiempo fueron la invención de Internet o del teléfono celular. Fue bastante divertido participar con mis colegas
en este juego intelectual y observar cómo la imaginación o los
miedos personales salen a flote y se vuelven colectivos.
La impresión general que saqué de esta sesión fue que esta
gente ve una gran probabilidad de que en los próximos años
la supremacía tecnológica pase a manos de China, India y
Japón, que ya en gran medida la tienen. Y como la mayoría
de los participantes del consorcio proviene de occidente,
esto les causa bastante preocupación. Medio en broma, comentaban que dentro de diez años el Software Engineering
Institute va dedicarse a la promoción de modelos de procesos chinos para América. Otro tema que les preocupa es la
estabilidad de las grandes empresas, en particular las trasnacionales. Por ejemplo, los proyectos de código abierto y
los servicios en línea son nuevas formas de organizarse que
rompen los esquemas tradicionales. Estos nuevos esquemas ofrecen a los clientes mayor flexibilidad, menor costo
y, por lo general, buena calidad. Esto empieza a contrastar
con la rigidez y relativa lentitud de grandes consorcios.
En México también estamos observando este fenómeno a través de la creación de las integradoras que empiezan a multiplicarse en los estados. Será interesante observar su impacto en
el mercado local y de exportación en los próximos años.
Por último, les quiero comentar sobre algo curioso en un
consorcio sobre procesos. Se armó una discusión muy acalorada sobre “¿qué es proceso?”, y que conste que allí participa la gente que sabe del tema. A mí me dio mucho gusto
que surgió esta pregunta porque, desde que empezamos a
trabajar sobre MoProSoft, buscamos una definición razonable de proceso y la mera verdad ninguna nos gustaba. Nos
quedamos con una inventada por nosotros. Y aquí salió que
las mismas dificultades tiene la gente para quienes esto es
“su mero mole”. Por supuesto no se pusieron de acuerdo.
Formaron un grupo que se va a encargar de presentarnos en
la próxima reunión una propuesta. Lo que ya se acordó es
que habrá que distinguir entre los procesos del lado de la
demanda, los procesos de gestión y los técnicos.
En MoProSoft ya tenemos los dos últimos, nos falta trabajar los primeros, los del lado de los compradores, para que
ambas partes se entiendan mejor. Por este medio abro la
convocatoria a los que quieren aportar su conocimiento
y talento para definir los procesos complementarios a
MoProSoft para la parte de adquisición. Favor mandar las
propuestas a Software Guru. Hasta la próxima.
- Hanna Oktaba
06
JUL-AGO 2005
COLUMNA
MEJORA CONTINUA
La Calidad no Cuesta...
Pero, ¿Cuál es el Retorno de mi Inversión?
H
Luis R. Cuellar es
Director de Calidad
a nivel mundial de
Softtek Information
Services. Luis es
reconocido por la
American Society for
Quality (ASQ) como
Certified Quality
Manager, Certified
Software Engineer, y
Six Sigma Black Belt.
En los últimos cinco
años ha estado a
cargo de la definición
e implantación de la
estrategia para CMM5
y Six Sigma a través
de las diferentes
áreas del centro de
desarrollo de Softtek.
ace algunas semanas participé en una plática con varias compañías que están buscando su certificación
de CMMi. Todas ellas compartieron sus experiencias
sobre los problemas que viven y los beneficios obtenidos con
el avance que se llevaba. Dentro de la conversación se tocó
el tema de porqué buscar una certificación. Las respuestas
fueron varias, en el orden de: “para competir en el futuro”,
“entrar al mercado americano”, o “demostrar nuestro compromiso con la calidad”. Al escuchar estas respuestas, me
pareció preocupante lo enfocado que están estos esfuerzos
en obtener una certificación, más que en obtener beneficios
específicos a corto plazo para la organización. Esto es comprensible tomando en cuenta que la certificación es una meta
alcanzable (por lo menos más de uno lo ha hecho antes),
fácilmente medible y principalmente muy clara de vender
y comunicar dentro y fuera de la organización. Desafortunadamente, manejar la certificación como la única meta de un
esfuerzo de calidad no necesariamente es lo más acertado,
principalmente si lo que se busca es crear una cultura de eficiencia, respeto por el trabajo bien hecho y mejora continua.
El Diablo está en los detalles
OK, entonces si la certificación no es la meta, ¿cómo podemos expresar una meta más adecuada? El principal elemento a tomar en cuenta es que buscar una certificación
es un proceso que genera un cambio en toda la organización. Normalmente requiere una reestructura de roles,
actividades, forma de trabajo, y tal vez hasta una redefinición de los servicios ofrecidos. La idea común de “pongamos a alguien que esté desocupado a definir procesos
para que después le digamos a todos que los sigan”, sólo
lleva a la frustración y malos resultados. La organización
va a cambiar, junto con la forma en que todos hacemos
las cosas. Para lograr ese cambio se necesita una razón lo
suficientemente importante, clara, y poderosa como para
generar ese cambio y mantenerlo a largo plazo.
El problema de basar las estrategias de calidad en obtener
algo como un documento de certificación, es la cantidad
de pequeños problemas que se encuentran todos los días
y que nos empujan a mantener todo como está. Imaginemos un escenario en el que tenemos que certificarnos en
seis meses, pero también debemos entregar un proyecto para un cliente. Sucede que para entregar a tiempo el
proyecto, tendríamos que saltarnos las pruebas unitarias.
¿Qué decisión tomaría la dirección de la compañía? ¿Renegociar con el cliente las fechas diciéndole que nos urge
certificarnos?, o ¿entregar a tiempo pero sin las pruebas?
Si la respuesta es esta última, el mensaje a la organización
es claro: “si te ves en problemas, entonces no sigas los
procesos”. En este caso, las razones para generar un cambio no son lo suficientemente fuertes para lograrlo.
08
JUL-AGO 2005
Certificarse es solamente un
producto secundario
En 1979, Philip B. Crosby escribió un libro cuyo tema principal se resume en: “el esfuerzo que se le dedica a la calidad
no cuesta”. Lo que Crosby quería decir en este libro es que
los beneficios obtenidos por las estrategias de calidad son
mayores al costo de los mismos. Así las metas de la certificación deben de estar íntimamente ligadas a los problemas más importantes que vive la organización: ¿se están
barriendo los proyectos?, ¿generamos demasiados defectos?, ¿somos demasiado caros? Si seguimos trabajando
con nuestro nivel de costos, ¿cuánto tiempo podríamos
seguir compitiendo? Si resolviéramos estos problemas,
¿cuánto dejaríamos de perder?, ¿cuánto adicional ganaríamos?, ¿dónde se vería reflejado este beneficio?, ¿Qué
tanto lo queremos?, ¿estamos dispuestos a sacrificar una
ganancia el día de hoy para lograr un ingreso mayor el día
de mañana? Estas son las preguntas que necesitamos
responder, estos son los beneficios que debemos de dar
seguimiento y asegurar que se cumplan.
Hace algunos años participé en la planeación de la certificación de una compañía mexicana. Al iniciar con el plan
de certificación lo principal fue investigar las razones de la
certificación. Después de algunas preguntas se llegó a la
conclusión de que la organización buscaba ser 10% más
productiva el próximo año, debido a que tenía anticipado
un recorte de presupuesto y se requería que los individuos
siguieran con la misma carga de trabajo. De ahí lo primero
que se estableció en el plan fue la definición de las métricas
de productividad, y todas las demás actividades se priorizaron de acuerdo a su impacto en productividad. Como actividad secundaria se definió el análisis de implementación, el
cierre de la brecha y la preparación de la certificación.
Estos objetivos no sólo le dan a la organización un incentivo claro para seguir adelante, sino que también sirve
como base para aclarar qué es lo que se espera de las
áreas de definición de procesos. Si lo que queremos es
reducir nuestros tiempos de entrega, no podemos definir
demasiados documentos, si lo que queremos es mantener
el cambio durante un crecimiento acelerado, necesitamos
un proceso sencillo que sea fácil de entrenar.
En conclusión, la certificación no debería ser un objetivo sino una consecuencia secundaria de una mejora que
queremos lograr como organización. Entre mejor relación
exista entre los objetivos de calidad con los objetivos
de negocio, más beneficios podemos lograr de nuestros
esfuerzos de calidad a corto, mediano y largo plazo.
- Luis Cuellar
PRODUCTOS
LO QUE VIENE
Primeros frutos de
cooperacion entre
Rational y Tivoli
Detección y reparación de errores
en sistemas empresariales
Durante su conferencia anual
para usuarios, IBM Rational
mostró dos nuevos productos
para acelerar y facilitar la detección y reparación de errores
en aplicaciones empresariales:
el Problem Resolution Toolkit
para IBM Rational Application
Developer y el Performance Optimization Toolkit para Rational
Performance Tester.
Estos productos integran capacidades del
suite para administración de aplicaciones
Tivoli, para mejorar la detección y solución de
problemas en aplicaciones J2EE, middleware
de integración y sistemas legacy.
Las herramientas funcionan de la siguiente
manera: el software Tivoli monitorea el rendimiento de las aplicaciones mientras están
en funcionamiento, rastreando y guardando detalles cuando identifica problemas de
rendimiento. El Problem Resolution Toolkit
permite acceder esta información, para que
los desarrolladores puedan identificar rápidamente la fuente de los problemas, minimizando el tiempo de caída de los sistemas.
Por su parte, el Performance Optimization
Toolkit proporciona colectores de datos,
también basados en software Tivoli, que se
ejecutan durante el proceso de prueba. Al
encontrar un problema, el toolkit sugiere posibles causas y resoluciones. Este es uno de
los primeros frutos del esfuerzo de “cómputo autonómico” de IBM para crear sistemas
que se reparen a sí mismos.
Dado que las herramientas de Rational y
Tivoli están basadas en la plataforma Eclipse, su comunicación e integración es transparente para el usuario.
PRODUCTOS
BEA Aqualogic
Cómputo Líquido
BEA Systems recientemente lanzó su nueva familia de productos,
AquaLogic. El propósito de estos productos es proveer lo que BEA
llama una infraestructura de servicios. Esta infraestructura consiste
en una especie de contenedor donde los servicios – sin importar la
plataforma en que fueron desarrollados –, puedan ser descubiertos,
ensamblados y administrados de manera fácil, rápida y segura. Los
productos de esta familia que se han dado a conocer hasta el momento son:
• BEA AquaLogic Service Bus, para la integración y administración
de servicios web en ambientes heterogéneos.
• BEA AquaLogic Data Services Platform, permite acceder de manera
unificada los datos de diversas fuentes disponibles en la empresa.
• BEA AquaLogic Enterprise Security, una infraestructura de seguridad orientada a servicios para proveer seguridad a aplicaciones
distribuidas.
Ademas de estos, se espera que en un futuro próximo se agreguen
nuevos productos a esta familia.
Al parecer, la nueva visión de BEA está completamente comprometida
con AquaLogic y el concepto del cómputo líquido. Incluso ha cambiado su logo y slogan, el cual ahora es “think liquid” (piensa líquido).
10
JUL-AGO 2005
Integración Dirigida por Negocio
Recientemente Magic Software liberó la versión 2.5 del iBolt
Business Integration Suite, una plataforma de integración
empresarial. Utilizando iBOLT, las empresas pueden alinear
rápida y fácilmente sus necesidades del negocio con su infraestructura IT. iBolt también posee capacidades de BPM,
así que las empresas pueden desarrollar nuevos procesos
de negocio, crear nuevas aplicaciones compuestas e implementar de manera más flexible las Arquitecturas Orientadas
a Servicios.
El suite está formado por los siguientes componentes:
• iBolt Studio – Herramienta para modelar y desarrollar
visualmente los procesos, flujos, conectores, datos, topologías, etc.
• iBolt Server – El engine o ambiente de ejecución para
proyectos creados en iBolt Studio.
• iBolt Monitor – Herramienta para monitorear en tiempo
real la ejecución de procesos de negocio.
Adicionalmente existe la Special Edition (SE) de iBolt, que
es una edición especialmente diseñada para SAP Business ONE, que integra todas las capacidades de iBolt en
esta plataforma.
PRODUCTOS
REPORTE DE MERCADO
BPMS
Aumentando las Expectativas
E
l 2005 muy probablemente será recordado como
el año en que los sistemas BPM despegaron. De
acuerdo con encuestas realizadas en Estados Unidos, BPM ha tomado el primer lugar en la lista de prioridades de los directores de sistemas, por encima de iniciativas como outsourcing y seguridad en TI. En México todavía
falta tiempo para llegar a esto, pero es de esperarse que
pronto lo haremos, así que es importante que comencemos a monitorear este mercado.
Historia
El mercado de los sistemas BPM es relativamente nuevo.
Los expertos del tema concuerdan en que los primeros productos que realmente pueden ser considerados como BPMS
hicieron su aparición entre 1999 y el 2000. En México, los
analistas de la industria apenas este año comenzaron a monitorear el mercado de estos productos. Tal es el caso de IDC,
quienes en su “Mexico Semiannual Software Tracker 2004”,
consideraron el rubro de BPM por primera ocasión.
• Cumbre de expectativas – Evangelización y proyectos
iniciales. El entusiasmo llega a su punto mayor.
• Valle de desilusión – Escepticismo generado cuando la
tecnología no cumple con todo lo que había anunciado, o
no se logra en el tiempo que se esperaba.
• Pendiente de claridad – Con el mayor uso y experimentación, por fin se aclara el verdadero potencial, beneficios
y riesgos.
• Meseta de productividad – Los beneficios reales se demuestran y reciben aceptación general. Las herramientas
relacionadas con la tecnología se estabilizan y maduran
incrementalmente.
En la gráfica 1, mostramos los puntos donde creemos que
actualmente se encuentra esta tecnología tanto en Estados Unidos como en México.
Tamaño
De acuerdo con información reportada por IDC en el estudio previamente mencionado, el tamaño de este mercado
en México en el 2004 fue de 3.9 millones de dls., lo cual representa tan sólo 2.1% del segmento de back office (182.1
millones dls.). Sin embargo, se espera que este mercado
crezca en dobles dígitos anuales durante los próximos tres
o cuatro años. Vale la pena recalcar que estas cifras se refieren exclusivamente a licencias de software.
Evolución
Este mercado actualmente cruza un momento muy importante. Las expectativas están en un nivel muy alto, lo cual provoca que todos los proveedores quieran “subirse al barco”. Una
enorme cantidad de proveedores están desarrollando “capacidades BPM” dentro de sus productos, y otros tantos han hecho adquisiciones de empresas especializadas en tecnología
BPM, para integrarlas dentro de su oferta. De acuerdo con Jim
Sinur, analista de Gartner, existen más de 225 proveedores
cuya oferta tecnológica abarca diferentes aspectos de BPM. Es
evidente que poco a poco este mercado se irá consolidando, y
la oferta quedará reducida a unos cuantos proveedores.
Al igual que la mayoría de las tendencias tecnológicas, los
BPMS están sujetos a una curva de evolución o madurez. Una
manera de representar esta evolución, es apoyándose en el
modelo del “Hype Cycle” (ciclo de expectativas, o de exageración), creado por Gartner. De acuerdo con este modelo, las
tendencias tecnológicas típicamente siguen cinco etapas:
• Lanzamiento – El disparo inicial generado por un lanzamiento,
demostración pública, u otro evento que provoca que la industria empiece a poner atención en la tecnología en cuestión.
12
JUL-AGO 2005
Como podemos apreciar, en México todavía estamos en
el ascenso hacia la cumbre de expectativas. Esto significa
que durante los próximos meses seguiremos escuchando
mucho respecto a este tema. Mientras tanto, parece que
en Estados Unidos el punto máximo de expectativas ya se
alcanzó, y ahora se está buscando convertir estas expectativas en realidad. Los analistas consideran que los BPMS
alcanzarán la meseta de la productividad en Estados Unidos durante el 2007. Nosotros creemos que en México
ésta se alcanzará de 18 a 24 meses después.
Industrias
El sector donde mayor adopción están teniendo los sistemas BPM hasta el momento, es el financiero. De acuerdo
con cifras en Estados Unidos, 46% de los proyectos de
BPM son en este sector, seguido por telecomunicaciones
(12%), salud (10%), y gobierno (8%). Aunque datos como
estos todavía no están disponibles en México, y realmente
son muy pocos los proyectos de BPM hasta el momento,
es de esperarse que la mayor adopción también se dé en
el sector financiero y de aseguradoras, seguido por gobierno y grandes tiendas de autoservicio (retail).
Estos son algunos de los principales proveedores de tecnología BPM con representación en
nuestro país, listados en orden alfabético.
Carnot (www.carnot-usa.com)
Magic Software (www.magicsoftware.com)
El Carnot Process Engine es uno de los productos
que podemos llamar “BPM puro”, ya que se limita a
proveer la funcionalidad exclusiva de un BPM. Esto,
en conjunto con su arquitectura basada en estándares, le da gran flexibilidad. Por ejemplo, puede
funcionar sobre diversos servidores de aplicación y
manejadores de base de datos. Horbis (www.horbis.com) es distribuidor de Carnot en México.
Su producto iBolt, es una plataforma de integración
empresarial que ha evolucionado y ahora incluye
capacidades BPM. Al usarlo en conjunto con eDeveloper —un producto de la misma empresa para desarrollar aplicaciones visualmente sin necesidad de
programar—, ofrece una solución conveniente para
integrar y desarrollar aplicaciones dirigidas por negocio. Roca Sistemas (www.rocasistemas.com.mx)
es el distribuidor de Magic Software en México.
Fuego (www.fuego.com)
Software AG (www.softwareag.com)
La Fuego BPM Suite puede ser calificada como
una solución de “gran escala”. Está orientada a
grandes empresas con ambientes heterogéneos
y grandes volúmenes de operación. La oficina
de contacto para Latinoamérica se encuentra
en Miami, pero en México se puede adquirir a
través de Axxis (www.axxis.com.mx).
La empresa alemana creadora de productos
como Natural, Adabas y Tamino XML Server,
recientemente lanzó un producto BPM llamado
Interstage Enterprise Process Manager, el cual
es resultado de una alianza entre Software AG
y Fujitsu.
Handysoft (www.handysoft.com)
Sterling Commerce
(www.sterlingcommerce.com)
BizFlow es otro BPM puro y multiplataforma. Su enfoque está en la facilidad de uso y administración. En
conjunto con el SOXA Accelerator (otro producto de
la misma empresa), brinda una solución “out-of-thebox” para lograr cumplimiento de Sarbanes Oxley.
Grupo Ecce (www.grupoecce.com) es distribuidor de
Handysoft en México.
Como parte de su plataforma MESA (Multi Enterprise Services Architecture) para colaboración interempresarial, Sterling Commerce ofrece el Gentran
Integration Suite. La suite está orientada a automatizar procesos de negocio colaborativos a lo
largo de su interacción entre clientes, proveedores
y otros socios de negocio.
IBM (www.ibm.com)
Ultimus (www.ultimus.com)
IBM acostumbra estar presente en todo lo que se
refiere a TI, y esta no es la excepción. Su suite para
BPM lleva el nombre de Websphere Business
Integration. Estos productos descansan sobre la
capa de middleware provista por otros productos
como Websphere Application Server y Websphere
MQ. IBM también es uno de los principales impulsores de estándares para lenguajes de descripción de procesos de negocio, como BPEL. Así que
este gigante está presente en todos los frentes:
estándares, middleware y productos finales.
Ultimus es una de las empresas pioneras en
BPM. Una de sus principales fortalezas de su
Ultimus BPM Suite es su integración avanzada
con tecnología de Microsoft. Por ejemplo, usa
unos componentes llamados “flobots”, que son
agentes que automáticamente interpretan, generan y distribuyen documentos de Office.
PRODUCTOS
TUTORIAL
Ingeniería en Reversa de DB2 iSeries
Utilizando XDE
Por Amaury Quintero
En este artículo veremos cómo utilizar Rational XDE para
hacer la ingeniería inversa de una base de datos DB2 albergada en un servidor iSeries o AS/400e. XDE es un ambiente integrado para desarrollo de software (IDE), que
incluye capacidades para modelado visual con UML.
H
ay ocasiones en las que necesitamos hacer ingeniería
inversa a una base de datos
existente para poder conocerla, entendarla y posiblemente modificarla.
Esto suele suceder cuando heredamos una base de datos de un sistema legado. Veamos entonces cómo
podemos utilizar Rational XDE para
realizar la ingeniería inversa y generar el modelo correspondiente.
Para realizar esta práctica vamos a
necesitar el IBM Toolbox para Java.
Este es un conjunto de clases Java
que nos permite accesar los datos en
servidores iSeries y AS/400e. En caso
que el servidor no contase con el IBM
Toolbox para Java es necesaria su instalación. Para instalar este conjunto
de utilidades haga lo siguiente:
• Desde la línea de comandos escriba GO
MENU (LICPGM) y presione [ENTER].
• Selecione 11. Install licensed program.
• Seleccione 5722-JC1 IBM Toolbox
for Java.
UML y el modelo Entidad-Relación
(E/R)
XDE no maneja directamente los diagramas EntidadRelación tradicionales. Lo que hace es utilizar diagramas de clases, complementados con el perfil de UML
para bases de datos. Este perfil incluye estereotipos
para modelar los elementos de un diagrama entidadrelación. Por ejemplo, las tablas se representan como
clases con el estereotipo <<Table>> mientras
que las relaciones se representan como asociaciones entre clases. Las columnas de las tablas se representan como si fueran atributos de clase, y los
constraints como operaciones.
14
JUL-AGO 2005
Para comenzar, creamos un nuevo proyecto en el XDE y seleccionamos alguno
de los tipos de modelos predeterminados para realizar el modelado de datos. En
nuestro caso utilizaremos el DB2 iSeries Data Model, el cual nos van a permitir
albergar los elementos que esten dentro de la base de datos DB2.
Para realizar la ingeniería inversa podemos partir de un script DDL que contenga las sentencias SQL de la estructura de la base de datos, o nos podemos
conectar directamente a la base de datos y obtener esta información. El script
se puede generar con el IBM iSeries Navigator, a través del cual nos conectamos a la base de datos, seleccionamos los esquemas deseados y generamos
el archivo. Para conectarnos a la base de datos desde XDE, podemos utilizar
DB2 Connect. Esta es la herramienta de selección cuando necesitamos tener
acceso a DB2 ya sea de la plataforma zSeries, iSeries y AS/400 principalmente. Sin embargo, desde XDE también podemos accesar una gran variedad de
manejadores de bases de datos sobre diferentes plataformas.
Una vez que XDE haya importado el contenido de la base de datos (ya sea a
través del DDL o por conexión directa), se procede a generar diagramas donde
se puede modelar visualmente los elementos de la base de datos.
Pasos
1. En la vista del Explorador de Modelos, que se encuentra ya abierta en la perspectiva de modelado, seleccionar el modelo que recibirá la ingeniería inversa.
2. Activar el asistente de ingenieria en reversa haciendo click derecho sobre el
modelo de datos y seleccionando Data Modeler > Reverse Engineer (Fig. 1).
Seleccionamos la opción de DDL Script, el tipo de base de datos IBM DB2
iSeries 5.x y el archivo con las sentencias SQL que nos proporcionó el iSeries
Operation Navigator.
3. Luego debemos filtrar los elementos de la base de datos que necesitamos conocer (índices, procedimientos almacenados, vistas, tablas,
etc) y con esto terminamos la operación. Siempre debemos verificar en
la vista de Output de XDE que no se hayan reportado problemas a la hora
de leer el script, de ser asi, debemos revisar los errores y corregirlos manualmente en el archivo con sentencias SQL. Esto evita que algún detalle
de la base de datos sea omitido. Una vez que el asistente es ejecutado,
XDE hace una correspondencia entre el DDL y el perfil UML, por ejemplo;
cada sentencia CREATE TABLE es transformada a una tabla del modelo
relacional y cada CREATE DISTINCT TYPE es convertido a una columna del
dominio dentro del modelo del dominio.
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
PRODUCTOS
TUTORIAL
A través del modelado visual podemos
entender mejor la estructura de una base
de datos, así como sus dependencias.
datos (Fig. 3), lo cual nos brinda una forma sencilla de visualizar el modelo. También
podemos revisar la correspondencia que efectuó XDE entre los datos de DB/2 UDB
iSeries y el perfil UML para base de datos consultando la ayuda de XDE.
2. Si el servidor de aplicaciones se
encuentra en otra máquina, entonces necesitamos un driver JDBC, de
preferencia el que viene con el IBM
Toolbox para Java. Este es un manejador tipo 4, que es un manejador
de protocolo nativo que provee un
mejor rendimiento que los drivers
del tipo 1 y 2, ya que se comunica
directamente con el host utilizando sockets sin pasar por la capa de
ODBC. La clase que lo implementa es
com.ibm.as400.access.
AS400JDBCDriver
Conclusión
Fig. 3. Diagrama de clases visualizando la relación entre los componentes del modelo de datos.
Luego de conocer nuestro dominio y ejecutar cambios sobre este, el diseñador puede pasar a aplicar estos cambios a la base de datos, posicionandose sobre uno de los esquemas modificados y nuevamente haciendo click
derecho Data Modeler > Forward Engineer, seleccionamos los elementos
que queremos actualizar y el nuevo archivo donde se guardarán las sentencias SQL con las modificaciones a la base de datos. Para hacer los cambios
efectivos, este archivo tenemos que ejecutarlo sobre el iSeries Operation
Navigator como un script SQL. Asegurese que la ejecución no le arrojó mensajes de error, si es asi corrijalos y continue la ejecución.
A través del modelado visual podemos entender mejor la estructura
de una base de datos, así como
sus dependencias. El modelado
visual es una de las mejores practicas del desarrollo de de software que contribuyen a aumentar
la probabilidad de la ejecucuión
exitosa de proyectos de software.
Hay que recordar que la ingenieria
en reversa debe ser considerada
una herramienta que nos asiste en
el proceso de entender y visualizar una configuración existente,
y no como una fuente de verdad
irrefutable. El resultado debe ser
revisado para asegurarnos que la
herramienta ha capturado los detalles de manera correcta.
Drivers para producción
Si fuese el caso que los cambios serán puestos en producción, tenemos dos
opciones para conectarnos a la base de datos desde el servidor de aplicaciones de Java, dependiendo de donde se encuentre instalado éste:
1. Si el servidor de aplicaciones se encuentra en la misma máquina que la base
de datos, conviene utilizar el driver nativo, que viene dentro del AS/400 Developer Kit, que es más rápido y está implementado con la clase com.ibm.
db2.jdbc.app.DB2Driver. Este driver también lo podemos obtener
directamente del mismo servidor AS/400, el archivo que deben buscar es
/QIBM/ProdData/http/Public/jt400/lib/jt400.jar
Referencias
• IBM Developerworks
www-136.ibm.com/developerworks/
• iSeries Information Center
publib.boulder.ibm.com/iseries/
v5r2/ic2924/
• JDBC Drivers: How Do You Know
What You Need?
archive.devx.com/dbzone/articles/
dd_jdbc/sosinsky-1.asp
Amaury Quintero es consultor de Itera especializado en Análisis y Diseño, donde se encarga de la iniciativa de Nuevas Herramientas de IBM Rational. Es graduado de
Cibernética-Matemática en la Universidad de La Habana, Cuba y actualmente cursa la Maestría en Ciencias de la Computación en el CIC del IPN.
16
JUL-AGO 2005
ENTREVISTA
Ing. en Computación de la UNAM y con 38 años de edad, Carlos
González es director de sistemas de Grupo TMM, una de las empresas más importantes del país. Carlos inició su carrera profesional
en Oracle, como consultor. Después llegó a TMM, donde coordinó
los esfuerzos de ingeniería de software durante un par de años. En
1999 decidió dedicarse a dar cursos y consultoría de manera externa, pero pronto regresó a TMM para apoyar en la definición de los
procesos operativos del área. Un par de años después, en el 2001,
asumió la dirección de sistemas.
Carlos
González
Director de Sistemas de TMM
¿Qué te hizo regresar a TMM cuando ya te habías ido?
Ahí hay una cuestión medio filosófica. Cuando me fui de instructor esos siete meses, durante un taller hicimos un ejercicio
en el que me pusieron el símil de la escalera. Se supone que tu
camino en la vida es una escalera, así que si quieres llegar a
algún lugar, tienes que pensar en si lo que estás haciendo hoy
en día te está ayudando a subir escalones o no. Yo lo pensé y
me di cuenta que lo que yo quería era ser director de sistemas,
así que por eso me regresé. Siento que hice una buena decisión
porque estoy haciendo algo que me apasiona.
18
JUL-AGO 2005
Tu camino a la dirección de sistemas fue a
través de las áreas de procesos y metodología.
¿Crees que este es un buen camino?
Sí, porque al trabajar en esta área también
conoces los procesos del negocio. Yo creo
que este es el camino más adecuado, no
porque yo haya pasado por ahí, sino porque me he topado con otras personas que
no han tenido esa progresión, y carecen
de las herramientas suficientes. También
es importante captar suficiente experiencia antes de llegar a un puesto directivo,
ya que con esto será más fácil asumir una
responsabilidad y lidiar con la incertidumbre. Porque estar en un puesto directivo es
lidiar continuamente con la incertidumbre,
la ambigüedad completa.
¿Cuáles son los principales proyectos que
tienen en curso en TMM?
Al igual que muchas otras empresas en
México, TMM tuvo una época difícil en los
últimos dos o tres años. Esto nos obligó
a detener un poco ciertas iniciativas que
traíamos. Al día de hoy, los principales proyectos que tenemos son en términos de
actualización de infraestructura, seguridad,
etc. El siguiente paso que queremos dar es
desarrollar una arquitectura de servicios
que nos permita ofrecer nuevos y mejores
servicios a los clientes. Esta arquitectura
también nos permitirá ligar nuestras cadenas de suministro con nuestros clientes y
proveedores para tener una interacción mucho más directa y eficiente.
Durante 2004 TMM redujo significativamente sus costos administrativos. ¿Fue
tijeretazo o en realidad hubo mejoras en
eficiencia? ¿Qué papel jugaron las TI?
Usualmente en la mayoría de las empresas
con una dinámica de negocio normal, donde se está ganando dinero de manera continua, se empieza a dar un desperdicio. Esto
pasa siempre, y no es evidente hasta que el
desperdicio es demasiado. Lo que nosotros
hicimos fue analizar nuestros procesos, y
entonces nos dimos cuenta que había ineficiencias como pasos duplicados, sistemas
que hacían lo mismo, áreas que trabajaban
con la misma información pero de diferente
manera. Así que al corregir esto mejoramos
nuestra eficiencia. Lo otro que hicimos fue
acercarnos a nuestros proveedores y buscar maneras creativas de resolver las cosas.
Por ejemplo, que pasa si en lugar de adquirir y despreciar los activos empezamos a
arrendarlos en un esquema de demanda, o
si en lugar de comprar licencias rentamos
servicios, o si en lugar de tener a los programadores ahí sentados, nos apoyamos
en proveedores externos.
¿Qué criterios de evaluación utilizas para
escoger proveedores de servicios de TI?
Más que nada nos fijamos en el nivel de la
gente. Normalmente cuando tú encuentras
un despacho que trae elementos de buen nivel, eso habla mucho de la empresa y cómo
escoge a su personal.
¿Cuáles consideras que son los principales
retos que viven los CIOs hoy en día?
Uno de los mayores retos es la alineación de TI
con el negocio, lograr tener esa visión lo suficientemente profunda para entender cómo es
que la tecnología afecta la operación central
del negocio. Hoy ya no es como antes, cuando
el contador te decía “necesito un sistema para
llevar la contabilidad”, así que era fácil definirlo y justificarlo. Hoy en día ya estamos hablando de iniciativas mucho más complejas, como
por ejemplo, Business Process Management.
Entender estos conceptos requiere madurez
no sólo en términos de tecnología, sino principalmente de la operación del negocio.
¿Cómo ha evolucionado el rol de las áreas
de sistemas y hacia dónde va?
En los 90s el rol del área de sistemas era una
cuestión eminentemente técnica. Ese periodo
ya pasó y hoy más que nada lo que hacen es
administrar la tecnología como un recurso.
Esto significa que cada peso que la organización destina a los sistemas debe ser lo más
inteligentemente gastado, para que de ser
posible pueda devolver dos pesos. Hacia el
futuro, creo que esta área deberá estar mucho
más involucrada en el negocio, para proveer
una visión “tecnologizada” de éste. Como
parte de esta visión, su responsabilidad será
proponer iniciativas que mejoren el negocio o
lo habiliten hacia nuevas oportunidades.
¿Entonces ya no bastará con
saber programar?
Así es. Cualquiera puede programar hoy en
día. El único diferenciador que puedes tener
es el conocimiento de negocio. El saber hacer
negocio con la tecnología es muy relevante.
¿Crees que BPM sea una moda o que sea real?
BPM a fin de cuentas es un concepto, cuyos
fundamentos están en la operación del negocio. No es algo nuevo, lo que sucede es
que hace muchos años las herramientas
que había eran poco adecuadas, y estaban
completamente desligadas entre sí. La orquestación de procesos entre sistemas era
imposible, ya que tenías que meterte a las
tripas de cada sistema y desarrollar procedimientos y llamadas a nivel de sistema operativo, entonces esto era muy poco práctico.
Hoy en día la tecnología ya evolucionó, y
todo esto es mucho más natural.
¿Nos puedes contar algo sobre su proyecto
para cumplimiento de Sarbanes Oxley?
La ley de Sarbanes Oxley es un mandato
para todas las empresas públicas que cotizan en el mercado de valores de Nueva York,
como nosotros. Esto significa básicamente
tener una definición de controles lo suficientemente robusta para permitir a los auditores hacer una atestiguación de que estás
controlando adecuadamente la empresa y
no estás defraudando a los inversionistas.
¿Crees que Sarbanes Oxley trae beneficios
más allá de cumplir con el mandato?
Sí. Cualquier empresa debe tener idea de qué
hace, cómo lo hace, cuándo lo hace, y qué oportunidades tiene de mejorarlo. Y la única forma de
lograr esto es teniendo clara la definición de los
procesos. No hay mejora si no hay procesos.
¿Cuáles son las principales habilidades y
conocimientos que necesita tener un CIO?
Al igual que para cualquier profesión, el conocimiento más importante es el de ti mismo. Hay que saber cómo es que aprendes,
cómo resuelves problemas, cómo enseñas.
Esto te hace ver tus principales fortalezas y
debilidades, y a final de cuentas te permite
mostrar una imagen auténtica de ti.
¿Qué características consideras importantes
en una persona que quieres reclutar?
La actitud es lo más importante. La gente
debe estar dispuesta a aprender, crecer, y
entrarle a la chamba difícil. El conocimiento
es secundario porque se puede adquirir.
¿Qué le pedirías al gobierno, las instituciones educativas y las empresas para desarrollar la industria de software?
Al gobierno, apoyo para facilitar el establecimiento de nuevas empresas. A las
instituciones educativas, que generen profesionistas más completos, que además de
habilidades técnicas cuenten con habilidades complementarias para que puedan hacer una presentación, administrar el tiempo,
comunicarse adecuadamente, etc. A las empresas, mayor determinación e innovación.
Frecuentemente, en México, cuando hay
oportunidades que involucran riesgo, simplemente no le entramos. Esperamos a que
llegue alguien más y lo haga. Creo que debemos aventarnos a vivir el sueño, en lugar de
seguirlo soñando.
¿Qué mensaje le dejas a nuestros lectores?
Que lean la revista, tiene cosas muy interesantes. Mucha gente está más pegada al rollo
de los lenguajes de programación y los bits y
los bytes, que en tratar de entender el proceso completo de desarrollo de software.
JUL-AGO 2005
19
EN PORTADA
BPM
Una Herramienta de Competitividad
Por Francisco López Lira
Las empresas enfrentan un entorno complicado. Por
un lado, la competencia es global y se hace contra
países con sueldos menores, lo que implica que las
empresas deben reducir sus costos o crear mayores
diferenciadores para competir. Por el otro, la situación económica adversa ha hecho que se disponga
de menor cantidad de recursos y ahora es necesario
hacer más con menos. Además, los clientes están más
informados y cuentan con mayor poder de elección,
lo cual genera más presión para venderles y retenerlos. Por si esto no fuera poco, los mercados y las condiciones cambian continuamente, requiriendo de las
empresas rapidez de adaptación y una mayor flexibilidad para el cambio.
20
JUL-AGO 2005
“Hay un método en esta locura”
—Horacio
M
uchas han sido las iniciativas
que a lo largo de los años se han
propuesto para que las empresas puedan afrontar estos retos.
Desde la Gestión de Calidad
Total (TQM) hasta Six Sigma (6σ), pasando por
Reingeniería de Procesos de Negocio (BPR), Just in
Time (JIT), Costeo Basado en Actividades (ABC),
Kaizen, Supply Chain Management (SCM) y Balanced Scorecard (BSC), por nombrar algunas. Por
supuesto, la tecnología de información ha estado
presente con propuestas propias, que se remontan
a la promesa de los Sistemas de Información Gerenciales (MIS) y la tecnología Cliente/Servidor
hasta llegar a los ERP y los CRM, sin olvidar las
soluciones Business to Business (B2B).
Tristemente, estas iniciativas no siempre han
dado los resultados esperados. Muchas fueron las
empresas que con gran ilusión se embarcaron en
la ola de Reingeniería de los 90’s, obteniendo resultados muy por debajo de lo esperado. Según el
propio Michael Hammer, 70% de estos proyectos
resultaron en fracasos. Esto ha dado lugar a un
gran escepticismo y ha creado el síndrome de cure
du jour. Por el lado de los proyectos de tecnología de información, los fracasos acumulados en
la industria han dado lugar a que los Directores
de Sistemas enfrenten ahora una creciente presión
para (a) probar que la tecnología de información
entrega valor a la organización, (b) involucrar a
las diferentes áreas en las decisiones tecnológicas,
(c) reducir costos, y (d) mantener bajo control los
riesgos, lo cual ha dado lugar al concepto de Gobernanza de TI (IT Governance).
¿Por qué estos esfuerzos no han tenido el éxito esperado? Un estudio sobre la utilización de 200 herramientas administrativas en 160 empresas durante
un lapso de diez años, encontró que las empresas
que alcanzan un desempeño superior son las que
dominan cuatro elementos fundamentales: estrategia, cultura, estructura y ejecución, independientemente de la herramienta utilizada. Esto implica
que las organizaciones, primero, deben de elaborar
una estrategia adecuada, que permita aprovechar
las condiciones externas y las capacidades internas.
Una vez que se cuenta con ésta, la cultura —los
supuestos compartidos— debe alinearse para permitir alcanzar los objetivos, al igual que debe crearse una estructura organizacional que soporte las
iniciativas dentro de la organización.
Ahora bien, ¿cómo pueden las organizaciones
ejecutar adecuadamente? Las organizaciones sólo
cuentan con dos formas de instrumentar las estrategias: los proyectos y los procesos. Recordemos que un proyecto es “un esfuerzo temporal que
se lleva a cabo para crear un producto o servicio
único”, mientras que un proceso puede definirse
como “un conjunto de actividades que transforman
insumos en productos de valor para un cliente”. Es
importante hacer notar que los proyectos, a su
vez, están formados por procesos y que 80% del
fracaso o éxito de los proyectos está relacionado
con una buena administración. Los elementos
clave para la ejecución son pues, los procesos y
su administración. Si repasamos las iniciativas
citadas, veremos que en todas los procesos tienen
un papel clave: son un área importante dentro de
un esfuerzo de TQM, son el foco central de BPR,
Kaizen y 6σ, y son cruciales en JIT, ABC y BSC.
Los procesos también ocupan un lugar trascendente en las iniciativas tecnológicas. Por ejemplo,
¿quién puede negar su importancia en un ERP o
B2B? Los procesos son importantes porque es a
través de ellos que la organización genera valor
para sus clientes, integrando la participación de
diferentes áreas funcionales a través de toda la cadena de valor.
En este contexto, surge con mucha fuerza una
iniciativa llamada Business Process Management
(BPM) que puede ayudar a consolidar todos los
esfuerzos anteriores. En el año 2000, Gartner predijo que BPM sería el siguiente gran fenómeno, y
posteriormente comentó que “BPM gana la triple corona por ahorrar dinero, ahorrar tiempo y
añadir valor”. Otro estudio realizado por el BPM
Institute arrojó que 96% de los encuestados indicaron que un enfoque centrado en procesos era
crítico para el éxito de su compañía.
¿Qué es BPM?
BPM consiste administrar el ciclo de vida de los
procesos, apoyándose en herramientas de automatización del flujo de trabajo, conocidas como
Business Process Management Systems o BPMS.
Aunque algunos opinan que BPM no necesariamente involucra un BPMS, en mi opinión esto le
resta potencial a la solución y no permite distinguirla fácilmente de otras propuestas como Kaizen, por ejemplo.
El ciclo de vida de un proceso cubre su conceptualización, representación (gráfica y/o textual),
optimización, automatización, simulación y
prueba, e implantación en la organización. Por
otro lado, la administración incluye la planeación, seguimiento, monitoreo y control.
JUL-AGO 2005
21
EN PORTADA
Beneficios
En su reporte Technology Focus: Business Process Management, Doculabs lista
como beneficios para las organizaciones
la reducción de costos, mejor servicio al
cliente, reducción de riesgos y una rápida
respuesta a las condiciones cambiantes.
De acuerdo con un estudio de Gartner,
78% de los proyectos de BPM arrojaron
una tasa interna de retorno mayor a 15%,
y algunos llegaron a 360%, lo cual justifica el costo de la solución.
BPM es la convergencia de iniciativas administrativas anteriores: toma el concepto
de enfoque de procesos y de mejora continua de Kaizen y TQM, la posibilidad de
innovar radicalmente los procesos de BPR,
el enfoque en la mejora con base en datos
estadísticos de 6σ, la idea de operación en
línea de JIT, el costeo de procesos de ABC,
la integración de procesos de SCM y la
idea de un tablero de control de BSC. Los
BPMS, por otro lado, aprovechan nuevas
tecnologías como XML y web services,
pero —maravillosamente— habilitando
la integración con sistemas legados, ERPs,
CRMs y herramientas de BI. Todo esto sin
perder de vista el proceso desde el punto de
vista del negocio.
BPMS
Para entender lo que es un BPMS, enlistemos
sus componentes funcionales típicos:
• Modelador de procesos.- Ayuda a descubrir
y modelar los procesos.
• Herramientas de desarrollo.- Diseñador de
formas y editor de reglas.
• Integración.- Habilita la integración para
interactuar con otras aplicaciones.
• Máquina de procesos.- El motor que habilita
la ejecución de procesos. Ejecuta instancias de
procesos en base al estado de los objetos y las
reglas definidas.
• Repositorio.- Almacena meta-definiciones
de procesos, participantes e integración.
• Gestión.- Provee registros de auditoría. Adicionalmente habilita la intervención manual
para redirigir, abortar o modificar la instancia
de un proceso en caso de emergencia.
• Reporte y Análisis.- Permite visualizar y
analizar la ejecución de los procesos.
Contraste con Paquetes
Los proveedores de paquetes y aplicaciones empresariales acostumbran argumentar que sus
productos cubren prácticamente todas las necesidades de una organización. Sin embargo, sabemos que esto dista de ser verdad. Según Gartner,
un ERP cubre en promedio únicamente 30% de
la funcionalidad requerida en las empresas. Adicionalmente, existen muchas actividades que involucran participación y toma de decisiones por
parte de las personas. Cuando estas actividades
no están incluidas en las aplicaciones, se crean
actividades fuera del proceso automatizado. Si el
proceso requiere la intervención de varios sistemas, se crean islas de automatización que obligan a las personas a utilizar papel o paquetería de
oficina para pasar de una “isla” a otra. Son famosas las historias de cómo las personas se ingenian
para usar una hoja de cálculo y “darle la vuelta” a
un ERP. Aún cuando a un paquete se le integre
una máquina de procesos, la solución está centrada en los “recursos” o “los clientes” y no en
los procesos de negocio. Así como un manejador
de bases de datos está hecho para manejar bases
de datos, tablas, columnas e índices, un BPMS
está diseñado para manejar procesos, instancias,
versiones y variantes, componentes, reglas y participantes de procesos. Esto cambia el enfoque
de centrado-en-datos a centrado-en-procesos.
Impacto al área de TI
BPM tiene una repercusión importante para
los roles relacionados con el software. Los proyectos de BPM serán parte del portafolio de
proyectos de las áreas de Sistemas y deberán ser
controlados por el Director. Los desarrollos de
software a la medida incluirán cada vez más la
identificación y modelado de los procesos de
negocio. Los desarrollos de software basados en
un BPMS requerirán que los desarrolladores
entiendan los procesos de negocio y sepan usar
la herramienta. Los analistas de sistemas deberán aprender sobre análisis de procesos, al igual
que los usuarios. Los testers deberán realizar
pruebas con una visión del proceso completo.
Los administradores de bases de datos deberán
incorporar bases de datos de procesos. Los administradores de redes deberán incluir en su
administración servidores de procesos y considerar el ancho de banda necesario para asegurar
el tráfico de la información de los procesos, no
sólo a través de la organización sino también
con los socios de negocio. Los administradores
de configuración tendrán que considerar entre
sus ítems a los procesos y sus objetos derivados. Los administradores de proyectos deberán
entender las implicaciones de la participación
de los usuarios de negocio y de los analistas de
procesos. Los especialistas en seguridad deberán ahora brindar seguridad a todo el proceso.
Pero no todo es mayor trabajo para el personal de Sistemas. En retribución, los sistemas
desarrollados tendrán una mayor visibilidad y
una mayor participación de las áreas usuarias.
Será posible reanimar sistemas “muertos” o
poco utilizados. Los usuarios podrán contar
con una interfaz común sin importar si detrás
está un ERP o un sistema legado. Quizá lo
más importante para nuestra industria es que
se aprovecha y potencía la inversión existente
en tecnología de información.
¿Cómo se relaciona BPM con los esfuerzos de
mejora de procesos basados en modelos? ¿No
son BPM también? Los modelos como CMMI
o MoProSoft son un gran avance ya que llevan
el concepto de administración de procesos a
las organizaciones de sistemas/software. Existen otros modelos, como SCOR para cadena
de suministro (Supply Chain), ITIL para servicio tecnológico, o COBIT para el control de
los objetivos. Todos ellos se basan en procesos
y considera en menor o mayor grado su administración. Las diferencias cruciales, quizá
sean que BPM primero lleva estos conceptos a
toda la organización, y además, tomando ventaja explícita de la tecnología para crear procesos digitalizados. Esto no significa que los
esfuerzos basados en estos modelos compitan
con BPM. Más bien, son un paso importante
en el sentido de lo que se buscan con BPM.
Por último, más no por menos, es importante
mencionar que además del expertise técnico en
BPM, un esfuerzo exitoso de este tipo requiere
incluir una administración efectiva de los proyectos, administrar el cambio organizacional,
obtener el patrocinio suficiente, y alinearse con
los objetivos estratégicos del negocio.
Referencias:
• William Joyce, Nitin Noria, Bruce Robertson. “What
Really Works”. Harvard Business Review. Julio 2003
• Jim Sinur, Jess Thompson. “The Business Process
Management Scenario.” Gartner Research. Junio 2003
• Thompson, Michael. “Requirements for effective
BPM”, Butler Group. Junio 2003
Francisco José López Lira e Hinojo es Director Operativo de Process & Project Health Services, firma dedicada a la consultoría en BPM y mejora de proyectos, Presidente de la Asociación Mexicana para la Calidad en Ingeniería de Software (AMCIS) y Vicepresidente de la Asociación BPM de México. Su correo es [email protected]
22
JUL-AGO 2005
Desde hace varios años las organizaciones (empresas
privadas o instituciones públicas) han ido incrementando el uso de procesos con el objeto de mejorar su
desempeño y mantener su operación. Podemos ver
reflejada esta megatendencia en muchos contextos
donde el proceso es una entidad relevante: paquetes
empresariales de software basados en modelos estándar de procesos (CRM, ERP, SCM), modelos de gestión del desempeño empresarial (Balanced
Scorecard), modelos de calidad (ISO
9000:2000, TQM), métodos de mejora de procesos (Six Sigma, BPR),
modelos de referencia de madurez
y capacidad de procesos (CMMI,
SPICE), modelos de procesos
específicos (RUP, SPEM, ITIL),
entre otros.
BPMS
La Nueva Plataforma de Misión Crítica
Por Roberto Silva
En la actualidad, los proveedores requieren acelerar la entrega de más valor a sus clientes y al mismo tiempo disminuir sus costos. Sin embargo, las
organizaciones no han comprendido la naturaleza
básica de los procesos y aún no han encontrado
una infraestructura de TI que signifique valor real
para el negocio en términos financieros (para las
organizaciones no lucrativas varía la unidad pero
no el concepto de valor).
JUL-AGO 2005
23
EN PORTADA
A finales de la década pasada aparecieron los primeros Sistemas de Administración de Procesos
de Negocio o BPMS (Business Process Management Systems) que permiten a las organizaciones mapear, integrar, liberar, medir, monitorizar,
controlar, analizar y optimizar procesos de negocio de misión crítica que requieren ser integradas
en una verdadera cadena de generación de valor
para un cliente final y ligada directamente al logro de objetivos estratégicos.
El objetivo de este artículo es dejar claro qué
es un BPMS, qué podemos hacer con él, pero
sobre todo, entender porqué es la plataforma
de misión crítica para toda organización que
pretenda sustentar el logro de sus objetivos y
mantener sus ventajas competitivas en un ambiente complejo de cambios constantes[1].
Fundamentos
Considerando que los proveedores de software o sus representantes son especialistas en
generar confusión alrededor de productos innovadores en el afán de venderlos, considero
muy importante aclarar que la Dirección de
Procesos de Negocio o BPM (Business Process
Management) al igual que, por ejemplo, CRM
(Customer Relationship Management), no son
términos acotados únicamente a un paquete
de software especializado ni tampoco es una
meta que puede ser alcanzada en un cierto
plazo ejecutando una serie de proyectos, es
una manera de vida.
¿Qué es BPM?
BPM es toda una filosofía de trabajo que coloca al proceso de negocio al centro de su universo, es la manera moderna de administrar
un negocio, donde su propósito es asegurar la
mejora continua del desempeño organizacional en un ambiente de cambios constantes.
Una empresa que practica BPM entiende y
vive tanto la operación como el desarrollo organizacional en términos de procesos de negocio integral y naturalmente. Los procesos de
negocio son las unidades de sincronización de
cambios, de generación de valor para los clientes, y de logro de objetivos estratégicos, más
adelante ahondaré al respecto en el bloque de
pensamiento sistémico.
24
JUL-AGO 2005
En una organización hay tres tipos básicos de
procesos de negocio. Los centrales son aquellos procesos cuyo cliente es el beneficiario de
la oferta de valor de la organización: los clientes comercialmente hablando; los estratégicos
son aquellos cuyo cliente es la organización
como un todo, ya que el valor obtenido es
mejor infraestructura organizacional en términos, por ejemplo, de mejores profesionales
o mejores sistemas de información; finalmente los procesos de soporte son aquellos cuyo
cliente es otro proceso de negocio, ya que el
valor que recibe es una entrada necesaria para
poder lograr su objetivo particular.
Sin embargo, un cuarto tipo es el más importante en BPM. Los procesos de negocio empresariales o EBP (Enterprise Business Process)
son los vitales, ya que corresponden a las grandes cadenas de generación de valor que involucran varias entidades internas y externas a la
organización (atraviesan varios departamentos
funcionales, requieren el uso de diversos sistemas y aplicaciones de software, involucran
proveedores y muchas veces aliados de negocio) cuyo alto desempeño significa el logro de
objetivos estratégicos. El BPMG[3] define a un
EBP como: “la coordinación de lado a lado (a
través de departamentos o inclusive fronteras organizacionales) de las actividades de trabajo que
genera y entrega valor real a clientes”. El gran
reto es desarrollar esta nueva capacidad que
requiere, como primer paso, romper el paradigma del pensamiento funcional.
¿Qué es un BPMS?
Desde el punto de vista BPM, un BPMS es
el principal facilitador para implantar un programa permanente de mejora continua en
la práctica, ya que es imposible administrar
sistemas tan complejos como lo son los procesos de negocio empresariales, simplemente,
¿cómo podríamos medirlos y monitorizarlos
en tiempo real?
Desde el punto de vista organizacional, un
BPMS es el medio de organización, alineación
y sincronización de las entidades (recursos) de
negocio más importantes en un mismo sistema integral y coordinado: personas, reglas de
negocio, datos, sistemas informáticos existen-
tes y aplicaciones de software (especialmente
servicios) nuevas sin importar su ubicación ni
alcance, ya que las personas pueden pertenecer
a diferentes departamentos u organizaciones y
estar en diferente piso o país, siempre que el
BPMS esté basado en estándares.
Desde el punto de vista técnico, un BPMS es
una plataforma que permite integrar la infraestructura tecnológica existente en un ambiente
Web que, a su vez, permite preservar los beneficios específicos de aplicaciones legadas. Al
mismo tiempo, es un bloque de construcción
esencial para un nuevo tipo de arquitectura
aplicativa, basada en estándares y orientada
a servicios (SOA). Soporta además procesos
B2X (B2B, B2C, B2P, B2E, etc.) y permite
a los diseñadores de aplicaciones construir soluciones orientadas a procesos de una manera
muy rentable y efectiva.
Desde el punto de vista del negocio, un BPMS
es el medio que finalmente permitirá integrar
Negocio y TI con un sentido estratégico, donde por un lado TI se enfoca al desarrollo de
la infraestructura tecnológica centrada en procesos y arquitecturas aplicativas orientadas a
servicios (SOA) y por otro lado le regresa el
control del negocio al negocio: extrayendo las
reglas de negocio implantadas mediante mecanismos internos a los sistemas o los manejadores de datos. Según Gartner, las tecnologías
de información son el principal impedimento
para la agilidad organizacional, ya que han sido
enfocadas a la mejora de necesidades funcionales. Además, si consideramos que 80% de
los requerimientos de cambio corresponden
a reglas de negocio (también según Gartner),
regresar el control significa manejar las reglas
de negocio como parte integral de los procesos
de negocio modelados y administrados dentro
del BPMS de manera independiente a las aplicaciones de software.
La Importancia del
Pensamiento Sistémico
Desde hace muchos años, W. Edward Deming, el padre del movimiento de la calidad,
puntualizó que el problema es el “sistema”.
Los procesos de negocio empresariales que
atraviesan las organizaciones funcionales de
Figura 1. Infraestructura de
Software de Misión de Crítica
lado a lado son sistemas dinámicos, pero desafortunadamente los profesionales que dirigen
y ejecutan los procesos generalmente no están
entrenados en el pensamiento sistémico. Lo
común es que su perspectiva esté restringida
a prácticas de negocio de muy bajo nivel de
abstracción (procedimientos muy específicos
y rígidos), realmente pocos profesionales tienen una perspectiva amplia de su contexto
más amplio dentro de la organización.
Hoy día es evidente que conforme avanza el
tiempo tanto el entorno como el interior de
las empresas se van volviendo más complejos y
de hecho la tendencia es hacia ambientes cuya
dinámica será progresivamente más compleja.
Afortunadamente ya tenemos la respuesta a la
interrogante: ¿cómo hacerle? Precisamente el
manejo de esta complejidad es el objetivo del
pensamiento sistémico. Este se enfoca en el
todo, no en las partes, de un sistema complejo.
Se concentra en las interfaces y las fronteras de
componentes, en sus conexiones y organización,
hacia una búsqueda de sistemas holísticos que
potencialmente generen resultados con mucho
más impacto que el de la suma de sus partes.
Cuando el pensamiento sistémico es dominado,
podemos afirmar que el mayor obstáculo para
construir organizaciones administradas por procesos ha sido sorteado, ya que cada proceso de
negocio será entendido, ejecutado y administrado como un sistema completo.
Es por esto que la competencia central más
importante que debe tener una organización
para aprovechar los beneficios de BPM es el
pensamiento sistémico o “process thinking”.
Los invito a hacer un ejercicio mental muy
sencillo, dediquen unos 20 segundos a mirar
con detenimiento a su alrededor y después
unos 30 segundos más a elaborar una lista de
los cinco elementos más relevantes que se les
quedaron grabados considerando que nuestro objetivo es trasladarnos de un punto A
hacia un punto B, seleccionados por ustedes
en el entorno visible. Ahora traten de hacer
lo mismo pero enfocados en toda la colonia o
entorno mayor en el que se encuentren, planteando un trayecto más amplio. ¿La segunda
lista tiene algún elemento? Ahora repitamos el
ejercicio, pero esta vez imaginen que se han
subido a un helicóptero y se han elevado unos
50 metros sobre el punto donde hace un momento se encontraban, en este caso les propongo dos preguntas: ¿qué pueden ver si están a 50
metros de altura a un nivel todavía más amplio,
digamos a nivel de la delegación, municipio o
inclusive país en el que se encuentran? Desde
esta perspectiva, ¿qué impacto relativo tienen
en su vista los cinco elementos originales que
teníamos a la mano a nivel del piso?
El problema para las organizaciones tradicionales de pensamiento funcional es que el reto
de acelerar la generación de cada vez más valor para sus clientes finales y al mismo tiempo
disminuir costos está como a 1,000 metros de
altura. El helicóptero es el BPMS, por eso son
necesarios para una organización que quiera
sobrevivir, crecer o destacar en un entorno de
cambios constantes, pero no hay que perder
de vista que no es suficiente, no por subirnos
al helicóptero ya resolvimos el problema, simplemente estamos en condiciones de aspirar a
ello con mucho mayor probabilidad, ya que
en el fondo un BPMS sólo es una herramienta
muy poderosa que debe ser utilizada correctamente para poder obtener todos sus potenciales beneficios que a continuación abordaré. El
otro elemento clave es el piloto del helicóptero, es decir, el pensamiento sistémico.
Plataforma de Software
Centrada en Procesos
La plataforma de misión crítica predominante durante ya varios años son los RDBMS,
con los cuales administramos el ciclo de vida
completo de datos de negocio, establecemos y
mantenemos las relaciones y estructura de los
datos de negocio, controlamos el acceso y modificación de los datos de negocio en función
a privilegios, hacemos consultas en función a
criterios que se aplican al repositorio de datos
de negocio, entre otras capacidades. Si sustituimos la palabra “datos” por “procesos”,
estaremos hablando de un BPMS. Por cierto,
el fundamento del éxito de los RDBMS es ni
más ni menos que las matemáticas, el álgebra
relacional como la base de los motores relacionales. Para el caso de los BPMS su éxito tiene
el mismo nivel de sustento en la misma ciencia, sólo que en este caso es teoría de procesos
como la base de los motores de procesos, que
es el corazón de un BPMS.
RDBMS vs. BPMS
En el caso de la plataforma de misión crítica
del pasado (para muchos todavía el presente),
los sistemas informáticos son las entidades que
llevan el control de las actividades y en general determinan el cuándo, el cómo, y el quién
hará uso de los servicios del DBMS. En el caso
de la nueva plataforma de misión crítica del
presente y del futuro, los procesos de negocio
en sí mismos son las unidades de negocio que
llevan el control de la ejecución y en general
determinan cuándo, cómo, y quién hará uso
de los servicios del BPMS (ver Figura 1).
En el fondo, lo que estamos consiguiendo es
contar con una plataforma de mayor nivel de
abstracción y por lo tanto de mucho mayor
impacto y visibilidad a nivel negocio. Es por
esto que muchos consideran a los BPMS como
una herramienta más orientada al negocio que
a TI. De hecho, Delphi Group, en sus reportes anuales acerca del estado y tendencias en el
mercado de software BPM a nivel mundial, ha
confirmado en más de una ocasión, que dos
de cada tres decisiones positivas para adquirir
un BPMS son realizadas por algún ejecutivo
de negocio ajeno al departamento de TI.
Esta percepción es muy simplista, superficial y
errónea. Como ya lo he dicho, debemos romper
JUL-AGO 2005
25
EN PORTADA
estándares como el Xf-XML del WFMC[4]
en combinación con el XPDL del mismo
WFMC o el WS-BPEL de OASIS[5] hacen
posible la colaboración entre instancias bajo
esquemas de seguridad confiables y donde
inclusive cada parte podría tener un BPMS
distinto (ver Figura 1).
Infraestructura de Software Empresarial Centrada en Procesos
Figura 2. Administración de Procesos de Software Orquestados
el paradigma tradicional del pensamiento funcional que ha mantenido separados a los departamentos de las empresas, especialmente a
Negocio y TI, cuando debemos entender que
TI es una parte fundamental (subsistema) del
negocio (sistema). De hecho, con la inclusión
de un BPMS en la arquitectura de TI estamos
logrando que por fin la aportación de TI al negocio sea visible a todo lo largo de las cadenas
de generación de valor medible en términos
financieros y alineables a objetivos de negocio.
Por si fuera poco, incrementa la visibilidad del
valor generado por cada uno de equipos de trabajo que ejecutan procesos, fortaleciendo el entendimiento, la comunicación y su aportación
al logro de la estrategia organizacional.
Dimensiones de un BPMS
El motor de procesos (corazón de un BPMS)
es representado por un cubo, donde la cara
superior representa la dimensión correspondiente a la capacidad central de orquestación
de procesos de negocio, la cara izquierda representa la dimensión correspondiente a la
integración tecnológica realizada hacia el
interior de la organización, y la cara derecha
representa la dimensión correspondiente a la
colaboración con entidades externas a la organización.
La orquestación de procesos de negocio es la
capacidad de coordinar la ejecución de cadenas de generación de valor al grado de llegar
a conseguir una armonía sistémica orientada
a la optimización del uso de recursos y generación de resultados tangibles para un cliente final común en el menor tiempo y costo
posibles. Los elementos primarios que son
coordinados son los flujos de tareas, reglas de
negocio, roles de negocio (responsabilidades
definidas en tiempo de diseño), y personas
(usuarios en tiempo de ejecución a través de
su mapeo a roles de negocio).
La integración tecnológica orientada a procesos es la capacidad de integrar sistemas existentes, aplicaciones nuevas, datos de negocio,
directorios y archivos al nivel de abstracción
del proceso de negocio en el que participan,
es decir, al nivel de la cadena de generación
de valor a la que pertenecen. Una ventaja muy
relevante es que las aplicaciones quedan desacopladas entre sí, es decir, ya no se comunican directamente con el enfoque tradicional
de integración de aplicaciones punto a punto,
lo que simplifica enormemente el desarrollo
y mantenimiento de software con valor real
para el negocio y por lo tanto sus costos asociados son minimizados, de hecho, esta es la
base conceptual de SOA.
La dimensión de colaboración representa la
capacidad organizacional para ser parte integral de cadenas de generación de valor más
amplias donde nuestros procesos de negocio
empresariales pasan a ser subprocesos de procesos de negocio intercompañía con un potencial mucho mayor. La disponibilidad de
El beneficio directo de un BPMS es que
permite asegurar la mejora continua del
desempeño del propio proceso de dirección
de procesos de negocio. Es decir, un BPMS
permite aterrizar la filosofía BPM como un
proceso estratégico cuyo resultado de valor
son procesos de negocio de alto desempeño,
donde el cliente es la organización como un
todo. Al ver BPM como un proceso podemos
administrar su ciclo de vida completo con el
soporte de la nueva plataforma de misión crítica (ver Figura 2).
El Business Process Management Group[3]
(BPMG) ha establecido que BPM es “el enfoque deliberado y colaborativo para manejar
sistemáticamente todos los procesos de negocio de
una organización” donde sus dos facilitadores
fundamentales son el pensamiento sistémico y
las tecnologías de información centradas en procesos. Este mismo consorcio ha puntualizado
los dieciséis grandes retos que enfrentan las
empresas en la actualidad (para sobrevivir,
crecer o destacar en un mundo complejo
donde lo único constante y seguro son los
cambios[1]) durante el proceso de adopción de
BPM y en trece de ellos el BPMS es la pieza
fundamental para soportar el desarrollo y mejora continua de las capacidades organizacionales requeridas para afrontar estos retos con
éxito. Especialmente es destacada su aportación directa para el desarrollo de las capacidades “agilidad” y “adaptación”.
Referencias
1. Roberto Silva, “Negocios Ágiles”.
Impulsare e-zine. www.impulsare.com
2. Howard Smith and Peter Fingar, Business
Process Management: The Third Wave, MeghanKniffer Press, 1st Edition 2003.
3. The Business Process Management Group, In
Search of BPM Excellence: Straight from Thought
Leaders, Meghan-Kniffer Press, 2005.
4. WFMC: The Workflow Management Coalition
www.wfmc.org
5. OASIS. www.oasis-open.org
Roberto Silva es Socio Fundador de Impulsare, empresa dedicada a la educación y consultoría en integración de negocios. Es Director de Horbis, enfocada exclusivamente al diseño e implantación de soluciones de integración de cadenas de valor centradas en procesos. Tiene nueve años de experiencia como empresario y catorce
años como consultor en el desarrollo e integración de sistemas de negocio y software para diversos sectores en México y América Latina. Es Consultor Asociado de la
Fundación Mexicana para la Innovación Gubernamental y Empresarial y miembro activo del Business Process Management Group.
26
JUL-AGO 2005
Por más de 15 años me he
dedicado al desarrollo de sistemas con lenguajes de programación estructurado, no
estructurados, y orientados a
objetos. Estos siempre habían
sido mis herramientas de
trabajo en la programación
para automatizar procesos. A
continuación les presento mi
experiencia realizando este
mismo trabajo bajo un nuevo
paradigma.
BPM
Desde la Perspectiva de
un Desarrollador
Por Ernesto Méndez Solís
JUL-AGO 2005
27
EN PORTADA
Como consultor en el desarrollo de software,
es muy común ser asignado a proyectos en los
que participan consultores de otras empresas
formando de esta manera equipos de trabajo
interdisciplinarios y multiempresa; unos se encargan de la administración y metodología del
proyecto, otros más del análisis, diseño, modelación, desarrollo, documentación y pruebas,
por mencionar solo algunas de las diferentes
tareas involucradas. Fue de esta manera que
fui asignado a participar en un proyecto en el
que había que automatizar el flujo de un proceso administrativo de una empresa dedicada
a la comercialización, industria perteneciente
al sector conocido como retail.
Así que me integré al equipo, que estaba conformado por tres diferentes empresas y fui asignado a la fase de desarrollo. Solo requería tener
conocimientos básicos de programación orientada a objetos y experiencia en el análisis, diseño y desarrollo de sistemas. La herramienta que
se iba a utilizar para este desarrollo se llamaba
Fuego. En mi vida había oído hablar de esta
herramienta, por supuesto que no se requería
experiencia, se dedicaría un periodo inicial para
capacitar a los desarrolladores antes de iniciar
formalmente el proyecto. Así fue como conocí
el concepto BPM. Fuego, es mas que una herramienta de desarrollo, es un ambiente de trabajo. Este ambiente de trabajo, se puede dividir
a su vez en dos: el ambiente de producción y el
ambiente de desarrollo y configuración. Estos
están basados en aplicaciones comunes a los
ambientes de sistemas: navegadores, servidores
web, servidores de bases de datos y servicios de
directorio, por mencionar algunos. Algunas
aplicaciones propias de Fuego complementan
el ambiente de producción y desarrollo: motor
de orquestación, portal de trabajo, administrador de componentes, administrador de la organización, diseñador de procesos, consola de
ejecución y el analizador de procesos.
Aunque pudieran parecer una gran cantidad
de aplicaciones, realmente no es tan complicado preparar el ambiente de operación y
desarrollo, inclusive el de desarrollo se puede
preparar en un solo equipo para poder trabajar en forma independiente y aislada para posteriormente poder desplegar el proceso en el
ambiente de producción.
Recuerdo que en alguna ocasión me tocó programar aplicaciones del tipo “flujo de trabajo”
utilizando lenguajes de programación convencionales. Esto representó un reto algo diferente al de cualquier otro tipo de desarrollo, pero
nada que impidiera alcanzar finalmente el éxito
y la automatización del proceso correspondiente. Sin embargo, los BPMS están específicamente diseñados para automatizar en forma
sencilla este tipo de procesos.
La clave del éxito de este tipo de ambientes
de desarrollo es el denominado “diseñador de
procesos”, la herramienta central del BPMS.
Al mismo tiempo, representa el mayor de los
retos que los programadores de lenguajes tradicionales enfrentan al pretender automatizar
un proceso. En este caso, la clave es “modelar el proceso” tal como se desarrolla en la
práctica; lo que implica primero, identificar
los diferentes pasos que el proceso incluye
para posteriormente, apoyado en una serie de
íconos para el modelado, representarlo gráficamente en el diseñador, considerando los
participantes en el proceso y los conectores
que comunican las actividades o pasos.
Aunque esta representación gráfica del proceso esta diseñada para que cualquier analista de
negocio e inclusive ejecutivo participante del
proceso lo pueda entender, la construcción o
modelado del proceso requiere de un nivel de
abstracción adicional al requerido simplemente
para su entendimiento. Un elemento fundamental a considerar al momento de modelar es
lo que se denomina una “instancia”. Las instancias son las ejecuciones individuales de un
proceso. Cada vez que se inicia un proceso, se
crea una instancia y el sistema mantendrá un
estricto control de ésta mientras fluye por cada
una de las actividades hasta llegar al punto final. Paralelamente, el sistema almacena la información de la instancia en la base de datos
para poder conocer el detalle particular de su
flujo, en función de la actividad particular en
la que se encuentre. Todavía hay un par de factores más a considerar en el modelado de un
proceso: la transformación o característica que
agrega cada una de las actividades a la instancia
y la descomposición de una instancia en dos o
más partes para poder realizar procesos paralelos que permitan posteriormente la reintegración de la instancia en una actividad posterior.
Considerar todos estos factores para poder modelar un proceso, resulta ser una tarea no muy
fácil cuando no se tiene experiencia y se esta
acostumbrado al proceso tradicional de desarrollo de aplicaciones. Por instinto uno quiere
aplicar sus conocimientos de programación al
modelado de procesos, lo cual solo crea gran
frustración y largas horas de reproceso.
Desde mi punto de vista, esto requiere de un
cambio de paradigma en el proceso de conceptualización y análisis cuando se utilizan
herramientas BPMS. Para contextualizar,
equivale al cambio de paradigma que los programadores de la vieja guardia tuvimos que
hacer cuando pasamos de la programación estructurada a la programación orientada a objetos. Se dice en forma muy sencilla, pero este
cambio de paradigma resulta bastante difícil
de realizar. Sin embargo, cuando una persona
que aprende a programar, lo hace inicialmente
bajo el paradigma de objetos, se le facilita ya
que no está acostumbrada a un paradigma alterno. Lo mismo aplica en el caso de los BPM,
los consultores que normalmente no realizan
las tareas de análisis, diseño y codificación de
sistemas, se les facilita un poco más el entender el concepto de modelado de procesos.
Una vez superada esta primera fase del proceso, la modelación, sigue la fase con la que los
programadores estamos más familiarizados,
la codificación. Cada una de las actividades
modeladas, lleva intrínsicamente una cierta funcionalidad, la cual es posible expandir
utilizando un lenguaje script, fácil de usar y
que permite configurar las actividades a la
necesidad particular del negocio. Algunas de
las características comunes de configurar en
las actividades son por ejemplo: el tiempo
máximo que puede permanecer una instancia
en la actividad, y el manejo de excepciones y
envío de notificaciones a otros integrantes del
proceso entre las más importantes. Con el lenguaje script se puede conseguir funcionalidad
adicional como: presentación de mensajes en
pantalla, acceso a la base de datos, manejo de
variables, expresiones condicionales, bucles y
manejo de sentencias de entrada para obtener
información de parte del operador.
Cuando la funcionalidad requerida en cualquiera de las actividades va mucho mas allá
de lo que se puede lograr con el lenguaje
script, se puede desarrollar un componente
que posteriormente se puede mandar ejecutar
desde cualquier actividad. Los componentes
permiten realizar formatos de captura de in-
El Ing. Ernesto Méndez Solís es consultor independiente especializado en administración y liderazgo de proyectos de desarrollo de software. Ha trabajado para varias
empresas relacionadas con el desarrollo de software como: Siga Desarrollos, Arthur Andersen e Interfaces. [email protected]
28
JUL-AGO 2005
formación mucho más complicados en forma
relativamente sencilla para solicitar información al operador e ir automatizando el proceso según sus requerimientos particulares.
Otra característica interesante que se puede
obtener de los componentes es la posibilidad
de interactuar con otros sistemas para intercambiar información o lanzar procedimientos
externos para conseguir automatizar en mayor
medida el proceso. Por ejemplo, se puede capturar información desde una de estas pantallas (incluyendo sus procesos de validación) y
posteriormente ejecutar un sistema “legacy” el
cual requiere de la información recién capturada, la que le es enviada de forma transparente. Este tipo de actividades, consiguen que los
operadores o participantes del proceso, interactúen con un solo sistema sin necesidad de
tener que usar diferentes aplicaciones e interfaces para conseguir cerrar el flujo del proceso.
Esta característica es una de las más poderosas
que se pueden obtener de un BPM y que precisamente cumple con el objetivo fundamental de este tipo de sistemas: la administración
de los procesos de negocio.
Antes de realizar el proceso de despliegue en
producción, la herramienta permite realizar
tareas de depuración para poder ir siguiendo el flujo de una instancia e ir evaluando
las diferentes variables que intervienen en el
proceso, facilitando sustancialmente la liberación de procesos libres de errores. Cuando
pudiera parecer que la automatización del
proceso ha terminado, ésta solo ha iniciado en realidad. Cuando un proceso esta en
producción, la fase más importante es precisamente la de evaluación para entonces
detectar mejoras, cuellos de botella y la justificación de reingenierías de proceso.
poco susceptibles de poder ser mejorados en
función de la experiencia y que normalmente
se quedan cortos en cuanto al alcance inicialmente programado.
El ambiente colaborativo bajo el que operan
este tipo de desarrollos, intranets y/o extranets, ofrece interfaces nítidas y claras para todos los involucrados, fáciles de operar y con
una curva de aprendizaje muy corta que permite en muy poco tiempo poder administrar
eficientemente los procesos. Desarrollar una
aplicación que permita realizar todas estas tareas y controles utilizando lenguajes de programación tradicionales resulta en proyectos
muy costosos, de muy difícil mantenimiento,
Conclusión
Los ambientes de desarrollo y producción de
los sistemas BPM ofrecen una extraordinaria
alternativa para la automatización y mejora
de procesos, se convierten en herramientas
de vital importancia en la operación de las
empresas ya que permiten adecuar y adaptar
los procesos en forma rápida a los dinámicos
cambios del medio ambiente de negocios que
vivimos hoy en día.
El esfuerzo requerido para establecer un
BPMS, la capacitación de consultores para
la automatización de procesos, así como el
cambio de paradigma que este tipo de herramientas exige a sus diseñadores y desarrolladores, bien vale la pena realizarlo ya que
los resultados que se pueden obtener son
sencillamente espectaculares y no se pueden
obtener con ninguna otra herramienta disponible hoy en día en el mercado.
CASO DE ESTUDIO
El Camino a CMM® nivel 3
Active Intelligence Comparte su Experiencia
Por Rafael Muñoz y Elizabeth Almeraz
En tiempos donde los márgenes canas con recursos económicos limitados, convencimiento y entusiasmo del personal
de utilidad se ven amenazados tomen la decisión de marcar una diferencia y los procesos enfocados y adaptados a la
cada día mas y la competencia en la manera en como se construye software forma de trabajar de Active Intelligence.
contra proveedores mundiales de en México, contribuyendo a poner a todo el
software se ha convertido en una país en el mapa para los mercados globales. La historia
guerra de precios interminable,
Active Intelligence nació en Aguascalientes,
fundada y dirigida por Humberto Sánchez
Active Intelligence, una compa- ¿Cómo se logró?
ñía con 50 integrantes y un año Sin duda el esfuerzo bien enfocado detrás Sandoval y Abraham Ramírez Basurto; el
de historia, consigue el reconoci- de cualquier iniciativa es la clave para obte- objetivo organizacional es la proveeduría de
miento de nivel 3 basados en el ner los resultados esperados. Este caso no servicios de exportación de segunda capa
es la excepción, sin embargo, vale la pena en modalidad de fábrica de software y tiene
modelo SW-CMM®
La historia de Active Intelligence es una historia que vale la pena contar, pues muestra
como al enfocar el esfuerzo en lo que es importante, los resultados que se pueden obtener son muy buenos, además pone el dedo
en el renglón para que más compañías mexi-
desmenuzar un poco la estrategia y características que se juntaron para que la meta
fuera posible. Especialmente es importante
remarcar la importancia en tres factores críticos que permitieron que la adopción de un
modelo de procesos, se hiciera en un tiempo
récord: El apoyo de la dirección, la actitud,
como principal objetivo el ofrecer desarrollo de soluciones de software a distancia. El
Ing. Sánchez, cofundador en 1988 de Ddemesis (que fue reconocida como nivel 3 de
SW-CMM® en 2001) aprovechó un momento
extraordinario en el mercado de exportación
de TI desde Aguascalientes. En 2003 Ddeme-
Rafael Muñoz es egresado de la carrera de Matemáticas Aplicadas y Computación de la UNAM. Actualmente es líder de Active Intelligence y tiene a su cargo las iniciativas de
calidad de esta empresa. Él y su equipo se encuentran actualmente trabajando en la implementación del modelo CMMi en esta compañía. Ha trabajado en el área de TI por más
de diez años, liderando proyectos para grandes compañías nacionales e internacionales.
30
JUL-AGO 2005
Se buscó el apoyo del Gobierno Federal
mediante el programa ProSoft y se recibieron
ayudas económicas para formación de personal.
sis fue vendida, ocasionando un movimiento
importante de profesionales buscando nuevas opciones laborales, en ese momento de
cambios Active Intelligence surgió como una
opción interesante para ellos.
Active Intelligence tuvo la visión de buscar colaboradores con experiencia en la implementación de procesos, Six Sigma y SW-CMM®,
además de las habilidades de tecnología que
el mercado requería, como .NET, que es la
principal herramienta tecnológica utilizada.
Adicionalmente pudo conformar un equipo
con mucha energía a través de una vinculación importante y selectiva con las Universidades de Aguascalientes; de este modo se
formó el equipo de trabajo que actualmente
figura entre las filas de la compañía.
La visión
Los beneficios en prestigio y participación de
mercado, que traería la adopción del modelo
siempre fueron un motivador importante de
la compañía, sin embargo, existe también en
la operación y gerencia, un compromiso pleno
con la calidad y la capacidad de entregar productos que satisfagan las necesidades de los
clientes, motivándolos a seguir invirtiendo en
tecnologías de información. Esta visión de las
direcciones general y de operaciones, ha sido
clave en el logro de las metas trazadas, pues el
compromiso no es solamente de un equipo, si
no de la organización completa.
El desarrollo del
programa de mejora
Basados en esta visión, se inició el programa de mejora como un proyecto cuyo objetivo era definir e implantar procesos basados
en el modelo SW-CMM® hasta el nivel 3; sin
embargo, no se contaba con recursos específicos para conseguirlo y mucho menos se
pensaba en considerar consultoría externa
para apoyar la definición e implantación
de procesos. El equipo original asignado
fue formado por dos personas, el primero
con experiencia en este tipo de procesos y
convencido de los beneficios que se obtendrían no sólo a nivel de cada proyecto sino
a nivel organizacional, mientras el segundo,
era una persona sin experiencia, ni entrenamiento en el modelo, mucho menos en procesos y estándares mundiales, pero eso sí
con muchas ganas de aprender y a mejorar
el trabajo de la empresa. Así, con muchas
desventajas, vio la luz el programa de mejora en Active Intelligence y se bautizó como
AMM (Active Maturity Model). El camino se
veía complicado.
Después del entrenamiento interno inicial,
se planeó la forma en que la meta se cubriría. Se iniciaron las actividades de definición
y se preparó el entrenamiento para los colaboradores. Este primer paso fue difícil, pues
los procesos no fueron muy bien recibidos
desde el inicio, había muchas dudas, los
proyectos que lo implantarían ya tenían otra
forma de trabajo, la implantación implicaba
tareas extras en los planes de proyecto ya
comprometidos, por lo que solo se veían dificultades en la implantación, sin mucho que
obtener a cambio. Estábamos atorados.
formar parte del proyecto, con ellos se hicieron revisiones documentales a los procesos,
verificación de la implantación en los proyectos, evaluaciones informales (simulando
actividades de la evaluación formal) y formación práctica del grupo de SQA para ejecutar
sus actividades (pieza clave para apoyar la
implantación de las prácticas), todo esto
ayudó a acelerar la adopción completa de la
iniciativa, además que el grado de confianza
en los procesos ya implantados se mejoró
considerablemente. Ya estábamos listos.
La tormenta pasó, sin lugar a dudas el apoyo de la dirección fue pieza clave en la resolución de estos problemas, además del
compromiso del equipo de implantación.
Para incrementar la motivación y remarcar
la importancia en el uso de los procesos, un
requerimiento clave llegó, el requerimiento
solicitaba el uso y conocimiento del modelo
SW-CMM® y finalmente, el trabajo que ya se
había hecho en este sentido, fue un factor
decisivo para ganarlo. Los procesos son un
valor agregado importante.
Mariana Pérez-Vargas, Directora General de
Avantare, fue el Lead Assessor de la evaluación, se trabajó con ella, un consultor más de
apoyo de Avantare y los miembros de Active
Intelligence elegidos para formar parte del
equipo de evaluación. El ambiente, aunque
agradable, era de nerviosismo pues finalmente había muchas cosas que dependían de un
resultado positivo en la evaluación CBA-IPI®,
(CMM Based Appraisal for Internal Process Improvement) a pesar de esto, el equipo formado
en su mayoría por gente muy joven, respondió
como se esperaba a las exigencias del método
de evaluación. Se aplicaron cuestionarios, se
hicieron las entrevistas y las consolidaciones
necesarias, hasta que llegó el momento de
la puntuación final, una a una las fortalezas y
oportunidades de mejora detectadas durante
cada una de las revisiones y/o entrevistas, se
fueron revisando y discutiendo entre todo el
equipo, ya que las decisiones debían tomarse
por consenso. Debíamos analizar si las oportunidades de mejora podían afectar de manera
La necesidad de robustecer los procesos
con la ayuda de algún externo se hizo más
palpable y entonces se buscó apoyo del
Gobierno Federal mediante el programa ProSoft y se recibieron ayudas económicas para
formación de personal por el Gobierno del
Estado de Aguascalientes; se trabajó duro
para conseguir una oportunidad real y por
supuesto, los recursos requeridos. Al ser
otorgados los recursos, la visión se amplió
acorde a la nueva
situación y el programa de calidad
tenía nuevas y más
retadoras
metas.
Los recursos permitieron tener acceso
a la consultoría externa, y además la
implantación no se
quedaría solo en
eso, pues se buscaría el reconocimiento formal del nivel 3.
La compañía estaba
entusiasmada.
La evaluación
Dada la buena experiencia en Ddemesis
y su reconocida capacidad, Avantare
fue elegida para
JUL-AGO 2005
31
CASO DE ESTUDIO
significativa a las metas relacionadas ... y así
una a una, cada meta se alcanzó, dando como
resultado alcanzar el nivel de madurez 3 de SW
CMM®.Todo el esfuerzo invertido, se redujo a
una alegría y satisfacción que difícilmente se
pueden describir.
Hoy día la evaluación quedó atrás, y lo mas
importante es que hay un cambio en la cultura organizacional. El entusiasmo en las revisiones es igual al que se notaba antes de
la evaluación, el interés de los colaboradores
en los procesos y en la mejora continua de las
herramientas que se han definido sigue ahí y
va en aumento. Después del resultado, más
personas están interesadas en formar parte
del equipo de calidad y más gente aprecia el
trabajo que esta área realiza. Se confirma una
frase que por méritos propios se ha convertido
en el lema del programa de mejora: “AMM es
el ADN de nuestra compañía”.
Las metas de este año tienen que ver con el
cambio de modelo (CMMi®) y el crecimiento de
nivel, el equipo está nuevamente organizado y
trabajando como el año anterior con una nueva
meta en la mente, buscando nuevas formas de
mejorar y aprovechar la experiencia ganada con
el primer paso. El compromiso de la organización está no solo con sus clientes, si no también
con todos aquellos que de alguna forma colaboraron al logro de la meta que empezó como un
sueño y que ahora puede servir como muestra
de que cuando se reúne al equipo adecuado, un
asesor experimentado, una idea clara llevada a
un proyecto viable, y un programa inteligente
de apoyo a la industria, los resultados pueden
ser “de clase mundial”. Active Intelligence ya
exporta el 68% de sus Servicios.
Algunas reflexiones que vale la
pena compartir
Sin lugar a dudas el caso de Active Intelligence es un ejemplo a seguir por muchas
otras empresas que están poniendo la mira
en el establecimiento de un programa de
mejora, sea cual sea, el modelo de referencia a seguir. Sin embargo, ahora que Rafael
les ha contado la historia y evolución de la
implantación de SW CMM en Active Intelligence, a mi me gustaría compartirles algunos factores, desde el punto de vista de
Avantare y como consultor en programas de
mejora, que me parece importante enfatizar ya que marcaron la diferencia entre un
“buen deseo” y “un realidad que da frutos
y beneficios” y que pueden ayudar a otras
Organizaciones en el establecimiento de su
programa de mejora.
Así pues los factores críticos de éxito, en
el caso de Active Intelligence, que quisiera
compartirles fueron:
1. El compromiso directivo. Sin este compromiso
y el convencimiento tanto del Ing. Humberto Sánchez como del Ing. Abraham Ramírez (el director
de operaciones), de que los procesos rendirían
frutos, cualquier esfuerzo por establecer mejores
formas de trabajo se quedan en el tintero.
2. Procesos adecuados a la empresa y la
forma de trabajo. Es fundamental establecer
procesos “a la medida” de las organizaciones, sobre todo cuando se trata de organizaciones pequeñas, donde si bien es vital
el establecimiento de procesos, también es
vital que éstos sean ágiles para soportar el
desempeño y operación que una PyME necesita. En Active Intelligence, el grupo de mejora buscó ante todo, que los procesos fueran
funcionales para el trabajo diario de los proyectos. Esto representó no sólo un reto para
el grupo de implantación, sino también para
Avantare como consultor, pues hubo que
buscar soluciones innovadoras que permitieran cumplir con las exigencias del modelo, sin sobrecargar a la operación.
3. Una cultura Organizacional de procesos.
La primera vez que como Avantare realizamos
revisiones presenciales en Active Intelligence,
se notaba que la gente había visto buenos
resultados al aplicar los procesos, lo cual hacía que fueran muy abiertos para realizar las
acciones de mejora solicitadas, e incluso en
proponer ellos mismos mejoras. Cuando la
gente está convencida de los beneficios que
los procesos le traen en su trabajo diario,
aporta para que estos procesos se mejoren logrando una sinergia real entre los procesos, la
gente y la productividad. Es entonces cuando
vemos que la mejora continua “se vive” y no
sólo “está escrita”. No hay cosa mas linda que
una mejora continua viva. Cuando esto se ha
logrado, el consultor está mas seguro de que
sus recomendaciones caerán en tierra fértil y
el progreso se notará a pasos agigantados.
4. La visión a largo plazo. Es de vital importancia lograr el compromiso a largo plazo, no
buscar sólo la obtención de un cierto nivel de
madurez, el reconocimiento público, o bien
los ahorros inmediatos, sino estar comprometidos con la calidad de los servicios y los
productos que se ofrecen. Sin duda Active
Intelligence, estuvo muy consciente de que
al establecer un programa de mejora, estaba
invirtiendo no para las recompensas inmediatas, sino para aquéllas que vendrían después,
mas allá de la evaluación, manteniéndose inmersos en un proceso de mejora que les exigiría cada vez más de ellos mismos.
5. El trabajo en equipo. Este fue sin duda un
factor clave para el éxito del programa de mejora de Active Intelligence, donde todo el personal, de alguna u otra manera participó en la
definición, revisión, asesoría y evaluación de
los procesos del programa de mejora. Cada uno
sabe que su participación es importante, y que
es un proyecto importante que los involucra a
todos y cada uno de ellos. Realmente hubo un
equipo entre Avantare y Active Intelligence.
Siempre hay nuevos retos que cumplir, siempre hay niveles, marcas y
records que lograr. Cuando se conjunta el liderazgo, el equipo, la motivación y los fondos adecuados, los
resultados suelen ser increíbles.
Elizabeth Almeraz es pionera en México en la realización de actividades de Aseguramiento de Calidad del Software (SQA), participando en el primer grupo de SQA que ayudó
a lograr una evaluación CMM en México. Actualmente es consultor de Avantare y especialista en las áreas de técnicas de verificación de productos de software y mejora de
procesos para la industria de TI.
32
JUL-AGO 2005
PUBLICIDAD
PRÁCTICAS
MÉTRICAS
DE TAMAÑO DE SW BASADAS EN FUNCIONALIDAD
Parte 2: Análisis de Puntos Función
E
n el número anterior hablamos sobre la importancia de contar
con una métrica funcional estándar para determinar el tamaño de un sistema de software. Los Puntos Función o Function
Points (FPs) son una excelente herramienta para este propósito.
La Métrica de Puntos Función
Esta métrica se define como una métrica funcional, dado que se enfoca a la funcionalidad que un producto de software proporciona a
sus usuarios.
“Es una métrica para establecer el tamaño y complejidad de los sistemas informáticos basada en la cantidad de funcionalidad requerida y entregada a los usuarios”.
Partamos de esta definición para entender las características de
la métrica:
Tamaño.– Es una métrica de tamaño, no de la calidad con la que se
hizo ese SW, o del valor de ese producto, o del esfuerzo requerido
para desarrollarlo, etc.
Aplicaciones.– Mide las aplicaciones de SW, no considera el HW que
utilizará, ni la administración del proyecto, ni la documentación, etc.
Funcionalidad.– Se refiere a la capacidad del SW para que un usuario pueda realizar transacciones (lectura, escritura, etc.) y guardar
datos. Si analizamos a detalle, con estos elementos podemos describir cualquier sistema.
Usuario.– Quien lo va a usar y no quien lo desarrolló o quien lo diseñó.
Así como existe el metro lineal para medir longitudes, Puntos Función
es “el metro” para medir tamaño de una aplicación de software.
Estándar Internacional ISO
La medición de la funcionalidad con la que cuenta un sistema informático ha sido desde hace años una preocupación de la industria. No es
suficiente contar con una métrica, sino que sea estándar, para así poderla usar a nivel industria. Poder comparar la productividad (Puntos
Función por Persona Mes) de una empresa con los datos de la indus-
Por Sergio Durán
tria, es fundamental en los planes de mejora.
Es por eso que a través de la International
Organization for Standardization (ISO) se ha
desarrollado un estándar internacional:
ISO/IEC 14143 – Information Technology
– Software Measurement – Functional Size
Measurement. Este estándar define los conceptos de una métrica de tamaño basada
en la funcionalidad y las características que
debe cumplir un método para estar homologado al estándar y ser considerado una medida del tamaño de la funcionalidad.
Existen varios métodos de conteo para establecer la cantidad de Puntos Función que
tiene una aplicación. En general, todos establecen un conteo basado en la identificación
del tipo de funciones que tiene la aplicación,
y a cada una le asocia un número de puntos
tomando en cuenta su complejidad. Las variantes surgen al buscar conteos más precisos en Puntos Función conforme al tipo de
aplicación. Por ejemplo, un sistema en tiempo real tiene una complejidad muy distinta a
un sistema tradicional de negocio o a un sistema operativo o a una aplicación científica
que realiza muchos cálculos pero el resultado
puede ser un solo dato. Estos son algunos de
los métodos homologados con el ISO 14143:
ISO/IEC 20926:2003 - Software engineering - IFPUG 4.1 Unadjusted functional size
measurement method. Este método ha sido
definido por el International Function Point
Users Group (IFPUG) y evolucionado a partir
de la propuesta original de Allan Albrecht en
IBM, por lo que es el más conocido y más
Sergio Eduardo Durán Rubio se desempeña como Director de Proyectos en certum. En 1996 se convirtió en el primer especialista de América Latina certificado por el International Function Point Users Group en Conteo de Puntos Función, y en miembro representante de México ante la ISO/IEC JTC1/SC7. Sergio es
Ingeniero en Sistemas Computacionales de la UDLA-P, Maestro en Tecnologías de Información y Administración del ITAM y Mastère Spécialisé en Réseaux Et
Systèmes D ‘information pour Les Entreprises de la ENST de Bretagne France.
34
JUL-AGO 2005
Puntos función está orientado a medir sistemas
de información completos.
utilizado. Esto es muy importante porque se
está convirtiendo en el estándar de facto en
la industria.
ISO/IEC 20968:2002 - Software engineering
- Mk II Function Point Analysis. Este método
ha sido desarrollado por la United Kingdom
Software Metrics Association, simplificando el método y haciéndolo compatible con
ideas de análisis y diseño estructurado.
ISO/IEC 19761:2003 - Software engineering
- COSMIC-FFP - A functional size measurement method. Este método ha sido definido
por el Common Software Measurement International Consortium, integrado por expertos
de Australia, Canadá, Finlandia, Alemania,
Irlanda, Italia, Japón, Holanda y el Reino Unido. La idea principal es adecuarse mejor a la
medición de sistemas en tiempo real.
Paso 1. Determinar el tipo de conteo. Este
paso consiste en definir el tipo de conteo
entre desarrollo, mantenimiento o de una
aplicación ya instalada. Esta es una forma
de determinar el objetivo del conteo.
Paso 2. Identificar los alcances de la medición
y los límites de la aplicación. El propósito de
una medición consiste en dar una respuesta a un problema de negocio. El alcance de
la medición define la funcionalidad que va
a ser incluida en una medición específica y
puede abarcar más de una aplicación.
El Método de Análisis de
Puntos Función
La versión actual de éste metodo es la 4.1.1,
cuyo manual de prácticas de conteo se puede
encontrar tanto en inglés como en español. El
método de conteo se basa principalmente en la
identificación de los componentes del sistema
informático en términos de transacciones y grupos de datos lógicos que son relevantes para
el usuario en su negocio. A cada uno de estos
componentes les asigna un número de puntos
por función basándose en el tipo de componente y su complejidad; y la sumatoria de esto nos
da los puntos de función sin ajustar. El ajuste es
un paso final basándose en las características
generales de todo el sistema informático que se
está contando. Veamos un poco más a detalle
el procedimiento, para entender mejor los conceptos mencionados y conocer su simplicidad.
Procedimiento
Paso 3. Contar las funciones de datos. Este
paso consiste en identificar y contar la capacidad de almacenamiento de los datos. Se
distinguen dos tipos de funciones de datos:
Archivo Lógico Interno.- Es un grupo de datos relacionados que el usuario identifica,
cuyo propósito principal es almacenar datos
mantenidos a través de alguna transacción
que se está considerando en el conteo.
Archivo de Interfaz Externo.- Es un grupo de datos relacionados y referenciados pero no mantenido por alguna transacción dentro del conteo.
A cada componente identificado se le asigna
una complejidad (baja, media o alta) considerando principalmente el número de datos.
Paso 4. Contar las funciones transaccionales.
Este paso consiste en identificar y contar la
capacidad de realizar operaciones. Se distinguen tres tipos de funciones transaccionales:
PRÁCTICAS
Entrada Externa.– Es un proceso cuyo propósito principal es mantener uno o más archivos lógicos internos.
Salida Externa.– Es un proceso cuyo propósito principal es presentar información al
usuario mediante un proceso lógico diferente al de sólo recuperar los datos.
Consulta Externa.– Es un proceso cuyo propósito principal es presentar información al
usuario leída de uno o más grupos de datos.
En nuestro caso, Puntos Función está enfocado a medir sistemas informáticos completos,
no programas. En este sentido no tiene un
nivel de precisión suficiente para medir el tamaño de programas individuales. El nivel de
granularidad que puede medir la métrica no
es muy pequeño. Adicionalmente el término
programa depende de la tecnología, y eso va
en contra del criterio de que esta métrica es
independiente de la tecnología que se use.
A cada componente identificado se le asigna
una complejidad (baja, media o alta) considerando el número de datos utilizado en el
proceso y los archivos referenciados.
Otro punto que se le ha criticado a las métricas funcionales es que requieren que alguien
“identifique” la funcionalidad y “evalúe” la
complejidad basándose en los criterios y
reglas establecidas; no puedo hacer un programa que cuente automáticamente. Debido
a esto, distintas personas podrían llegar a un
conteo diferente. Para resolver esto, se han
venido depurando las reglas de conteo para
eliminar posibles ambigüedades y cada vez
hay más material de apoyo con ejemplos.
Aunado a lo anterior, hay esquemas de certificación como el del IFPUG, donde hay una
evaluación formal de la teoría y casos prácticos. Estos elementos buscan reducir las
posibles variaciones en un conteo hecho por
diferentes personas. Si tomamos en cuenta
que la métrica está pensada para contar proyectos o aplicaciones completas, entonces
las pequeñas variaciones en un conteo, no
van a ser significativas para los indicadores
o datos relacionados que obtengamos.
Paso 5. Determinar los puntos de función no
ajustados. Este paso consiste en sumar el
número de componentes de cada tipo conforme a la complejidad asignada, y multiplicarlo por el factor indicado en la siguiente
tabla para obtener el total.
EI
EO
EQ
ILF
EIF
Bajo
Medio
Alto
3
4
3
7
5
4
5
4
10
7
6
7
6
15
10
Paso 6. Determinar el valor del factor de
ajuste. El factor de ajuste se obtiene sumando 0.65 a la sumatoria de los grados
de influencia de las 14 características
generales del sistema, multiplicado por
0.01. Dentro de las características hay
criterios como: complejidad del proceso,
facilidad de instalación, entrada de datos
en línea, etc.
Paso 7. Determinar los puntos función ajustados. Para determinar los puntos función
ajustados se consideran los puntos función
no ajustados por el factor de ajuste.
Cualquier Métrica tiene un
Alcance Definido
Cualquier métrica tiene un ámbito de acción
y alcance definido que hay que entender
para usarla correctamente. Así, por ejemplo, el metro lineal no es lo mejor para medir
grandes distancias en el mar.
36
JUL-AGO 2005
Comprar SW por Puntos Función
Las compras de SW son en muchos casos
desarrollos a la medida. Pero ¿cómo comprar si todavía no se tiene el diseño? Una
opción que habilita una métrica como Puntos Función es comprar por “metro” de SW
a una empresa que tenga una productividad
mínima establecida, conforme al tamaño de
las aplicaciones que requiero. Ya durante el
proyecto puedo ir solicitando esos Puntos
Función que compré, en las aplicaciones que
requiero. Por ejemplo, en el caso de Gobierno, la ley de adquisiciones permite hacer
compras basadas en estándares internacionales, que como vimos, ya existen en este terreno. Adicionalmente, en el Programa para
el Desarrollo de la Industria del Software de
la Secretaría de Economía (ProSoft), hay un
punto específico que ayudará en este tema:
“Promover que se elaboren las normas necesarias para que se cumpla el Reglamento
de la Ley de Adquisiciones, Arrendamientos
y Servicios del Sector Público en lo que se
refiere a la existencia de normas nacionales
o internacionales en las adquisiciones de
software”.
En mi opinión, el uso de métricas en los proyectos de SW va a empezar a cambiar en la
medida que los compradores lo exijan. Es
por eso muy importante que los compradores analicen que sólo comprar por precio
sin distinguir tamaño de las aplicaciones
para escoger a un proveedor que tenga experiencia con esa complejidad o indicadores como productividad o calidad, nos va a
seguir llevando a las historias que hemos
oído de grandes proyectos que no terminan
a tiempo o que exceden por mucho el presupuesto o, en el peor de los casos, nunca
llegan a operación.
Se requiere un modelo que permita identificar capacidades de los proveedores,
para entonces poder comparar propuestas
de proveedores de capacidad similar. “Los
proyectos nacionales en informática requieren de empresas con capacidades reales y funcionarios/ejecutivos competentes
y exigentes”.
Ya empieza a haber proyectos que, como
parte de sus bases para invitar a proveedores, solicitan contar con métricas y con
registros históricos que fundamenten los
estimados en esfuerzo y tiempo, para tener
mejor certeza en que el proyecto que están comprando va a llegar a buen término,
a tiempo y en presupuesto. Próximamente
empezaremos a ver los primeros resultados
y alguno de estos casos de éxito será motivo
de un siguiente artículo.
Referencias
• IFPUG. “Manual para la Medición de Puntos
Función”. Versión 4.1.1. 1999
• Alberto Balderas, Arnoldo Díaz. “Fábrica de
software. Un modelo de negocio certificable
basado en Estructura y Capacidades”.
Soluciones Avanzadas. No. 59
PRÁCTICAS
PROCESOS
BPM
APLICADO AL DESARROLLO DE SOFTWARE
Por Axel Nissim
U
no de los errores más comunes dentro
del entendimiento de BPM por parte
de los desarrolladores de SW, es la
creencia de que BPM se limita a una estrategia tecnológica. Es cierto que plataformas
como J2EE nos proporcionan herramientas
para implementar estrategias BPM, y también
es cierto que existen varios BPMS “Out of the
Box” que nos permiten modelar procesos de
negocios, y llevar su seguimiento. Sin embargo, lo que es esencial entender es que BPM es
una estrategia de negocios, no tecnológica, y
que se sirve de la tecnología para alcanzar sus
metas. BPM es el resultado de una tendencia
mundial hacia la claridad y transparencia dentro de los procesos, aportando flexibilidad al
mismo tiempo y acabando con los órdenes
monolíticos dentro de los flujos de trabajo,
que hacen imposible a la empresa adaptarse
rápidamente a las condiciones eternamente
cambiantes del mercado. En una empresa
que gira en torno a la tecnología y al desarrollo de software, también existen procesos de
negocio, flujos de trabajo que deberían estar
definidos; materia difusa e intangible para la
mayoría, y que sólo vive en la cabeza del arquitecto o del líder de proyecto.
La mayoría de las personas que representan los
roles en el desarrollo de SW, a pesar de su alta
necesidad de conectividad, interacción y retroalimentación, hacen esfuerzos heroicos para adivinar exactamente cuál es el tipo de información
que se requerirá para los siguientes pasos del
flujo de desarrollo, y a la vez, ruegan todos los
días para que los artefactos que lleguen a sus
manos, provenientes de fases anteriores, contengan toda la información necesaria.
Claro, existen metodologías estructuradas,
como RUP, que nos dicen lo que entra y lo que
sale de cada una de las etapas de nuestro
proyecto, pero de ninguna manera estas son
soluciones definitivas a los problemas de flujo de trabajo, puesto que al final el proyecto
mismo es quien decide la estrategia que se
ha de tomar. A veces los artefactos escogidos
no son los adecuados, los requerimientos no
se estabilizan, o la gente se da cuenta de que
“el sistema” no es la piedra angular, y que deberá adaptarse al negocio, sin importar si la
metodología dice tal o cual cosa.
También en el desarrollo de sistemas, los
procesos de negocio deben de ser medibles,
colaborativos, finitos (de manera indispensable), y eficientes. La implementación de CMM
tiene como resultado la eficientización de los
procesos, identificando las áreas clave, cuellos de botella, y a la vez atajando uno a uno
los riesgos y minimizándolos. ¿Es esto una
solución total? Si esto fuera cierto, pudiéramos pensar que los proyectos de TI fracasados son una historia de terror del pasado.
Sin embargo, la triste y a la vez prometedora
realidad, es que aún tenemos mucho trabajo
que hacer, y precisamente parte de este trabajo es el empleo de metodologías BPM dentro del desarrollo de software, y a la vez, el
desarrollo de herramientas que nos permitan
mapear, seguir de cerca y medir los procesos
de desarrollo, así como comunicar y reutilizar
el conocimiento generado dentro de éstos.
Las metodologías actuales de flujo de trabajo para el desarrollo de software se centran
en la documentación extensa y el modelado,
siendo éste una extensión misma de la documentación. El modelo es el sistema, la documentación es el sistema y, por supuesto, el
código es el sistema, en una representación
que varía en su grado de granularidad de
acuerdo a la fase en que nos encontremos.
¿En qué consiste una solución de BPM? La
tecnología detrás de los sistemas BPM es el
software que automatiza y hace más directos
y eficientes los procesos. Típicamente, la solución incluye una herramienta gráfica de diseño y
navegación de procesos, capacidades de simulación, software de integración y middleware,
así como capacidades de monitoreo y reporteo
de cada uno de los procesos.
Los procesos del desarrollo de software comúnmente se definen a partir de los diferentes milestones o hitos a los que va llegando
el proyecto, los cuales a su vez se definen a
partir de los artefactos programados para
Axel Nissim es Director de entrempresarios.com, un portal y startup de Internet con la meta de desarrollar herramientas colaborativas basadas en el Social Networking. Axel es
Licenciado en Sistemas Computacionales Administrativos por la Universidad de las Américas, y ha laborado como consultor en algoritmos para seguridad e inteligencia artificial.
Actualmente trabaja de manera estratégica en la definición de metodologías y herramientas de workflow en megaproyectos basadas en redes sociales, planeando sacar al
mercado el producto resultante.
38
JUL-AGO 2005
El modelo es el sistema, la documentación es el
sistema y, por supuesto, el código es el sistema.
cada fase. La realidad es que en el desarrollo de software los procesos se entrelazan de
maneras inesperadas, y muy al pesar de los
metodólogos, aún dependen del heroísmo
personal de los participantes del proyecto.
proyectos se basan en un enfoque jerarquizado que les permite mantener cierto control
de la información, basado en la restricción
de los roles y artefactos, sin tomar en cuenta
las oportunidades y la eficiencia.
La visión centrada en artefactos y asociada
a roles del RUP, es muy útil en el sentido de
la estandarización de procesos, y como un
checklist en base a los entregables que se
deben de conseguir. Lo que el RUP no toma
en cuenta es la interacción humana y el alto
grado de entropía en los proyectos, donde
los artefactos se transforman, cambian hasta sus raíces y finalmente son usados para
propósitos diferentes a los de su concepción.
Los encargados de la administración de los
La eficiencia de los procesos en el desarrollo
de software queda incompleta aún implementándola dentro del marco de las mejores
prácticas de desarrollo y hasta de procesos de
negocio. Lo que se necesita es una solución
más completa, y que sea capaz de armonizar
los conceptos de BPM con las metodologías
formales de desarrollo como XP o RUP, todo
esto dentro de un marco de colaboración en
capas, indistinto de organigramas y que permita aislar y atacar las oportunidades y siner-
gias no sólo en cuanto a los roles dentro de
los procesos, sino en cuanto a las competencias de cada individuo, sus habilidades, intereses y hasta sus metas particulares.
BPM es un esfuerzo encaminado a la flexibilidad y el tiempo de respuesta ante condiciones cambiantes. Las condiciones cambiantes
en un megaproyecto de desarrollo son una
realidad que va más allá del simple cambio de
requerimientos, y que tienen que ver más con
la falta de unificación de criterios de negocio
que nos permiten conocer las necesidades
reales de los clientes externos (los compradores del sistema) y nuestros clientes internos
(las personas trabajando en otros módulos o
fases del desarrollo del sistema).
PRÁCTICAS
PROCESOS
La comunicación es, por mucho, el activo más
valioso dentro del desarrollo de software
¿Qué pasa si a la mitad del análisis nos damos cuenta que uno de los artefactos simplemente no tiene relevancia de acuerdo al
problema atacado? ¿Quién se da cuenta de
esto? Obviamente no es el arquitecto, ni el
líder de proyecto, ambos encerrados en sus
actividades de control. ¿Qué uso se le da a
la información que no generó utilidad inmediata o esperada? Los verdaderos poseedores de la información y los que perciben
de manera instantánea sus incongruencias
son los que trabajan directamente con ella:
analistas, programadores, testers y demás,
por tanto en ellos debe de recaer —de manera colectiva— el mantenimiento de una
base de conocimientos común que permita
el intercambio sin fronteras de la información hacia adentro. El mantenimiento de los
vínculos para la fluidez de esta información,
es responsabilidad de los arquitectos, administradores de la configuración, y en última
instancia del líder de proyecto, que además
debe facilitar estos mismos vínculos a los
“stakeholders”, usuarios y consultores de
negocio de los proyectos, para cerrar el ciclo
de comunicación.
La comunicación es, por mucho, el activo
más valioso dentro del desarrollo de software, sólo comparable en importancia con
nuestros recursos humanos calificados. Es
por esto que toda implementación que planee hacer uso de las herramientas de BPM
en el ámbito del desarrollo de sistemas,
dependerá primordialmente del nivel de soporte a las comunicaciones inteligentes y la
transferencia del conocimiento entre diversos “keyplayers” en diferentes áreas.
Lo ideal, en el sentido de la comunicación,
serían herramientas que fueran independientes del organigrama en el sentido del
intercambio positivo de la información no
clasificada, y que además fuese sensible a
estas mismas estructuras organizacionales
para poder intercambiar de manera segura la
información confidencial que no es de interés
para todos los miembros del equipo. La herramienta deberá ser sensible socialmente a las
relaciones mantenidas por parte de los dife-
40
JUL-AGO 2005
rentes miembros de los equipos, para poder
aprovechar los canales de comunicación mas
eficientes, y que no deben de fallar a causa
de las altas tasas de rotación de personal,
ni a las condiciones cambiantes de movilidad organizacional. Nuestras herramientas
y conocimiento deben de estar a la mano de
quien lo necesita, independientemente de si
el dueño de la información dejó de trabajar
en la empresa, recibió un ascenso, cambió
su rol o cambió de proyecto. El manejo del
conocimiento debe ser contextual e hipervinculado, así como modificable por cada uno
de los miembros que posea la información
necesaria para hacer aportaciones positivas,
aún y cuando aparentemente su área de responsabilidad no sea congruente. Siempre
habrá posibilidad de que el administrador de
la configuración reciba un reporte de incongruencias en la edición de un documento, y
simplemente aplique un Rollback a la última
versión estable de la documentación.
La organización en células de trabajo cohesivas internamente y modulares hacia el
exterior, nos permitirá hacer un intercambio
dinámico de recursos, independientemente
de si el proceso actual o requerimiento dicta
que primero llevemos a cabo el análisis y luego simulaciones, o viceversa. Nuestras herramientas flexibles de BPM deberán permitir el
acoplamiento de nuestros flujos de trabajo a
situaciones variadas en las que los procesos
puedan tomar formas iterativas, en cascada,
aleatorias y hasta caóticas, pero siempre sin
perder de vista el alto grado de comunicación
necesaria y el mantenimiento de los estándares documentales que nos permitirán obtener retornos sobre cada una de las fases de
nuestros proyectos. La comunicación deberá
de ser sensible a las personas y sus maneras
naturales de agruparse en cuanto a intereses,
habilidades, conocimientos y hasta amistades,
y no solamente en cuanto a células de trabajo
bien estructuradas, dado que sabemos que el
trabajo en desarrollo de sistemas no permite
que estas células sean persistentes en el tiempo, en cambio el conocimiento permanece ahí,
en esa área gris representada por los vínculos
sociales entre las personas. Nuestros recursos
humanos podrán aprovechar conocimientos
generados en diferentes células y hacerlo con
el menor costo posible en términos de comunicación organizacional, y sin tener que pasar
por muchos eslabones redundantes que únicamente fiscalizan el proceso sin aportar nuevos
conocimientos o valor.
Los elementos necesarios mínimos que debe
de incluir una solución BPM para el desarrollo de software son los siguientes, sin un orden particular de importancia:
• Definición y administración dinámica de
procesos, independiente de metodologías
formales (se deberá poder implementar
cualquier metodología, según se considere
conveniente).
• Enfoque de producción basado en documentación estandarizada.
• Formación de equipos de trabajo cohesivos internamente y modulares hacia fuera,
con un enfoque particular en sus procesos
propios, pero permitiendo la participación
en los procesos ajenos.
• Herramientas de modelado visual y definición de procesos.
• Herramientas de reporteo y seguimiento
de los procesos en tiempo real.
• Middleware que permita conectar las diferentes partes, sistemas, y equipos de trabajo, con un enfoque orientado a procesos
dinámicos.
• Herramientas de comunicación colaborativa sensibles a la competencia, habilidades y
relaciones sociales de los recursos humanos
del proyecto.
• Herramientas colaborativas inteligentes de
administración del conocimiento, que permitan
el flujo de información seguro y a la vez transparente, independiente de organigramas, y que
busquen la participación indistinta de las personas que poseen el conocimiento.
INNOVACIONES EN SOFTWARE
COLUMNA
La “Revolución” del BPM
Pasado, Presente y Futuro
L
a forma de hacer negocios
cambia constantemente. Los
Procesos que soportan la organización son altamente dinámicos.
Gartner piensa que el futuro de la construcción de software será, en parte, la
composición de piezas en modeladores
visuales, alterando instantáneamente
el comportamiento de la organización
—una labor realizada por los mismos
dueños de los negocios.
Pasado
En un principio se pensó que los procesos de negocio podrían ser soportados
por Flujos de Trabajo, ya que era posible
enviar documentos, formas en rutas
establecidas de manera automática
usando reglas del negocio. Aunque muchos Workflow Management Systems
(WFMS) lograron rebasar la vista centrada en documentos, el problema principal fue que codifican un metamodelo
de procesos que limita la capacidad de
resolver los problemas del mundo real.
Hoy las aplicaciones de negocio como
SAP R/3 incluyen componentes WFMS
convirtiendo a los ERPS en plataformas
de construcción de software. Pero aunque estas tecnologías existen, no se han
utilizado ampliamente. Si todo se puede
desarrollar de esta forma, ¿por qué no
dejar de usar .NET y Java?
humano es sólo una forma de pensar
en procesos. En la vida real los sistemas de flujo de trabajo limitan fuertemente los procesos de negocio que
se desean modelar. Aquellos que han
implantado estos sistemas conocen
bien estas limitaciones.
Presente
Recientemente ha aparecido una
nueva categoría de software, los Business Process Management Systems
(BPMS), como el WFMS o Relational Database Management Systems
(RDBMS).
Los BPMS son la búsqueda de una
maquinaria universal de procesos.
Hoy por ejemplo, los WFMS no pueden sustituir el correo electrónico. Extraño porque el correo electrónico se
puede considerar un proceso muy común hoy en día: es un proceso simple
de recibir y enviar con el que adquirimos la capacidad de comunicarnos
con otros mediante una dirección
electrónica. Es irónico que los WFMS
no puedan modelar este escenario
tan simple.
Claramente los distintos WFMS trabajan en formas diferentes, aun cuando
la Workflow Management Coallition
(WfMC.org) ha tratado de unificar las
normas. Este hecho ha limitado fuertemente la penetración al mercado
de tecnologías de automatización de
procesos, porque los directores de
sistemas se tienen que comprometer
con un proveedor.
Otro factor no considerado en los
WFMS es la movilidad, como lo demostró el ganador del premio ACM
Turing, Robin Milner, quién desarrolló
una teoría formal de procesos móviles llamada Cálculo Pi. El término
movilidad se refiere a la forma en que
los procesos transcurren mientras se
ejecutan, mediante el intercambio de
información entre participantes cuyas relaciones y vínculos evolucionan
como resultado, determinando qué
se conoce, quiénes se conocen y qué
se ha encontrado.
Pero hay razones adicionales de
porqué los WFMS no pueden ser un
modelo para ejecutar todos los procesos de software. El flujo de trabajo
Una explicación detallada de estos
conceptos está fuera del alcance de
esta columna, pero se puede resumir
como un proceso para crear procesos
de cualquier tipo y que no se basa en
comunicaciones sino en transformaciones a sí mismo.
El BPMS se compone de herramientas de modelado, maquinaria de ejecución, herramientas de agilidad para
alterar procesos, herramientas para
monitorear y administrar los procesos, y herramientas de análisis que
permitan medir la eficiencia de los
procesos (ahí la relación con Six Sigma y procesos de mejora continua).
Intalio fue el primer proveedor en implementar este modelo.
Futuro
Es claro que, dada la capacidad de comunicación que Internet ofrece, hoy
es posible implementar procesos que
salgan de la organización uniendo a
proveedores, empresas pequeñas y
usuarios finales.
El Business Process Outsourcing
(BPO) consiste en delegar la propiedad, administración y operación de
un proceso a un tercero: Quien monta una nueva empresa puede preferir
enviar al exterior un proceso de recursos humanos en lugar de hacerlo
ellos mismos. Ese proceso debe ser
de excelencia pero no se desea realizar el esfuerzo en lograrlo. En el futuro
las “experiencias” permitirán integrar
procesos entre industrias distintas.
Por ejemplo, la contratación de un
empleado en una organización puede
provocar que al concretar la operación en el sistema de administración
de recursos humanos se disparen
procesos como compra del automóvil, apertura de cuenta, contratación
del seguro, registros en el gobierno y
otros procesos que hoy se realizan en
forma manual, sean verdaderamente
automatizados.
Luis Daniel Soto
Maldonado es Director de Evangelización
en Nuevas Tecnologías en Microsoft
México. Entre sus funciones actuales están
la administración de
la relación con el Gobierno Mexicano para
el desarrollo de la
industria de software
(ProSoft). Luis Daniel
es jurado del “Gran
Orden de Honor al
Mérito Autoral” en
software del INDAUTOR/SEP y fundador
de diversas asociaciones de Tecnologías de Información
(TI) relacionadas a
inteligencia competitiva, administración del
conocimiento y construcción de software.
Luis Daniel Soto es
Ingeniero en Sistemas
de la Fundación
Arturo Rosenblueth y
ganó el primer lugar
en el concurso nacional para software
de exportación en
1989. blogs.msdn.
com/luisdans
- Luis Daniel Soto
JUL-AGO 2005
41
PRÁCTICAS
UML
CASOS DE USO
Y EL VALOR DEL SISTEMA
Por Sergio Orozco
¿
A quién no le ha pasado que compra algo
sólo para terminar con ese producto en
un rincón sin jamás ser utilizado? Nos
pudo haber pasado porque no alcanzó nuestras
expectativas, o porque resultó demasiado complicado de utilizar, o porque en realidad no era
una verdadera necesidad sino simplemente un
capricho. Sea cual fuera la razón, la realidad es
que hicimos un gasto inútil e innecesario.
Con el software, y en particular con el desarrollo de software a la medida, ocurre con
bastante frecuencia algo similar. No es raro
encontrarse con empresas que contratan un
desarrollo de software sólo para darse cuenta
de que desperdiciaron su dinero y su tiempo,
pues no obtuvieron lo que ellos esperaban o
necesitaban. En otras palabras, no obtuvieron
el valor que esperaban recibir para su negocio
con el software adquirido.
La Administración
de Requerimientos
Una de las razones principales por las cuales
se da esta situación, y de hecho, una de las
causas principales por las cuales los proyectos
de desarrollo fracasan o por lo menos no tienen el éxito que deberían, se debe a una mala
administración de requerimientos. Esto generalmente se da por falta ya sea de habilidades
en el personal responsable o de técnicas apropiadas utilizadas para llevar a cabo esta labor.
La administración de requerimientos, de
acuerdo a CMM, abarca actividades como
la recopilación, documentación, validación
y control de los requerimientos y sus cambios. UML, como estándar integrador de las
buenas prácticas de desarrollo nos ofrece
en este sentido los casos de uso como una
técnica excelente para administrar los requerimientos de nuestros proyectos.
¿Consultoría o Manufactura?
Si queremos realizar una verdadera consultoría
de software, entonces nos corresponde algo
más que escuchar la lista de funciones que el
cliente cree que debería de tener su sistema (a
menos que nuestro cliente tenga un área con la
capacidad de realizar una buena recopilación
y análisis de requerimientos). Si nos limitáramos a lo primero, entonces en lugar de llamarle
consultoría a nuestro trabajo, deberíamos llamarle manufactura de software, donde uno implementa las funciones exactamente como se
las solicita el cliente, cuestionando nada o muy
poco, tal como se haría en una planta manufacturera donde se reciben las especificaciones del
producto a construir.
pedido”, “Consultar comisiones”, “Administrar
prospectos”, “Generar factura” y “Administrar
clientes”. Todas ellas son ejemplos de situaciones u objetivos importante que podría necesitar
un vendedor para llevar a cabo su trabajo, conocidas y modeladas como casos de uso en UML,
tal como se muestra en el diagrama.
El Sistema y su Misión
Si queremos desarrollar el mejor sistema posible, debemos realizar un trabajo serio para
identificar, en primer lugar, cuál es el valor que
el sistema debe proporcionar al negocio, para lo
cual habrá que preguntárselo a las personas que
obtendrán alguna clase de beneficio cuando se
ponga en operación. Una buena parte de estas
personas probablemente vayan a ser usuarios
del sistema; en UML los conocemos como Actores (más adelante veremos otros tipos de Actores
que también tendremos que identificar).
Buscando los Beneficios
del Sistema
Una vez identificados los usuarios del sistema
(actores primarios) habrá que preguntarles en
qué situaciones valdrá la pena para ellos utilizarlo. La lista identificada de dichas situaciones no
debería de tener pequeñas funciones, sino flujos
completos que le proporcionen suficiente valor
tanto a ellos como al negocio, de manera que
“valga la pena usar el sistema” en dichas situaciones. Ejemplo: un vendedor en cierto sistema
de ventas querrá “Registrar venta”, “Registrar
Diagrama de casos de uso para el sistema de venta.
Los Requerimientos Funcionales
Normalmente los casos de uso son iniciados por
algún actor, conocido como actor primario. Lo
inicia con algún evento, que podría ser tan simple como elegir una opción en el sistema, y continúa como una serie de eventos o interacciones
entre actores y sistema, hasta que el objetivo del
caso de uso se cumple (el objetivo principal del
caso de uso es lo que le da el nombre al mismo).
Por lo tanto los casos de uso describen la funcionalidad del sistema para alcanzar objetivos
Sergio Orozco es director general e instructor senior en Milestone Consulting, empresa especializada en capacitación práctica y consultoría en UML, CMM y orientación a objetos.
[email protected].
42
JUL-AGO 2005
importantes. Lo que estamos obteniendo así es
una especificación de requerimientos funcionales mediante un análisis top-down (de lo general a lo particular), es decir, primero obtenemos
los objetivos que hay que cumplir en el sistema
descritos con el nombre del caso de uso (p. ej:
Realizar una venta) y después buscamos cuáles
son las funciones o requerimientos funcionales
precisos y ordenados para que el actor cumpla
dicho objetivo al utilizar sistema. Esto nos lleva
a identificar requerimientos realmente relevantes para alcanzar la misión del sistema.
Pasos para recopilar los requerimientos
funcionales adecuados del sistema mediante casos de uso:
1. Especificar la misión del sistema.
2. Identificar quiénes utilizarán el sistema
(actores primarios).
3. Averiguar cuáles objetivos desean cumplir
los actores al usar el sistema (casos de uso).
4. Identificar los pasos o eventos de cada
caso de uso (especificación del caso de uso).
Las Interfaces del Sistema
Hay otro tipo de actores que también hay
que modelar; los actores secundarios. Suelen ser otros sistemas, componentes externos o dispositivos con los cuales interactúa
nuestro sistema. A diferencia de los actores
primarios, éstos no son los que inician o
requieren del caso de uso, sino que nuestro sistema, al llevar a cabo un caso de uso
requiere tener algún tipo de interacción con
él. En el diagrama de casos de uso también
suele ser apropiado mostrar a este tipo de
actores, en cuyo caso aparecerán asociados
a los casos de uso durante los cuales tienen
que intervenir con algún tipo de interacción
con el sistema a modelar.
Ejemplo de Actor Secundario
Nuestro sistema de ventas podría requerir enviarle información al sistema
de contabilidad cuando se ejecuta la
funcionalidad del caso de uso “Generar factura”. En dicha situación el sis-
tema de contabilidad aparecerá como
un actor secundario asociado a dicho
caso de uso. De esta forma estamos
mostrando las interfases requeridas
con otros sistemas en cada momento.
Por experiencia sabemos que, en los
modelos de UML, el buen uso de pocos elementos da mejores resultados
que el uso de muchos elementos mal
aplicados. La esencia de los modelos
radica en la simplicidad, ya que facilita
el análisis, entendimiento y comunicación entre quienes solicitan el sistema
y los que participan en su desarrollo.
En otras oportunidades veremos elementos adicionales para modelar los
casos de uso, pero podemos asegurar
que la sencillez es parte importante
del modelado, y esto implica que en
ocasiones, y sobre todo cuando el
analista no tiene tanta experiencia en
UML, es mejor limitarnos a los elementos más básicos.
COLUMNA
PRUEBA DE SOFTWARE
Fundamentos de la Prueba de Software
Conceptos, Justificación y Alcance
E
n el número anterior hablamos sobre el contexto
de la prueba de software. En esta ocasión, nos
concentraremos en definir algunas definiciones
relacionadas con la prueba de software, así como su
justificación y alcance.
Luis Vinicio León
Carrillo es profesor-investigador del Departamento de Electrónica,
Sistemas e Informática
del ITESO, y director
general de e-Quallity
S.A. de C.V., empresa
especializada en prueba
de software. Luis Vinicio
es doctorando por la
Universidad Técnica de
Clausthal, Alemania; su
trabajo predoctoral giró
alrededor a la aplicación
de los lenguajes formales en la Ingeniería de
Software. Es coautor de
un marco tecnológico
que hoy permite a
e-Quallity desarrollar
empresas de prueba
de software. Su tesis
doctoral está enfocada
en la aplicación de
métodos y lenguajes
formales para hacer
más eficiente y efectiva
la prueba de software.
Luis Vinicio es co-fundador del Capítulo Guadalajara de la AMCIS y
su Secretario actual.
Las descripciones de algunos conceptos que expondré en el presente, si bien son generalizables, estarán
enunciados desde la perspectiva de la técnica denominada “prueba de caja negra”, consistente en ejecutar el
sistema a probar revisando los requerimientos, con la
consigna de detectar insatisfacción de los mismos. La
razón es que facilita la exposición sin introducir complejidad innecesaria.
Definiciones
Complementando nuestro primer acercamiento a una definición, que tuvimos en el número anterior, podemos argüir
que la prueba de software:
Es un proceso en el que se revisa el sistema a probar
(el SUT) bajo condiciones definidas explícitamente,
y se le aplica (eventualmente con apoyo de software
especializado de tipo CAST) un conjunto de estímulos
(los casos de prueba) diseñados de manera sistemática utilizando técnicas apropiadas, con el objetivo de
detectar niveles inadecuados de calidad. Este proceso
debe llevarse a cabo disciplinadamente, y respaldarse
en métricas bien definidas. Todas estas actividades y
sus resultados son documentados, en especial las fallas detectadas [1].
Precisemos cada uno de los conceptos de esta definición.
Intuitivamente, un proceso puede verse como una secuencia de actividades, cada una de las cuales genera productos, tiene insumos asociados, e involucra gente (roles) y
otros recursos (v.gr. hardware y software).
Un primer bosquejo del proceso de prueba de caja negra sería el siguiente, que refinaremos en números subsiguientes:
1. Establecer alcances, entregables y criterios de éxito
2. Estimar el esfuerzo de prueba
3. Planear el proyecto
44
JUL-AGO 2005
4. Reproducir el contexto del SUT
5. Hacer
a) Diseñar casos de prueba
b) Aplicar casos de prueba
c) Reportar métricas y dar seguimiento
d) Reportar análisis de resultados
Mientras no (criterio de terminación)
6. Hacer el cierre del proyecto
El SUT (System Under Testing) se refiere en general al
elemento a probar. Por otro lado, las herramientas que
utiliza el tester para llevar a cabo las actividades anteriores son cobijados bajo el acrónimo CAST (Computer
Aided Software Testing).
En cuanto a los casos de prueba, es deseable que presenten las siguientes características:
• Ortogonalidad. No tener casos que incluyan segmentos
de otros
• Efectividad. Que detecten fallas.
• Ejemplaridad. Que “con poco se pruebe mucho”.
• Claridad. Que evidencien fallas de manera clara.
Con calidad nos referimos a [2]:
• El grado en que el producto satisface los requerimientos
funcionales y no-funcionales explícitamente establecidos.
• El nivel al que se siguieron los estándares de desarrollo
explícitos y documentados.
• Que el producto muestre las características implícitas que
se espera de todo software desarrollado profesionalmente.
Una equivocación es una acción incorrecta cometida por
un humano (v.gr. no presionar [shift]), que ocasiona que
se genere una falta (sin el [shift], queda “<” en vez de “>”
en el código fuente); al ser ejecutada, la falta se evidencia en forma de lo que llamamos una falla. El error es la
magnitud de la diferencia entre el resultado esperado y
el obtenido [3].
Justificación
Los principales objetivos que se buscan con la prueba de
software suelen ser:
• Conocer el nivel de calidad de productos intermedios,
para actuar a tiempo (v.gr. rehacer un componente); esto
facilita una administración realista del time
to market del producto en cuestión.
• No pagar por un producto de software
sino hasta que alcance el nivel de calidad
pactado; esto eleva el nivel de certidumbre en el comprador de software, y minimiza riesgos.
• Disminuir la penosa y costosa labor de
soporte a usuarios insatisfechos, consecuencia de liberar un producto inmaduro.
Esto puede mejorar la imagen de la organización desarrolladora (y la credibilidad
en ella).
• Reducir costos de mantenimiento (la fase
más costosa del desarrollo de software),
mediante el diagnóstico oportuno de los
componentes del sistema (v.gr. seguimiento a estándares, legibilidad del código, integración adecuada de los componentes,
rendimiento apropiado, nivel y calidad del
reuso, calidad de la documentación, etc.).
• Obtener información concreta acerca de
fallas, que pueda usarse como apoyo en
la mejora de procesos, y en la de los desarrolladores (v.gr. capacitación en áreas
de oportunidad).
Entre más pronto se apliquen mecanismos
de prueba en el proceso de desarrollo,
más fácilmente podrá evitarse que el proyecto se salga del tiempo y presupuesto
planeado, pues se podrán detectar más
problemas originados en las fases tempranas del proceso, que son los que mayor impacto tienen.
Alcance
La prueba de software tiene limitantes, tanto teóricos como prácticos. Desde el punto
de vista teórico, la prueba es un problema
que llamamos no-decidible; esto implica,
grosso modo, que no podemos escribir un
programa que pruebe los programas sin
intervención humana. Sin embargo, como
mencionábamos anteriormente, la prueba
sí es automatizable en muchos aspectos.
Desde el punto de vista práctico, la
cantidad de posibilidades para probar
exhaustivamente un sistema es sencillamente inmanejable; es necesario
entonces utilizar técnicas adecuadas
para maximizar la cantidad de fallas importantes encontradas con los recursos
asignados. Cada método que se utilice
para detectar defectos deja un residuo
de defectos más sutiles contra los cuales ese método es ineficaz (la llamada
“Paradoja del Pesticida”).
La prueba de software implica pues, la
aplicación de técnicas y herramientas
apropiadas en el marco de un proceso bien
definido, determinado por el tipo de proyectos de desarrollo de software que se
abordan. En el siguiente número veremos
con mayor detalle las principales técnicas
de prueba de software.
- Luis Vinicio León
Referencias
1. www.e-quallity.net pestaña Definiciones - Conceptos
2. Pressman, R.: Ingeniería de
Software. Un Enfoque práctico.
McGraw-Hill; 1993
3. Kit, E.: Software Testing in the
Real World. ACM Press, 1995
COLUMNA
CÁTEDRA Y MÁS
BPM
El Impacto en el Desarrollo de Software Aplicativo
L
os negocios o empresas hoy
en día están preocupados por
lograr la eficiencia organizacional al estandarizar los procesos
de negocios en forma consistente en
toda la compañía. La Administración
de Procesos de Negocios (BPM) se
enfoca en las prácticas inconsistentes
de negocios. Cada quién realiza las
actividades de forma diferente, con
resultados poco homogéneos.
El Dr. Ralf Eder Lange
es Profesor ConsultorExtensionista del Departamento de Sistemas
de Información en el
Tec de Monterrey, Campus Estado de México,
donde ha sido Director
de los Programas de
Graduados en Ciencias
Computacionales y
Sistemas de Información, y Director del
Centro de Investigación
en Informática. Sus
áreas de especialidad
incluyen Reingeniería de
Procesos y Administración de la Innovación
Tecnológica. Ralf es
miembro fundador de la
Asociación Latinoamericana y del Caribe de
Sistemas de Información (LACAIS).
Muchas empresas proveedoras de
software se encuentran evaluando el
replanteo de sus productos, usando,
por ejemplo, soluciones CRM, cuando
este acrónimo apareció en la escena.
Lo mismo ha ocurrido con BPM, sin embargo, los productos que ofrecen los
proveedores varían dramáticamente en
capacidad y funcionalidad. BPM brinda
la posibilidad de definir los procesos de
negocio a nivel estratégico, para posteriormente automatizar dichos procesos
en una aplicación computacional y finalmente proveer a los gerentes del negocio con la posibilidad de monitorear
y analizar la operación de dichos procesos. Esto permite resolver problemas
en el momento en que ocurren.
Resulta muy importante que una plataforma de BPM permita especificar
procesos que abarquen múltiples
compañías, usando varios sistemas
aplicativos en forma rápida, para
luego implantarla en seguida. De lo
contrario, dicha plataforma ofrece
muy poco valor, al referirse a la automatización de procesos. Los negocios
están inmersos cotidianamente en
cambios constantes, tanto por actividades internas como externas, por lo
que una plataforma de administración
de procesos de negocios debe ser capaz de responder a estos cambios.
La administración de procesos de negocio es llevada a cabo con diferentes
herramientas utilizadas para capturar, modelar, diseñar, integrar, probar,
46
JUL-AGO 2005
implantar, medir y mantener diversos
procesos de negocio en una empresa.
Los procesos de negocio centrales definen el negocio y proporcionan la posibilidad de satisfacer y retener a los
clientes, de maximizar las alianzas con
otras empresas y de obtener resultados
extraordinarios con respecto a la competencia. Al administrar los procesos
de negocio se evitan prácticas inconsistentes de peticiones de cambio en aplicaciones computacionales, se asignan
roles que ayudan a los clientes a definir
los permisos de uso y acceso a la información, junto con las aprobaciones a
los cambios en cada proyecto.
BPM permite definir colectivamente
los procesos de negocios, implantarlos
en forma de aplicaciones computacionales, de tal forma que los administradores puedan monitorear, analizar,
controlar o mejorar la ejecución de dichos procesos en tiempo real. Para implantar BPM se requiere entender en
forma detallada la interacción de los
diversos procesos de negocio existentes, así como poseer el conocimiento
acerca de cómo fueron desarrolladas
las aplicaciones computacionales correspondientes. Esto resulta ser un
gran reto para todas las empresas, ya
que al especificar la solución y diseñar
el proyecto de BPM debe haber representantes de los procesos de negocios
y de las aplicaciones computacionales, y esta interacción continúa aún
después de la implantación, ya que
debe proveerse mantenimiento a dichas aplicaciones. Por ejemplo, aquellas personas que realizan diagramas
de flujo con herramientas como Visio o
PowerPoint, también deben ser capaces de modelar procesos de negocio
usando un BPMS. Luego se debe de
poder comentar el proceso de negocio y pasarlo a los técnicos para su
implantación. La habilidad de definir
procesos con sus reglas de negocio,
integrar aplicaciones computacionales e implantarlas, es necesaria para
mejorar la productividad del negocio,
pero por sí sola no es suficiente. Por
esto la importancia de la habilidad de
monitorear la ejecución de procesos
en tiempo real, conociendo su impacto
de ejecución y controlarlos en virtud
de los cambios en las condiciones de
negocio.
A las personas con habilidades de negocio se les dificulta la comprensión
de los detalles o la perspectiva de la
tecnologías de la información —potencial de uso y funcionalidad—, y
a los técnicos se les dificulta el apreciar los requerimientos —legales,
económicos, organizacionales—, tal
como se plasman en los procesos de
negocio. Bajo estos puntos de vista
divergentes, resulta difícil lograr la optimización del diseño propuesto, así
como la implantación y la solución de
problemas. El punto crucial, desde mi
punto de vista como administrador de
un proyecto de BPM, es la asignación
de personal para que haya representatividad en el equipo formado con tal
fin, que garantice el desarrollo de una
aplicación computacional que efectivamente apoye objetivos de negocio,
que estén sustentados en procesos de
negocios auténticos, y que ayuden en
el monitoreo. Dicho personal debe demostrar tener experiencia de campo,
con usuarios por un lado y con las aplicaciones computacionales por otro.
-Dr. Ralf Eder L.
Referencias
• Learn Data Modeling
www.learndatamodeling.com/b_
manage.htm
• Serena Software - BPM
www.serena.com/business_process_management.html
• Savvion - BPM
www.savvion.com/business_process_management.php
FUNDAMENTOS
PMBOK Guide
Guía de los Fundamentos de la Dirección de Proyectos
Por Ramón Hernández
Como su nombre lo indíca, el
PMBOK (Project Management
Body of Knowledge) Guide es
un documento que reúne el conocimiento relacionado con la
Dirección de Proyectos. La versión en español lleva el título
“Guía de los Fundamentos de la
Dirección de Proyectos (Guía del
PMBOK®)”, y se encuentra actualmente en su tercera edición,
liberada a finales del 2004.
La primera versión del PMBOK se publicó
como un artículo especial en el año de 1983
en una revista especializada del PMI (Project Management Institute). Algunos años
después, en 1986, se publicó como un libro
que contenía la estructura general que conocemos hasta el día de hoy (nueve áreas del
conocimiento y cinco grupos de procesos). En
el año 2000 se publicó una actualización, así
como la primera traducción oficial al español.
Finalmente en el 2004 se publicó la tercera
edición de este libro. Prueba de la difusión de
este documento como un estándar mundial,
fue el hecho de que se publicó de manera
simultánea en once idiomas: inglés, árabe,
chino simplificado, francés, alemán, italiano,
japonés, coreano, portugués, ruso y español.
“La finalidad principal de la Guía del PMBOK
es identificar el subconjunto de Fundamentos de la Dirección de Proyectos generalmente reconocido como buenas prácticas”.
—PMBOK pág. 3
Iniciación
Planificación
Control
Ejecución
Cierre
Grupos de Procesos
Ejecución.- En este grupo de procesos se integra a personas y otros recursos para llevar
a cabo el plan de proyecto, así como realizar
los cambios aprobados para el proyecto.
Seguimiento y Control.- Mide y supervisa
regularmente el avance, a fin de identificar
desviaciones respecto al plan de proyecto,
de tal forma que se tomen medidas correctivas o preventivas cuando sea necesario para
cumplir con los objetivos del proyecto. Aquí
se lleva el control de los cambios al proyecto que asegura que los mismos son benéficos para el proyecto, el control de calidad
del proyecto y la recopilación y distribución
acerca del rendimiento del proyecto.
Cierre.- Formaliza la aceptación del producto, servicio o resultado, y termina de manera
ordenada el proyecto o una fase del mismo,
o cierra un proyecto cancelado.
Los cinco grupos de procesos agrupan a 44
procesos de dirección de proyectos que están clasificados por Área de Conocimiento.
Grupos de Procesos
Áreas de Conocimiento
Los Grupos de Procesos son guías para aplicar los conocimientos y habilidades relativas
a la Dirección de Proyectos. Los Grupos de
Procesos tienen dependencias claras y se
realizan siguiendo la misma secuencia para
cada proyecto, son independientes de la industria o aplicación. El PMBOK define cinco
grupos de procesos:
Iniciación.- Aquí se define y autoriza el proyecto o una fase del mismo. La repetición de
estos procesos permite que el proyecto sea
detenido si deja de existir la necesidad de
negocio o si se considera que el proyecto no
puede satisfacer esa necesidad.
Planificación.- Define y refina los objetivos,
y planifica el curso de acción requerido para
lograr los objetivos y el alcance pretendido
del proyecto. Aquí se define el alcance y costo del proyecto o fase del mismo.
Para poder estudiar todos los procesos de
la Dirección de Proyectos, se agruparon en
Áreas de Conocimiento, ya que en la vida real,
estas Áreas de Conocimiento se pueden sobreponer una sobre la otra o interactuar entre
sí de maneras muy diversas. Las Áreas de Conocimiento definidas en el PMBOK son:
Gestión de la Integración del Proyecto.- Incluye los procesos y actividades necesarios
para identificar, definir, combinar, unificar
y coordinar los distintos procesos y actividades de dirección de proyectos dentro de
los Grupos de Procesos de Dirección de Proyectos. La necesidad de integración se hace
evidente en situaciones donde procesos individuales interactúan.
Gestión del Alcance del Proyecto.- Incluye
los procesos necesarios para asegurarse que
el proyecto incluya todo el trabajo requeri-
Ramón Hernández es Gerente de proyecto con más de diez años de experiencia en Tecnología de Información concentrado en proyectos para el sistema financiero.
Ramón es PMP certificado desde 1999 y colabora en el capítulo del PMI en la Ciudad de México.
48
JUL-AGO 2005
do, y sólo el trabajo requerido, para terminar
un proyecto de manera satisfactoria, básicamente es controlar lo que está incluido en el
proyecto y lo que quedará fuera del mismo.
Aquí se desarrolla la especificación del trabajo, o Statement of Work (SOW).
Gestión del Tiempo del Proyecto.- Tiene
todos los procesos necesarios para lograr
terminar el proyecto en tiempo, como son la
definición y secuencia de las actividades, así
como los recursos necesarios para cada actividad y la duración de las mismas. El producto principal es el Cronograma del proyecto.
Gestión de los Costos del Proyecto.- Aquí se
tienen todos los procesos que permiten que
el proyecto termine dentro del presupuesto
aprobado. Se menciona que no sólo se debe
poner énfasis en los costos del proyecto, sino
en la repercusión que éstos pueden tener en
el cliente, por ejemplo, disminuir el número
de revisiones de aseguramiento de calidad
al proyecto puede reducir el costo del proyecto, pero puede incrementar los costos
que tendrá que pagar el cliente por tener un
producto que no cumpla sus necesidades de
acuerdo a lo pactado en el proyecto.
Gestión de la Calidad del Proyecto.- Esta
área de conocimiento incluye todas las actividades que determinan las políticas, objetivos y responsabilidades relacionadas con la
calidad del proyecto que satisfaga las necesidades por las cuales se originó.
Gestión de los Recursos Humanos del Proyecto.- Incluye todos los procesos que coordinan
los trabajos de un equipo de proyecto en el cual
se han definido roles y responsabilidades.
Gestión de las Comunicaciones del Proyecto.- Es el área de conocimiento que incluye
los procesos necesarios para asegurar que
la información del proyecto sea entregada en
tiempo y forma a todos los involucrados en
el proyecto, algunos señalan que es en esta
área donde el Gerente de Proyecto debe destinar la mayor parte de su tiempo. Se debe
definir para cada involucrado en el proyecto
el tipo y la frecuencia con que debe recibir
información del proyecto, se debe informar
a todos los niveles, hacia arriba, hacia abajo
y hacia los lados.
Gestión de los Riesgos del Proyecto.- Aquí
se realiza la planificación de la gestión de
riegos, la identificación y análisis de riegos,
las respuestas a los riegos, y el seguimiento
y control de los riesgos de un proyecto, se
pretende con esto aumentar la probabilidad e
impacto de los eventos positivos, y disminuir
la probabilidad e impacto de los eventos contrarios al éxito del proyecto. Los riesgos son
eventos o condiciones inciertos que, en caso
de ocurrir, tienen un efecto positivo o negativo sobre alguno de los objetivos del proyecto,
ya sean tiempo, costo, alcance o calidad.
Gestión de las Adquisiciones del Proyectos.- En esta última Área de Conocimiento
se incluyen todos los procesos de comprar
o adquirir productos o servicios externos al
equipo de proyecto necesarios para realizar
el trabajo. Se incluye la administración de
cualquier contrato, que es un documento legal entre un comprador y un proveedor, asumiendo que el comprador forma parte del
equipo del proyecto y el proveedor no.
Conclusión
De una manera breve se muestra
cómo está estructurado el PMBOK;
para aquellos relacionados con la
Ingeniería de Software puede ser
un complemento interesante y un
libro de consulta por excelencia que
permita desarrollar proyectos de
software cumpliendo con las necesidades de los clientes. Si mezclamos
el SWEBOK (ver sección Fundamentos de SG Año 01 No.01) con el
PMBOK, tendremos dos excelentes
documentos que nos permitirán establecer el marco de referencia para
desarrollar software de calidad.
Referencias
• Guía de los Fundamentos de la Dirección
de Proyectos. Project Management Institute.
3era Edición, 2004.
• “Fundamentos: Ingeniería de Software”.
Revista SG Año 01 No.01
JUL-AGO 2005
49
TECNOLOGÍA
WiMAX
El siguiente paso en redes inalámbricas
Por Ariel García
WiMAX, del inglés Worldwide Interoperability for Microwave Access, es un estándar para transmisión inalámbrica de datos en redes de área metropolitana (MAN). Es una certificación para productos que cumplen
con las pruebas de interoperabilidad de los estándares de IEEE 802.16, que tienen su área de especialidad
en conexiones inalámbricas punto multipunto.
Qué esperar de una red WiMAX
WiMAX es una nueva alternativa para la
construcción de redes inalámbricas, pero
con mayores beneficios. Algunas ventajas son el manejo de velocidades de hasta
70Mbps y coberturas de hasta 50km. Esto
no significa que WiMAX venga a sustituir la
tecnología Wi-Fi, al contrario, está diseñada
para complementar e interoperar con esta
solución, al igual que con otras como Ethernet, Token Ring, FDDI, Cable MODEM, etc.
Bandas (Mhz)
Actuales y Autorizaciones Vigentes*
Nuevas Aplicaciones
(Diseñadas para convivir
con atribuciones previas)
2400-2483.5
ICM (aplicaciones industriales,
científicas y médicas), teléfonos inalámbricos, enlaces p-p y p-mp (espectro
disperso), telemetría, sistemas
multiacceso telefonía rural, tx de datos,
hornos y enlaces de microondas.
802.11b/11Mbps,
802.11g/54Mbps,
802.20/1 Mbps/movilidad,
Bluetooth, Home RF
ps/movilidad,
802.16/70 Mbps/movilidad.
En su primera etapa de implantación, WiMAX
sólo estará disponible para los carriers,
(compañías que ofrecen servicios de telecomunicaciones como telefónicas e ISPs) y
grandes corporativos, para que puedan mejorar el servicio que ofrecen a sus clientes.
La cobertura de la tecnología WiMAX se medirá en kilómetros cuadrados (Wi-Fi lo hace
en metros cuadrados). Esto implica que en
el área de cobertura de una estación base
de WiMAX, se podrían habilitar soluciones
de acceso a Internet de alta velocidad para
hogares y oficinas en un radio de hasta
50km. Estas estaciones base eventualmente
podrían cubrir toda una zona metropolitana,
habilitando un acceso inalámbrico ininterrumpido en toda una ciudad.
5150-5350
Enlaces p-p y p-mp (espectro disperso y
modulación digital), MOVIL
802.11ª/54Mbps,
802.11i, 802.16/70 Mbps/
movilidad, 802.20/1
Mbps/movilidad.
5470-5725
Radio Navegación marítima,
Radiolocalización movil, radioaficionados.
El estándar de WiMAX trabaja en el espectro
entre 2 y 11GHz y supera las limitaciones de
Wi-Fi al proveer anchos de banda de mayor
velocidad y una encripción más robusta.
Otra característica importante de WiMAX es
su capacidad de proveer acceso al medio sin
necesidad de línea de vista directa a la estación base. Obviamente esto disminuye el
50
JUL-AGO 2005
5725-5850
ICM (aplicaciones industriales, científicas
y médicas), Detección, identificadores,
telemetría, telecomando y enlaces p-p y
p-mp (espectro disperso)
802.16/70 Mbps/movilidad,
802.20/1 Mbps/movilidad
802.11ª/54Mbps
802.16/70 Mbps/Movilidad,
802.20/1 Mbps/movilidad.
* Incluye permisos, concesiones, autorizaciones y registros.
alcance, pero aún así WiMAX hace un muy
buen trabajo en este tipo de situaciones.
Las ventajas de WiMAX
La tecnología podría proveer accesos compartidos de hasta 70Mbit/s. Esta capacidad
es suficiente para soportar más de 60 enlaces tipo T1, o varios cientos de hogares con
accesos DSL de 1Mbit/s. WiMAX tiene un
manejo optimizado y de mayor eficiencia del
ancho de banda, en base a sus algoritmos de
control de acceso al medio. Estos algoritmos
permiten a la estación base controlar la calidad de servicio al balancear la asignación de
ancho de banda en base a las necesidades
de cada subscriptor de la estación; por ejemplo, si algún suscriptor está realizando una
descarga de archivos que tiene una velocidad promedio de 80Kb/s y tiene contratado
un enlace de 256Kb/s, la estación base sólo
asignará los 80Kb/s que está demandando
y pueda aprovechar el resto del ancho para
otros suscriptores que lo necesiten.
Dónde adquirir una
solución WiMAX
Actualmente en ciudades como Los Angeles, Nueva York, y Seattle en EUA; y Dalian,
Chengdu en China, ya hay implementaciones de redes que funcionan con esta tecnología, pero no están certificadas por el
WiMAX Forum (ver recuadro), es por esto
que se les conoce como pre-WiMAX. Actualmente el WiMAX Forum tiene su programa
de certificación en curso, y se espera que
las primeras soluciones WiMax certificadas
aparezcan a principios del 2006.
Una vez liberada la certificación podremos
obtener productos que nos permitan construir soluciones que puedan trabajar con
cualquier equipo “WiMAX certified” sin importar la marca o el fabricante del chipset.
Se espera que para finales del 2007 aparezcan los primeros dispositivos WiMAX para
usuarios finales, con los que una persona se
podrá conectar a Internet por WiMAX a velocidades de 4Mbps. Posteriormente, a finales
del 2008, aparecerían las primeras laptops
“WiMAX-ready”.
¿Existen otras tecnologías
tipo WiMax?
El competidor equivalente de WiMAX en Europa es HIPERMAN. Actualmente el WiMAX
Forum está trabajando en métodos para que
WiMax y HIPERMAN pueden interoperar de
forma transparente. La industria de telecomunicaciones de Corea también ha desarrollado su propio estándar: WiBro. El año
pasado Intel y LG acordaron una interoperabilidad entre WiBro y WiMAX.
Regulación del Espectro
Los usos de tecnologías como WiMax
o WiFi permiten compartir el espectro,
haciendo un uso más eficiente. Es fundamental que para promover estos ser-
vicios, las administraciones consideren
diferentes e innovadoras formas de utilizar el espectro radioeléctrico en vez de
asignarlo a un único dueño, lo que limita
la cobertura y desarrollo de infraestructura, dando paso a un cambio de paradigma,
en que el espectro puede ser compartido y
donde bajo un marco mínimo de criterios
operativos, se puede dar oportunidad a la
sociedad e industria de acceder al beneficio que ofrecen estas tecnologías. Hoy en
día estas bandas de frecuencias presentan una problemática en México, ya que
su utilización libre para acceder Internet
esta sujeta a autorización.
En tal contexto, es necesario que el Estado
mexicano en conjunto con la industria, determinen la mejor manera de aprovechar las
modernas tecnologías en uso en las bandas
de 2.4 y 5 GHz, a fin de promover el acceso de
la mayor parte de la población. La SCT tiene
hoy ante sí la decisión de masificar el acceso
a Internet y sus servicios, las tecnologías ya
están disponibles y las economías de escala
permiten tener dispositivos de muy bajo costo, desaprovechar o demorar esta magnifica
oportunidad, significaría perder la oportunidad que brindan las TIC para aportar al crecimiento y desarrollo sustentable del país.
Conclusiones
La tecnología WiMAX es una nueva solución
para implementación de redes de acceso
inalámbrico dentro de un área metropolitana. Esto no viene a competir con soluciones
existentes como fibra óptica, satélite, Wi-Fi,
etc. Al contrario, nos ayuda a complementar
cada una de estas soluciones. Ejemplos:
• Para aquellas compañías que cuentan con
enlaces de fibra óptica y buscaba soluciones
para un enlace de respaldo a bajo costo,
WiMAX es una buena opción.
• Aquellos proveedores que se encuentran
dando servicios de acceso Internet inalámbrico pueden expandir sus áreas de cobertura o iniciar nuevas implementaciones en
otras ciudades con esta tecnología.
• Tomemos el caso de la Sierra Tarahumara.
No existen soluciones de conectividad por
cableado de ningún tipo. Mediante un enlace
satelital podríamos colocar una antena donde se provee la conectividad a la Internet. En
ese punto colocamos nuestra estación base
WiMAX de donde tendremos un radio de cobertura de hasta 50 kilómetros para habilitar
servicios de telefonía IP. Podemos colocar
hotspots Wi-Fi para poder brindar servicios
de Internet o educación a distancia, etc.
WiMAX iniciará su crecimiento dentro de los
grandes corporativos y empresas de comunicaciones consolidadas. Una vez que este
mercado sea cubierto, los costos habrán
bajado y seremos nosotros, los usuarios finales, quienes comenzaremos a poder tener
accesos directo a esta tecnología con sus
respectivos beneficios.
*Agradecemos a Pedro Cerecer de Intel por
la información provista para la generación
de este artículo.
Qué es el WiMAX Forum?
El WiMAX Forum es un consorcio de empresas (inicialmente 67 y actualmente más de
100), dedicadas a diseñar los parámetros y estándares de esta tecnología, y a estudiar, analizar y probar los desarrollos implementados. En principio se podría pensar
que esta tecnología supone una grave amenaza para el negocio de tecnologías inalámbricas de acceso de corto alcance en que se basan muchas empresas, pero hay
compañías muy importantes detrás del proyecto. Las principales firmas de telefonía
móvil también están desarrollando terminales capaces de conectarse a estas nuevas
redes. Mayor información sobre el WiMAX Forum en www.wimaxforum.org
JUL-AGO 2005
51
TECNOLOGÍA
Sony
Vaio Notebook Serie F
Con un diseño más delgado y ligero, la recientemente presentada Serie F de Vaio combina rendimiento y comodidad. En tan
sólo 2.5cm de ancho, y 2.8kg, la Serie F integra procesador
Pentium M a 1.60GHz, 512MB (escalables a 1GB) de memoria
RAM, disco duro de hasta 60GB, pantalla de 15.4 pulgadas visibles, unidad DVD+RW/-RW/CD-RW y Windows XP Home. Lo
mejor del software propietario de multimedia de Sony, Vaio
Zone, es la capacidad de manipular el contenido de varias
computadoras enlazadas en una red local, lo que convierte
a la Serie F en un centro de control de entretenimiento ideal.
Con un precio bastante accesible y todas las características
enlistadas, la Serie F es una excelente opción en computadoras portátiles de alta capacidad y tamaño reducido.
nVIDIA
GeForce 7800
La nueva tarjeta aceleradora de video de nVIDIA presenta la arquitectura de siguiente generación, con una unidad de vértices
de sombreado independiente que recorta dramáticamente el
tiempo de rendereado de geometría compleja. El motor gráfico
CineFX 4.0 procesa el doble de operaciones de punto flotante
que las tarjetas de la generación anterior, obteniendo las mejores texturas y efectos de iluminación en tiempo real, concretando el motor cinematográfico prometido desde hace más de
cuatro años. 256MB de memoria y un procesador central de 128
bits, brindan la gama más amplia de profundidad de color en 32
bits, así como un radio de actualización de 85Hz en monitores
de hasta 2048x1536 pixeles de resolución. La tecnología Digital
Vibrance Control 3.0 permite al usuario manipular fácilmente la
calibración de color de sus monitores, para ofrecer igualación
precisa en el área de trabajo, ya sea en medios digitales o impresos. La GeForce 7800 es para edición de video, rendereo de imágenes en 3D y juegos, por supuesto, permitiendo correr títulos
como Doom 3 en todo su potencial.
52
JUL-AGO 2005
PalmOne
Tungsten E2
Orientada a los nuevos usuarios, la E2 incorpora toda la utilidad de una PDA con la más reciente versión de PalmOS, el
Garnet v5.4, de interfaz sencilla y familiar. Todas las aplicaciones de organización (contactos, calendario, administrador de citas y correo electrónico), y el fabuloso Documents
To Go, con el que se pueden leer y modificar documentos
de Excel, PowerPoint y Word, garantizan la productividad en
cualquier lugar. La pantalla a color de 320x320 pixeles de
resolución, ranuras de expansión para tarjetas MultimediaCard, SD y SDIO, el software palmOne media, y RealPlayer,
hacen de esta Tungsten la compañera perfecta para un viajero, convirtiéndose en un centro multimedia, reproductor de
MP3, fotografías y video. Puertos Bluetooth, infrarrojo y USB
permiten sincronizar la información e intercambiar contactos
con otros dispositivos sin complicaciones. Los accesorios
disponibles incluyen un teclado y el GPS Navigator, actualizable para contar con la última información en mapas para
trazado de rutas.
BIBLIOTECA
01
As the Future Catches You: How Genomics & Other
Forces Are Changing Your Life, Work, Health & Wealth
Juan Enríquez Cabot
Crown 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
pueblo y por la tecnología.
• En 1960, “Hecho en Japón”, era sinónimo de mala calidad, y en el 2005 es todo lo contrario. Adivinen qué hizo Japón.
• En enero de 2000, Microsoft estaba valuada en 592 mil millones de dólares. Diez veces lo que Brasil exportaba en 1998, o cinco veces lo
que México exportaba. Pero, ¡ojo!, Brasil tenía 171 millones de habitantes, México 100 y Microsoft empleaba a sólo ¡32,000 personas!
Cabot pone todos estos ejemplos para llegar al tema central del libro: la nueva revolución impulsada por la nanotecnología.
Esta ya no estará dominada por los 0’s y 1’s (digital), sino por lo que pueda escribirse con las letras ATCG (Adenina, Tiamina,
Citosina y Guanina). El futuro nos depara un mercado en el cual podrás adquirir una manzana para controlar la diabetes, una
pera contra la gripe, mosquitos que te inyectarán vitaminas, y así sucesivamente. ¿Sorprendente?, bueno si realmente te quieres sorprender, no dejes de leer este impactante libro, escrito con un formato que ha sido aclamado a nivel mundial.
Reseña proporcionada por Armando Sánchez Rodríguez ([email protected]).
In Search of BPM
02
Excellence: Straight
from the Thought Leaders
Business Process Management Group
(BPMG)
Meghan Kiffer Press, 2005
Existen muchos libros de BPM. Sin embargo, la mayoría solamente habla sobre
lo grandioso que es BPM y los beneficios
que traerá a las empresas, pero muy pocos
realmente hablan acerca de cómo hacerlo
una realidad y mucho menos sobre lecciones aprendidas. Es por ello que en este
número les recomendamos “In Search of
BPM Excellence”, ya que es uno de los pocos libros de BPM que no sólo hablan del
qué, sino también del cómo.
Este libro fue creado por el Business Process Management Group (BPMG) y reúne
el pensamiento de algunos de los personajes más importantes de este movimiento.
Es un compendio de artículos que tratan
54
JUL-AGO 2005
temas como el pasado, presente y futuro
de BPM, frameworks de implantación (8
Omega Framework), y criterios para seleccionar un BPMS. También hay artículos
muy interesantes que abordan temas de
negocio tales como estrategia, ventaja
competitiva y cambio organizacional, desde la perspectiva de BPM.
Dado su reciente publicación (mayo de
2005), es muy probable que todavía no
hayan escuchado mucho sobre este libro.
Sin embargo, confiamos en que pronto se
convierta en una de las lecturas obligadas
sobre el tema.
Recomienda un libro para esta sección, escribe a: [email protected]
INDEX
DIRECTORIO
TENEMOS UN ESPACIO
RESERVADO PARA TI
Si deseas anunciarte contáctanos
en el (55) 5239 5502 o en
[email protected]
Anunciante
Páginas
Sitio
Alpha Consultoría
AMCIS
Avantare
certum
e-Quallity
Gopac
Grupo STI
Horbis
IBM
Itera
MGE
Microsoft
Milestone
Oracle
Roca Sistemas
SafeNet
Ssistemas
Software AG
Top SW Show
XpoLinux
49
55
45
35
43
29
13
39
F4
53
37
F2-1
11
07
47
17
15
33
09
F3
www.alpha-hardin.com
www.amcis.org.mx
www.avantare.com
www.certum.com
www.e-quallity.net
www.gopac.com.mx
www.gsti.com.mx
www.horbis.com
www.ibm.com/mx
www.itera.com.mx
www.mgeups.com
www.microsoft.com/mexico
www.milestone.com.mx
www.oracle.com/global/mx
www.rocasistemas.com.mx
www.la.safenet-inc.com
www.ssistemas.com
www.softwareag.com
www.mayen-project.com.mx
www.expolinux.com
JUL-AGO 2005
55
CARRERA
El Arquitecto de Software
Habilidades Necesarias
Por Sergio Orozco y Carlos Macías
E
l término “arquitectura de software” y el rol de “arquitecto de software” parecen estar cada día más de moda en nuestra industria. Sólo basta asomarnos a la trama de
películas de ciencia ficción como The Matrix: Revolutions donde el arquitecto aparece
como un Dios Todopoderoso, responsable de la creación de ese mundo virtual. De igual manera, existe una caricatura donde se hace la analogía entre un programador representando a
un padawan (aprendiz de Jedi en la saga Star Wars) y un arquitecto de software representando a un maestro Jedi. El aprendiz no podía creer la cantidad de habilidades y conocimiento
que requería para convertirse en un Jedi (o arquitecto según esta analogía), por lo que comenzaba a dudar si sería mejor irse por el lado oscuro de la fuerza.
¿Qué es la Arquitectura de Software?
La arquitectura es el conjunto de decisiones relevantes acerca de la organización de un sistema de
software, la selección de los elementos estructurales y las interfases que lo componen, junto con
el comportamiento según se especifica en la colaboración entre sus elementos, la composición de
dichos elementos estructurales y de comportamiento en subsistemas cada vez mayores, así como el
estilo arquitectónico que dirige su organización.
— La Guía de Usuario de UML, Booch-Jacobson-Rumbaugh, 1999.
Si el analista de sistemas es el responsable de identificar y especificar las necesidades y requerimientos del usuario,
entonces el arquitecto es el responsable
de tomar las decisiones más relevantes en
cuanto a la forma más óptima en que se
explotará la tecnología para implementar
dichos requerimientos.
¿Qué es lo que se necesita para dominar
los principios que pueden transformar a
un desarrollador común en un arquitecto
de software?
Influencia en los Proyectos.- Es conveniente
que domine la mayor cantidad de tecnologías de software para ser capaz de ofrecer las
mejores recomendaciones tecnológicas en
beneficio del proyecto. Sus decisiones tienen
un impacto al corto, mediano y largo plazo.
Características importantes que definen la calidad de la aplicación, como son el desempeño, reuso, robustez, portabilidad, flexibilidad,
escalabilidad y mantenibilidad dependen en
gran medida de las decisiones que tome. Incluso generan un impacto directo sobre la economía del proyecto, pues debería de ser capaz
de sacarle el máximo provecho a la tecnología
existente, en especial cuando ésta representa una restricción del proyecto, como ocurre
cuando el cliente no se puede dar el lujo de
invertir en nuevo equipo o tecnología adicional al que ya tiene.
Dominio.- Sus decisiones sobre la estructura y dinámica de la aplicación son plasmadas en notación formal. Para hacer esto los
arquitectos modernos requieren dominar
UML, sobre todo si piensan usar nuevas tecnologías y en especial aquellas orientadas a
objetos. A pesar de esto, no creerían la cantidad de alumnos que han llegado a nuestros cursos a aprender UML, creyendo ser
“arquitectos de software”, cuando les falta
algo tan básico como el dominio de dicha
nomenclatura. Claro que no hay que culparlos, ya que existe un desconocimiento
generalizado acerca del perfil de dicho rol.
El conocimiento y experiencia del arquitecto
moderno pueden resumirse en los siguientes puntos:
1. UML y el uso de por lo menos una herramienta de modelado.
2. Análisis, Diseño y Programación Orientada a Objetos.
3. Ventajas, desventajas y particularidades
entre los principales lenguajes y tecnologías
disponibles: Java, C#, .Net, J2EE, etc.
4. Bases de datos.
5. Desarrollo basado en componentes.
6. Patrones de diseño.
7. Patrones de arquitectura.
8. Estilos de arquitectura.
9. Frameworks.
10. Nuevas tecnologías y plataformas, incluyendo open source.
11. Conocimientos del hardware y
sus capacidades.
12. Procesos de desarrollo de software modernos, como el Proceso Unificado.
Es importante notar que los arquitectos no construyen sus planos desde cero, sino que aprovechan el conocimiento y experiencia de otros,
plasmado en patrones y frameworks.
Habilidades.- Además de este conocimiento, requiere contar con habilidades como las
siguientes:
• Capacidad de abstracción, creatividad, liderazgo, comunicación oral y escrita; negociación, disciplina y ser autodidacta.
Si usted cumple con todos estos requisitos,
probablemente ya es, o está muy cerca de
convertirse en un arquitecto de software.
Después de ver todo lo que se requiere, podemos entender porqué el programador se
puede ver tentado a seguir “el lado oscuro de
la fuerza” en lugar de seguir esta carrera.
Sergio Orozco es director general, consultor e instructor senior de Milestone Consulting, certificado en UML por la OMG. Carlos Macías es arquitecto en jefe, consultor e instructor senior de la misma empresa. Milestone Consulting es la primer empresa mexicana miembro de la OMG, especializada en servicios relacionados con UML: capacitación,
consultoría y distribución de herramientas de modelado con dicho estándar.
[email protected] / www.milestone.com.mx
56
JUL-AGO 2005
Año 01 No. 04
SOFTWARE GURU CONOCIMIENTO EN PRÁCTICA
Julio-Agosto 2005

JUL-AGO 2005

Transcription

Similar documents

Descargar PDF - Dexon Software

prepas a detalle

BPM - Software AG

Facultad de Informática

ENE-FEB 2006

Introducción a BPM

T3: Introducción a la Inteligencia de Negocios con Técnicas de la

proyecto fin de carrera - Universidad Autónoma de Madrid

Análisis cuantitativo del terrorismo internacional en Europa

Descargar Abstracts - Conferencia Visio 2016