CAPITULO 2

CICLO DE VIDA GENÉRICO DEL MODELO Y APLICACIONES

1. CICLO DE VIDA BPM.

Por lo general los modelos de BPM son muy simples o muy complejos. Si son muy simples,
contienen sólo procedimientos banales y sirven a lo más para presentaciones de maketing.
Mientras que si son modelos muy complejos tratan de captar todas las ocurrencias y
eventualidades, amarrando u obligando al usuario en un plan de trabajo demasiado intensivo,
que generalmente no es aplicable en la práctica. Por otra parte, si no contamos con ningún
modelo nos faltaría una carta de navegación para orientarnos en nuestros proyectos de BPM.
A continuación presentamos un modelo que representa el ciclo de BPM, ni muy simple ni muy
sofisticado pero que ha dado muy buenos resultados en la práctica. Figura 1: El ciclo de BPM

El ciclo está pensado para ser aplicado para cada proceso por separado o en forma
independiente.

Cada proceso puede encontrarse en un estado diferente del ciclo. El ciclo comienza a partir de
dos posibles constelaciones:

• Un proceso actual que debe levantarse y documentarse y/o rediseñarse.

• Introducir un nuevo proceso, no existente en la organización.

FASES:

1.- Levantamiento del Proceso, primero se debe recoger la información sobre cómo está
organizado el flujo de trabajo. Esto se realiza con la ayuda de técnicas de moderación, talleres,
entrevistas, recolección de documentación, etc. Para esto en el proceso a levantar se debe:

• Delimitar claramente de procesos anteriores o posteriores.

• Describir los servicios que produce para los clientes y qué prioridad tiene desde el
punto de vista de los objetivos empresariales
• Representar tanto el flujo de trabajo como los roles que intervienen en cada uno de
los paso, los recursos que se utilizan y los sistemas de información que lo apoyan.

2.- Documentación del Proceso, el conocimiento adquirido en la etapa de levantamiento se

documenta en un modelo de procesos que refleja la situación actual. La documentación
resultante comprende los diagramas de los flujos, fichas de descripción, políticas de negocio y
procedimientos que se utilizan para ejecutar el trabajo.

3.- Análisis de Mejora, o las desviaciones que muestra el “Monitoreo del Proceso” son por
lo general el punto de partida para un rediseño de procesos. Eventualmente, se pueden
evaluar diferentes variantes o escenarios con ayuda de simuladores. Esto aplica también si se
está diseñando un proceso nuevo. En ambos casos el resultado o entregable es un modelo de
procesos deseado (To be).
4.- Implementación del Proceso, abarca tanto la implementación técnica como también las
adaptaciones organizacionales que se requieren. La gestión del cambio (en inglés: Change
Management) y la estrategia de comunicación constituyen elementos fundamentales a
considerar para el éxito del proyecto.

El modelo técnico puede implementarse por medio de un Process Engine o una Suite de BPM
(en inglés: Business Process Management Suite, BPMS) o a través de un clásico desarrollo de
software. El resultado final de la implementación técnica del proceso en la situación actual (As
is) automatizado y documentado, corresponde con el modelo de proceso deseado (To be).

En la literatura y en el mercado se utilizan varios términos para sistemas que implementan

procesos: sistema de workflow (WfM), Business Process Management Suite (BPMS), motor de
workflow y Process Engine. De ahora en adelante vamos a utilizar preferéntemente el término
Process Engine en forma genérica que en la práctica puede ser cualquiera de ellos. Por lo
general la Suite de BPM (BPMS) es el sistema más completo que trae todas las componentes
integradas (modelador técnico, motor de workflow, panel de control, interfaz de usuario, APIS
de integración y en algunos casos Enterprise Service Bus (ESB). Las fases desde el
“Levantamiento del Proceso” hasta la “Implementación del Proceso” se administran por lo
general por medio de la organización de un proyecto.

5.- Monitoreo del Proceso, se concibe como un proceso continuo y forma parte de todas las
operaciones. Las actividades más importantes de Monitoreo del Proceso son:

• El control constante de las operaciones (técnicamente hablamos del control de

instancias de los procesos reales).
• Evaluación de los indicadores.

De acuerdo a la escuela de BPM, si se detectan problemas puntuales debieran corregirse de

inmediato o en línea. Si hay recursos disponibles es posible solucionar problemas estructurales
sin necesidad de formular un proyecto, pero si sus causas no están claras o son complejas, se
hace necesario planificar e implementar un proyecto de mejora y rediseño. La decisión sobre si
es necesario formular un proyecto nuevo o instalar un equipo de trabajo en operaciones,
debiera tomarla el responsable del proceso de común acuerdo con los participantes.

Con esta breve explicación de cómo funciona el ciclo de BPM, el lector se dará cuenta de la
importancia que tienen los modelos de procesos en BPM y junto a ello la importancia que
puede adquirir un estándar de modelamiento como BPMN. Se puede constatar también que el
modelamiento de procesos no es una etapa del ciclo de BPM, sino que es más bien una
actividad transversal, porque de facto se aplica en todas las fases del ciclo, sobre todo en las
fases de “Documentación del Proceso”, “Diseño As is” y “Diseño To be”.

Desgraciadamente, siempre nos volvemos a encontrar con gente que confunden la

“Documentación del Proceso” con el modelamiento del proceso y lo incluyen como una fase
en el ciclo; esto es una equivocación.

El ciclo BPM muestra en sus principales fases cómo funciona el círculo virtuoso de mejora
continua de los procesos. Para aplicarlo es necesario:
 • Asignar responsabilidades a los procesos y a cada uno de sus pasos
• Emplear métodos de análisis y gestión en él.
• Contar con el apoyo de soluciones adecuadas de TI

Lograr una coordinación fluida entre estas tres componentes es tarea de gestión por procesos
(BPM-Governance). Gestión por procesos se encuentra por sobre cualquier proyecto de BPM y
tiene por consiguiente la misión de introducir la “Gestión por Procesos de Mejora Continua”.

El primer objetivo de BPMN fue desarrollar una notación gráfica que permitiera automatizar en
forma más rápida los procesos. Esta es la razón del porque se tiene que entender los
fundamentos de TI si quiere diseñar buenos modelos en BPMN. Si ha logrado entender los
conceptos detrás de BPMN, habrá construido fundamentos sólidos para diseñar buenos
modelos y de esta forma poder cerrar la brecha entre la capa de negocio y la capa de TI.

2. CICLO DE VIDA DE LAS APLICACIONES. Las principales diferencias entre distintos modelos de
ciclo de vida están divididas en tres grandes visiones:

• El alcance del ciclo de vida, que depende de hasta dónde deseamos llegar con el proyecto:
sólo saber si es viable el desarrollo de un producto, el desarrollo completo o el desarrollo
completo más las actualizaciones y el mantenimiento.

• La cualidad y cantidad de las etapas en que dividiremos el ciclo de vida: según el ciclo de vida
que adoptemos, y el proyecto para el cual lo adoptemos.

• La estructura y la sucesión de las etapas, si hay realimentación entre ellas, y si tenemos

libertad de repetirlas (iterar).

En los distintos modelos de ciclo de vida mencionaremos el riesgo que suponemos aceptar al
elegirlo. Cuando hablamos de riesgo, nos referimos a la probabilidad que tendremos de volver
a retomar una de las etapas anteriores, perdiendo tiempo, dinero y esfuerzo.

2.1. Modelo Lineal.- Es el más sencillo de todos los modelos. Consiste en descomponer la
actividad global del proyecto en etapas separadas que son realizadas de manera lineal, es
decir, cada etapa se realiza una sola vez, a continuación de la etapa anterior y antes de la
etapa siguiente. Con un ciclo de vida lineal es muy fácil dividir las tareas, y prever los tiempos
(sumando linealmente los de cada etapa). Las actividades de cada una de las etapas
mencionadas deben ser independientes entre sí, es decir, que es condición primordial que no
haya retroalimentación entre ellas, aunque sí pueden admitirse ciertos supuestos de
realimentación correctiva. Desde el punto de vista de la gestión, requiere también que se
conozca desde el primer momento, con excesiva rigidez, lo que va a ocurrir en cada una de las
distintas etapas antes de comenzarla. Este último minimiza, también, las posibilidades de
errores durante la codificación y reduce al mínimo la necesidad de requerir información del
cliente o del usuario.

2.2. Modelo en Cascada.- Propiciado por Winston Royce en 1970, sugiere un enfoque
sistemático y secuencial, disciplinado y basado en análisis, diseño, pruebas y mantenimiento.
Al final de cada etapa se reúnen y revisan los documentos para garantizar que se cumplen los
requerimientos antes de avanzar a la fase siguiente (Garcés & Egas, 2015). Pionero en guiar el
proceso de Desarrollo de Software dirigido por un plan, introduciendo una planificación de
cada fase antes de empezar a trabajar en ella.

2.3. Modelo de Cascada en “V”.- Propuesto por Alan Davis a principios de los 90. Se base en el
modelo en cascada con la innovación de procurar actividades de pruebas más efectivas y
productivas mediante la introducción de validaciones en la medida en que se avanza en el
proyecto; dado que en el modelo tradicional las pruebas se introducían al final los defectos
aparecían en forma tardía. Las pruebas necesitan empezarse lo más pronto posible en el ciclo
de vida y estas actividades deberían ser llevadas a cabo en paralelo con las actividades de
desarrollo. (Sáez, Rodríguez, Villanueva & Cueto, 2014).

2.4. Modelo de Desarrollo Incremental.- Harlan Mills en el año 1980. Se basa en el desarrollo
a partir del incremento de la funcionabilidad del programa, se puede considerar un precursor
de las modernas metodologías iterativas. El primer incremento es a menudo un desarrollo
esencial, apenas con los requisitos básicos, cada incremento representa una entrega escalable.
Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al
usuario la funcionalidad. (Sáenz et al, 2014).

2.5. Modelo de desarrollo evolutivo (espiral).- Propuesto por Barry Boehm en 1986, en su
artículo “A Spiral Model of Software Development and Enhancement” (Patpondo, 2010).
Conjuga una naturaleza iterativa en la construcción de prototipos con aspectos controlados y
sistemáticos del modelo en cascada. (Cendejas, 2014.) Cuando se aplica este modelo en
espiral, el software se desarrolla en una serie de entregas evolutivas. Cada una de las
actividades del marco de trabajo representan un segmento de la ruta del espiral. En cada ciclo
repetitivo va ganando madurez el producto final.

2.6. Modelo prototipo evolutivo.- Modelo iterativo a través del cual es posible identificar los
requerimientos del cliente mediante la construcción de un prototipo de funcionalidad
simulada; si no se ajusta a la expectativa del cliente, se construye otro prototipo con una
definición mejorada, el diseño va evolucionando ajustándose cada vez más al requerimiento,
aunque su funcionalidad será simulada hasta tanto se aclaran la totalidad de los
requerimientos con la validación del último prototipo. (Cervantes & Gómez, 2012.)

2.7. Modelo de desarrollo basado en Componentes.- Según Pérez (2011) los marcos
tradicionales imponen una planificación rígida y meticulosa del proyecto, soportada por
herramientas y una carga de trabajo pesada en planificación, diseño y documentación, en un
afán por hacer al desarrollo predecible dentro de un marco de temporalidad y costo;
recordando que derivan de solventar los problemas de la crisis del software vivida décadas
atrás. Las más difundidas y citadas en textos son: Rapid Application Development (RAD),
Rational Unified Process (RUP) y Microsoft Solution Framework (MSF).

• Rapid Application Development (RAD).- O desarrollo rápido de aplicaciones,

presentado por James Martin desde 1980, formalmente documentada en su libro con
ese mismo nombre en 1991. La metodología se centra en una lista de tareas y una
estructura de desglose del trabajo orientada a la rapidez, aunque no está alineada al
“manifiesto ágil” si buscó responder a la necesidad de agilizar las entregas de
aplicaciones. Comprende el desarrollo bajo un modelo iterativo, la construcción de
 prototipos y el uso de utilidades CASE (Computer Aided Software Engineering) esto es,
aplicaciones informáticas dirigidas a aumentar la productividad en todos los aspectos
del ciclo de desarrollo (Garcés & Egas, 2015).
 Rational Unified Process (RUP).- Propuesta en 1998 por Ivar Jacobson, Grady Booch y
James Rumbaugh. (Pérez, 2011). Metodología basada en los modelos en Cascada y por
Componentes. Presenta las siguientes características: Es dirigido por “casos de uso”
esto es, la descripción del servicio que el usuario requiere del sistema y la secuencia de
iteraciones usuario-sistema; se centra en la arquitectura, dicta pautas específicas para
la constitución del equipo y las escalas de tiempo, es iterativa e incremental. Es una de
las metodologías clásicas vigentes y más usadas para el análisis, desarrollo y
documentación de sistemas orientados a objetos, muy aplicada en proyectos de gran
complejidad y magnitud con apoyo de equipos expertos, desde sus inicios ha contado
con respaldo por parte de IBM. (ob. Cit.)
 Microsoft Solution Framework (MSF).- Pérez (2011) señala que fue introducida por
primera vez en 1994 como un conjunto de las mejores prácticas (principios, modelos,
disciplinas, conceptos y directrices) en los desarrollos de Software de Microsoft y
Microsoft Consulting Service. Es flexible, permite aplicar de manera individual e
independiente cada uno de sus componentes, es escalable según la magnitud del
proyecto; fundamentada en los modelos espiral y cascada. Profesa la aplicación de 8
principios fundamentales para una mejor organización del trabajo; modelos o
esquemas para la organización de los equipos y disciplinas de gestión. (ob. Cit.).

2.8. Metodologías Ágiles.- Qué duda cabe, los avances tecnológicos y las dinámicas exigentes
de los mercados, han incentivado la aparición de nuevos métodos de gestión de procesos, los
cuales buscan optimizar el rendimiento y los resultados de los mismos. Los métodos
tradicionales, provenientes casi todos de sistemas funcionalistas, alguien da órdenes y otros
las cumplen, o demasiado jerarquizados, no son suficientes dentro del escenario actual. Entre
otras cosas, porque la velocidad de los procesos ha cambiado notablemente y se precisan
herramientas más efectivas. De ahí que, bajo el término de «metodologías ágiles», desde hace
unos años para acá hayan aparecido numerosas estrategias de gestión de procesos. Son
múltiples, variadas y con la posibilidad de adaptarse a cada caso. Tal como su nombre lo indica,
se trata de herramientas basadas en la respuesta rápida y la intervención progresiva de los
procesos, los cuales antes estaban supeditados a la entrega final. Era en ese único momento
cuando se realizaban las mejoras oportunas, aunque con costes más elevados y resultados
menos óptimos.

Las metodologías ágiles no son, desde luego, un certificado de inmunidad de cara a la gestión
de procesos. No evita los fallos ni los contratiempos. Sin embargo, ayudan a los equipos de
trabajo a estar mejor preparados en el momento de afrontarlos. Veamos las herramientas
ágiles más empleadas en la actualidad:

 Extreme Programming (xp) Propuesta por Kent Beck, en su trabajo fundamental que
publicó en 1999 buscando guiar a equipos de desarrollo de software pequeños, entre
dos y diez desarrolladores, en ambientes de requerimientos imprecisos o cambiantes.
(Cadavid et al. 2013). Cinco valores fundamentan sus principios: Simplicidad,
Comunicación, Retroalimentación, Respeto y Coraje. Sus postulados o principios son:
 Retroalimentación rápida, asumir simplicidad, el cambio incremental, la aceptación del
cambio y el trabajo de calidad.
 Scrum. Su nombre no es una sigla, sino un término deportivo aplicable al rugby. Su
primera referencia en el contexto de desarrollo data de 1986; utiliza un enfoque
incremental que tiene como fundamento la teoría de control empírico de procesos.
Los llamados Equipos Scrum son autogestionados, multifuncionales y trabajan en
iteraciones. Define tres roles: el “Scrum master”, líder del equipo y de la
implementación de la filosofía, mas no del desarrollo; el dueño del producto y el
equipo de desarrollo. El “dueño del producto” que representa a los interesados y vela
por la maximización del valor del entregable y “el equipo de desarrollo” responsables
de convertir los requerimientos del cliente en iteraciones funcionales del producto.
(Cadavid et al. 2013). La terminología Scrum define un evento temporal conocido
como “Sprint” con una duración máxima de un mes en el que debe crearse una versión
utilizable del producto. Cada Sprint cumple con los siguientes elementos: reunión de
planeación, Daily Scrum, trabajo de desarrollo, revisión del Sprint y retrospectiva del
Sprint. La terminología también involucra “Artefactos de Scrum.” Estos son
subproductos de las actividades de la metodología que le brindan dirección y
transparencia al equipo son: Backlog del producto, Backlog del sprint, Monitoreo de
Progreso e Incremento. (ob. Cit.) Toda esta terminología se esquematiza en la
siguiente imagen.