50

PASTE UNO SOFTWAKE

EL PROCESO DEL

^CONSEJoJ^ Aunque un proceso seaprescriptivo,nose debe osumii que ste es esttico. Los modelos piesaiptivos se deben adoptar a las personas, al problema y al proyecto.

En las secciones siguientes se examinarn varios de los modelos prescriptivos del proceso de software. Se les llama "prescriptivos" porque prescriben un conjunto de elementos del proceso: actividades del marco de trabajo, acciones de ingeniera del software, tareas, productos del trabajo, aseguramiento de la calidad, y mecanismos de control del cambio para cada proyecto. Cada modelo de proceso prescribe tambin un/lujo de trabajo; esto es, la forma en la cual los elementos del proceso se inte-rrelacionan entre s. Todos los modelos de proceso del software se ajustan a las actividades genricas del marco de trabajo descritas en el captulo 2, pero cada uno aplica una importancia diferente a estas actividades y define un flujo de trabajo que invoca cada actividad del marco de trabajo (as como acciones y tareas de la ingeniera del software) de una manera diferente. JL2 ____El. MODELO EN CASCADA Existen ocasiones en que los requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comunicacin a travs del despliegue de una manera casi lineal. Esta situacin se encuentra a veces cuando es necesario hacer adaptaciones o mejoras bien definidas a un sistema existente (por ejemplo, una adaptacin a un software contable debido a los cambios en las regulaciones del gobierno). Esto puede ocurrir tambin en un nmero limitado de proyectos de nuevos desarrollos, pero slo cuando los requerimientos estn bien definidos y son estables en forma razonable. El modelo en cascada, algunas veces llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial2 hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y que contina con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado. El modelo en cascada es el paradigma ms antiguo para la ingeniera del software. Sin embargo, en las dcadas pasadas, las crticas a este modelo de proceso han

FIGURA 3.1

El modelo en cascada.

Comunicacin
inicio del proyecto recopilacin de requisitos

Planeacin
estimacin itinerario seguimiento

Modelado
anlisis

Construccin
cdigo
prueba

diseo

Despliegue
entrega soporte retroalimentacin

A pesar de que el modelo en cascada original, que propuso Winston Royce [ROY70], prev "ciclos de retroalimentacin", la inmensa mayora de las organizaciones que aplica este modelo de proceso lo trata como si fuera estrictamente lineal.

CAPITULO 3

MODELOS PRESCRIPTIVOS DE PROCESO

51

ocasionado que aun sus ms fervientes practicantes hayan cuestionado su eficacia [HAN95]. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada estn:
i Uiil

1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto acta. 2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explcita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 3. El cliente debe tener paciencia. Una versin que funcione de los programas estar disponible cuando el proyecto est muy avanzado. Un error grave ser desastroso si no se detecta antes de la revisin del programa. En un anlisis interesante de proyectos reales, Bradac [BRA94J concluy que la naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser ms comn al principio y al final del proceso secuencial. En la actualidad, el trabajo del software est acelerado y sujeto a una cadena infinita de cambios (de caractersticas, funciones y contenido de la informacin). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo. puede servir como un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el trabajo se realiza, hasta su conclusin, de una manera lineal.

En muchas situaciones los requisitos iniciales del software estn bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Adems, quiz haya una necesidad imperiosa de proporcionar de manera rpida un conjunto limitado de funcionalidad para el usuario y despus refinada y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseado para producir el software en forma incre-mental.

"Con (temosiado frecuencia, el trabajo en el software sigue la primera ley dei ciclismo: no importa bocio dnde vayas, es montaa arriba y contra el viento.'

Annimo

CAPTULO 3

MODELOS PRESCRIPTIVOS DE PROCESO

67

EL PROCESO UNIFICADO ______________________________

En su libro fundamental sobre el proceso unificado, Ivar Jacobson, Grady Booch y james Rumbaugh [JAC99] exponen la necesidad de un proceso de software "guiado por los casos de uso, de arquitectura cntrica, iterativo e incrementar'. Estos autores establecen: En la actualidad la tendencia en el software se encamina a sistemas mayores y complejos. Eso se debe en parte al hecho de que las computadoras se volvan ms poderosas cada ao, lo que alentaba que los usuarios esperaran ms de ellas. Esta tendencia tambin la impuls el uso expandido de Internet para el intercambio de todo tipo de informacin. Nuestro apetito por un software cada vez ms complejo crece en la medida en la que aprendemos cmo puede mejorarse un producto desde que sale uno hasta que llega el otro. Necesitamos un software que se adapte mejor a nuestras necesidades, pero que, a su vez, haga el software ms complejo. En resumen, queremos ms.

mejores rasgos y caractersticas de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principios del desarrollo gil de software (captulo 4). El proceso unificado reconoce la importancia de la comunicacin con el cliente y los mtodos encaminados a describir el punto de vista del cliente con respecto a un sistema (por ejemplo, el caso de uso'4). El PU enfatiza el importante papel de la arquitectura de software, y "ayuda al arquitecto a enfocarse en las metas correctas, como el entendimiento, el ajuste a los cambios futuros y la reutilizacin" [JAC99]. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno. En esta seccin se presenta una visin general de los elementos clave del proceso unificado. En la parte 2 de este texto se analizan los mtodos que pueblan el proceso y las tcnicas y notaciones complementarias del UML,' las cuales se requieren
De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los al aplicar el proceso unificado en el trabajo real de la ingeniera del software. 3.6.1 Una breve historia

Durante la dcada de 1980 y al principio de la dcada siguiente, los mtodos y lenguajes de programacin orientados a objetos (OO)16 obtuvieron una amplia difusin entre la comunidad de la ingeniera del software. Durante el mismo periodo se pro-

14 Un caso de uso (captulos 7 y 8) es un contexto narrativo o plantilla que describe una caracterstica o funcin del sistema desde el punto de vista del usuario. El caso de uso lo escribe el usuario y sirve como una base para la creacin de un modelo de anlisis ms completo. 15 El UML (Unified Modeling Language) se ha convertido en la notacin ms utilizada para el modelado del anlisis y el diseo. Representa una unin entre tres importantes notaciones orientadas a objetos. 16 Si el lector no se encuentra familiarizado con los mtodos orientados a objetos, en los captulos 8 y 9 se presenta una breve revisin general de ellos. Para una presentacin ms detallada vase [REE02] [STlOlj o (FOW99|.

PARTE UNO

EL PROCESO DEL SOFTWARE

puso una amplia variedad de anlisis y diseo orientados a objetos (AOO y DOO) y se introdujo un modelo de proceso orientado a objetos de propsito general (similar a los modelos evolutivos presentados en este captulo). Al igual que la mayora de los paradigmas "nuevos" para la ingeniera del software, los seguidores de cada uno de los mtodos de AOO y DOO argumentaban acerca de cul de ellos era el mejor, pero ningn mtodo o lenguaje domin la escena de la ingeniera del software. Al principio de la dcada de 1990, James Rumbaugh [RUM9U, Grady Booch IB0094] e Ivar Jacobson [JAC92] comenzaron a trabajar en un "mtodo unificado" que combinara las mejores caractersticas de cada uno de sus mtodos individuales y adoptara caractersticas adicionales que propusieran otros expertos (por ejemplo, [WIR90]) en el campo OO. El resultado fue el lenguaje de modelado unificado (UML, por sus siglas en ingls) que contiene una notacin robusta para el modelado y el desarrollo de sistemas OO. Para 1997, el UML se convirti en un estndar de la industria para el desarrollo de software orientado a objetos. Al mismo tiempo, Rational Corporation y otras firmas desarrollaron herramientas automticas para apoyar los mtodos del UML. El UML proporciona la tecnologa necesaria para apoyar la prctica de la ingeniera del software orientada a objetos, pero no provee el marco de trabajo del proceso que gue a los equipos en la aplicacin de la tecnologa. En los aos siguientes, Jacobson, Rumbaugh y Booch desarrollaron el proceso unificado, un marco de trabajo para la ingeniera del software orientada a objetos, mediante la utilizacin del UML. En la actualidad, el proceso unificado y el UML se emplean de forma amplia en proyectos OO de todos los tipos. El modelo iterativo e incremental que propone el PU puede y debe adaptarse para satisfacer necesidades de proyecto especficas. Como consecuencia de la aplicacin del UML se puede producir un arreglo de productos de trabajo (por ejemplo, modelos y documentos). Sin embargo, stos los reducen los ingenieros de software para lograr que el desarrollo sea ms gil y reactivo ante el cambio. 3.6.2 Fases del proceso unificado17

Se han analizado cinco actividades genricas del marco de trabajo y se ha explicado que stas se pueden aplicar para describir cualquier modelo de proceso del software. El proceso unificado no es la excepcin. En la figura 3.7 se muestran las "fases" del proceso unificado (PU) y se relacionan con las actividades genricas que se trataron en el captulo 2. La fase de inicio del PU abarca la comunicacin con el cliente y las actividades de planeacin. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el

17 Algunas veces el proceso unificado se llama proceso unificado racional (PUR) despus de que lo respaldara la Rational Corporation, un contribuyente importante en el desarrollo y refinamiento del proceso y un constructor de ambientes completos (herramientas y tecnologa).

CAPTULO 3 PROCESO

MODELOS PRESCRIPTIVOS DE

69

sistema, y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a travs de un conjunto preliminar de casos de uso que describen cules caractersticas y funciones son deseables para cada clase importante de usuarios. En general, un caso de uso describe una secuencia de acciones que desarrolla un actor (por ejemplo, una persona, una mquina, otro sistema) cuando ste interacta con el software. Los casos de uso ayudan a identificar el mbito del proyecto y proporcionan una base para la planeacin de ste. En este punto, la arquitectura no es ms que un esquema tentativo de los subsistemas ms importantes y de las funciones y caractersticas que los forman. Despus, la arquitectura se refinar y expandir en un conjunto de modelos que representarn visiones diferentes del sistema. La planeacin identifica recursos, evala los riesgos importantes, define un itinerario y establece una base para las fases que se aplicarn conforme se desarrolle el incremento del software. La fase de elaboracin abarca la comunicacin con el cliente y las actividades de modelado del modelo genrico del proceso (figura 3.7). La elaboracin refina y expande los casos de uso preliminares que se desarrollaron como una parte de la fase de inicio; adems, expande la representacin arquitectnica para incluir cinco visiones diferentes del software: el modelo de caso de uso, el modelo de anlisis, el modelo de diseo, el modelo de implementacin y el modelo de despliegue. En algunos casos, la elaboracin crea una "lnea de base arquitectnica ejecutable" [ARL02] que representa un sistema ejecutable en su "primer corte".18 La lnea de base arquitectnica demuestra la viabilidad de la arquitectura, pero no proporciona todas las

Elaboracin

Inicia

Construccin Transicin

Produccin

18 Es importante destacar que la directriz arquitectnica no es un prototipo que se deseche (seccin 3.4.1). En lugar de ello la directriz se aprovecha durante la siguiente fase del PU.

PARTE UNO

EL PROCESO DEL SOFTWARE

caractersticas y funciones necesarias para utilizar el sistema. Adems, el plan se revisa de manera cuidadosa al trmino de la fase de elaboracin para asegurar que el mbito, los riesgos y los datos entregados an son razonables. Las modificaciones al plan se deben hacer en este momento. La fase de construccin del PU es idntica a la actividad de construccin definida para el proceso genrico del software. Si se utiliza el modelo arquitectnico como entrada, la fase de construccin desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de anlisis y diseo iniciados durante la fase de elaboracin se completen para reflejar la versin final del incremento del software. Todas las caractersticas y funciones necesarias y requeridas del incremento del software (por ejemplo, la entrega) se implementan en cdigo fuente. Conforme los componentes estn en proceso de implementacin, se disean y ejecutan pruebas de unidad para cada uno de ellos. Adems, se realizan las actividades de integracin (ensamblaje de componentes y pruebas de integracin). Los casos de uso se utilizan para derivar un conjunto de pruebas de aceptacin que se ejecutan antes del inicio de la siguiente fase del PU. La fase de transicin del PU abarca las ltimas etapas de la actividad genrica de construccin y la primera parte de la actividad genrica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta, 19 y la retroalimentacin del usuario reporta tanto defectos como cambios necesarios. Adems, el equipo de software crea la informacin de soporte necesaria (por ejemplo, manuales del usuario, guas de resolucin de problemas, procedimientos de instalacin) para el lanzamiento. Al final de la fase de transicin, el incremento de software se convierte en un lanzamiento de software utilizable. La fase de produccin del PU coincide con la actividad de despliegue del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo (infraestructura), y se reciben y evalan los informes de defectos y los requerimientos de cambios. Es probable que mientras se realizan las fases de construccin, transicin y produccin ya se hayan iniciado los trabajos para el siguiente incremento del software. Esto significa que las cinco fases del PU no suceden en una secuencia, sino en una concurrencia por etapas. A lo largo de las fases del PU se distribuye un flujo de trabajo de ingeniera del software. En el contexto del PU, un flujo de trabajo es anlogo a un conjunto de tareas (definido en el captulo 2). Esto es, un flujo de trabajo identifica las tareas necesarias para completar una accin importante de ingeniera del software y los productos de

19 En la prueba beta, una accin de prueba controlada (captulo 13), el software lo utilizan usuarios finales reales, con la intencin de descubrir defectos y deficiencias. Se establece un esquema de informe de defectos y deficiencias de manera formal, y el equipo de software evala la retroalimentacin.

CAPTULO 3

MODELOS PRESCRIPTTVOS DE PROCESO

71

trabajo que se producen como consecuencia de la realizacin exitosa de tareas. Se debe destacar que no todas las tareas identificadas para un flujo de trabajo del PU se realizan para cualquier proyecto de software. El equipo debe adaptar el proceso (acciones, tareas, subtareas y productos de trabajo) para satisfacer sus necesidades. 3.6.3 Productos de trabajo del proceso unificado

En la figura 3.8 se ilustran los productos de trabajo clave que se produjeron como consecuencia de las cuatro fases tcnicas del PU. Durante la fase de inicio, el propsito es establecer una "visin" general para el proyecto, identificar un conjunto de requisitos de negocios, formar un caso de negocios para el software y definir los riesgos del proyecto y del negocio que pudieran representar un obstculo para el xito. Desde el punto de vista del ingeniero de software, el producto de trabajo ms importante generado durante la etapa de inicio es el modelo de caso de uso: una coleccin de casos de uso que describen la forma en que actores externos ("usuarios" humanos y no humanos del software) interactan con el sistema y obtienen valor a partir de ste. En esencia, el modelo de casos de uso es una coleccin de escenarios de uso con plantillas estandarizadas que implican caractersticas y funciones del software mediante la descripcin de una serie de condiciones previas, un flujo de eventos o un escenario, y un conjunto de condiciones exteriores para la interaccin representada. En un inicio, los casos de uso describen requisitos al nivel del dominio de negocios (por ejemplo, el grado de abstraccin es alto). Sin embargo, el modelo de casos de uso se refina y elabora conforme cada fase del PU se ejecuta y sirve como una entrada importante para la creacin de productos de trabajo subsecuentes. Durante la fase de inicio slo se completa entre el 10 y 20 por ciento de los casos de uso. Despus de la elaboracin, se ha creado entre un 80 y 90 por ciento del modelo. La fase de elaboracin produce un conjunto de productos de trabajo que elabora requisitos (incluso requisitos no funcionales20), as como una descripcin arquitectnica y un diseo preliminar. Cuando el ingeniero de software inicia con el anlisis orientado a objetos, el objetivo primordial es definir un conjunto de clases de anlisis que describan en forma adecuada el comportamiento del sistema. El modelo de anlisis del PU es un producto de trabajo que se desarrolla como consecuencia de esta actividad. Los paquetes de clases y anlisis (colecciones de clases) definidos como una parte del modelo de anlisis se refinan despus en un modelo de diseo, el cual identifica clases de diseo, subsistemas y las interfases entre los subsistemas. Los modelos de anlisis y diseo expanden y refinan una representacin evolutiva de la arquitectura del software. Adems, en la fase de elaboracin se revisan los riesgos y el plan de proyecto para asegurar que cada uno de ellos conserve su validez. La fase de construccin produce un modelo de implementacin que traduce las clases de diseo en componentes de software que se construirn para ejecutar el sis________ ,
20 Requisitos que no se pueden deducir del modelo de caso de uso.

72

PARTE UNO SOFTWARE

EL PROCESO DEL

tema, y un modelo de despliegue convierte los componentes en el ambiente fsico de computacin. Por ltimo, un modelo de prueba describe las pruebas empleadas para asegurar que los casos de uso se reflejen de manera apropiada en el software que se ha construido. La fase de transicin entrega el incremento del software y evala los productos de trabajo elaborados durante la etapa en que los usuarios finales trabajan con el software. En esta etapa se produce la retroalimentacin proveniente de las pruebas beta y los requerimientos cualitativos de cambio.

Los modelos prescriptivos del proceso de software se han aplicado durante muchos aos en un esfuerzo encaminado a ordenar y estructurar el desarrollo del software. Cada uno de estos modelos convencionales sugiere un flujo de proceso que de alguna forma es diferente, pero todos realizan el mismo conjunto de actividades genricas del marco de trabajo: comunicacin, planeacin, modelado, construccin y despliegue. El modelo en cascada sugiere una progresin lineal de actividades del marco de trabajo que a menudo resulta inconsistente con la realidad moderna en el mundo del software (por ejemplo, con el cambio continuo, los sistemas en evolucin, las fechas de entrega restringidas). Sin embargo, este modelo se puede aplicar en situaciones en las cuales los requisitos estn bien definidos y son estables.