METODOLOGIAS DE DESARROLLO DE

SOFTWARE

1
 Ingenierı́a Informática

Ciencias de la Computación

Franco Alejandro Sánchez Huertas

neofrancosh@gmail.com

March 23, 2010

2
1 Introducción
Según la muy difundida (y no por eso confiable) Wikipedia encontramos la sigu-
iente definición: ”Se entiende como desarrollo ágil de software a un paradigma
de desarrollo de software basado en procesos ágiles. Los procesos ágiles de desar-
rollo de software, conocidos anteriormente como metodologı́as livianas, intentan
evitar los tortuosos y burocráticos caminos de las metodologı́as tradicionales en-
focándose en la gente y los resultados.” Por ende y basándome en la información
encontrada en la nube me doy cuenta que hoy por hoy el tema referido a las
metodologı́as de desarrollo se encuentra tambien bajo el nombre de ”Desarrollo
ágil de Software”. La Metodologı́a de Desarrollo vendrı́a a ser entonces una
colección de documentación formal referente a los procesos, las polı́ticas y los
procedimientos que intervienen en el desarrollo del software. En Ingles software
development methodology (SDM) o system development life cycle (SDLC). La
finalidad de una metodologı́a de desarrollo es garantizar la eficacia (p.ej. cumplir
los requisitos iniciales) y la eficiencia (p.ej. minimizar las pérdidas de tiempo) en
el proceso de generación de software. Los riesgos a afrontar y los controles a es-
tablecer varı́an en función de las diferentes etapas del ciclo de vida de desarrollo.
De forma general podrı́amos encontrar las siguientes fases:

• Definición del proceso de negocio y los requerimientos

• Documentación funcional
• Arquitectura y diseño técnico
• Codificación y ejecución de pruebas unitarias
• Pruebas globales del sistema

• Pruebas de integración
• Implantación
• Formación de usuarios

• Mantenimiento del sistema (estas fases según MarbleStation)

Ademas, durante todo el ciclo de vida del proyecto se deberán realizar las
siguientes tareas:

• Gestión de la configuración: identificación de versiones, control de cam-

bios, etc.
• Gestión de la calidad: seguimiento de errores, revisiones del nivel de cali-
dad. (famoso Testing)
• Revisión de las premisas iniciales: revisión de los requerimientos y de los
diseños.

3
 • Gestión del entorno de desarrollo: herramientas de desarrollo, librerı́as,
ficheros, gestión de datos.

El núcleo de cualquier metodologı́a de desarrollo se encuentra constituido

por documentos escritos que detallan cada uno de los puntos expuestos. (La
Documentación)
Aunque siempre es mas conveniente consultar el estándar ISO 12207 (wikipedia:
ISO/IEC 12207 establece un proceso de ciclo de vida para el software que incluye
procesos y actividades que se aplican desde la definición de requisitos, pasando
por la adquisición y configuración de los servicios del sistema, hasta la final-
ización de su uso. Este estándar tiene como objetivo principal proporcionar una
estructura común para que compradores, proveedores, desarrolladores, personal
de mantenimiento, operadores, gestores y técnicos involucrados en el desarrollo
de software usen un lenguaje común. Este lenguaje común se establece en forma
de procesos bien definidos).
Aquı́ la estructura del estándar internacional:

Figure 1:

4
 La relación entre los diferentes procesos variará en función de la metodologı́a
que la organización desee utilizar. En términos generales, podrı́amos hacer 3
agrupaciones:

• Procesos en cascada (Waterfall): El desarrollo se compone por fases se-

cuenciales. Una vez cerrada una, no se considera la posibilidad de volver
atrás.
• Procesos en espiral: Se desarrollan prototipos de software que son vali-
dados y mejorados a partir de la validación por parte del usuario. Una
vez se tiene el prototipo definitivo, se realiza el desarrollo, implantación y
mantenimiento de la misma forma que el modelo en cascada.
• Procesos iterativos: Desarrollo incremental e iterativo, cada elemento de-
sarrollado es validado con objeto de redefinir las necesidades funcionales.
En este caso no se utilizan prototipos. Se dispone de marcos de trabajo
de desarrollo ágil que son bastante populares como Extreme Programming
(XP).

Si bien es importante formalizar una metodologı́a de desarrollo para mini-

mizar riesgos e incrementar las posibilidades de éxito en los desarrollos, también
es necesario establecer mecanismos de mejora continua sobre los procesos que
componen la metodologı́a. En ese sentido disponemos del estándar ISO 15504
(worldlingo: ISO/IEC 15504 es un estándar internacional que se refiere sobre
las muchas ofertas nacionales del modelo de la madurez y establece un estándar
internacional en esta área. Ademas presenta un modelo de la referencia como
referencia internacional, de modo que los asesores puedan dar una determinación
total de las capacidades de la organización para entregar los productos.) Es de-
cir, nos ofrece unas pautas para verificar si estos procesos son efectivos en la
consecución de sus objetivos:

Figure 2:

5
 Para la implantación de mecanismos de mejora, primero es necesario iden-
tificar/mapear los procesos definidos en la ISO 12207 con los procesos de la
organización. En una segunda parte, a partir del modelo de referencia definido
en el estándar, es posible medir el nivel de ”capacidad” de cada uno de los
procesos:
• Nivel 0 - Proceso incompleto: El proceso no existe o no cumple con los
objetivos
• Nivel 1 - Proceso ejecutado
• Nivel 2 - Proceso gestionado: el proceso no solo se encuentra en fun-
cionamiento, sino que es planificado, monitorizado y ajustado.
• NIvel 3 - Proceso definido: el proceso, los recursos, los roles y responsabil-
idades se encuentran documentados y formalizado.
• Nivel 4 - Proceso predecible: se han definido técnicas de medición de
resultados y controles.
• Nivel 5 - Proceso optimizado: todos los cambios son verificados para de-
terminar el impacto, se han definido mecanismos para la mejora continua,
etc.
Por tanto, para cada proceso se evalua y se asigna un nivel. A partir de aquı́,
es posible definir las acciones de mejora necesarias. En general, la ISO 15504
consta de las siguientes normas:

Figure 3:

Ahora que tenemos la idea de lo que es, posee y requiere una Metodologı́a
de Desarrollo de Software paso a presentar algunas de las metodologı́as mas
utilizadas. Poniendo de menos a más ágil, de más ’revolucionaria’ a menos, las
metodologı́as más populares, tenemos la siguiente lista:

6
 • SCRUM
• RUP - Rational Unified Process
• MSF Agile
• Extreme Programming

A continuación detallaré SCRUM y RUP que son las metodologı́as mas co-
munes, utilizadas y eficientes.

2 SCRUM
Es una forma de gestionar proyectos de software. No es una metodologı́a de
análisis, ni de diseño, es una metodologı́a de gestión del trabajo. Es un proceso
ágil que puede ser usado para gestionar y controlar el desarrollo de productos
y software complejos usando prácticas iterativas y actualizables. Se trata de
evitar lo que como habı́amos hablado en clase, fácilmente nos va a pasar: Nuestro
proyecto se encuentra bastante avanzado nos damos cuenta de que no vamos por
el buen camino o, simplemente, el cliente decide introducir cambios sustanciales,
y esos cambios nos obligan a tirar por la borda todo el trabajo realizado hasta
entonces, y nos impiden acabar en el plazo previsto. Dado que los cambios
nunca van a dejar de existir, lo que necesitamos es ser capaces de gestionar los
proyectos de una forma más ágil. Con ese objetivo, en los años 80 los japoneses
Takeuchi y Nonaka estudiaron las prácticas de empresas con buenos resultados
de rapidez y flexibilidad en la producción: Xerox, Canon, Honda, NEC, Epson,
Brother, 3M o Hewlett-Packard. De ahı́ extrajeron la base de la metodologı́a
SCRUM que, aunque nació en el ámbito tecnológico, ha ido creciendo hasta
consolidarse en campos de actividad muy diferentes. Seguro que puedes utilizar
algunas de sus técnicas y procedimientos para mejorar la gestión de los proyectos
en tu empresa. Estas son algunas de las claves de SCRUM:

2.1 Mejor con equipos pequeños y auto-organizados

Los equipos pequeños y formados por miembros de diferentes disciplinas con-
siguen mejores resultados. Es fundamental que el equipo pueda organizarse por
sı́ mismo y la comunicación sea transparente. Esta es la manera de que todos los
miembros se compromentan y se encuentren motivados. De hecho, la palabra
SCRUM procede del vocabulario del rugby y significa melé; es decir, esa ”figura”
en la que los compañeros del equipo se amontonan, forman una piña y empujan
todos en la misma direccion.

2.2 Punto de vista del usuario

La recogida de requisitos para crear un producto se realiza teniendo en cuenta la
visión del cliente y del usuario. Para ello se utilizan las historias de usuario, unas
sencillas tarjetas en las que se recoge -de forma esquemática y en un lenguaje

7
 Figure 4:

claro- QUÉ es lo que queremos hacer. Con esas historias de usuario construimos
la lista de requisitos del producto o ”product backlog”. A cada item de la lista se
le asigna una prioridad. El equipo tiene que estimar cuánto tiempo es necesario
para realizar cada una de las tareas.

2.3 Sprints cortos, entregas frecuentes

El mercado exige ciclos de desarrollo cada vez más cortos. Para lograrlo se
utiliza el sprint de requisitos o ”sprint backlog”, una lista en la que se detalla
CÓMO se van a construir los diferentes requisitos del producto. Los requisitos
del product backlog se ”trocean” para transformarlos en tareas de no más de
16 horas. Cada sprint suele realizarse en un plazo de entre 2 y 4 semanas. Al
final, el objetivo es entregar algo que funcione, para el usuario pueda probarlo y
se puedan introducir los cambios necesarios antes de que sea demasiado tarde.
Esto es lo que nos permitirá ser flexibles.

2.4 Roles dentro de SCRUM

Aunque suene a broma, los roles se dividen en dos: los ”cerdos” y los ”pollos”.
Y la mejor manera de entender la diferencia entre unos y otros es un chiste: Un
cerdo y un pollo van caminando por la carretera. El pollo le dice al cerdo:
Oye, £por qué no abrimos un restaurante?
El cerdo se vuelve y le responde:
Buena idea, £cómo quieres que lo llamemos?
El pollo se lo piensa y propone:
£Por qué no lo llamamos ”Huevos con jamón”.
No cuentes conmigo -responde el cerdo-. En ese caso, tú sólo estarı́as IMPLI-
CADO, mientras que yo estarı́a realmente COMPROMETIDO.
Siguiendo esta lógica, el papel de los cerdos -que son los que están realmente
comprometidos, porque son los que contribuyen con su ”jamón” al proyecto- lo
desempeñan:

• El product owner o dueño del producto, que representa la voz del cliente
y aporta la visión de negocio. Él se encarga de escribir las historias de
usuario, les da prioridad y las ubica en la lista de requisitos del producto.

8
 • El ScrumMaster o facilitador, que tiene como principal papel el de dejar
el camino libre de obstáculos e impedimentos para que el resto del equipo
consiga el objetivo del sprint.
• El equipo, que tiene la responsabilidad de entregar el producto. Lo ideal es
que incluya entre 5 y 9 miembros, y que pertenezcan a diferentes disciplinas
(desarrolladores, diseñadores, etc.).

El papel de los ”pollos”, que no son actores esenciales pero sı́ están implicados
y deben ser tenidos en cuenta, lo juegan:

• Los usuarios del producto o aplicación.

• Los clientes y vendedores.

• Los gestores y directivos.

2.5 Reunión diaria. Transparencia total

Una de la figuras fundamentales de la metodologı́a SCRUM es la reunión diaria
de todo el equipo. Tiene que hacerse de la siguiente forma:

• La reunión es diaria y se hace siempre a una hora predefinida, normalmente

por la mañana. Es importante que todos los miembros del equipo acudan
puntuales.
• La reunión debe durar alrededor de 15 minutos y se realiza de pie, para
mantener el máximo de concentración y atención.

• Todos los roles son bienvenidos, pero sólo los ”cerdos” pueden hablar
• En la reunión se realizan las siguientes 3 preguntas clave: 1. £Qué has
hecho desde ayer? 2. £Qué tienes planeado hacer mañana? 3. £Has
encontrado algún problema para conseguir tu objetivo?

• Uno de los puntos más importantes es el de la transparencia: todos los

miembros saben que están haciendo os demás, y los problemas deben ser
sacados a la luz en cuanto se detectan.
En definitiva, SCRUM permite la creación de equipos motivados, capaces de
organizarse por sı́ mismos, donde la comunicación y la transparencia es total.
Y además, con esta metodologı́a, el usuario gana protagonismo y el cliente se
convierte en parte del equipo de desarrollo.
En Resumen:
Elementos básicos:
• Product Backlog: Es una lista con las funcionalidades de la aplicación
ordenadas de mayor a menor importancia. No hace falta que esta lista
contenga todas las funcionalidades inicialmente.

9
 • Sprint Backlog: De la lista anterior, se toman las primeras funcionalidades,
se descomponen en tareas y son anotadas en esta lista. Estas tareas serán
realizadas en el siguiente mes.
Reglas Básicas:

• Una vez que se pasan las tareas más prioritarias del ”Product Backlog”
al ”Sprint Backlog”, estas no se pueden cambiar, esto quiere decir, que el
trabajo de un mes queda fijado. Esta es la regla más importante de todas.

• Al final del mes, este periodo se le llama ”Sprint”, se tiene que tener un
ejecutable con las funcionalidades del ”Sprint Backlog”.
• Todo el mundo puede añadir funcionalidades al ”Product Backlog”, pero
sólo una persona puede ordenarlo. A esta persona se le denomina ”Product
Owner”. Es el responsable del producto final.

• Cada dı́a se hace una reunión de menos de 15 minutos, en la que se reúne

todo el equipo: ingenieros y gestor (llamado ”Scrum Master”) en la que
cada miembro del equipo expone sólo los siguientes temas:

3 RUP
3.1 Historia
El antecedente más importante se ubica en 1967 con la Metodologı́a Ericsson
(Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desar-
rollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre
los años de 1987 a 1995 Jacobson fundó la compañı́a Objectory AB y lanza el
proceso de desarrollo Objectory (abreviación de Object Factory).

Figure 5:

10
 Posteriormente en 1995 Rational Software Corporation adquiere Objectory
AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir
de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML
como lenguaje de modelado.
Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James
Rumbaugh, Rational Software desarrolló e incorporó diversos elementos para
expandir ROP, destacándose especialmente el flujo de trabajo conocido como
modelado del negocio. En junio del 1998 se lanza Rational Unified Process.

3.2 Caracterı́sticas esenciales

Los autores de RUP destacan que el proceso de software propuesto por RUP
tiene tres caracterı́sticas esenciales: está dirigido por los Casos de Uso, está
centrado en la arquitectura, y es iterativo e incremental.

3.2.1 Proceso dirigido por Casos de Uso

Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar
en términos de importancia para el usuario y no sólo en términos de funciones
que seria bueno contemplar. Se define un Caso de Uso como un fragmento de
funcionalidad del sistema que proporciona al usuario un valor añadido. Los
Casos de Uso representan los requisitos funcionales del sistema.
En RUP los Casos de Uso no son sólo una herramienta para especificar los
requisitos del sistema. También guı́an su diseño, implementación y prueba. Los
Casos de Uso constituyen un elemento integrador y una guı́a del trabajo.

Figure 6:

Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcio-
nan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos
que son generados en las diferentes actividades del proceso de desarrollo.

3.2.2 Proceso centrado en la arquitectura

La arquitectura de un sistema es la organización o estructura de sus partes más
relevantes, lo que permite tener una visión común entre todos los involucra-
dos (desarrolladores y usuarios) y una perspectiva clara del sistema completo,
necesaria para controlar el desarrollo.

11
 La arquitectura involucra los aspectos estáticos y dinámicos más significa-
tivos del sistema, está relacionada con la toma de decisiones que indican cómo
tiene que ser construido el sistema y ayuda a determinar en qué orden. Además
la definición de la arquitectura debe tomar en consideración elementos de calidad
del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe
ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influen-
ciada por la plataforma software, sistema operativo, gestor de bases de datos,
protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de
estas restricciones constituyen requisitos no funcionales del sistema.
En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso
se presta especial atención al establecimiento temprano de una buena arquitec-
tura que no se vea fuertemente impactada ante cambios posteriores durante la
construcción y el mantenimiento.
Cada producto tiene tanto una función como una forma. La función corre-
sponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona
la arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura,
los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la
arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos,
actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos
de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de
software.
Aquı́ podemos ver la evolución de la arquitectura durante las fases de RUP.
Se tiene una arquitectura más robusta en las fases finales del proyecto. En las
fases iniciales lo que se hace es ir consolidando la arquitectura por medio de
baselines y se va modificando dependiendo de las necesidades del proyecto.

Figure 7:

3.2.3 Proceso iterativo e incremental

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy
parecido al equilibrio de la forma y la función en el desarrollo del producto,
lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en
RUP es tener un proceso iterativo e incremental en donde el trabajo se divide
en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre
Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, ası́

12
durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como
una iteración (un recorrido más o menos completo a lo largo de todos los flujos
de trabajo fundamentales) del cual se obtiene un incremento que produce un
crecimiento en el producto.
Una iteración puede realizarse por medio de una cascada como vemos a con-
tinuación. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,
Implementación y Pruebas), también existe una planificación de la iteración,
un análisis de la iteración y algunas actividades especı́ficas de la iteración. Al
finalizar se realiza una integración de los resultados con lo obtenido de las itera-
ciones anteriores.

Figure 8:

El proceso iterativo e incremental consta de una secuencia de iteraciones.

Cada iteración aborda una parte de la funcionalidad total, pasando por todos
los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se
analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos
o han cambiado los existentes, afectando a las iteraciones siguientes. Durante
la planificación de los detalles de la siguiente iteración, el equipo también ex-
amina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda
la retroalimentación de la iteración pasada permite reajustar los objetivos para
las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya
finalizado por completo con la versión actual del producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en número variable según el proyecto y en las que se hace un mayor
o menor hincapié en los distintas actividades. Aquı́ se muestra cómo varı́a el
esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto
RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan
hacia la comprensión del problema y la tecnologı́a, la delimitación del ámbito

13
 Figure 9:

del proyecto, la eliminación de los riesgos crı́ticos, y al establecimiento de una

baseline de la arquitectura.
Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en activi-
dades modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la base-
line de la arquitectura, abarcan más los flujos de trabajo de requerimientos, mod-
elo de negocios (refinamiento), análisis, diseño y una parte de implementación
orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por
medio de una serie de iteraciones.
Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis
y diseño y se procede a su implementación y pruebas. Se realiza una pequeña
cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la
implementación de la nueva versión del producto.
En la fase de transición 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
que dependiendo de la fase el esfuerzo dedicado a una disciplina varı́a.

3.3 Estructura del Proceso

El proceso puede ser descrito en dos dimensiones o ejes:

• Eje horizontal: Representa el tiempo y es considerado el eje de los aspec-

tos dinámicos del proceso. Indica las caracterı́sticas del ciclo de vida del
proceso expresado en términos de fases, iteraciones e hitos. Se puede ob-
servar en la Figura 8 que RUP consta de cuatro fases: Inicio, Elaboración,
Construcción y Transición. Como se mencionó anteriormente cada fase se
subdivide a la vez en iteraciones.

14
 • Eje vertical: Representa los aspectos estáticos del proceso. Describe el
proceso en términos de componentes de proceso, disciplinas, flujos de tra-
bajo, actividades, artefactos y roles.

Figure 10:

3.4 Estructura Dinámica del proceso. Fases e iteraciones

RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un pro-
ducto. Cada ciclo concluye con una generación del producto para los clientes.
Cada ciclo consta de cuatro fases: Inicio, Elaboración, Construcción y Transi-
ción. Cada fase se subdivide a la vez en iteraciones, el número de iteraciones en
cada fase es variable.
Cada fase se concluye con un hito bien definido, un punto en el tiempo en
el cual se deben tomar ciertas decisiones crı́ticas y alcanzar las metas clave
antes de pasar a la siguiente fase, ese hito principal de cada fase se compone
de hitos menores que podrı́an ser los criterios aplicables a cada iteración. Los
hitos para cada una de las fases son: Inicio - Lifecycle Objectives, Elaboración -
Lifecycle Architecture, Construcción - Initial Operational Capability, Transición
- Product Release. Las fases y sus respectivos hitos se ven a continuación.

3.4.1 Inicio
Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto.
Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso
más esenciales (aproximadamente el 20Los objetivos en esta fase son:
• Establecer el ámbito del proyecto y sus lı́mites.
• Encontrar los Casos de Uso crı́ticos del sistema, los escenarios básicos que
definen la funcionalidad.

15
 Figure 11:

• Mostrar al menos una arquitectura candidata para los escenarios princi-

pales.
• Estimar el coste en recursos y tiempo de todo el proyecto.
• Estimar los riesgos, las fuentes de incertidumbre.
Los resultados deben ser:
• Un documento de visión: Una visión general de los requerimientos del
proyecto, caracterı́sticas clave y restricciones principales.
• Modelo inicial de Casos de Uso (10-20
• Un glosario inicial: Terminologı́a clave del dominio.
• El caso de negocio.
• Lista de riesgos y plan de contingencia.
• Plan del proyecto, mostrando fases e iteraciones.
• Modelo de negocio, si es necesario
• Prototipos exploratorios para probar conceptos o la arquitectura candi-
data.

3.4.2 Elaboración
El propósito de la fase de elaboración es analizar el dominio del problema,
establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y
eliminar los mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe evolu-
cionar en iteraciones sucesivas hasta convertirse en el sistema final. Este pro-
totipo debe contener los Casos de Uso crı́ticos identificados en la fase de inicio.
También debe demostrarse que se han evitado los riesgos más graves. Los obje-
tivos en esta fase son:
• Definir, validar y cimentar la arquitectura.
• Completar la visión.

16
 • Crear un plan fiable para la fase de construcción. Este plan puede evolu-
cionar en sucesivas iteraciones. Debe incluir los costes si procede.
• Demostrar que la arquitectura propuesta soportará la visión con un coste
razonable y en un tiempo razonable.
Los resultados deben ser:
• Un modelo de Casos de Uso completa al menos hasta el 80
• Requisitos adicionales que capturan los requisitos no funcionales y cualquier
requisito no asociado con un Caso de Uso especı́fico.
• Descripción de la arquitectura software.
• Un prototipo ejecutable de la arquitectura.
• Lista de riesgos y caso de negocio revisados.
• Plan de desarrollo para el proyecto.
• Un caso de desarrollo actualizado que especifica el proceso a seguir.
• Un manual de usuario preliminar (opcional).

3.4.3 Construcción
La finalidad principal de esta fase es alcanzar la capacidad operacional del pro-
ducto de forma incremental a través de las sucesivas iteraciones. Durante esta
fase todos los componentes, caracterı́sticas y requisitos deben ser implementa-
dos, integrados y probados en su totalidad, obteniendo una versión aceptable
del producto. Los objetivos en esta fase son:
• Minimizar los costes de desarrollo mediante la optimización de recursos y
evitando el tener que rehacer un trabajo o incluso desecharlo.
• Conseguir una calidad adecuada tan rápido como sea práctico.
• Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba)
tan rápido como sea práctico.
Los resultados deben ser:
• Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Imple-
mentación)
• Arquitectura ı́ntegra (mantenida y mı́nimamente actualizada)
• Riesgos Presentados Mitigados
• Plan del Proyecto para la fase de Transición.
• Manual Inicial de Usuario (con suficiente detalle)
• Prototipo Operacional - beta
• Caso del Negocio Actualizado

17
3.4.4 Transición
La finalidad de la fase de transición es poner el producto en manos de los usuar-
ios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del
producto, completar la documentación, entrenar al usuario en el manejo del pro-
ducto, y en general tareas relacionadas con el ajuste, configuración, instalación
y facilidad de uso del producto. Los objetivos en esta fase son:

• Conseguir que el usuario se valga por si mismo.

• Un producto final que cumpla los requisitos esperados, que funcione y
satisfaga suficientemente al usuario.
Los resultados deben ser:

• Prototipo Operacional
• Documentos Legales
• Caso del Negocio Completo
• Lı́nea de Base del Producto completa y corregida que incluye todos los
modelos del sistema
• Descripción de la Arquitectura completa y corregida
• Las iteraciones de esta fase irán dirigidas normalmente a conseguir una
nueva versión.

4 Fuentes
• MarbleStation (http://www.marblestation.com/)
• IBM Best Practices (http://groups.google.com.pe/group/c-data-structure-
ucsp/files)
• Kruchten, P., The Rational Unified Process: An Introduction, 2000

• Geeks MS (http://geeks.ms/blogs/rcorral/)
• Consulta web a McV1c10us Moya (SCRUM) ( http://www.lavidaeninternet.net
)

18