El papel central de los procesos en la ingeniería de negocios
y en el desarrollo de software
Por Jaime González [ acerca del autor ]

Resumen: El Proceso Unificado (UP, por sus siglas en inglés) propone ciclos de vida ágiles y modernos, los cuales podrían ser aplicables tanto a proyectos de software como a proyectos de ingeniería de negocios. Para lograr que este modelo sea totalmente aplicable al diseño o rediseño de procesos de negocios, es necesario superar uno de los dogmas centrales del UP; es decir, el que el proceso está dirigido por casos de uso, que son artefactos con un fuerte enfoque informático. Es necesario admitir que el papel central lo deben jugar los procesos de negocio, y no los casos de uso. 

En otras secciones de nuestro manual, ya hemos explicado la importancia de considerar la transformación de los requerimientos en un producto como un proceso (véase, por ejemplo, la sección titulada “RUP”, bajo “Temas específicos”).

En resumen, y para retomar el hilo de la idea: Trabajar más duro no es la mejor respuesta ante los retos que nos presentan los proyectos, sino más bien se trata de enfocarse en el proceso para trabajar más inteligentemente.

El proceso de ingeniería es el marco que nos permite definir qué se va a producir, cómo se va a producir (es decir, los procedimientos, las técnicas y sus entregables), quién o quiénes (los roles, papeles o responsabilidades que se requieren), bajo qué políticas, y que nos da los elementos para cuantificar el cuándo y los cuántos.

Toda organización de desarrollo de software y de ingeniería de negocios cuenta con uno o varios procesos como el que hemos descrito, ya sea que lo practique informalmente (es decir, que no haya una política establecida sobre dicho proceso), o bien que lo tenga claramente definido y que los participantes de dicha organización cuenten con una capacitación formal en el mismo.  

El UP es quizás el modelo de procesos de software más extendido y conocido en la actualidad. A diferencia de RUP®, que es propiedad de IBM Corp., el UP es una versión libre y abierta del modelo propuesto por Jacobson, Booch y Rumbaugh (también conocidos como los tres amigos) en su libro El proceso unificado de desarrollo de software, publicado por Addisson-Wesley en 1999.

En otras palabras, es perfectamente posible definir el proceso de ingeniería de una organización sobre la base del UP, sin tener que pagar derechos. 

Existen, por supuesto, otros modelos de procesos de ingeniería, como son (por citar sólo algunos ejemplos) Extreme Programming, CrystalClear, Iconix, Adaptive Software Development, Microsoft Development Framework. Debido al grado de aceptación que ha logrado el UP, y dada las experiencias exitosas que hemos obtenido con éste en proyectos de software y de ingeniería de negocios, vamos a centrar el presente artículo en una interpretación ágil de este modelo.

La adecuación del proceso para cada proyecto

No es necesario que una organización defina su proceso de ingeniería “de un jalón”, o que tenga que producir grandes volúmenes de texto para formalizar sus políticas, procedimientos, técnicas, y demás artefactos. En la presente sección del manual, partimos del supuesto que, inicialmente, es mejor que la organización tenga bien definidas y comprendidas unas cuantas técnicas y definiciones, en lugar de tener mal definido e incomprendido un proceso completo. Los modelos más serios, como RUP y el UP, se han venido desarrollando durante muchos años, por lo cual padecen de enormidad y de una curva de aprendizaje muy pronunciada. Una mala comprensión de la utilidad de estos modelos puede llevar a la producción excesiva de entregables y a la parálisis por análisis: más de un proyecto se ha quedado pasmado en la producción de todo tipo de diagramas y entregables, sin poder avanzar hacia la producción del entregable principal. De ahí que estemos poniendo el acento en la agilidad del proceso.

Otra consideración muy importante consiste en que cada proyecto tiene sus peculiaridades, y que es indispensable adaptar el proceso conforme a sus necesidades y características: las metas fundamentales de cualquier proyecto consisten en satisfacer los objetivos primarios de la empresa o institución, así como la satisfacción de los requerimientos de las áreas interesadas. Por lo tanto, cualquier consideración académica o rigorista debe quedar subordinada a estos objetivos primarios.

Comparemos lo anterior con las características principales tradicionalmente
definidas para el UP:

• Está dirigido por casos de uso (véase la sección sobre UML).
• Está centrado en la arquitectura; es decir, que se enfoca a proporcionar una solución harmónica, económica y de conjunto.
• Tiene un ciclo de vida iterativo incremental; es decir, que el proyecto avanza mediante esfuerzos concentrados que pueden durar desde un par de semanas hasta un par de meses, después de los cuales obtenemos la aprobación, o bien la retroalimentación, de las áreas interesadas.

Salta a la vista, pues, una corrección necesaria: a la primera de las anteriores características fundamentales del UP: el proceso de ingeniería debe ser dirigido por los procesos de negocios (o, en su caso, por los procesos institucionales). En otras palabras, los casos de uso, si se llegaran a utilizar, deberán derivarse y quedar subordinados a los procesos de negocios.  

Con este ajuste de prioridades, no sólo logramos que el modelo del UP sea totalmente aprovechable para la ingeniería de negocios, sino también el que podamos ampliar nuestra visión más allá de consideraciones informáticas. 
El ciclo de vida del Proceso Unificado está sintetizado en la siguiente ilustración.

Se puede observar, claramente, que la modificación propuesta no afecta ni las disciplinas del UP ni el ciclo de vida del proyecto; es decir, que no afecta ni las técnicas, ni los procedimientos. Simplemente se trata de poner los objetivos y procesos institucionales o de negocios en el lugar que les corresponde.

Temas relacionados:
Curso de Análisis y Diseño Orientado a Objetos con UML
Curso de administración de proyectos con CMMI 2, El Proceso Unificado y UML