El problema del software se reduce a la
dificultad que afrontan los desarrolladores para coordinar las
múltiples cadenas de trabajo de un
gran proyecto de
software. El Proceso
Unificado de Desarrollo
(RUP) es una solución a este problema porque:
Proporciona una guía para organizar las actividades
de un equipo.Dirige las tareas de cada desarrollador por separado y las
del equipo como un todo.Especifica los artefactos a desarrollar.
Ofrece criterios para el control, la medición de
los productos y actividades del proyecto.
RUP utiliza el UML para preparar
los esquemas del software y esta basado en componentes de
software interconectados entre si a través de interfaces
bien definidas. Tiene como características principales que
es dirigido por casos de uso, centrado en la arquitectura y es
iterativo e incremental. Es práctico subdividir el trabajo en
partes más pequeñas o mini-proyectos donde
cada uno resulta en un incremento o versión del producto.
El ciclo de vida
un proyecto consta de cuatro fases: concepción,
elaboración, construcción y transición. Cada fase
termina con un hito donde se dispone de un conjunto de artefactos
(documentos,
modelos,
código
ejecutable, etc), su objetivo
más importante es que los directores del proyecto pueden
tomar decisiones para continuar a la siguiente fase. Al finalizar
las fases del ciclo de vida se termina una versión del
producto.
En la fase de concepción se desarrolla una descripción del producto final a partir de
una buena idea y se presenta el análisis del negocio para el producto.
Durante la fase de elaboración se especifican en
detalle la mayoría de los casos de uso del producto y se
diseña la arquitectura del sistema. Al final
de esta fase el director esta en disposición de planificar
las actividades y estimar los recursos
necesarios para terminar el proyecto.
En la fase de construcción se crea el producto, la
arquitectura crece hasta convertirse en sistema completo y ya
contiene todos los casos de uso acordados.
En la fase de transición se realizan las pruebas del
sistema con un número reducido de usuarios para detectar
defectos y deficiencias. Los desarrolladores corrigen errores e
introducen mejoras propuestas.
Cada fase puede tener varias iteraciones y cada
iteración puede abracar varios procesos del
flujo de trabajo.
Los grupos de
desarrollo de software trabajando de una forma iterativa tienen
algunos miembros que sobrepasan la planificación y logran un conjunto de metas
hechas para iteraciones posteriores. La técnica de
iteraciones solapadas puede ser beneficiosa si es comprendida y
manipulada de forma correcta.
Iteraciones estándar l1, l2 y l3, ocurren de forma
secuencial de izquierda a derecha, ocurriendo de forma secuencial
hacia abajo en cada iteración (Requirements, Design, Code
and Test).
Estas iteraciones pueden solaparse como muestra el
siguiente gráfico:
En el siguiente a continuación se aprecia las
iteraciones solapadas controladas por la técnica de
time-boxes:
Esta técnica de iteraciones solapadas tiene los
siguientes riesgos:
Incrementa el trabajo.
Incrementa el costo de cancelación de un
proyecto.Disminución de la moral.
Impacto en el proceso de mejora.
Mentalidad de disciplina.
El peligro de la cascada.
Para evitar las iteraciones solapadas en el proyecto se puede
utilizar al personal en:
Dos proyectos.
Múltiples roles.
Aceptar la situación de pérdida de
tiempo.Reducir el tamaño del grupo.
Las iteraciones solapadas pueden ser de gran ayuda, pero debe
tener un riguroso control para que
no se conviertan en un arma de doble filo, para ello se deben
seguir estas dos importantes reglas:
No permitir solapamiento de iteraciones durante la
elaboración, si en la construcción.Durante la construcción no permitir ir más
allá de una iteración.
Referencias Bibliográficas:
Philippe Kruchten. "The Racional Unified Process: An
introduction". Addison – Wesley. 2000.Barry Boehm. "Get ready for Agile Methods , with care".
Computer, pp. 64 – 69, 2002.
Página siguiente  |