La Metodologa de Booch es una tcnica usada en ingeniera de software. Es un lenguaje de modelado de objetos y una metodologa ampliamente usada en el diseo de software orientado a objetos. Fue desarrollada por Grady Booch mientras trabajaba para Rational Software (hoy parte de IBM). Los aspectos notables de la metodologa de Booch han sido superados por el Lenguaje Unificado de Modelado, que combina elementos grficos de la metodologa de Booch junto a elementos de la tcnica de modelado de objetos y la Ingeniera de software orientada a objetos Los aspectos metodolgicos de la metodologa de Booch fueron incorporados en varias metodologas y procesos, siendo la principal de ellas el Proceso Racional Unificado (RUP).
ndice
1 Principios de desarrollo o 1.1 Adaptar el proceso o 1.2 Equilibrar prioridades o 1.3 Demostrar valor iterativamente o 1.4 Colaboracin entre equipos o 1.5 Elevar el nivel de abstraccin o 1.6 Enfocarse en la calidad 2 Ciclo de vida 3 Principales caractersticas 4 Fases 5 Artefactos 6 Un poco de historia 7 Comentarios sobre Metodologa 8 Enlaces externos
Principios de desarrollo
El RUP est basado en 6 principios clave que son los siguientes:
Adaptar el proceso
El proceso deber adaptarse a las necesidades del cliente ya que es muy importante interactuar con l. Las caractersticas propias del proyecto u organizacin, el tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto en un rea subformal para hacer un proceso de satisfaccin del software.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro.
El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.
Ciclo de vida
El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP. Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado del negocio y de requisitos. En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementacin de la nueva versin del producto. En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina vara.
Principales caractersticas
Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona puede desempear distintos roles a lo largo del proceso).
Fases
Establece oportunidad y alcance Identifica las entidades externas o actores con las que se trata Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: 'Proceso': Las etapas de esta seccin son: (Revise nuevamente la grfica)
La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:
Inicio (tambin llamado Incepcin o Concepcin). Elaboracin. Desarrollo (tambin llamado Implementacin, Construccin). Cierre (tambin llamado Transicin).
Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar.
Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Transicin: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura dinmica) realiza una serie de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema (entre otros). Estos artefactos (entre otros) son los siguientes: Inicio:
Elaboracin:
Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica
o o
Vista de Implementacin
o o o
Vista Conceptual
o
Modelo de dominio
Vista fsica
o Mapa de comportamiento a nivel de hardware. Diseo y desarrollo de casos de uso, o flujos de casos de uso arquitectnicos
Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura documentada responde adecuadamente a requerimientos funcionales y no funcionales.
Construccin:
Especificacin de requisitos faltantes Diseo y desarrollo de casos de uso y/o flujos de acuerdo con la planeacin iterativa Pruebas de los casos de uso desarrollados, y pruebas de regresin segn sea el caso
Transicin:
Un poco de historia
Los orgenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colabor con Boehm en la investigacin. En 1995 Rational Software compr una compaa sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los mtodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusin fue el Rational Objectory Process, la primera versin de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten. El primer libro para describir el proceso fue titulado "The Unified Software Development Process (ISBN 0-201-57169-2)" El Proceso Unificado de Desarrollo de Software (ISBN 0-20157169-2), y publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh.
En lo referente a iterativo e incremental, significa que el proyecto se divide en varios ciclos de vida (llamadas iteraciones) que deben dar como resultado un ejecutable. Por cada una de las iteraciones se va agregando requerimientos y sobre todo valor al cliente; por este motivo es incremental.