Buscar en Gazafatonario IT

jueves, marzo 08, 2007

Lecturas Fundamentales 8

Lectura Fundamental Anterior: “RUP o Todo lo que quisiste saber alguna vez de RUP y no te atreviste a preguntar…”

Lectura # 8
RUP: Fase de Concepción

“No hay nada más difícil de emprender, ni más dudoso de hacer triunfar, ni más peligroso de manejar, que el introducir nuevas leyes.”
Nicolás Maquiavelo (El Príncipe, 1513)


“In principio creavit…”
Génesis 1 {1:1}

Inicio o Concepción es la primera fase de RUP. El nombre no es importante, solo la meta es importante. Lo realmente trascendental es el objetivo que buscamos durante este período de gestación del proyecto: complementando lo que dije en la lectura fundamental # 7, la finalidad cardinal de esta fase es establecer la visión y el alcance del proyecto y del sistema, lo que se hará y no se hará dentro del proyecto y más aún, lo que hará y lo que no hará el producto a construir.

Para ello, RUP nos proporciona herramientas, a manera de mecanismos y maniobras, que bien usadas nos llevan de la mano hacia la consecución del objeto primario que nos ocupa: obtener un acuerdo con todos los involucrados sobre los objetivos del ciclo de vida para el proyecto.

Pero antes de abordar detalladamente la fase de Concepción como la explica RUP, quiero referirme al significado de las características del proceso durante la misma.

RUP es Dirigido por Casos de Uso y es Centrado en la Arquitectura

Esto significa que los casos de uso son la base para el resto del proceso de desarrollo. Durante la fase de Inicio, cuantificamos y cualificamos los requisitos funcionales del sistema en términos de casos de uso. Estos se convierten en el insumo para:
  • Crear y validar el modelo de diseño de la solución
  • Diseñar la arquitectura del sistema
  • Definir los casos y procedimientos de prueba en el modelo de pruebas
  • Planear las iteraciones
  • Elaborar la documentación de usuario
  • Hacer el despliegue del sistema
  • Sincronizar el contenido de los diferentes modelos que forman el sistema

Los casos de uso también son usados para modelar el negocio, actividad que pocas veces es tenida en cuenta a la hora de entender el comportamiento sistemático de una organización.

Cualificar los casos de uso quiere decir en el contexto del proceso que el Arquitecto del software debe hacer una priorización de los mismos desde el punto de vista arquitectónico. Es decir, establecer cuales son los casos de uso que definen la arquitectura o que tienen un impacto mayor en la misma. Para ello, los Arquitectos ponemos de manifiesto nuestra experiencia en proyectos anteriores y similares, si es posible, para reconocer los casos de uso arquitecturales: El ciclo de vida del caso de uso, el número y la calidad de los elementos estructurales (tanto de arquitectura como de diseño como de implementación) que se requieren para implementar el comportamiento del caso de uso en el sistema, requisitos de desempeño, confiabilidad, soportabilidad, concurrencia y restriccio-nes de diseño, la complejidad algorítmica asociada al caso de uso, el número de escenarios del caso de uso, el ranking del caso de uso desde el punto de vista de su criticidad (esto es, si el caso de uso es requerido u obligatorio, o importante, o adicional –normalmente los casos de uso arquitectónicos se cuentan entre los dos primeros), el grado de novedad de la tecnología y las estrategias disponibles para implementar el caso de uso o, en otras palabras, la experiencia del equipo de desarrollo en el uso de tal o cual tecnología o conjunto de técnicas para resolver un problema dado, son todas variables relevantes a la hora de catalogar o evaluar los casos de uso desde una perspectiva de arquitectura.

La fase de inicio es exploratoria, los casos de uso, todavía en estado primitivo, corren por un río de aguas diáfanas que se precipitan desde la mente de los usuarios como huevos prehistóricos. Encontrarlos, darles un lugar en el sistema, clasificarlos, esbozarlos, modelarlos y finalmente presentarlos, es lo que hacemos como analistas durante este período del proyecto. Una vez aprobado el modelo, los casos de uso rigen los designios a veces insondables a veces meta-humanos de todo el proyecto. A los casos de uso no se les puede poner limitantes técnicas y el equipo de desarrollo debe mantenerlos como un libro abierto de referencia para decidir siempre el siguiente paso. Eso significa “dirigido por casos de uso.”

La arquitectura del software, por su parte, asoma tímida durante la concepción, a manera de arquitectura candidata o preliminar y debería contemplar más de una posible solución, un conjunto pequeño de alternativas de cómo se va a implementar el software y la estrategia que usaremos para abordar el tratamiento de los requisitos suplementarios o no funcionales: la vista de casos de uso o funcional, subconjunto propio del modelo de casos de uso, una vista lógica de alto nivel y quizás una perspectiva del despliegue de la aplicación, surgen de la mente creativa del arquitecto, cual visión futurista de lo que será, de cómo lucirán las entrañas del sistema una vez esté construido. Y sea cual fuere la decisión, la elección que tomemos en la siguiente fase del proyecto, la arquitectura es desde todo punto de vista restrictiva, circunscribe el diseño y, consecuentemente, la implementación y el despliegue de la solución software que se conciba. Pero a partir de ella se abordan y mitigan los riesgos técnicos del proyecto, durante las primeras iteraciones del mismo; también se construyen las bases o cimientos del sistema, unas en las que todos los requisitos conocidos y algunos de los no conocidos tengan cabida; por supuesto, la arquitectura es el eje medular alrededor del cual se construye la solución, se planea y se controla el proyecto y también, en torno al cual se asegura la calidad del producto. Eso significa “centrado en la arquitectura.”

Para el Gazafatonario IT

A manera de inventario, y puesto que esto no es más que un Gazafatonario, la palabra Conceptualización[1], aunque aparece en algún diccionario de la lengua española definida simplemente como: “f. Elaboración detallada y organizada de un concepto a partir de datos concretos o reales” no es aceptada por la Real Academia de la Lengua Española. Así que seguiremos usando Inicio o Concepción para referirnos a la primera fase del ciclo de vida de acuerdo a RUP.

Roles y Responsabilidades Durante Concepción

Un Ingeniero de Procesos, un Gerente de Proyectos, al menos un Analista de Requisitos, un Analista del Negocio y un Administrador de la Configuración y el Versionamiento son los responsables de iniciar el proyecto. Con ellos, los usuarios, clasificados en Usuarios Líderes, Usuarios Finales y otros Involucrados (stakeholders es el término que nos llega del inglés) son los encargados de dictar el problema (y el problema detrás del problema, la causa raíz), sus necesidades, y hasta sus ambiciones, sus sueños y sus esperanzas. Más adelante, un Especificador de Requisitos (realmente un escritor técnico de casos de uso que bien podría ser el mismo analista de requisitos –de hecho casi siempre lo es) y un Arquitecto del Software, se unen a los anteriores para establecer las características (de alto nivel) del software, los primeros requisitos funcionales (a manera de casos de uso) detallados, los requisitos no funcionales y la misma solución de software expresada en términos arquitectónicos y de diseño.

Vamos por partes.

El Ingeniero de Procesos

Sí, RUP es un proceso configurable y adaptable a cada proyecto. Es así como lo leen, a cada proyecto. La primera conclusión que viene a mi mente, aunque reiterativa, tiene que ver con la forma de abordar el proceso. Recordemos que el proceso expone prácticas que han funcionado alguna vez, pero que no deberíamos seguir al pie de la letra, cual ensayo de laboratorio.

Un proyecto tiene condiciones muy particulares: el tipo de organización, más exactamente, el contexto del negocio, el tamaño del esfuerzo de desarrollo del software, el grado de novedad, el tipo de aplicación, el proceso actual de desarrollo, los problemas actuales y sus causas primarias, los factores organizacionales, las actitudes y la complejidad técnica y de gestión son algunos discriminantes que el así llamado Ingeniero de Procesos debe tener en cuenta al momento de decidir el mejor de los caminos posibles del proceso para ese proyecto.

Previo a ello, debemos tener claridad sobre las influencias del proceso de desarrollo: factores del dominio, por ejemplo, entre los que se cuentan factores del dominio de la aplicación, del proceso de negocio a soportar, de la comunidad de usuarios y de las ofertas disponibles de los competidores; factores del ciclo de vida como el tiempo de salida al mercado, la vida esperada del software y las versiones futuras planeadas son igualmente importantes; factores técnicos, ni más faltaba, como los lenguajes de programación a usar, las herramientas de desarrollo, las bases de datos, los frameworks de componentes y los sistemas de software existentes, constituyen influjos de peso que actúan sobre el proceso de desarrollo, junto con otros factores organizacionales cuyo nombramiento, al menos, se escapa del alcance de esta lectura fundamental.

Sobre el tamaño del esfuerzo del proceso de desarrollo, tenemos en cuenta aspectos medibles como el número de líneas de código entregadas, el número de casos de uso, el número de personas por mes o por alguna otra unidad de tiempo, el número de clases y de componentes, el número de tablas y de procedimientos almacenados en la base de datos, entre otros, para cuantificar la influencia en el desarrollo: a mayor tamaño de proyecto, mayor tamaño de equipo de desarrollo, el contexto del negocio pierde importancia en favor de más formalidad y más visibilidad en los requisitos, en las interfaces y en los indicadores de progreso del proyecto. Adicionalmente, para equipos geográfi-camente dispersos, incluso transoceánicos, tenemos en cuenta aspectos cruciales de comunicación y el cambio del huso horario.

El grado de novedad es otra condición influyente que tengo en cuenta como ingeniero de procesos. Este grado de novedad es relativo al equipo de desarrollo y a la organización que lo envuelve: factores como la madurez de la organización y del proceso de desarrollo (medido vía CMMi o algún otro modelo similar), los activos del proceso, las habilidades actuales del personal, la composición y el entrenamiento del equipo y la adquisición de herramientas y otros recursos para el proyecto, son definitivos a la hora de configurar el proceso: si se trata de un sistema nuevo, establezco fases de concepción y de elaboración más largas y más iteraciones en esta última; también hago más énfasis en la captura y administración de requisitos, el modelo de casos de uso, la arquitectura y en la mitigación de riesgos. Entre tanto, para un sistema en evolución, enfatizo en la gestión de cambios y en la incorporación o no de código legado.
En breve, durante la concepción, el ingeniero de procesos además elabora el caso de desarrollo, prepara las plantillas y las guías para el proyecto y, con un especialista en herramientas, selecciona las herramientas más adecuadas para el proyecto. Son materias que tienen tanto extensión como profundidad y abordarlas bien podría ser objeto de futuras Lecturas Fundamentales.

Lo que sí tengo que decir antes de cerrar esta puerta es que el ingeniero de procesos es al proceso lo que el arquitecto es al sistema y recuerden: la calidad de un producto está determinada en gran medida por la calidad del proceso que se usa para desarrollarlo y mantenerlo[2].

El Analista de Procesos del Negocio

Hablo de procesos distintos. En el apartado anterior me refería al proceso de desarrollo de software, mientras que en este me refiero al conjunto de procesos mediante los cuales una compañía organiza su actividad para conseguir sus objetivos. Cada proceso del negocio se identifica por un repertorio de datos que son elaborados y operados mediante un conjunto de quehaceres, en los que ciertos agentes (trabajadores, proveedores, departamentos, entre otros) interactúan de acuerdo a un flujo de trabajo determinado. Además, estos procesos dependen de un conjunto de reglas de negocio que fijan las políticas y la arquitectura de la información de la empresa.

El analista de procesos del negocio o simplemente analista del negocio es el responsable de definir la arquitectura del negocio y los actores y casos de uso del negocio, lo mismo que la interacción entre ellos. El modelo producido por este analista delimita la organización desde el punto de vista del sistema a desarrollar.

Entender la organización es un aspecto clave en todo desarrollo de software: enterarse de los procesos de negocio, quienes intervienen en su ejecución, sus entradas y sus resultados, como se manejan las excepciones, como se mantiene la integridad de la información y la consistencia entre procesos; también, conocer hacía donde va la organización, las expectativas de los usuarios, la visión que ellos tienen sobre lo que será y no será el negocio en el futuro, al menos, durante el ciclo de vida esperado del sistema.

Ahora bien, idealmente, la construcción de sistemas de software es uno de esos buenos momentos para cambiar procesos de negocio, no porque el negocio tenga que adaptarse al nuevo sistema, sino porque el esfuerzo de revisión de tales procesos puede llegar a ser tan significativo, tan profundo, que se encuentren oportunidades de mejora. Esto, por supuesto, es completa responsabilidad de la organización para la cual se construye el sistema y el área de TI, como buena conocedora de estos procesos, debe apoyar el diseño y la implantación del nuevo modelo y de paso quedar con el nuevo conocimiento para futuros ejercicios de esta índole.

Por supuesto, este trabajo implica un tiempo y recursos adicionales considerables que casi nunca son estimados a la hora de emprender un proyecto de tecnología informática, de tal forma que la cautela y el tratamiento efectivo de las expectativas de nuestros clientes son recomendables.

El Gerente de Proyectos

Planea, maneja y asigna recursos, determina prioridades, coordina las interaccio-nes con los usuarios y mantiene el foco del equipo del proyecto. También establece un conjunto de prácticas para asegurar la integridad y la calidad de los entregables del proyecto. Es un orquestador, articula y coordina los movimientos que se den en el proyecto.

Es el gerente quien precisamente concibe el proyecto mediante la transformación de una idea inicial a un estado en el que, soportado en razones de peso, pueda tomar una decisión sobre continuarlo o abandonarlo. Para lo que nos ocupa la mayor parte del tiempo, este “abandonarlo” más bien se convierte en un “ajustar” algunas condiciones críticas del proyecto, como el tiempo, el talento humano necesario para llevarlo a cabo y, por consiguiente, el presupuesto y la estrategia para alcanzar el éxito.

Durante la concepción, el gerente del proyecto identifica y evalúa los riesgos, elabora un caso de negocio e inicia el proyecto. Más adelante, en la misma concepción, planea el proyecto, teniendo en cuenta las métricas, los riesgos, los criterios de aceptación del producto, las tácticas para la resolución de problemas, el proceso de aseguramiento de la calidad, la organización del equipo de desarrollo, los modos de monitoreo y control del proyecto y las fases e iteraciones del mismo. Para ello se alimenta de toda la materia prima que los demás responsables de la concepción le transmitan. Es el gerente quien también decide si se han alcanzado los objetivos de la fase de concepción y si es viable empezar la fase de Elaboración.

Tanto en Concepción, como en el resto del proyecto, el gerente tiene una perspectiva de mediana profundidad para poder izar los hilos del proyecto con mayor propiedad y asegurar, casi como un dogma, que se pueda hacer una entrega, que se pueda avanzar o, si por el contrario, que se deba replantear la técnica y reorientar el enfoque (corregir el rumbo). Y el final de la fase de concepción es buen momento para asegurarnos de la idoneidad (en cuanto talento, competitividad, aptitud) del equipo de desarrollo, de indagar si los miembros del equipo tienen las habilidades y destrezas suficientes, comparten todos la misma visión de lo que vendrá, soportarán la presión, están dispuestos a dar ese “delta de t” (y otros deltas) necesarios para triunfar en todo proyecto. Desde este punto de vista, el destino del proyecto, incierto hasta este punto, depende enteramente de su gerente.

Bueno, esto no lo dice ningún proceso, no está escrito en ningún lado, simplemente es y con eso basta.

Continuará…

Hace poco uno de mis revisores de cabecera me dijo que estas lecturas fundamentales estaban quedando muy largas. Yo les reenvío la inquietud, ¿ustedes qué piensan? En cualquier caso, les he dado suficiente tiempo, creo, para que hagan la mejor de las lecturas. Estoy atento, los escucho.

De todas formas, es evidente que esta lectura amerita otra parte, donde concluiremos con los aspectos más importantes de la fase de concepción. Hasta la próxima entonces.

Referencias

Algunas de las características y conceptos expuestos aquí se basan en la documentación de IBM Rational Unified Process.

1. Diccionario de la lengua española © 2005 Espasa-Calpe S.A., Madrid:
Conceptualización
f. Elaboración detallada y organizada de un concepto a partir de datos concretos o reales.

2. Basado en principios de Administración Total de la Calidad enseñados por Shewhart, Juran, Deming y Humphrey.

Lectura Fundamental Siguiente: “RUP: Fase de Concepción. Parte 2.”

lucho.salazar@gmail.com

miércoles, febrero 21, 2007

Lecturas Fundamentales 7

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.

Metas

Inicio 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.

Referencias

Algunas 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

martes, febrero 06, 2007

Lecturas Fundamentales 6

Lectura Fundamental Anterior: Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2

Lectura # 6
De Procesos y de Humanos

“Hay ciertos privilegios comunes a un escritor cuyos beneficios, espero, no haya razón para dudar; particularmente, que si no se me entiende, se debería concluir que algo muy útil y profundo se esconde debajo; y también, que si cualquier palabra o frase es impresa en un carácter diferente, debería pensarse que contiene algo extraordinario o ingeniosamente sublime.”
Jonathan Swift, A Tale of a Tub, Prefacio (1704)

Jochen Krebs dice en un artículo reciente: “Seguir un proceso de ingeniería de software implica un compromiso con la consistencia y estandarización.”1 Y más adelante expone: “Desde una perspectiva organizacional, emplear especialistas certificados en RUP crea un ambiente consistente para la comunicación y la colaboración entre los miembros del equipo del proyecto y los demás involucrados, lo cual es la base para la eficiencia y la productividad.”2

Esta misma convicción me acompañó desde el instante en que la irreparable voluntad del destino me condujo a usar RUP por primera vez hace ya unos seis años que, convertidos a “años TI”, bien podrían ser treinta o cuarenta. Pero también desde entonces me inquieta férreamente, como una espina clavada en el cerebro, el motivo por el cual en una cultura como la nuestra no hayamos logrado la madurez suficiente y necesaria para enfrentar todos y cada uno de nuestros proyectos con el éxito debido. Pues bien, este es un nuevo intento por remediar esta situación. Hablemos de Procesos.

Definición 13: Un proceso es un conjunto de pasos o acciones parcialmente ordenadas mediante las cuales se busca un objetivo. Un proceso define quién hace qué, cuándo hacerlo y cómo alcanzar ese objetivo.

Lo primero que se me ocurre agregar a esta definición sistémica es que no tiene nada que ver con artefactos documentarios o el puro acto de documentar. Lo aclaro porque en mis continuas asesorías todavía me encuentro con la excusa de “es que nosotros no seguimos ningún proceso porque no hay tiempo para documentar.” Ahora bien, en este contexto, “parcialmente ordenadas” significa que no siempre tenemos que seguir caminos iguales. Es otra aclaración importante porque tendemos a creer que un proceso es una receta o una fórmula que siempre debe llevar los mismos ingredientes y prepararse de idéntica forma y no es así: un proceso se configura o se adapta, no solo para cada empresa, sino para cada proyecto. Y para el caso de la TI, el objetivo del proceso es desarrollar un producto de software nuevo (y estoy usando un término bastante general al decir “producto de software” porque soy de los que consideran al software como un medio y el verdadero producto es el conocimiento contenido en el software), o hacer el mantenimiento de uno existente. Justamente, otro error común es creer que no podemos dar soporte a un sistema de software usando un proceso si este sistema no fue desarrollado originalmente usando ese proceso.

En la segunda parte de la definición, Quién se refiere a los practicantes, actuarios (no actores) en el sentido de actuar, o a los ejecutantes de las acciones. Normalmente es un equipo de personas y, hoy más que nunca, de máquinas y herramientas a nuestra disposición. Entre tanto el Qué da cuenta precisamente de las acciones o pasos que se ejecutan o llevan a cabo por esas personas o herramientas. Son funciones que se suceden en el tiempo, pero que se repiten continuamente una y otra vez (de forma iterativa) hasta alcanzar el resultado esperado. Se trata de tareas más o menos simples, muchas de ellas mecánicas, que se pueden hacer en días o en horas. Esta sucesión de momentos redundantes señalan el Cuándo del enunciado; son instantes que se multiplican durante un proyecto y en muchos proyectos, de tal forma que con el paso del tiempo podemos llegar a predecir con gran exactitud cuando pasarán y cuanto tardará su ejecución; al menos esa es la presunción al usar un proceso: estimaciones más precisas y la conversión del mal llamado “arte” de la programación de computadores en Ingeniería, en ciencia numérica que pueda ser cuantificada. Y finalmente, el Cómo, constituido por los medios, las herramientas (y no me refiero siempre a maquinaria) y las técnicas proporcionadas por el proceso, que no son más que una suma de prácticas documentadas que han funcionado al menos una vez para al menos una persona en al menos un entorno.

Esto último es muy importante asimilarlo con cuidado, porque también tenemos la tendencia a asumir que todo lo que está por escrito sirve para cualquier ocasión cuando una buena práctica es medir distintas variables relacionadas con el hábitat, con los miembros del equipo, con la economía, con la cultura y hasta con la idiosincrasia de las personas para decidir cual es la mejor trayectoria a seguir.

Un proceso se documenta: esto mejora su difusión en cada una de las dimensiones de la compañía que lo adopta, clarifica conceptos y estandariza el uso del mismo. También permite la medición del mejoramiento del proceso. Con esto en mente, un proceso se sigue: lo que pasa es que el seguimiento no es del tipo “receta de cocina”, es decir, no siempre tenemos que participar de acciones semejantes, construir artefactos semejantes, ni actuar tipo “robot” sistemático. Eso ocurre esencialmente porque los actuantes del proceso medimos además variables del ambiente en el que nos transportamos a través del ciclo de vida del desarrollo del software. Variables como el tiempo disponible, la criticidad y complejidad del software, el equipo del proyecto (aspectos como experiencia técnica, conocimiento del negocio y del proceso usado influyen), herramientas de apoyo, modo de utilización del proceso, entre muchas otras, se usan para adaptar el proceso al proyecto que está iniciando.

En ese orden de ideas, un proceso puede ser pequeño al comienzo: y es una buena práctica que sea pequeño para empezar a usarlo. De hecho, es posible emplear sólo una pequeña parte del proceso: la fase de inicio, por ejemplo, o solamente una disciplina como la Gerencia del Proyecto a lo largo de todo el ciclo de vida. De esta forma, luego de aplicar esa porción del proceso, medimos los resultados, mejoramos esa parte del proceso, de ser posible, y la divulgamos al interior de la empresa. Más adelante usamos otra fracción del proceso, quizás junto con la anterior, y vamos creciendo con el.

Y algo muy importante: un proceso no tiene que ser perfecto. Es más, ninguno lo es. Y hay más: un proceso nos indica que hacer bajo ciertas condiciones, que bien podríamos llamar “ideales”. Por ejemplo, un proceso no dice que hacer si al equipo de desarrollo le faltan dos personas intempestivamente o si hay problemas técnicos que no son solucionables a corto o mediano plazo. Lo que sí hace es dar ideas (prácticas documentadas) de qué hacer en casos como esos. En resumen: un proceso no dice que hacer en tiempos de crisis. Es en esos momentos cuando toda nuestra razón, nuestros conocimientos, nuestra praxis (hablo de los seres humanos actuarios del proceso) y nuestra pragmática se debe poner de manifiesto para superar el trance.

Importante es que un proceso vaya de la mano con un programa de entrenamiento para el manejo de las habilidades de las personas que usan el proceso. El proceso no hace nada por sí solo, ni las herramientas, son las personas las que, con cierto grado de conocimiento del proceso y de experiencia en el rito procesal, lo siguen, lo ejecutan. Lo que no debe ocurrir es que el proceso de pie a interpretaciones diversas. El proceso debe ser claro, no ambiguo, preciso, sin que ello quiera decir inflexible. Al final, el proceso debe contar con unas bases para el mejoramiento continuo de la calidad y he aquí la primera premisa de lo que se ha llamado Mejora de Procesos: “La calidad de un producto es determinada en gran medida por la calidad del proceso que es usado para desarrollarlo y mantenerlo”3.

Y para finalizar esta disertación sobre Procesos y Personas, me resta decirles que un proceso debe usar las mejores prácticas probadas en la industria, no sólo la última moda en materia de guías o actividades. Un proceso debe estar bien establecido en el medio donde se utilizará, ser familiar a los miembros del equipo de desarrollo, a los clientes, a los usuarios (de alguna forma), a los socios de negocios y a todos los involucrados en el proyecto. No podemos forzar el uso de tal o cual práctica que aprendimos en un libro de aparición reciente o que escuchamos en la conferencia de la noche anterior.

Y más aún, un proceso debe ser práctico, esto es, entregar la información que se necesita, cuando se necesita y en un formato y medio usable. Y con el temor de ser incisivo: el proceso debe adaptarse a las necesidades de quien lo usa, es decir, un proceso debe proporcionar los mecanismos para que sea configurable de acuerdo al proyecto.

¿Y todo esto qué tiene que ver con RUP? Pues bien, RUP es un proceso pensado en principio para desarrollar software. RUP posee todas esas características a las que me acabo de referir. La entrada de RUP son los requisitos, nuevos o cambiados; la salida de RUP es el sistema, nuevo o cambiado. Pero lo más importante, es un sistema de alta calidad, como lo exigen los estándares de la industria.

Pero para hablar de RUP tendremos todo un volumen, a partir de la próxima lectura fundamental. Por ahora quiero dejarlos con estas tres leyes del proceso de software, algo como para tener siempre presente:4

La Primera Ley del Proceso de Software

Los procesos solamente nos permiten hacer cosas que ya sabemos hacer.

El Corolario a La Primera Ley del Proceso de Software

No puedes tener un proceso para algo que no hayas hecho nunca ni que sepas como hacer.

La Creación Reflexiva de Sistemas y Procesos

1. La única forma de crear sistemas efectivos es a través de la aplicación de procesos efectivos.

2. La única forma de crear procesos efectivos es a través de la construcción de sistemas efectivos.

El Lema de la Tardanza Eterna

Los únicos procesos que podemos usar en el proyecto actual fueron definidos en proyectos previos, que son diferentes de éste.

La Segunda Ley del Proceso de Software

Solamente podemos definir procesos de software a dos niveles: uno demasiado vago o uno demasiado limitante.

La Regla de la Bifurcación del Proceso

Las reglas de los procesos de software muchas veces se dictan en términos de dos niveles: una sentencia general de la regla y un ejemplo detallado específico (valga el ejemplo: La Segunda Ley del Proceso de Software).

La Hipótesis Dual del Descubrimiento del Conocimiento

· Hipótesis Uno: Solamente podemos “descubrir” el conocimiento en un entorno que contiene el conocimiento.

· Hipótesis Dos: La única forma de declarar la validez de cualquier conocimiento es compararlo con otra fuente de conocimiento.

La Observación de Armour sobre el Proceso de Software

Lo que todo desarrollador de software realmente quiere es un conjunto de reglas riguroso, hermético, concreto, universal, absoluto, total, definitivo y completo que se puedan romper.

La Tercera Ley del Proceso de Software

El último tipo de conocimiento a ser considerado como candidato para la implementación en un sistema de software ejecutable es el conocimiento de cómo implementar el conocimiento en un sistema de software ejecutable.

Las Metas Gemelas de la Terminación Óptima

1. La única meta natural de un grupo de procesos de software debería ser alejada del negocio tan pronto como sea posible.

2. El resultado final del desarrollo y aplicación continuos de un proceso efectivo será que nadie realmente tiene que usarlo.

Quizás el único comentario que me queda por hacer es que los procesos y los modelos no pueden separarse de la forma como pensamos los seres humanos. Más que cualquier otra cosa, el desarrollo de software es una actividad pensante. Como humanos, sólo pensamos en términos de modelos. Las restricciones de estos modelos nos asisten en la actividad pensante, pero también nos restringen y pueden aún conducir el resultado de nuestro pensamiento forzando una respuesta sobre nosotros. Todos estos elementos, los procesos que usamos y los modelos de nuestro entendimiento que nosotros mismos creamos, incluyendo el modelo del código, deben conformar con los requisitos de la mente.

Referencias
1. The value of RUP certification, by Jochen Krebs. The Rational Edge, Enero 2007.
2.
The value of RUP certification, by Jochen Krebs. The Rational Edge, Enero 2007.
3. Basado en principios de Administración Total de la Calidad enseñados por Shewhart, Juran, Deming y Humphrey.
4. The Laws of Software Process: A New Model for the Production and Management of Software by Philip G. Armour

Lectura Fundamental Siguiente: “Todo lo que siempre quisiste saber de RUP y no te atreviste a preguntar”

lucho.salazar@gmail.com

viernes, diciembre 22, 2006

Lecturas Fundamentales 5 (2 de 2)

Lectura Fundamental Anterior: “Casos de Uso: ¿Cuándo Están Terminados? ... ¿Y qué hacer con ellos a continuación?” Parte 1

Lectura # 5
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2
Previamente en Lecturas Fundamentales…

En la parte 1 de este artículo enunciaba mi Ley de la Terminación del Caso de Uso. Decía que un caso de uso está terminado cuando se cumplen al menos diez de trece condiciones. Las primeras seis condiciones a las que me refería son:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
5. ¿Los subflujos en el caso de uso están modelados con precisión?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Y aportaba algunos elementos de criterio para hacer la revisión con cada uno de esos puntos. Bien, estas son las demás:
¿Las interacciones del actor y la información intercambiada están claras?
¿Es comprensible la forma como el actor proporciona datos al sistema mediante el caso de uso y qué datos suministra? Esto es, establecer si el actor debe seleccionar de una lista o debe digitar el dato o debe escoger una de un conjunto de posibles opciones; o si debe especificar la ruta o la dirección de un archivo de datos o si debe autorizar la carga de información mediante un proceso.
También debe hacerse evidente el tipo y mecanismo de validación, si existe, para cada dato intercambiado con el sistema. En este contexto, “hacerse evidente” quiere decir “especificar o documentar”, que sea explícito en el caso de uso. No porque algo nos parezca evidente, como especificadores de requisitos, le parecerá evidente a los demás, hay que hacerlo incuestionable, axiomático.
¿La descripción breve ofrece un cuadro verdadero del caso de uso?
Aunque la descripción breve no hace parte de la funcionalidad establecida en el caso de uso, ésta debe brindar a los lectores del mismo una visión horizontal, concisa, que permita formar imágenes mentales precisas de lo que hace el caso de uso y hasta un bosquejo del mismo.
Durante la fase de exploración del proyecto, la fase de Concepción o Inicio, cuando se descubren los casos de uso, la descripción breve del caso de uso juega un papel muy importante no solo para los analistas y usuarios, sino para el Arquitecto del Software, que cuenta con que le facilitemos de estas descripciones para que comience a elaborar la arquitectura del producto, al menos, la arquitectura preliminar, o para que tome decisiones acerca de llevar a cabo pruebas de concepto o no.
¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (Menos de 20)
El límite puede ser 20, 15, 25, 17, 13, 23. “Pequeño” es un término relativo, eso lo sabemos de sobra. Puede haber casos de uso “grandes”, de 30, 50 ó 70 pasos; sin embargo, éstos deben ser la excepción. Además, el tamaño es un índice de complejidad, pero no es el único. Y siempre puede suceder que un caso de uso de 50 pasos sea sencillo y uno de 10 pasos sea complejo.
En cualquier caso, cuando el número de pasos de un caso de uso empieza a crecer, debemos también comenzar a pensar en que quizás se pueda dividir. De hecho una de los lineamientos a seguir para crear casos de uso incluidos es precisamente la máxima de “divide y vencerás” que, en esta oportunidad, podríamos traducir como “divide y entenderás.”
Definición 12. Un caso de uso incluido es aquel cuyo comportamiento (funcionalidad) puede ser insertado en el comportamiento definido para otro caso de uso, llamado caso de uso base.
La inclusión, junto con la extensión y la generalización, son las relaciones que pueden existir entre casos de uso. En una lectura fundamental posterior les hablaré en detalle de este tema de las relaciones entre casos de uso.
¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
En la lectura fundamental #1 anotaba que, desde el punto de vista del usuario, un caso de uso es una pieza indivisible de software, simple, con un objetivo exacto y único.
Siempre debemos buscar estas características en el caso de uso. Si observamos que el caso de uso hace varias tareas desacopladas, si la complejidad de algunas de sus acciones lo hace incomprensible para los usuarios o aún para los desarrolladores, si tiene un número excesivo de pasos o de secuencias alternativas, si la profundidad de las anidaciones (decisiones lógicas o ciclos) es mayor de dos (por ejemplo, si hay secuencias alternativas que se derivan no de la secuencia básica o principal, sino de otra secuencia alternativa), si parte de las acciones de un caso de uso se puede “ocultar” deliberadamente (en casos de uso incluidos) sin que se afecte el matiz que se obtenga de su lectura, si para entender el caso de uso se hace necesario acompañarlo de adjuntos como prototipos de usuario, manifiestos en prosa sobre la funcionalidad del caso de uso u otros elementos de diseño, entonces seguramente será necesario fraccionar la especificación en dos o más casos de uso.
Sí, otra vez, simplicidad es la clave.
¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
En términos generales, un caso de uso incluido no es autónomo en cuanto a que por sí solo no entrega un resultado de valor observable para el actor. Esto lo convierte en dependiente del caso de uso base.
A pesar de tal interdependencia, el comportamiento de un caso de uso incluido no debe verse sobre-influido por un cambio al caso de uso base, sobre todo, cuando la razón de la inclusión es una factorización en la funcionalidad de varios casos de uso, es decir, distintos casos de uso tenían una funcionalidad común que se eliminó de éstos y se incluyó en un único caso de uso incluido por todos los demás.
De esta forma, si al modificar la funcionalidad de uno de los casos de uso, se acomete contra la funcionalidad “incluida”, todos los casos de uso que la usan deben someterse a una minuciosa inspección con el fin de mantener la consistencia en el modelo funcional o de casos de uso.
¿Cada caso de uso es independiente del resto?
Es realmente necesario abordar este chequeo con un pensamiento sistémico que nos permita no sólo modelar el producto sino también obtener varias perspectivas del modelo.
En particular, al revisar las interrelaciones de los casos de uso en los distintos modelos del sistema, el resultado debe ser uno que exhiba bajo acoplamiento y alta cohesión. Bajo acoplamiento quiere decir que hay poca o ninguna interdependencia entre el caso de uso y su entorno (otros casos de uso u otros actores distintos al que ejecuta este caso de uso). Entre tanto, el principio de alta cohesión señala que el caso de uso ejecuta una tarea simple y precisa y alcanza un objetivo predeterminado. En este contexto, los casos de uso a los que me refiero son casos de uso concretos, ejecutados por actores del sistema; esto excluye, si me permiten la disfunción, a los casos de uso incluidos y a los abstractos o generalizados. Estos últimos son aquellos que no se implementan, pero que existan para estabilizar el modelo y entenderlo mejor.
Este, que es un patrón común de diseño heredado cuidadosamente de las técnicas estructuradas de programación de computadores, requiere tanto un enfoque de bajo nivel para verificar el acoplamiento, como un punto de vista más alto para cotejar la cohesión. De allí la necesidad de hacer cálculos holistas con los elementos funcionales del sistema, o sea, con los casos de uso.
¿Este caso de uso hace algo muy parecido a otro caso de uso?
De ser así, quizás deberían convertirse ambos en un único caso de uso.
Ocurre mucho con los casos de uso descompuestos funcionalmente, que deberíamos evitar. Estos tienden a parecerse, porque, por ejemplo, uno es para adicionar un elemento y el otro es para actualizar los datos de ese elemento, digamos un producto o un cliente.
Pero en casos de uso no descompuestos funcionalmente también suele suceder, sobre todo, cuando obtenemos la visión de un rango heterogéneo de usuarios y cada uno de ellos expresa sus necesidades de acuerdo a sus criterios y ambiente de trabajo. Reservar Vuelo y Comprar Tiquete quizás sean dos casos de uso distintos, pero también pueden llegar a convertirse en uno solo, dependiendo de la meta que se quiera alcanzar con uno u otro.
¿Y qué hacer con los casos de uso una vez están terminados?
Realmente no es necesario terminar un caso de uso para continuar con su ciclo de vida. Desde la descripción breve y el esbozo que se obtiene durante la fase de Inicio del proyecto, ya es posible empezar a hacer el análisis y diseño del caso de uso. En este punto ya también el arquitecto puede considerar distintas variables para seleccionar los casos de uso más críticos o complejos para la arquitectura del software, aquellos que definen las bases del producto a construir.
Más adelante, durante cada una de las iteraciones, al completar la secuencia básica es factible diseñar prototipos, “realizar” los casos de uso y comenzar a implementarlos. Y también es posible diseñar los casos de prueba.
Todos estos eventos subsiguientes a la especificación de un caso de uso, serán temas que ocuparán nuestras lecturas fundamentales durante 2007.
Hasta entonces y feliz navidad.

Lectura Fundamental Siguiente: De Procesos y de Humanos.

lucho.salazar@gmail.com

jueves, diciembre 07, 2006

Lecturas Fundamentales 4 (1 de 2)

Lectura Fundamental Anterior: “Casos de Uso: Del Todo y de Sus Partes”
Lectura # 4
Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 1 de 2
Volvamos a considerar el siguiente caso de uso típico de un sistema de reservaciones:
Caso de Uso: Reservar Vuelo
Actor: Pasajero Frecuente
Descripción: este caso de uso permite a una persona reservar un vuelo de ida y regreso entre dos ciudades distintas en las fechas de su elección. El sistema valida la disponibilidad de un asiento de las características que el Pasajero especifique. La reservación se hace vía Internet. La aerolínea sólo tiene aviones con asientos estándar.
Objetivo: Proporcionar un mecanismo rápido y seguro a un Pasajero Frecuente para hacer reservas en vuelos nacionales o internacionales de ida y regreso. No se incluye la funcionalidad de pagar o cambiar el estado de la reserva.
Precondiciones: El Pasajero debe estar plenamente identificado ante el sistema de reservas (Cuenta de Pasajero Frecuente, Identificación, Nombre y otros datos básicos).
Secuencia Básica:
1. El caso de uso inicia cuando el Pasajero decide Hacer una Reserva Aérea
2. El sistema solicita las ciudades origen y destino del vuelo
3. El Pasajero selecciona las ciudades origen y destino del vuelo
4. El sistema valida que las ciudades Origen y Destino sean distintas, que haya al menos un vuelo entre esas ciudades y solicita las fechas de ida y regreso
5. El Pasajero especifica las fechas de ida y regreso, incluyendo la hora de ambos viajes
6. El sistema valida que la fecha de regreso, incluyendo la hora, sea superior a la fecha de ida, incluyendo la hora, y pide seleccionar una opción de la lista de vuelos disponibles para las fechas y ciudades establecidas
7. El Pasajero selecciona una opción de vuelo
8. El sistema muestra los detalles del vuelo y solicita confirmación de la reserva
9. El Pasajero confirma la reserva
10. El Sistema asigna un asiento al Pasajero, genera y muestra un código de reserva
11. El caso de uso termina
Secuencia Alternativa 1:
4A. No hay vuelos entre las ciudades seleccionadas
4A1. El sistema muestra el mensaje: “No hay vuelos entre las ciudades seleccionadas. Verifique.”
4A2. El caso de uso termina
Secuencia Alternativa 2:
6A. No hay vuelos disponibles en las fechas especificadas
6A1. El sistema muestra el mensaje: “No hay vuelos disponibles en las fechas seleccionadas. Verifique.”
6A2. El caso de uso termina
Secuencia Alternativa 3:
6B. La fecha/hora de regreso es inferior a la fecha/hora de ida
6A1. El sistema muestra el mensaje: “La fecha de regreso es inferior a la fecha de ida. Especifíquelas nuevamente.”
6A2. El caso de uso continúa en el paso 5 de la secuencia básica
Poscondiciones: El Pasajero puede consultar el estado de su reserva. El Pasajero puede modificar o cancelar su reserva.
Requisitos Especiales: El sistema sólo muestra y permite seleccionar pares de vuelos disponibles en las fechas y entre las ciudades establecidas. El sistema de reservas es solo para el tipo de Pasajeros Frecuentes de la aerolínea.
Advertencia: todavía este continua siendo un caso de uso de una situación simulada, no intente usarlo en ningún proyecto en curso.
Voy a cerrar este primer ciclo de lecturas fundamentales sobre casos de uso basándome precisamente en una corta pero sustanciosa lista de chequeo para revisar casos de uso. Vale la pena decir que esta lista hace parte del proceso de Ingeniería de Requisitos institucionalizado en InterGrupo hace ya algún tiempo y que a su vez está cimentada en RUP.
Ley de la Terminación de un Caso de Uso
Un caso de uso está terminado cuando se cumplen al menos diez de las siguientes trece condiciones:
1. ¿El caso de uso tiene especificado el Actor que lo inicia?
2. ¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
3. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
4. ¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
5. ¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
6. ¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
7. ¿Las interacciones del actor y la información intercambiada están claras?
8. ¿La descripción breve ofrece un cuadro verdadero del caso de uso?
9. ¿La secuencia básica del caso de uso tiene un número de pasos pequeño? (menos de 20)
10. ¿Está claro que el caso de uso no se puede dividir en dos o más casos de uso?
11. ¿Para un caso de uso incluido: se probó que si se modifica el caso de uso que lo incluye, el caso de uso incluido no se afecta?
12. ¿Cada caso de uso es independiente del resto?
13. ¿Este caso de uso hace algo muy parecido a otro caso de uso? De ser así, quizás deberían convertirse ambos en un único caso de uso.
¿El caso de uso tiene especificado el Actor que lo inicia?
No habría mucho que decir de este control si la búsqueda y posterior definición de los actores de un sistema no estuviera hoy tan desestimada. En principio tengo que decir que intentar definir un sistema sin conocer sus actores es un error bastante común. Antes que cualquier otra cosa es importante conocer para quien construimos el sistema, luego procedemos a documentar lo que hace cada uno de esos actores.
Debemos indagar por el perfil del actor y sus responsabilidades en el sistema. Recordemos que un actor bien podría ser alguien “abstracto” para el negocio, es decir, no equivale a un rol desempeñado por una persona o un grupo de personas dentro del negocio, razón por la cual, luego de hacer la abstracción, hay que mirarlo desde el punto de vista del sistema.
Con ese perfil, evaluamos si las actividades descritas en el caso de uso pueden ser ejecutadas por ese actor. Este es realmente el punto de chequeo, no simplemente asegurarnos de que haya un nombre cualquiera en la sección Actor del caso de uso.
Ahora bien, un caso de uso normalmente tiene un único actor que lo inicia; sin embargo, el caso de uso puede tener más actores. En este caso, los demás actores son pasivos, es decir, o simplemente reciben información, como en el caso de un sistema o un dispositivo externo, o son espectadores participes del proceso del negocio que envuelve el caso de uso, como en el caso de un cliente en un punto de venta. En cualquier caso, es importante enumerar a todos los actores que intervienen en el caso de uso por el horizonte que se extiende tanto para los analistas como para los desarrolladores y probadores del producto, en cuanto al entendimiento del mismo.
En el ejemplo, un “simple” Pasajero puede significar un cliente casual de la aerolínea, mientras que un Pasajero Frecuente es precisamente una persona que toma vuelos con una frecuencia uniforme o que, al menos, está registrado como tal ante la compañía.
¿El caso de uso ha sido leído y entendido por todos los interesados en el mismo, incluyendo representantes de los usuarios finales y los programadores del mismo?
Los usuarios son la última línea de defensa del caso de uso, son quienes confirman que está terminado, son quienes lo aprueban. Es tarea del Especificador de Requisitos obtener de ellos la información suficiente y necesaria para terminar el caso de uso. Siempre tenemos a la mano el “¿Qué más debo saber acerca de esta funcionalidad?” Otras preguntas importantes son: ¿Quién más está interesado en este caso de uso? ¿Quién debería leerlo? ¿Quién debería aprobarlo?
Una vez se tiene esa información, el revisor del caso de uso, si existe, puede indagar sobre el número de personas que leyeron y aprobaron el caso de uso para establecer si eso constituye una muestra representativa para dar por terminado el caso de uso.
En el ejemplo, puesto que el Pasajero es un actor externo a la compañía, alguien dentro de ésta es quien lo representa, es decir, es quien decide cómo quiere que los clientes de la aerolínea perciban el sistema. Por ello es importante documentar desde el principio del proyecto, no solo quienes son los usuarios finales, sino quienes serán sus representantes a lo largo del ciclo de vida.
¿La secuencia de comunicación entre el actor y el caso de uso cumple con las expectativas del usuario?
Es más que evidente. Otra vez, es sólo el usuario y nadie más que el usuario, quien decreta la correcta finalización del caso de uso. Por ello el caso de uso no debe incluir aspectos técnicos o detalles del diseño o implementación del mismo.
Se evidencia la participación dinámica y constante del usuario o de un grupo de usuarios durante la Ingeniería de Requisitos (por supuesto, también durante el resto del ciclo de vida, pero sin duda es esta etapa donde se hace más evidente la necesidad de contar con el mayor número de usuarios del producto).
El usuario regular no está interesado en conocer lo que ocurre “detrás del telón” del sistema. Para él sólo es importante el grupo de acciones donde él participa activamente, donde interactúa con el software y finalmente es quien indica si está satisfecho con lo que está documentado en el caso de uso.
Si, por ejemplo en el paso 6, dijéramos que la lista de vuelos se busca haciendo una intercalación multivía seguida de una selección por reemplazamiento, estaríamos adicionando detalles que confundirían innecesariamente al usuario común y corriente. Es más, ni siquiera tendríamos que mencionar las tablas y mucho menos los componentes involucrados en dicha búsqueda y selección.
¿Está claro cómo y cuándo comienzan y terminan los flujos de eventos del caso de uso?
Si mantenemos el caso de uso en su estado más simple, aunque con el suficiente detalle para pasar al siguiente estado, los momentos de inicio y finalización de cada secuencia de acciones deberían estar a la vista de todos.
Los errores más comunes se encuentran en las secuencias alternativas, al decidir si la acción retorna a la secuencia básica o si el caso de uso termina. También pasa que si el caso de uso tiene varios escenarios a partir de una misma acción, luego de escribir dos o tres de ellos perdamos el foco de la “horizontalidad” del caso de uso y empezamos a cubrir detalles que nos podrían llevar, desde el punto de vista del usuario, por caminos insubstanciales del caso de uso.
¿Los subflujos en el caso de uso están modelados con precisión?
Luego de mi lectura fundamental # 1 no volví a mencionar la palabra modelo. No es que cuando estamos documentando casos de uso no estamos modelando, es que precisamente a veces perdemos la conciencia de que es eso lo que estamos haciendo, aunque sea puramente texto lo que escribamos. De hecho, el modelo de casos de uso es mayormente texto.
Así que cuando hablo de modelar subflujos del caso de uso con precisión, me refiero a que proporcionemos toda la información necesaria al modelo: lugar donde se inicia el subflujo, motivo del subflujo, acciones del subflujo y método de terminación del subflujo.
Cabe decir que los subflujos no son sólo secuencias alternativas, también pueden ser “porciones” de la secuencia básica, normalmente, porciones pequeñas y extremadamente simples.
Sí, el concepto clave es simplicidad.
¿Está claro quién quiere ejecutar el caso de uso? ¿El propósito del caso de uso también está claro?
Una cosa es especificar un actor y otra es si ese actor representa adecuadamente al grupo de usuarios que ejecutará el caso de uso. Es posible que haya diferencias entre lo que piensa el representante de los usuarios asignado para proporcionar la información de, revisar y aprobar el caso de uso, y lo que finalmente quede documentado.
Un trabajo de campo, donde aseguremos que varios usuarios lean y acuerden el caso de uso ayuda mucho en estos casos. Así evitamos esa escena de terror que más de uno hemos vivido cuando mucho tiempo después de la especificación, probablemente durante las pruebas de certificación o ya en producción, nos preguntan “¿Quién dijo eso?”
De otro lado, el propósito puede estar implícito a lo largo y ancho de la declaración del caso de uso, o bien puede estar explícito en una sección inicial del mismo. Esta última opción es mi favorita porque permite verificar la consistencia del caso de uso lo mismo que medir su valor para el sistema y para los usuarios.
El propósito, si se especifica, debe escribirse a priori, quizás durante la etapa de descubrimiento del caso de uso, para que posea la menos subjetividad posible. Por supuesto, siempre podemos afinarla, aún antes de presentar el caso de uso para su última revisión.
El propósito debe incluir lo que el actor consigue del caso de uso y también lo que no consigue. Esto ayuda en las etapas posteriores al resto del equipo de desarrollo del proyecto a construir un sistema de alta usabilidad y gran aceptación.
Lo que Falta
Bien, hasta aquí la exploración a los primeros aspectos fundamentales que nos ayudan a decidir cuando un caso de uso está terminado. En la siguiente entrega volveré con el final de este artículo.
Esta lectura #4 continuará. Hasta entonces.
Lectura Fundamental Siguiente: “Casos de Uso: ¿Cuándo Están Terminados?... ¿Y qué hacer con ellos a continuación? Parte 2 de 2”