Lectura Fundamental Anterior: “De Procesos y de Humanos” Lectura # 7
RUP o Todo lo que quisiste saber alguna vez de RUP y no te atreviste a preguntar…
RUP es un proceso punto.
¿Hace falta decir algo más? Sí, todo. Aquí vamos.
RUP es un proceso y una metodología y un framework. RUP nos habla de actividades, de responsables, de procedimientos de trabajo, de casos de uso, de arquitectura del software, de iteraciones e incrementos, de riesgos, de modelos y de modelado con UML, de análisis y diseño del software, de pruebas y control de calidad; RUP también nos habla de guías y listas de chequeo, de herramientas del proceso (no software no hardware), de herramientas de software para apoyar el proceso; y también de gerencia de proyectos, de control de versiones, de configuración y adaptación del proceso, de prácticas contextuales; RUP nos cuenta los porqué de las cosas o, al menos, hace un recuento de la experiencia de otros; RUP tiene dinámica y tiene estática; RUP proporciona mecanismos para que hagamos mejor nuestro trabajo y nos lleva de la mano hacia el éxito y hacia la calidad total.
Framework, Proceso y Metodología
Esto, por ningún motivo es un uso estándar. En el pasado encontré útil diferenciar
proceso de
metodología como explico a continuación: literalmente, un proceso es un conjunto de pasos para realizar algo, incluyendo quien hace que, cuando y todas esas cosas que expuse en la
Lectura Fundamental #6. Estrictamente hablando, RUP no contiene nada de esto. Los flujos de trabajo y las actividades no están entretejidos en procedimientos específicos organizados en el tiempo. De esta forma, RUP es referenciado como un
framework de procesos que contiene piezas de las cuales se puede escribir un proceso para una organización. Forzosamente, este proceso debería ser configurado para la organización y sus roles específicos, su estructura y sus objetivos, entre otros.
RUP también es una metodología. Esta afirmación quiere decir que RUP es una base teórico-conceptual detallada para hacer las cosas de cierta manera. Es como una enciclopedia. De este modo, cuando un proceso dice “escriba un caso de uso” hay mucha información en RUP sobre como y aún porqué escribir casos de uso.
Usando los términos así, se aclara la confusión en las empresas que hablan de “hacer el proceso” o “tener un proceso” cuando simplemente quieren decir que tienen algunos procedimientos de trabajo. Adoptar una metodología es algo más –significa involucrarse con un
framework conceptual y un conjunto de métodos. Estos métodos entonces necesitan anidarse en procedimientos que concuerden con la organización.
En aquel tiempo también encontré otros dos términos relacionados a los anteriores que debía entender: método y técnica. El primero se refiere a una descripción detallada de quien hace que, cuando y como; se parece mucho a metodología, ni más faltaba, pero hay una diferencia substancial que haré evidente en breve. Mientras tanto, la técnica es mucho más detallada y, por consiguiente, aborda o trata un área muy especializada.
Esto también significa que un framework puede contener varios procesos, un proceso puede contener varios métodos y un método puede contener varias técnicas. Es difícil de decir en que punto se convierte una técnica en método, lo importante es que todos estos conceptos, concluí, es que son parte del mismo cuadro.
Como siempre, hice uso de Mi Gazafatonario para establecer definiciones más semánticas. Este fue el resultado:
Definición 14: Un
framework se refiere a un número de bloques de construcción predefinidos con los cuales es posible configurar un proceso, método, etc.
Definición 15: Un
proceso se refiere a una serie de acciones, cambios o funciones que entregan un resultado (un flujo). Cuando hablamos de RUP, es útil recordar que el proceso es lo que tiene lugar en el “mundo real” mientras que la
descripción del proceso es lo que está documentado en el producto RUP como tal… ¡algunas veces éstas son dos cosas distintas!
Definición 16: una
metodología se refiere al cuerpo completo de prácticas (una práctica es una forma regular y sistemática de realizar alguna cosa), procedimientos y reglas usados por quienes trabajan en una disciplina (por ejemplo en la IT); pero una metodología también se refiere al estudio teórico del análisis de tales métodos de trabajo.
Definición 17: un
método, por otro lado, se refiere a solamente una de esas prácticas.
Definición 18: Una
técnica se refiere al procedimiento sistemático mediante el cual una tarea compleja o científica se lleva a cabo.
Eso era entonces, era feliz e indocumentado y
“el mundo era tan reciente, que muchas cosas carecían de nombre, y para mencionarlas había que señalarlas con el dedo."[1]
Hoy, estos conceptos tienen más vigencia que nunca.
Comentario del Autor
Confieso que a pesar de haber hecho docenas de presentaciones sobre RUP y de haber escrito algunos artículos al respecto, me encontré en una encrucijada al momento de abordar este nuevo volumen de lecturas fundamentales sobre el tema. Los enfoques pueden ser muchos: que si las características, que si las fases, que si las disciplinas, que si las actividades, que si las plantillas, en fin, eran muchas las posibilidades. Por fin inicié como acaban de leer, pero entonces algo, quizás sensato quizás absurdo, pasó por mi mente: acaso la mayoría de ustedes nunca ha tenido una primera vez con RUP. Entonces decidí volver a lo fundamental.
Aquí vamos otra vez.
Raíces
Para lo que nos interesa, RUP es un proceso de Ingeniería de Software que busca asegurar la producción de software de alta calidad, satisfaciendo las necesidades de un cliente (y estoy usando un espectro muy amplio de la palabra “cliente” al abordar desde usuarios finales y a otros involucrados hasta las organizaciones que de una u otra forma se ven impactadas por el software), con un plan y presupuesto previsibles.
Pero también podemos mirar a RUP como un conjunto extenso, en lo horizontal, y profundo, en lo vertical, de experiencias documentadas alrededor de los distintos procesos relacionados con el ciclo de vida de los sistemas. Son prácticas dispuestas es una dimensión estática que establecen estándares probados, en principio, para desarrollar software, a través de una dimensión dinámica: el tiempo. Los procedimientos están enmarcados en procesos, conocidos también como disciplinas o flujos de trabajo: Modelado del Negocio, Administración de Requisitos, Análisis y Diseño, Implementación, Pruebas, Administración de la Configuración y Control de Versiones, Administración del Entorno y, por último pero no menos importante, Gerencia de Proyectos. Entre tanto, el tiempo está dividido en Fases: Inicio, Elaboración, Construcción y Transición. A su vez, cada fase, esta fraccionada en etapas o ciclos pequeños llamados Iteraciones.
A través del tiempo hay que alcanzar hitos o cumplir objetivos, en cada fase y, dentro de ellas, en cada iteración. Para alcanzar esas metas, hay que llevar a cabo las funciones definidas en los distintos procesos que, a su vez, tienen objetivos más específicos. La suma de todos estos propósitos alcanzados resulta precisamente en la finalidad universal de todo proceso y RUP no es la excepción: la construcción de un sistema de software de calidad excelsa.
MetasInicio o
Concepción es la primera fase de RUP. El propósito principal es que alcancemos un acuerdo entre todos los involucrados sobre los objetivos del ciclo de vida para el proyecto. Los involucrados, mejor conocidos como stakeholders, son todas las personas y entidades que de una u otra forma influyen o se ven afectados por el desarrollo del proyecto y por el producto que resulta del proyecto. Ejemplos de involucrados son: usuarios finales, todo el equipo de desarrollo, patrocinadores del proyecto (los productores ejecutivos), socios de negocios, proveedores, clientes, otras áreas de la compañía distintas a aquella para la cual se elabora el software, entre otros.
Al final de la fase de Inicio, revisamos los objetivos del ciclo de vida y decidimos proceder con el proyecto o cancelarlo. Esto último puede ocurrir porque no alcanzamos el hito de la fase o porque, al hacerlo, encontramos que no es posible, tanto técnica como financieramente (y con frecuencia una combinación de ambos factores), continuar con el proyecto.
En particular, durante esta fase elaboramos el modelo del negocio, de ser necesario, y establecemos la visión y el alcance del proyecto, es decir, lo que haremos y lo que no haremos dentro del proyecto; también definimos un plan de manejo de riesgos, lo mismo que diseñamos, implementamos y evaluamos una o más pruebas de concepto arquitectónicas, a criterio del Arquitecto del Software o de los analistas más experimentados del equipo. Estas pruebas se ejecutan para tener la tranquilidad de que distintas estrategias de índole técnica o tecnológica tendrán cabida durante la construcción del software, es decir, es posible realizarlas con éxito. Con todo lo anterior, elaboramos el Plan de Desarrollo de Software o, al menos, una agenda viable para el proyecto que defina tiempos y número de iteraciones potenciales por fase, lo mismo que el talento humano asignado a cada iteración.
Por su parte, el objetivo principal de la fase de
Elaboración es delinear la arquitectura del software y proporcionar una base estable para el grueso del diseño e implementación en la siguiente fase. Pero además de bosquejar la Arquitectura, durante la Elaboración probamos esa arquitectura mediante la implementación de la funcionalidad más significativa (precisamente, la que tiene un mayor impacto en la arquitectura) y una evaluación de los riesgos técnicos del proyecto, es decir, los que tienen que ver con el desempeño esperado, la seguridad, la infraestructura requerida para correr el sistema, la usabilidad y otras restricciones de diseño y del entorno de desarrollo del software. Al final de la Elaboración obtenemos una
arquitectura estable vía prototipos arquitectónicos sucesivos, que se construyen durante cada uno de los ciclos o etapas en los que se divida la fase.
Mas adelante, en la fase de
Construcción, diseñamos, implementamos e integramos el software en su totalidad, basado en la arquitectura prescrita durante Elaboración. En esencia, la Construcción termina con lo que llamamos la versión βeta del producto, listo para someterlo a procedimientos de certificación de calidad. Durante esta fase realizamos pruebas que bien podríamos llamar Pruebas Alfa, completamos la capacidad operacional inicial del sistema y finalizamos la documentación del manual del usuario, cuando hay lugar a ello.
Al final, durante la fase de
Transición, nos aseguramos de tener el software listo para entregar a nuestros usuarios quienes, revisan y aprueban todos los entregables del proyecto.
Por su parte, las
iteraciones, durante las fases de Elaboración y Construcción sobre todo, tienen un único objetivo: la entrega de software ejecutable y su documentación asociada. Aunque tengo mucho por decir sobre el desarrollo iterativo, esta simple premisa, software ejecutable más documentación, encierra un gran significado que debería ser evidente para todos.
Conocer la intención de cada una de las fases del ciclo de vida nos da una idea inicial de las acciones a seguir para alcanzar tales metas. Les hablo de tareas por hacer, procedimientos por ejecutar, los que finalmente nos conducirán al resultado esperado: un producto de notable calidad y valor. Con esto quiero decir que pensamos en actividades antes que en “entregables”.
Estos últimos son consecuencia inmediata de aquellas, son el recipiente que debemos llenar.
Ahora bien, el propósito principal del
Modelado del Negocio gira en torno a entender el problema actual de la organización objetivo e identificar mejoras potenciales; también, evaluar el impacto del cambio organizacional. Esto último debido a que un sistema de software trae un nuevo orden a las cosas, una nueva forma de desempeñar funciones y procedimientos en la organización. En esta disciplina también nos aseguramos de contar con un entendimiento común del negocio para el cual desarrollamos el sistema; y cuando digo común, me refiero a los usuarios, a los desarrolladores y a todos los demás involucrados en el proyecto.
A su vez, la disciplina de
Requisitos establece y mantiene un acuerdo entre nosotros y los usuarios sobre lo que el sistema debe hacer; asimismo, define los límites y proporciona bases para la estimación de costos y tiempos para el desarrollo del sistema. Esta disciplina también aporta lo necesario para planear el contenido técnico de las iteraciones y permite definir una interfase de usuario para el sistema, conduciendo nuestro enfoque hacia las necesidades y metas de los usuarios. Un aspecto importante de este proceso de Requisitos es que expone las prácticas recomendadas para instaurar una buena comunicación con los usuarios y el resto de la organización destino del software.
Me queda bien decir en este punto de la lectura es que a menudo no se conoce donde termina la administración de requisitos y donde comienza el análisis y diseño del sistema. Si bien, el Analista del Sistema interviene en ambos procesos, debemos tener claro los límites de uno y otro, para no exponer a los usuarios a aspectos de corte técnico inherentes al Análisis o al Diseño, o aún a la misma Arquitectura del software. Durante la Ingeniería de Requisitos, el Analista del Sistema tiende a ser un Especificador de Requisitos; mientras tanto, durante el Análisis y Diseño, ese mismo Analista tiende a ser un Diseñador y, quizás, un Arquitecto.
Precisamente, el propósito de
Análisis y Diseño es transformar los requisitos en un diseño del sistema a construir, adaptar ese diseño para que concuerde con el entorno de implementación teniendo en cuenta, entre otros, factores de desempeño y de usabilidad; Y es también este proceso el que nos ayuda a determinar una arquitectura robusta que albergue el sistema.
Importante es que la línea divisoria entre el Análisis y el Diseño del sistema es bastante tenue pero a la vez bien definitoria. Durante el análisis definimos una arquitectura candidata, ejecutamos una síntesis arquitectónica y analizamos el comportamiento del sistema; en tanto que en diseño, diseñamos componentes, base de datos y servicios, y hasta encontramos una actividad llamada Diseñar Casos de Uso, donde exhibimos todos los aspectos técnicos propios de un caso de uso.
Después del diseño está la
Implementación, cuya finalidad es que podamos definir la organización del código, en términos de subsistemas de implementación organizados en capas. Es en este proceso donde convertimos los elementos de diseño en elementos de implementación (archivos fuentes, binarios, programas ejecutables, entre otros); también aquí probamos como unidades los componentes desarrollados e integramos e un sistema ejecutable los resultados producidos por cada uno de nuestros programadores.
Quiero enfatizar en lo de pruebas unitarias o pruebas de unidad. Éstas son ejecutadas por el
Implementador, precisamente para verificar tanto la especificación como la estructura interna de una unidad de código, una clase, por ejemplo. Al validar que el componente está trabajando correctamente antes de someterlo a pruebas más formales, estamos asegurándonos de que la transición del código fuente al sistema ejecutable integrado será llevadera. Así como las pruebas hacen parte intrínseca y básica del desarrollo del software, las pruebas de unidad son congénitas a la implementación.
Ya que hablo de
Pruebas, esta disciplina, que actúa como un proveedor de servicios a las demás disciplinas de RUP, nos permite enfocarnos en evaluar y valorar la
Calidad del Producto mediante la búsqueda y documentación de defectos, y la validación y prueba de las suposiciones hechas en el diseño y en la especificación de requisitos vía demostraciones concretas.
Los Probadores también aconsejan o asesoran sobre la calidad percibida en el software; de hecho, el equipo de pruebas es quizás la máxima autoridad del proyecto, dado el carácter restrictivo que tienen sus funciones. Ya alguna vez había señalado que en el futuro no habría gerentes de proyecto como los conocemos hoy, sino gerentes de calidad.
La documentación de RUP anota una diferencia interesante que existe entre la disciplina de Pruebas y las demás disciplinas en RUP: esencialmente, Pruebas encuentra y expone debilidades en el software. Es interesante porque para conseguir mayores beneficios, necesitamos una filosofía general diferente a la que usamos durante la Administración de Requisitos, Análisis y Diseño e Implementación. Estos tres procesos se enfocan en la
completitud del software, mientras que Pruebas se enfoca en la
incompletitud. Así que no es gratuito aquello de que es mala práctica que sean los mismos desarrolladores quienes ejecuten las pruebas. Además está demostrado que celularmente es cuasi-imposible que un desarrollador tome el camino requerido para encontrar lo que le hace falta a su creación.
Todavía hay más disciplinas. La de
Despliegue, por ejemplo, nos guía sobre las actividades necesarias para asegurar que el producto de software esté disponible para los usuarios. Aquí,
disponible no sólo quiere decir “en producción”, sino también utilizable para pruebas y demostraciones.
Todos los procesos anteriores, conforman las Disciplinas Básicas del ciclo de vida. Pero existen otros procesos, que son transversales a cualquier proyecto y sirven de apoyo durante todo el ciclo de vida de desarrollo: la disciplina de
Administración de la Configuración y Versiones nos permite controlar y sincronizar la evolución del conjunto de Productos de Trabajo que componen un sistema de software. Por su parte, la disciplina del Entorno organiza los elementos del método que suministran el entorno de desarrollo de software que apoya al equipo de desarrollo, incluyendo tanto procesos como herramientas; al hacer esto, esta disciplina soporta los demás procesos.
En breve, la disciplina del
entorno es la que nos provee los mecanismos clave para configurar y adaptar el proceso para cada proyecto, brindándonos herramientas para cuantificar y cualificar distintas variables que afectan el desarrollo de un producto de software incluyendo el tiempo y los recursos disponibles, la complejidad del producto, la tecnología a usar, la experiencia del equipo de desarrollo, el conocimiento que este tenga del negocio, el tipo de cliente final, información de la competencia y el grado de formalidad, entre otros.
Finalmente, la
Gerencia de Proyectos exhibe las prácticas recomendadas para los procesos de Inicio, Planeación, Ejecución, Control y Cierre de proyectos (incluyendo el cierre de iteraciones y de fases). Esta disciplina nos propone actividades y estructuras para la planeación de proyectos, la administración adecuada de riesgos, lo mismo que para monitorear el avance del proyecto y gestionar las métricas del mismo.
Tendremos mucho espacio, en futuras lecturas fundamentales, para hablar de todos y cada uno de estos procesos. Lo importante, por ahora, es que para alcanzar cada una de estas metas, las actividades propuestas son dirigidas por los casos de uso, centradas en la arquitectura del software además de iterativas, es decir, se repiten una y otra vez, a lo largo de todo el proyecto, quizás hasta el cansancio. Esta última característica ciertamente es como una revolución, de hecho, entender el modelo de desarrollo por ciclos cortos de tiempo implica experimentar una profunda y quizás traumática transformación a varios niveles de nuestras creencias sobre la forma como desarrollamos software.
Aún hoy, muchos proyectos “rupizados” después, muchos años después, me pregunto si lo que hacemos más bien es una secuencia continuada de “cascadas” en vez de seguir prácticas realmente iterativas e incrementales.
Trataremos de dilucidar este y otros temas alrededor de RUP, por supuesto, en nuestra siguiente lectura fundamental.
ReferenciasAlgunas de las características y conceptos expuestos aquí se basan en la documentación de IBM Rational Unified Process. 1. Cien Años de Soledad, Gabriel García Márquez. Página 1.Lectura Fundamental Siguiente: “RUP: Fase de Concepción” lucho.salazar@gmail.com
