Aspectos Generales

El Proceso Unificado de Rational (RUP) constituye un proceso de Ingeniería de Software

desarrollado por Rational Software. Este proceso “...captura muchas de las mejores prácticas en el desarrollo
moderno de software y las presenta en una forma que puede ajustarse a la medida a una amplia gama de
proyectos y organizaciones” (Krutchen, 1999: ix).

Las mejores prácticas de la Ingeniería de software se pueden sintetizar en los seis puntos que
aparecen a continuación:
Desarrollo Iterativo del Software Modelado Visual del Software
Gestión de Requerimientos Verificación de Calidad del Software
Uso de arquitecturas basadas en componentes Control de Cambios

A continuación realicemos un breve recorrido por cada una de las Mejores Prácticas de la
Ingeniería del Software planteadas.

Desarrollo Iterativo del Software

Los procesos de desarrollos de software clásicos aplican el modelo de cascada o Waterfall, tal y
como aparece indicado en la figura. En este enfoque, el desarrollo del software sigue una orientación lineal
desde el Análisis de Requerimientos o Estudio Preliminar, pasando por el Análisis y Diseño, la
Implementación e Integración, la Prueba, y por último la Distribución del software. El principal problema de
este modelo de desarrollo radica en el impacto que sobre el desarrollo ocasiona el deshacer errores
cometidos en etapas anteriores, lo cual se traduce en un alto costo de proyección.

Requerimiento
Análisis
Diseño
Codificación
Prueba

TIEMPO

Figura 1. Modelo de Ciclo de Vida en Cascada (Waterfall)

Es importante considerar que “... si no atacamos en forma activa los riesgos ellos nos atacaran a
nosotros...”, (Tom, 1988: p.73).

05/03/02 p. 1
 Como una alternativa más moderna al ciclo de desarrollo en cascada ha surgido uno que se basa en
la evolución a través del tiempo, del producto de software a obtener. Con cada iteración el producto que se
obtiene adquiere nuevo valor agregado, y cada iteración se enfoca a abordar cada vez aquellos aspectos de
interés para la iteración.

... Planeamiento Requerimiento Análisis y Codificación Prueba Distribución ...

Diseño tiempo

Itera otra vez

Figura 2. Ciclo de Desarrollo Iterativo e Incremental.

En este modelo el resultado final del desarrollo se alcanza por medio de sucesivas aproximaciones,
incorporando al producto de software nuevas características, haciéndolo crecer en valor hasta alcanzar el
producto final, listo para la implementación completa en la comunidad de usuarios finales.

El enfoque que se sigue es por lo tanto uno de continuo descubrimiento, invención e

implementación o codificación, donde en cada iteración se fuerza al equipo de desarrollo a conducir los
artefactos del proyecto a finalizar en una forma predecible y repetitiva (Krutchen, 1999: 8).

Este enfoque de desarrollo permite alcanzar una serie de ventajas y soluciones a problemas claves
del desarrollo de software (Krutchen, 1999: 8).
1. Mal entendimiento serio se hacen evidente
en forma temprana del ciclo de vida,
momento en el cual resulta posible
reaccionar ante ellos.
2. Garantiza una retro alimentación directa de
los usuarios, garantizando la identificación
de los requerimientos reales del sistema de
software
3. Se fuerza al equipo de desarrollo a enfocarse
en los requerimientos más críticos para el
proyecto, y permiten escudarse de aquellos
que les distraen de los riesgos reales del
proyecto.
4. Prueba continuas e iterativas que permiten
la evaluación objetiva del estado del
proyecto.
5. Se detectan en forma temprana las
inconsistencia entre requerimientos, diseño e
implementación.
6. La carga de trabajo del equipo, en especial
de los que efectúan las pruebas se esparce
más equitativamente a través del ciclo de
vida.
7. El equipo puede aplicar las lecciones
aprendidas y mejorar continuamente el
proceso.
8. Se le puede proporcionar evidencia concreta
sobre el avance del proyecto a los
interesados en el proyecto, a través del ciclo
de vida del desarrollo.

Gestión de Requerimientos

Un requerimiento representa una condición o capacidad que un sistema debe tener. El desafío actual
en la gestión de los requerimientos reside en el hecho de que ellos son dinámicos o cambiantes en el tiempo.

“Donde yo vivo, los clientes no saben lo que quieren, ellos especifican requerimientos en forma
mutuamente excluyente, cambian de opinión tan pronto como ven el primer sistema, discuten entre ellos
05/03/02 p. 2
mismo acerca del significado y que es más importante. Donde yo vivo la tecnología cambia, de tal forma
que lo que parece ser el mejor diseño para un sistema no resulta obvio a priori, y se encuentra sujeto a
cambios en el tiempo” (Sharon, 2000).

Pudiéramos considerar dos alternativas diferentes para enfrentar el problema anterior. Ellas se
definen a continuación.
Una posible solución al problema anterior puede ser contar con un proceso de documentación
detallada que no posee esa propiedad indeseable, y hacer que los clientes firmen el documento
de forma que no puedan sentirse inconforme con el producto de software una vez terminado,
luego se produciría un diseño detallado de cómo debería ser construido el sistema.
De otra parte podríamos aceptar que los requerimientos son cambiantes por naturaleza, y
desarrollar un proceso que se acomode a la razón con que cambien los requerimientos
(posiblemente semanal, o en algunos casos hasta diario), el cual siga siendo predecible, de bajo
riesgo y de fácil ejecución. Ese proceso deberá ser capaz de permitir evolucionar el diseño del
sistema en la dirección que se desee. No deberíamos sentirnos sorprendidos por la dirección que
tome el diseño, pues a priori estaríamos preparados para ello.

La última alternativa me parece que es mucho más razonable si partimos del hecho de que los
requerimientos son cambiantes por naturaleza.

Excepto para aquellos sistemas simples y triviales, resulta prácticamente imposible completar y
exhaustivamente definir los requerimientos de un sistema antes de iniciar el desarrollo del mismo
(Krunchten, 1999: 8).

Uso de Arquitectura basada en componentes

La arquitectura de un sistema constituye posiblemente el resultado más importante que puede ser
usado para gestionar los diferentes puntos de vistas de los stakeholders (usuarios finales, analistas,
programadores, integradores, expertos, y otros), y por ende controla el desarrollo iterativo e incremental del
sistema de software a través de su ciclo de vida.

La arquitectura de un sistema abarca el conjunto de decisiones importantes acerca de (Krunchten,

1999: 8):
La organización del sistema de software
Su comportamiento (expresado a través de los diagramas de interacción)
Selección de los elementos estructurales (componentes y sus interfaces) que componen el
sistema.
La interrelación entre los diferentes elementos estructurales.

La arquitectura del software no solo está relaciona con la estructura y el comportamiento, sino
además con restricción sobre su uso, seguridad, funcionalidad, rendimiento, reuso, facilidad de comprensión,
economía y tecnológica (Krunchten, 1999: 9-10).

05/03/02 p. 3
 Modelado Visual del Software
Un modelo es una simplificación de la realidad que describe a un sistema desde una perspectiva
particular. Los modelos se construyen a fin de que los investigadores e interesados, tengan una mejor
comprensión del sistema que estemos modelando(Krunchten, 1999: 11). Se elaboran modelos de sistemas
complejos por el mero hecho de que resulta poco práctico presentar el sistema como un todo.

El modelado de un sistema reviste vital importancia por cuanto nos ayuda a visualizar, especificar,
construir y documentar el comportamiento y estructura de la arquitectura de un sistema. Formalmente esto se
realiza a través de un lenguaje formal de modelación como puede ser UML (Unified Modeling Language),
OML (Object Modeling Language) u otros, que permitan que los stakeholders puedan comunicarse los unos
con los otros en forma efectiva y eficaz.

El modelamiento visual del software nos permite dar solución a los problemas básicos del desarrollo
intensivo de sistemas de software. Entre las soluciones podemos citar:
Especificación no ambigua de comportamiento a través de los escenarios y de los casos de usos.
Captura del Diseño del Software en forma no ambigua.
Exposición de arquitecturas no modulares y e inflexibles
Los detalles pueden aparecen solo cuando sean necesarios
Diseños no ambiguos revelan sus inconsistencias mar rápidamente.
La aplicación de calidad empieza con un buen diseño.
Uso de herramientas CASE para la modelación visual basadas en los lenguajes de modelación.

Verificación de la Calidad del Software

LA verificación de la funcionalidad de un sistema implica el desarrollo de pruebas para los diversos

escenarios claves, cada uno de los cuales representa algún aspecto del comportamiento deseado del sistema.
En la misma medida que desarrollamos en forma iterativa, en forma continua probamos el software para
verificar su correspondencia con los requerimientos, lo cual constituye un proceso de evaluación continua.

La verificación de la calidad de software ofrece un número de soluciones considerable a los

problemas principales del desarrollo de software(Krunchten, 1999: 13). Entre las soluciones mas importantes
podemos citar:
Evaluación del estado del proyecto se realiza en forma objetiva, debido a que los resultados de
las pruebas, y no la documentación en papel, se evalúan.
La evaluación muestra inconsistencias en los requerimientos, diseño e implementación.
Las pruebas y verificaciones se enfocan a áreas de alto riesgos, y por ende incrementan su
calidad y efectividad.
Existe una identificación temprana de los defectos, lo cual permite reducir en forma radical el
costo de los ajustes.
Las herramientas automatizadas para realización de pruebas proporcionan pruebas de
funcionalidad, confiabilidad y rendimiento.

05/03/02 p. 4
 Control de Cambios
Un desafío importante que como desarrolladores trabajamos en múltiples equipos, trabajando
posiblemente en diferentes sitios, juntos en múltiples iteraciones, múltiples lanzamientos, productos, y
plataformas. Si en ese infierno de trabajo caótico no existe una fuerza que imponga orden, resultaría casi
imposible alcanzar la meta del desarrollo que es justamente la de obtener un producto ajustado a los
requerimientos de los usuarios. Esa fuerza lo constituye justamente un control disciplinado de cambios y
configuración.

La coordinación de la iteración y de los lanzamientos involucran el establecimiento y liberación de

una línea base probada al concluir la iteración(Krunchten, 1999: 14). El mantenimiento del seguimiento de
los elementos de cada lanzamiento y entre los lanzamientos, (posiblemente paralelos) es esencial para
evaluar y en forma activa gestionar el cambio.

El control de los cambios al software ofrece una variedad de soluciones a las causas principales de
los problemas del desarrollo de software. Algunas soluciones importantes son las que a continuación se
indican:
El flujo de trabajo de cambio de requerimientos es definido y repetido.
Los requerimientos de cambios facilitan la comunicación clara
Espacios de trabajos independientes reducen interferencias entre miembros de equipos
trabajando en paralelo
Las estadísticas de razón de cambios proporcionan una muy buena métrica para evaluar en
forma objetiva el estado del proyecto.
Los espacios de trabajo contienen todos los artefactos, facilitando la consistencia.
La propagación del cambio es evaluable y controlable.
Los cambios pueden mantenerse e un sistema robusto y personalizable.

El Proceso Unificado de Rational

Tal y como aparece indicado en la figura 2, estamos en presencia de un enfoque de desarrollo
donde las metas para cada etapa se alcanza en forma iterativa e incremental a través del tiempo por medio de
fases (ver figura 3).

Planeación Elaboración Construcción Transición

Figura 3. Fases del Proceso de Desarrollo

Cada una de las iteraciones anteriores tienen objetivos específicos a cumplir una vez que ellas
culminan. Los objetivos o hitos para cada una son los que aparecen la siguiente tabla.
TABLA 1. Fase Hito Principal
HITOS POR
Planeación Especificación de la visión del producto final y
FASES definición del alcance del proyecto. Concluye con la
especificación de los objetivos: el producto.

05/03/02 p. 5
 Elaboración Planeamiento de las actividades y los recursos
requeridas. Especificar las características del producto y
diseñar la arquitectura. La fase termina con la
especificación de la arquitectura.
Construcción Construcción del producto y evolución de la visión, la
arquitectura, y el plan hasta que el producto esté listo
para la distribución final a la comunidad de usuarios. La
fase culmina con la capacidad operacional inicial.
Transición Transición del producto a la comunidad de usuarios
finales, lo que incluye la manufactura, entrega,
entrenamiento, soporte y mantenimiento del producto
hasta que los usuarios finales se sientan conformes con
la solución. Termina el ciclo con el lanzamiento del
producto.

Realizar la planificación de un proyecto, en toda su extensión, sin tener un conocimiento preciso de

muchos de los detalles del mismo, resulta algo absurda. Sería mucho mejor intentar planificar de acuerdo a
la misma medida en que se va progresando en cada una de las iteraciones del desarrollo del proyecto.

Lo anterior constituye la base para la realización de un plan de proyecto dividido en dos partes
fundamentales:
Plan Global del Proyecto
Plan Detallado de la Iteración
Cada uno de los cuales está orientado a determinados aspectos específicos, dado el momento en que
ellos se realizan.

El Plan Global del Proyecto

Su objetivo principal es el de definir las actividades de desarrollo en término de las fases y las
iteraciones requeridas para implementar el sistema. Este plan se recomienda actualizarlo por lo menos una
vez en cada fase.

Para planear cada una de las fases en el ciclo de desarrollo inicial (planeamiento) se deben realizar
algunas adivinanzas “educadas” sobres los hitos principales sobre la base de:
Experiencia con proyectos similares en naturaleza y dominio.
El grado de novedad
Restricciones específicas del entorno, tales como: tiempos de respuestas, distribución, y
seguridad, entre otras.
La madurez de la organización

No todas las fases son idénticas en términos de esfuerzo y cronograma de realización. A pesar de
que estas varían considerablemente en dependencia de las características propias de cada proyecto, un ciclo
típico inicial de desarrollo para un proyecto de mediano tamaño puede anticipar la siguiente distribución
entre esfuerzo y cronograma tal y como se presenta en la tabla siguiente:

05/03/02 p. 6
TABLA 2. Planeación Elaboración Construcción Transición
DISTRIBUCIÓN DE
Esfuerzo ~5 % 20 % 65 % 10 %
ESFUERZO Y
CRONOGRAMA PARA
CICLO DE DESARROLLO Cronograma 10 % 30 % 50 % 10 %
INICIAL TÍPICO

Gráficamente la distribución anterior puede ser vista de acuerdo a como se muestra en el gráfico que
aparece a continuación (RATIONAL SOFTWARE, 2000a).

70
50
60
40
50
30
40
20
30
20 10 Cronogram a
Esfuerzo 0
10
0

Figura 3. Gráfico de Distribución de Esfuerzo y Cronograma

Para un ciclo de evolución, las fases de planeación y elaboración resultarán considerablemente
menores. Si se cuenta con herramientas que automaticen una parte de la construcción se puede mitigar el
esfuerzo, haciendo que esta fase sea también mucho menor que la fase de planeación y elaboración juntas
(RATIONAL SOFTWARE, 2000a).

Por cada una de las fases del proceso de desarrollo se deberá estimar el número de iteraciones a
desarrollar, así como la fecha de inicio y de terminación de cada una, tal y como se presenta en la tabla.

TABLA 3. FASE NO DE ITERACIONES FECHA DE INICIO FECHA DE FIN

ESTIMACIÓN DE
Planeación
ITERACIONES Y
DURACIONES Elaboración
Construcción
Transición

¿Cómo determinar el número de iteraciones?

Complejidad Baja: Para un proyecto simple se puede pensar en tener una iteración por cada
fase (0 + 3 Iteraciones). Por ejemplo:

TABLA 4. FASE NO DE ITER. ¿PARA QUÉ?

CONFIGURACIÓN
PARA UN
05/03/02 p. 7
PROYECTO DE
COMPLEJIDAD
BAJA
 Planeación 0ó1 Producir un prototipo para probar conceptos,
una interfaz usuario superficial, etc.
Elaboración 1 Para producir un prototipo de la arquitectura.
Construcción 1 Construir el producto (versión beta)
Transición 1 Concluir el producto (versión final)

Complejidad Media: Para un proyecto mediano en complejidad, se pueden considerar las

distribuciones siguientes:
TABLA 5. FASE NO DE ITER. ¿PARA QUÉ?
CONFIGURACIÓN
Planeación 1 Producir algún prototipo.
PARA UN
PROYECTO DE Elaboración 2 Primera Establecer la Arquitectura base.
COMPLEJIDAD
Segunda Refinar la Arquitectura
MEDIANA
Construcción 2 Para producir una madurez incremental del
producto.
Transición 1 Para transitar de la capacidad operacional
inicial al producto final.

Complejidad Alta: Para un proyecto grande, se deben considerar las distribuciones

siguientes: Cuando se tiene mucho desconocimiento, involucra nuevas tecnología, altos
riesgos, etc.
TABLA 6. FASE NO DE ITER. ¿PARA QUÉ?
CONFIGURACIÓ
Planeación 1 Producir algún prototipo.
N PARA UN
PROYECTO DE Elaboración 3 Primera Establecer la Arquitectura base.
COMPLEJIDAD
Segunda y Tercera Refinar la
ALTA
Arquitectura
Construcción 3 Para producir una madurez incremental del
producto.
Transición 2 Para mejorar y transitar de la capacidad
operacional inicial (de las versiones) al
producto final.

Se pueden tener muchas variaciones dependiendo de los riesgos, tamaño y complejidad del
producto:
Si el producto está orientado para un dominio completamente nuevo se necesitará
adicionar algunas iteraciones en la fase de planeación / iniciación para consolidar los
conceptos, mostrar algunos prototipos de dominio a los clientes o usuarios finales, elaborar
una respuesta sólida a la Solicitud Propuesta.
Si una arquitectura nueva debe desarrollarse o existe una gran cantidad de
modelamiento de casos de uso, o existen muchos riesgos desafiantes, deberá planear tener
dos o tres iteraciones en la fase de elaboración.
Si el producto es grande y complejo y a desarrollarse a través de un período largo de
tiempo, se debe planear tener tres o mas iteraciones en la fase de construcción.

05/03/02 p. 8
 Si se debe minimizar el tiempo de entrega o se desea mayor tiempo para adaptarse a
los usuarios finales después de un cierto periodo de uso se deberá planear tener varias
iteraciones en la fase de transición, debido a que posiblemente se vayan incorporando un
conjunto reducido de funcionalidades.

¿Cómo estimar la duración de la iteración? Una iteración se inicia con la planeación y los
requerimientos, y culmina con una entrega externa o interna.

La rapidez con que se puede iterar depende fundamentalmente del tamaño de la organización de
desarrollo. En ocasiones el tamaño de la organización o del grupo de desarrollo puede convertirse en un
obstáculo, que impida obtener el resultado esperado.

Otro factor a tener en cuenta lo constituye el grado de familiaridad de la organización con el

enfoque iterativo, que incluye una organización estable y madura, el nivel de automatización usado por el
equipo para gestionar código, información distribuida (WEB interno), automatización de las pruebas, etc.

A continuación se relacionan algunos datos empíricos que pueden tomarse como base para las
estimaciones:
TABLA 7. SLOC1 NO DE DESARROLLADORES DURACIÓN DE LA ITERACIÓN
DURACIÓN PARA
10,000 5 1 semana
PROYECTOS DE
TAMAÑOS TÍPICOS 50,000 15 1 mes
500,000 45 6 meses
1,000,000 100 1 año

Para cada una de las fases se debe definir cuales son los principales hitos que marcan el conclusión
de la fase. La tabla siguiente muestra la especificación de hitos por fases.
TABLA 8. HITOS FASE DESCRIPCIÓN HITOS
POR FASES
Planeación
Elaboración
Construcción
Transición

Posteriormente cada una de las fases anteriores se dividen en iteraciones, reflejando los hitos
principales y los riesgos a tener en cuenta en cada iteración. La tabla siguiente presenta una propuesta para
reflejar la información requerida (6 3 iteraciones):
TABLA 9. FASE ITERACIÓN DESCRIPCIÓN HITOS RIESGOS
ITERACIONES ASOCIADOS IDENTIFICADOS
POR FASES
Planeación Iteración
Preliminar


            

05/03/02 p. 9
 Elaboración Iteración E1-
Iteración E2 -
Construcción Iteración C1 -
Iteración C2 -
Iteración C3 -
Transición Iteración T1 -
Iteración T2 -

Se deberá estimar la conformación del equipo de proyecto, atendiendo a la estructura organizativa

definida (Ver Figura 4). Se estimará el costo total del proyecto, aplicando cualesquiera de los modelos de
estimación existentes.

El Plan Detallado de la Iteración

El plan detallado de la iteración describe las actividades específicas a desarrollar dentro de la

iteración, los resultados a obtener, las fechas de inicio y de terminación, el/los responsables y sus roles, los
recursos financieros (por etapas) y actividades de soporte, equipamiento y otras facilidades requerido, etc.
TABLA 10. ACTIVIDAD INICIO FIN
ACTIVIDADES POR
ETAPAS

El cronograma de plan de la iteración puede desarrollarse usando el Microsoft Project (ver anexo 1)

"Plan de
Proyecto.mpp"

Los entregables para cada iteración determinan aquellos productos o sub productos que como
resultado de las actividades de la iteración deberán obtenerse al finalizar la misma.

La Conformación del Equipo

Se deberá realizar una estimación, tanto de los recursos humanos como financieros para el
cubrimiento de la iteración. Un Plan General fue realizado en el Plan General del Proyecto.

Se deberá estimar los requerimientos de equipamientos y Recursos requeridos para el soporte de las
actividades de la iteración.

Durante la Fase de Planeación, el centro de atención está ubicado en la definición del alcance del
proyecto, y del desarrollo del Caso del Negocio (viabilidad económica del proyecto). Por consiguiente, el
tamaño del equipo resulta relativamente pequeño y puede componerse de los siguientes roles:
Un Gerente de Proyecto;

05/03/02 p. 10
 Un Arquitecto; y
Uno o Dos Desarrolladores (cuando se requiera de la elaboración de prototipo técnicos para
pruebas de conceptos, que permitan esclarecer los requerimientos o construir soportes para el
producto).

Durante la Fase de Elaboración, el foco de atención lo constituye en primer lugar en la arquitectura

y en los prototipos arquitectónicos. Las actividades de diseño en la primera parte de la elaboración se centra
en los aspectos de la arquitectura; se le presta por ende poca atención a los detalles de las clases (operaciones
y atributos detallados), los que no son considerados como significativos para la arquitectura.

Durante las iteraciones entre fase, la mayor parte del esfuerzo proviene del equipo de arquitectos y
de un equipo que se designe para el desarrollo de prototipos. El equipo de desarrollo de prototipos
usualmente debe conformarse con los programadores mas experimentados. Se cuenta además con un equipo
de diseño pequeño enfocado a los mecanismos, componentes y tecnologías genéricas. Por su parte el equipo
de prueba se centra en la construcción del ambiente para pruebas, así como la aplicación de pruebas a los
casos de usos primarios.

El equipo de arquitectos debe conformarse con mucho cuidado, tratando no solo de colocar a los
mas habilidosos en análisis y diseño, sino además a aquellos que poseen una buena capacidad para ejercer
liderazgo.

Ya para la Fase de Construcción debemos intentar realizar una distribución de los miembros del
equipo de arquitecto en los equipos de construcción, con la finalidad de comunicar la arquitectura a dichos
equipos. Normalmente un equipo de construcción es responsable de uno o mas subsistemas con interfaces
bien definidas, los cambios que se le realicen a dicha interfaz provocan cambios en la arquitectura y deberán
ser revisados con mucho cuidado. Dentro de un subsistemas se tiene cierta libertad para diseñar e
implementar, por la comunicación cruzada entre equipos es necesaria para asegurar que los equipos no se
encuentren construyendo los mismo en forma paralela.

La organización de los equipos de desarrollo es básicamente horizontal, a lo largo de las líneas de

las capas. Un equipo debe ser responsable de la interfaz con la Base de Datos, otro con la infraestructura de
comunicación, en tanto que otro equipo estará inmerso en la funcionalidad de la aplicación en si misma. Por
supuesto que se requerirá de determinadas habilidades, los equipos que laboren en la funcionalidad misma
del sistema, deberá posee un buen dominio del campo o alcance de la aplicación, en tanto que aquellos que
se dediquen a las interfaces con las Bases de Datos y la comunicación, deberán dominar mucho mas la
tecnología de implementación.

05/03/02 p. 11
 TABLAS DE ILUSTRACIONES

Figura 1. Modelo de Ciclo de Vida en Cascada (Waterfall)................................................................................1

Figura 2. Ciclo de Desarrollo Iterativo e Incremental. .........................................................................................2
Figura 3. Fases del Proceso de Desarrollo ............................................................................................................5
Figura 3. Gráfico de Distribución de Esfuerzo y Cronograma ............................................................................7
Figura 4. Organigrama de una Organización de Desarrollo de Softwa.............................................................12
 REFERENCIAS

KRUCHTEN, Philippe
1999 The Rational Unified Process. UK: Adisson-Wesley. ISBN 0201604590

GILB, Tom
1988 Principles of Software Engineering Management. Harlow, UK: Adisson-Wesley,
1988, p.73.

SHARON, Yonat
2000 Lightweight OO Development Process, ObjetiveView URL (www.ratio.co.uk)

RATIONAL SOFTWARE
2000a Rational Unified Process 5.1, Rational Suite 2000
2000b Rational Unified Process 5.5, Rational Suite 2000

BOEHM, Barry
1995 Anchoring the Software Process, IEEE Software.

BOEHM, Barry; Clark Bradford; Horowits, Ellis; Westland, Chris; Madachy, Ray; Selby, Richard
2000a Cost Models for Future Software Life Cycle Processes: COCOMO 2.0 *
2000b The COCOMO 2.0 Software Cost Estimation Model
TABLA DE CONTENIDO

Aspectos Generales..................................................................................................................................................1

Desarrollo Iterativo del Software ........................................................................................................................1

Gestión de Requerimientos...................................................................................................................................2
Uso de Arquitectura basada en componentes.....................................................................................................3
Modelado Visual del Software .............................................................................................................................4
Verificación de la Calidad del Software..............................................................................................................4
Control de Cambios..............................................................................................................................................5

El Proceso Unificado de Rational..........................................................................................................................5

El Plan Global del Proyecto ................................................................................................................................6

El Plan Detallado de la Iteración ......................................................................................................................10
La Conformación del Equipo.............................................................................................................................10
 Proceso
Unificado de
Rational:
Configuración del
Ciclo de
Desarrollo.

2000