Procesos basados en UML - algo es mejor que nada

¡Estoy harto de los procesos y estándares de desarrollo! Ese suele ser el grito desesperado de muchos responsables de organizaciones de software que han intentado formalizar sus procesos con resultados poco eficientes.

Y no es para menos, pues muchas veces la experiencia de los “gurús” que los asesoran en la mejora de sus procesos se reduce a lo que aprendieron en libros o cursos y no a la realidad de los proyectos. No es un secreto que no necesariamente lo que dicen los libros es lo que aplica para todas las organizaciones.

El caso de UML entra en esta categoría de estándares incomprendidos. Y es que intentar usar todo UML, simplemente porque aprendiste cuáles son los diagramas que lo conforman, no es precisamente el camino que te llevará a obtener los mejores resultados. Recuerda que UML no es el proceso, sino que es una notación que puedes utilizar parcial o totalmente en tu proceso.


Selección de Artefactos

La experiencia nos ha demostrado que muchas veces es necesario seleccionar un mínimo indispensable de artefactos a desarrollar durante un proyecto. Los clientes quieren calidad, pero también necesitan eficiencia. Los recursos son limitados, y sabemos que un proceso mal utilizado puede traer resultados contraproducentes en este sentido.

El mal uso de UML puede ser una causa para esta frustración por parte de los desarrolladores y un motivo de decepción en el uso de procesos formales. Así que muchas veces conviene aplicar la filosofía de KISS (“Keep it Simple, Stupid” o “Keep it Short and Simple”).

Si vas a usar un diagrama de UML asegúrate de obtener un beneficio en tu proyecto, o mejor no lo uses. Y si tienes una limitante importante de tiempos y recursos, es mejor que elijas el mínimo indispensable para poder obtener beneficios de un estándar, pero sin agregarle costos que no puedes absorber por las restricciones del proyecto.

A continuación intentaremos esquematizar diferentes variantes de procesos, en cuanto a la selección de artefactos de UML que utilizan, Desde uno muy simple hasta otro medianamente elaborado.
Imagina que tu forma de desarrollar consiste en entrevistarte con el usuario y después programar; actividades elementales que no podrían desaparecer. La pregunta que trataré de responder es: ¿qué agrego (de UML) en medio de esas dos actividades?

Proceso A. El Más SImple: Requerimientos, el Principio de Todo

Si actualmente tu proceso consiste en entrevistar a tus usuarios y con base en dicha información comienzas a programar de inmediato, entonces mi recomendación es que por lo menos agregues casos de uso a tu proceso (diagramas y especificaciones de casos de uso).
Básate en estos para planear, para repartir el trabajo, para cotizar, para desarrollar, así como para planear y diseñar tus pruebas. Verás que este simple cambio será un cambio drástico y sumamente beneficioso en los resultados de tus proyectos.


Proceso B. El Sencillo: Requerimientos y Diseño.

Si estás un poco menos limitado de tiempo (y de motivación) como para formalizar un poco más las tareas de tu proyecto entonces aprovecha los beneficios de otro artefacto básico de UML: el diagrama de clases.

Si puedes utilizarlo con un enfoque de análisis primero (modelo de dominio) y después refinarlo para convertirlo en tu modelo de diseño, sería ideal. De esta forma obtendrás beneficios al tratar de comprender los requerimientos y el dominio, así como en las decisiones respecto a cómo construir una aplicación orientada a objetos.

Pero, si consideras que no tienes tiempo de usarlo con los dos enfoques mencionados entonces por lo menos úsalo para realizar el diseño de tu aplicación. Considera que no necesariamente tienes que desarrollar el diagrama de clases completo antes de comenzar con la programación, seguramente identificarás nuevas clases al comenzar con dicha actividad que podrás reflejar posteriormente en tu modelo.

Proceso C. El Intermedio: Requerimientos, Análisis y Diseño

El proceso anterior inicia el camino a la formalización en requerimientos, análisis y diseño. Eso ya es ganancia para la mayoría de los equipos de desarrollo, en los que el valor lo concentran exclusivamente en la programación y no en el resto de las actividades del proyecto.
La siguiente recomendación para mejorar tu proceso consiste en refinar tus actividades de análisis y diseño. Para lograrlo te recomiendo el diagrama de secuencia (en su lugar puedes usar el de comunicación).

Una vez identificado tu modelo de dominio, aprovéchalo y basándote en los flujos de tus casos de uso modela las interacciones entre las clases. Modelar las interacciones te permitirá tomar mejores de decisiones de diseño. El beneficio será el desarrollo de una mejor aplicación.
Una advertencia: no intentes desarrollar los diagramas de secuencia para todos y cada uno de tus casos de uso.

En general considero que sólo es indispensable para aquellos casos de uso más críticos y complejos. Usa la regla del 20-80 y utilízalo para modelar el 20% de tus casos de uso; los más complejos e importantes. Si modelas las interacciones de todos tus casos de uso tendrás que invertirle tiempo valioso que podrías estar aprovechando en otro tipo de actividades del proyecto.

Casos Especiales: ¿Cómo es tu Sistema?

Los 3 ejemplos anteriores de procesos pueden ser suficientes para muchos de los proyectos que suelen desarrollarse. Pero, adicional a estos puedes agregar otro tipo de artefactos, dependiendo de las características del proyecto.

Hazte preguntas como las siguientes: ¿Tu proyecto va a requerir control de documentos o productos? ¿Es un sistema distribuído? ¿Estás automatizando un proceso de negocio complejo?

Dependiendo de estas condiciones es recomendable utilizar artefactos adicionales de UML que te darán una perspectiva diferente, pero necesaria, para comprender mejor y tomar decisiones apropiadas para la construcción de tu proyecto.

A continuación se mencionan posibles artefactos de UML que podría convenir agregar en condiciones especiales.

1. Sistemas de Control

Para cierto tipo de sistemas es bastante recomendable agregar el diagrama de estados. Por ejemplo en aquellos sistemas en los que tienes que controlar y monitorear el estado por el que va un cierto documento o producto dentro del proceso de negocio que estas automatizando. O para aquellos sistemas de control que automatizan dispositivos electrónicos, como un refrigerador, un elevador o un despachador automático de refrescos.

2. Sistemas Distribuidos

Si tu sistema va a construirse de manera distribuida, es decir, parte de la funcionalidad va a correr en una máquina y parte en otra. O si estás pensando construir partes reutilizables, entonces te recomiendo que utilices el diagrama de componentes y el diagrama de despliegue. Estos permitirán especificar dónde repartirás cada “parte” del sistema. Estos diagramas corresponden a la disciplina de diseño.

3. Negocios Complejos

Si tu proyecto va a desarrollarse para automatizar un proceso complejo de tu usuario, entonces te recomiendo que aproveches los diagramas de actividades. En un caso muy sofisticado puedes usar los diagramas de procesos de negocios del estándar BPMN, pero asegúrate de aprender bien ese nuevo estándar antes de decidir utilizarlo.

Buscando lo Simple en la Complejidad

UML ha ido evolucionando en algo que no necesariamente cumple, a decir de algunos, con uno de los objetivos originales de dicho estándar: el de mantener la simplicidad. Por lo tanto, es importante comprender que no necesariamente aplican todos los artefactos y elementos para tus proyectos para lograr la simplicidad en tu trabajo al utilizar esta notación.

Este artículo no pretende de ninguna manera ser “LA guía definitiva”, pero estoy seguro que a algunas personas les facilitará el trabajo a la hora de decidir respecto a la formalización de sus procesos de software, con respecto a la elección de los artefactos de dicho estándar. De hecho hay otros artefactos de UML que no están considerados aquí, por corresponder a los menos utilizados.

Vale la pena notar que en este artículo ni siquiera estoy recomendando un ciclo de vida; ya sea de cascada, iterativo, o cualquier otro. En general, podrías utilizar cualquiera de los subconjuntos de artefactos mencionados independientemente del ciclo de vida que utilices.
Espero que saques algún provecho de este artículo y recuerda que “mucho no necesariamente significa mejor”. Hasta la próxima y suerte con tus modelos.

Ver más artículos

PMI, PMI-RMP, PMI-SP, PMBOK, OPM3, CAPM y PMP son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. MDA, BPMN, SysML, MOF, OMG y UML son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP es una marca registrada por IBM Corp.

Póliza Abiztar Plus

Descubre aquí todos los beneficios de La Póliza Abiztar Plus.

Garantía Universal

Los ambientes ubicuos de aprendizaje Abiztar, incluyen Garantía Universal. ¿Qué es esto?

Información general
Conoce la Póliza Abiztar Plus
Recomendaciones de capacitación
Calendario de cursos

Base de conocimiento
UML y Arquitecturas
Administración de Proyectos
Procesos de Software
Artículos

Contáctanos

Teléfono en México D.F. - +52 (55) 5594 6411 / E-mail: cursos@abiztar.com.mx

O si lo prefieres llena el formulario de contacto

Ver aviso de privacidad

© Abiztar. PMI, PMBOK Guide, OPM3, CAPM, PMP, PMI-SP y PMI-RMP son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. Capability Maturity Model y CMM son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon. CMM, IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. MDA, BPMN, SysML, MOF, OMG y UML son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP es una marca registrada por IBM Corp."