Una de las grandes preocupaciones de los desarrolladores de software a todo nivel es utilizar y sacarle provecho a las metodologías de desarrollo de aplicaciones. Si bien es cierto que apenas estamos creando la cultura para usar cualquier metodología, para adoptar una de ellas y adaptarla a nuestras necesidades (tropicalizar), unas necesidades que muchas veces están por debajo de las expectativas de uso de metodologías formales que demandan tiempo y recursos adicionales que en repetidas ocasiones no tenemos, creo que es importante que empecemos la discusión de si realmente estamos requiriendo emplear una de tantas, conociendo los aspectos más básicos de la que es considerada hoy una “potencia” en cuanto a procesos se refiere.
He aquí algunos conceptos:
El Proceso Unificado® es una metodología proporcionada por IBM Rational® para desarrollar sistemas con gran cantidad de software basado en componentes. El Proceso Unificado usa UML para preparar todas las plantillas y modelos del software en construcción. De hecho, UML es parte integral del método, fueron desarrollados en paralelo.
Las principales características del método son:
1. Dirigido por casos de uso
2. Centrado en la arquitectura
3. Iterativo e incremental
Un caso de uso es una pieza de funcionalidad del sistema que captura requerimientos funcionales. Esto posibilita pensar en términos del valor del sistema para los usuarios y no solo en términos de las funciones que debería tener el sistema. Basado en los casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que comprendan todos los casos de uso. Los desarrolladores revisan cada modelo sucesivo para ver si concuerdan con el modelo de casos de uso. Los evaluadores prueban la implementación para asegurarse de que los componentes del modelo de implementación implementen correctamente los casos de uso. De esta forma, los casos de uso no solo inician el proceso de desarrollo sino que lo enlaza paso a paso. Dirigido por casos de uso significa que el proceso de desarrollo sigue un flujo que se deriva de ellos.
De otra parte, el concepto de la arquitectura del software envuelve los aspectos estáticos y dinámicos más significativos de un sistema, dejando los detalles del mismo a un lado. Ahora bien, cualquier sistema de software tiene funcionalidad y forma. Ninguno de los dos es suficiente por sí solo. En este caso la funcionalidad corresponde a los casos de uso y la forma a la arquitectura. Por un lado, los casos de uso deben acoplarse en la arquitectura. De otra parte, la arquitectura debe tener espacio para la implantación de todos los casos de uso, en el presente y en el futuro del sistema. En realidad, ambos deben evolucionar en paralelo.
Por último, es práctico dividir un proyecto en pequeñas piezas o mini-proyectos. Cada uno de ellos es una iteración que resulta en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo y los incrementos al crecimiento en el producto. Los desarrolladores basan la selección de lo que va a ser implementado en una iteración en dos factores. Primero, la iteración trata con un grupo de casos de uso que extienden la usabilidad de los productos desarrollados hasta ese punto. Segundo, la iteración trata con los riesgos más importantes. Las iteraciones sucesivas se construyen sobre los artefactos de desarrollo desde el estado en el que estaban al final de la iteración previa. Por supuesto, un incremento no necesariamente es aditivo. Especialmente en las fases tempranas del ciclo de vida, los desarrolladores pueden reemplazar un diseño superficial por uno más detallado o sofisticado. En las fases posteriores los incrementos son típicamente aditivos.
Entre otros, estos son algunos beneficios de un proceso iterativo controlado:
1. Reduce el riesgo del costo a los gastos de un solo incremento. Si los desarrolladores necesitan repetir la iteración, la organización pierde solo el esfuerzo de una iteración, no el valor del producto completo.
2. Reduce el riesgo de no tener el producto en el tiempo planeado.
3. Aumenta la velocidad del esfuerzo de desarrollo, esto es, la productividad, dado que los desarrolladores se enfrentan a objetivos pequeños y no a un objetivo mayor que puede causar letargos en el proyecto.
4. Es adaptativo, o sea, es fácil de adaptar a cambios en los requerimientos.
El Proceso Unificado® se divide en cuatro fases: Concepción, Elaboración, Construcción y Transición. Cada una de estas fases se divide a su vez en un número dado de iteraciones y cada iteración consta de las etapas conocidas del ciclo de vida de un sistema: Modelamiento del Negocio, Estudio de Requerimientos, Análisis y Diseño, Implementación, Pruebas y Distribución. En este proceso, los entregables se proporcionan por iteraciones. En cada iteración se entrega: 1. un ejecutable que cumple los criterios de aceptación y 2. Documentación de las etapas que produjeron el ejecutable (Análisis, Diseño, Implementación, Pruebas).
Durante la fase de Concepción, se desarrolla una visión del producto final y se presenta el modelo del negocio para el producto. Esencialmente esta fase responde las siguientes preguntas:
1. Qué va a hacer el sistema para cada uno de los grupos de usuarios?
2. Cómo podría ser la arquitectura del sistema?
3. Cuál es el plan y cuánto costará desarrollar el producto?
En particular, la etapa de Modelamiento del Negocio que hace parte de esta fase, busca describir tanto un modelo de las funciones pensadas para el sistema como las entidades que entregan esa funcionalidad, para comprender mejor los casos de uso del negocio, y cómo estas entidades interactúan. El propósito del modelamiento del negocio es doble:
1. Entender la estructura y dinámica de la organización
2. Asegurar que los clientes, los usuarios finales y los desarrolladores tienen un entendimiento común de la organización.
Durante la fase de Elaboración, la mayoría de los casos de uso del producto son especificados en detalle y se diseña la arquitectura del sistema. Al final de esta etapa, el Gerente del Proyecto está en una posición de planear las actividades y estimar los recursos requeridos para completar el proyecto.
Más adelante, en la fase de Construcción, se construye el producto. En esta fase se requieren la mayoría de los recursos, la arquitectura del sistema es estable pero se pueden discutir cambios menores a la misma. Al final de esta fase el producto contiene todos los casos de uso que la Gerencia y los usuarios del sistema acordaron desarrollar.
La fase de Transición, al final del proceso, cubre el periodo durante el cual el producto se mueve de las versiones de prueba, pasando por refinamientos sucesivos, hasta el producto final, este se instala, se capacita a los usuarios, el producto entra en un ciclo de mantenimiento y se da por terminado el proyecto.
Así comienza la historia. Saber que pasa antes y después de este capitulo será nuestra tarea en próximas entregas. Así es que manténganse en contacto.
Mientras tanto, comparte tus impresiones conmigo y con todos en la Red sobre este y otros temas. Puedes escribirme a lucho.salazar@gmail.com.
Luis Antonio Salazar Caraballo
Medellín, agosto 11 de 2003
No hay comentarios.:
Publicar un comentario