Este documento compara el Proceso Unificado y el Modelo en V para el desarrollo de software. Ambos métodos buscan regular el proceso de desarrollo a través de actividades ordenadas. El Proceso Unificado se basa en casos de uso iterativos guiados por la arquitectura, mientras que el Modelo en V separa el desarrollo de la verificación y validación a lo largo de cuatro niveles. El objetivo de ambos es minimizar riesgos y costos y garantizar la calidad del software.

1. ADMINISTRACION DE PROYECTOS
COMPARACION ENTRE EL MODELO
PROCESO UNIFICADO Y EL MODELO EN V
EMILIO MAXIMILIANO GRANIZO MORA
INGENIERIA EN SISTEMAS COMPUTACIONALES
NOVENO SEMESTRE
AÑO 2010
1

2. VISION GENERAL
Un proceso de desarrollo de software es el conjunto de actividades que necesita para transformar los
requisitos del usuario en un sistema software, este proceso representa la secuencia de pasos en el
desarrollo del ciclo de vida de un proyecto, el objetivo es construir un producto de software nuevo o
extender uno existente.
Ambos modelos, proceso unificado y modelo en v son procesos de desarrollo de software que fueron
creados para poder tener un control a la hora de implementar o desarrollar un software, realizando un
estudio sobre todas las actividades a lo largo del proyecto mediante un conjunto de pasos ordenados para
alcanzar un objetivo
El proceso unificado es un proceso de desarrollo de software, el proceso unificado está guiado por casos de
uso, centrado en la arquitectura con un ciclo de vida iterativo e incremental. El Proceso Unificado se repite a
lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versión del
sistema.
El modelo en v significa verificación y validación, es un proceso que representa la secuencia de pasos en el
desarrollo del ciclo de vida de un proyecto. Se describen las actividades y resultados que deben producirse
durante el desarrollo del producto, el lado izquierdo de la v representa la descomposición de las
necesidades, y la creación de las especificaciones del sistema, el lado derecho de la v representa la
integración de las piezas y su verificación.
OBJETIVOS
El proceso unificado y el modelo v fueron desarrollados para regular el proceso de desarrollo de software
describiendo las actividades y los resultados que se producen durante el proceso de desarrollo del software,
los principales objetivos de estos métodos son:
(1) La minimización de los riesgos del proyecto: mejora la transparencia del proyecto y control del
proyecto, especificando los enfoques estandarizados, permite una detección temprana de las desviaciones
y los riesgos y mejora la gestión de procesos, reduciendo así los riesgos del proyecto,
(2) El mejoramiento y Garantía de Calidad: asegura que los resultados que se proporcionan sean
completos y contengan la calidad deseada,
(3) La reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de Vida: el
esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema puede ser calculado,
estimado y controlado de manera transparente mediante la aplicación de un modelo de procesos
estandarizados,
(4) y La mejora de la comunicación entre todos los inversionistas: la descripción estandarizada y
uniforme de todos los elementos pertinentes y términos es la base para la comprensión mutua entre todos
los inversionistas. De este modo, se reduce la pérdida de fricción entre el usuario, comprador, proveedor y
desarrollador.
CARACTERISTICAS
Entre las características del PROCESO UNIFICADO tenemos que:
Es Dirigido por Casos de Uso, un caso de uso es un fragmento de funcionalidad del sistema que
proporciona un resultado de valor a un usuario. Los casos de uso modelan los requerimientos funcionales
del sistema. Todos los casos de uso juntos constituyen el modelo de casos de uso. Los casos de uso
también guían el proceso de desarrollo. Basándose en los casos de uso los desarrolladores crean una serie
de modelos de diseño e implementación que llevan a cabo los casos de uso. De este modo los casos de
uso no solo inician el proceso de desarrollo sino que le proporcionan un hilo conductor, avanza a través de
una serie de flujos de trabajo que parten de los casos de uso.
2

3. Es Centrado en la Arquitectura, la arquitectura de un sistema software se describe mediante diferentes
vistas del sistema en construcción. La arquitectura es una vista del diseño completo con las características
más importantes resaltadas, dejando los detalles de lado. Los casos de uso y la arquitectura están
profundamente relacionados. Los casos de uso deben encajar en la arquitectura, y a su vez la arquitectura
debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y a futuro. A medida que los
casos de uso se especifican y maduran, se descubre más de la arquitectura, y esto a su vez lleva a la
maduración de más casos de uso. Este proceso continúa hasta que se considere que la arquitectura es
estable.
Es Iterativo e Incremental, Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en
partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento.
Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos a crecimientos en el
producto. Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y ejecutarse de
una forma planificada. Los desarrolladores basan la selección de lo que implementarán en cada iteración en
dos cosas: el conjunto de casos de uso que amplían la funcionalidad, y en los riesgos más importantes que
deben mitigarse. En cada iteración los desarrolladores identifican y especifican los casos de uso relevantes,
crean un diseño utilizando la arquitectura seleccionada como guía, para implementar dichos casos de uso.
Si la iteración cumple sus objetivos, se continúa con la próxima. Si no deben revisarse las decisiones
previas y probar un nuevo enfoque.
Entre las características del MODELO V tenemos que también es llamado como el modelo de 4 niveles:
El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto constituyen los dos extremos
del ciclo. Se compone del análisis de requisitos y especificaciones, se traduce en un documento de
requisitos y especificaciones.
El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede considerarse el sistema
como una caja negra, y caracterizarla únicamente con aquellas funciones que son directa o indirectamente
visibles por el usuario final, se traduce en un documento de análisis funcional.
El nivel 3 define los componentes hardware y software del sistema final, a cuyo conjunto se denomina
arquitectura del sistema.
El nivel 4 es la fase de implementación, en la que se desarrollan los elementos unitarios o módulos del
programa.
CICLO DE VIDA DEL PROYECTO
El PROCESO UNIFICADO se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema.
Cada ciclo constituye una versión del sistema. Cada ciclo constas de cuatro fases: inicio, elaboración,
construcción, y transición.
Durante la fase de inicio se desarrolla una descripción del producto final, y se presenta el análisis del
negocio. Esta fase responde las siguientes preguntas: ¿Cuáles son las principales funciones del sistema
para los usuarios más importantes?, ¿Cómo podría ser la mejor arquitectura del sistema?, ¿Cuál es el plan
del proyecto y cuanto costará desarrollar el producto?, en esta fase se identifican y priorizan los riesgos más
importantes.
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. Las metas fundamentales de la elaboración son tratar factores de riesgo sabidos y
establecer y validar la arquitectura del sistema, Establecen una firme comprensión del problema a
solucionar, elimina los mayores riesgos.
Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece hasta
convertirse en el sistema completo. Al final de esta fase, el producto contiene todos los casos de uso
implementados, sin embargo puede que no esté libre de defectos. Los artefactos producidos durante esta
fase son: Diseño de Sistemas, El sistema software, Los casos de prueba, Los manuales de usuario.
La fase de transición cubre el período durante el cual el producto se convierte en la primera versión
completa del programa. La fase de la transición también incluye conversiones del sistema y el
3

4. entrenamiento de usuario. Las características se agregan a un sistema que el usuario se encuentra
utilizando activamente. El equipo se encuentra ocupado fundamentalmente en corregir y extender la
funcionalidad del sistema desarrollado en la fase anterior.
En el modelo v, para cada fase del desarrollo, existe una fase correspondiente o paralela de verificación o
validación. Esta estructura obedece al principio de que para cada fase del desarrollo debe existir un
resultado verificable.
Fase de verificación del modelo v:
Análisis de requisitos, en esta fase, los requisitos del sistema propuesto son recogidos analizando las
necesidades de los usuarios. Esta fase se refiere sobre establecer lo que tiene que realizarse el sistema
ideal. Sin embargo, no se determina cómo el software será diseñado o construido.
Diseño del sistema, los técnicos analizan y entienden el negocio del sistema propuesto estudiando el
documento de las exigencias del consumidor. Calculan hacia fuera las posibilidades y las técnicas por las
cuales las exigencias del consumidor pueden ser puestas en ejecución.
Diseño de la arquitectura, esta fase se puede también llamar como diseño de alto nivel. El objetivo principal
consiste en seleccionar la arquitectura en que debe realizar todo y que consista en típicamente la lista de
módulos, breve funcionalidad de cada módulo.
Diseño del módulo, esta fase se puede también llamar como diseño bajo. El sistema diseñado está
quebrado para arriba adentro a unidades más pequeñas o se explica los módulos y cada uno de ellas de
modo que el programador pueda comenzar a cifrar directamente. Las especificaciones del documento o del
programa del diseño del nivel bajo contendrán una lógica funcional detallada del modulo.
Fase de validación del modelo en v:
Prueba de la unidad, la prueba de la unidad implica la primera etapa de prueba dinámica de proceso, una
avería descubierta y corregida en la fase de prueba de la unidad es más que cientos veces más barato que
si se hace después de entrega al cliente. Implica el análisis del código escrito con la intención de eliminar
errores.
Prueba de la integración, en la integración la prueba de los módulos separados será probada junta para
exponer averías en interfaces y en la interacción entre los componentes integrados. Se hace usando el
diseño de la prueba de la integración elaborada durante la fase de diseño de la arquitectura. La prueba de la
integración es conducida generalmente por los probadores del software.
Prueba del sistema, comparará las especificaciones de sistema contra el sistema real. El diseño de la
prueba del sistema se deriva de los documentos del diseño del sistema y se utiliza en esta fase. Una vez
que se integren todos los módulos varios errores pueden presentarse.
Prueba de aceptación de usuario, Para determinarse si un sistema satisface sus criterios de la aceptación o
no, Para permitir al cliente determinarse si aceptar el sistema o no, esta prueba tiene como propósito
verificar el sistema o los cambios según las necesidades originales.
CONCLUSION
Los conceptos anteriormente tratados: dirigido por casos de uso, centrado en arquitectura, desarrollo
iterativo e incremental, son igualmente importantes. La arquitectura provee la estructura sobre la cual guiar
el trabajo en iteraciones, mientras que los casos de uso definen las metas y dirigen el trabajo en cada
iteración. Remover cualquiera de estos conceptos reducirá severamente el valor del Proceso Unificado. El
proceso unificado es una metodología completa y bien documentada. Se la utiliza como una interesante
fuente de ideas y herramientas y con una amplia disponibilidad de formación técnica y práctica.
4

5. BIBLIOGRAFÍA
http://www.worldlingo.com/ma/enwiki/es/Unified_Process#Characteristics
http://yaqui.mxl.uabc.mx/~molguin/as/RUP.htm
http://www.worldlingo.com/ma/enwiki/es/V-Model_%28software_development%29
ANEXOS
CONCEPTOS
Disciplina.- Una disciplina es una colección de actividades relacionadas vinculadas con un área específica
del proyecto. Este agrupamiento de actividades en disciplinas es principalmente para facilitar la
comprensión del proyecto desde la perspectiva tradicional del modelo en cascada.
Flujo de trabajo.- Un flujo de trabajo describe la secuencia en que se realizan las actividades en una
disciplina, quienes la realizan (trabajadores) y que artefactos producen.
Trabajador (Rol).- Un trabajador o rol, define un comportamiento o responsabilidades de un individuo o
grupo de individuos trabajando en equipo, en el contexto de una organización de ingeniería de software.
Actividad.- Los trabajadores realizan actividades. Una actividad es algo que realiza un trabajador para
proveer un resultado de valor en el contexto de un proyecto.
Pasos (steps).- Las actividades son descompuestas en pasos. Podemos distinguir tres categorías de
pasos:
· Pasos de análisis: donde el trabajador comprende la naturaleza de la tarea, examina los artefactos de
entrada, y formula las salidas.
· Pasos de acción: donde los trabajadores crean o actualizan algunos artefactos.
· Pasos de revisión: donde los trabajadores inspeccionan los resultados según determinados criterios.
Artefactos.- Las actividades tienen artefactos de entrada y de salida. Un artefacto es un producto de trabajo
en un proceso: los trabajadores utilizan artefactos para realizar actividades y producen artefactos como
resultado de sus actividades.
5