Proceso Unificado

Proceso Unificado de Desarrollo de Software
Visin general
Es un conjunto de actividades necesarias para transformar los requisitos del
usuario en un sistema software.
Es un marco genrico que puede especializarse para una variedad de tipos de
sistemas, diferentes reas de aplicacin, tipos de organizaciones, niveles de
aptitud y diferentes tamaos de proyectos.
Est basado en componentes. El SW est formado por componentes software
interconectados a travs de interfaces.
Esta dirigido por casos de uso, centrados en la arquitectura y es iterativo e
incremental.
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.
Todos los casos de uso de un sistema constituyen un modelo de caso de uso.
Los casos de uso guan el proceso de desarrollo de un sistema (diseo,
implementacin y prueba).
Centrado en la arquitectura
La arquitectura de un software se describe mediante diferentes vistas del sistema
de construccin. Incluye los aspectos estticos y dinmicos ms significativos del
sistema.
La arquitectura de un sistema se define como un conjunto de decisiones
significativas acerca de la organizacin de un sistema software, la seleccin de los
elementos estructurales a partir de los cuales se compone el sistema, las
interfaces, su comportamiento, sus colaboraciones y su composicin.
Iterativo e incremental
Es prctico dividir el desarrollo de un proyecto de software en partes pequeas
(miniproyectos). Cada mini proyecto es una iteracin que resulta en un
incremento.
UNIDAD 1
ASIGNATURA : ARQUITECTURA DE SOFTWARE
PROGRAMA: INGENIERIA DE SISTEMA
TUTOR: CARLOS ARTURO CANCHALA E.

MAIL: redcolombia@hotmail.com
Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos a

crecimientos del producto.
Las iteraciones deben ser controladas, deben seleccionarse y ejecutarse de una
forma planificada.
El ciclo de vida del proceso unificado

El ciclo de vida del proceso unificado se divide en 4 fases:
1.
2.
3.
4.
Inicio: Define el alcance del proyecto

Elaboracin: planificar el proyecto, elaborar una arquitectura base.
Construccin: construir el sistema
Transicin: transicin a los usuarios
Cada fase se divide en iteraciones y en cada iteracin se desarrollo en secuencia

un conjunto de disciplinas o flujos de trabajos, las cuales son:
Disciplinas ms importantes:
Modelado de Negocio
Requerimientos
Analisis y Diseo
Codificacin
Prueba
Instalacin
Disciplinas de soporte:
Adm. Configuracin y cambios

Adm. De Proyecto
Ambiente
Cada disciplina est asociada a un conjunto de modelos que se desarrollan. Estos

modelos estn compuestos por artefactos. Los artefactos ms importantes son los
modelos de cada disciplina realiza.
Disciplina
Requisitos
Anlisis
Diseo
Implementacin
Prueba
UNIDAD 1
Modelos
Modelo de casos de uso
Modelo de anlisis
Modelos de Diseo Modelo de
despliegue
Modelo de implementacin
Modelo de prueba
Hito
Cada fase finaliza en un hito. Cada hito se determina por la
disponibilidad de un conjunto de artefactos, es decir un conjunto de
modelos o documentos que han sido desarrollados hasta alcanzar un
estado predefinido.
Descripcin de Fases
Fase de Inicio
Durante esta fase se desarrolla una descripcin del producto final y se presenta el
anlisis del negocio. Esta fase responde a las siguientes preguntas:
Cules son las principales funciones del sistema para los usuarios ms
importantes?
Cmo podra ser la mejor arquitectura?
Cul es el plan del proyecto y cuanto costar desarrollar el producto?
En esta fase se identifican y priorizan los riesgos ms importantes.
Los artefactos que sobreviven en esta fase son:
Un enunciado de los mayores requerimientos planteados generalmente como
casos de uso.
Un boceto inicial de la arquitectura.
Una descripcin de los objetivos del proyecto.
Una versin muy preliminar del plan del proyecto.
Un modelo del negocio.
Esta fase finaliza con el hito de objetivos del ciclo de vida.
Fase de elaboracin
Aqu se especifican en detalle la mayora de los casos de uso y se disea la
arquitectura.
Las iteraciones en esta fase son:
Establecen una firme comprensin del problema a solucionar

Establecen la fundacin arquitectural para el software
Establece un plan detallado para las siguientes iteraciones
UNIDAD 1

Elimina los mayores riesgos
El resultado de esta fase es la lnea base de la arquitectura.

En esta fase se construyen los siguientes artefactos:
El cuerpo bsico del sw en la forma de un prototipo arquitectural

Casos de prueba
La mayora de los casos de uso (80%) que describen la funcionalidad del
sistema
Un plan detallado para las siguientes iteraciones
Esta fase finaliza con el hito de la arquitectura del ciclo de vida.
Fase de construccin
Durante esta fase se crea el producto. La lnea base arquitectural crece hasta
convertirse en el sistema completo.
Los artefactos producidos durante esta fase son:
El sistema software
Los casos de prueba
Los manuales de usuario
Esta fase finaliza con el hito de capacidad operativa inicial.
Fase de transicin
Esta fase cubre el periodo durante el cual el producto se convierte en la versin
beta.
Las iteraciones en esta fase continan agregando caractersticas al sw. Sin
embargo estas caractersticas se agregan a un sistema que el usuario ya se
encuentra utilizando.
Los artefactos construidos durante esta fase son los mismos que en la fase de
construccin.
Esta fase finaliza con el hito de lanzamiento del producto.
UNIDAD 1

Un Proceso dirigido por casos de uso

Un caso de uso es una descripcin de los pasos o las actividades que debern
realizarse para llevar a cabo algn proceso. Los personajes o entidades que
participarn en un caso de uso se denominan actores.
En el contexto de ingeniera del software, un caso de uso es una secuencia de
interacciones que se desarrollarn entre un sistema y sus actores en respuesta a
un evento que inicia un actor principal sobre el propio sistema.
Los diagramas de casos de uso sirven para especificar la comunicacin y el
comportamiento de un sistema mediante su interaccin con los usuarios y/u otros
sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores
y los casos de uso en un sistema.
Una relacin es una conexin entre los elementos del modelo, por ejemplo la
especializacin y la generalizacin son relaciones. Los diagramas de casos de uso
se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona a
eventos que se producen en su mbito o en l mismo.
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.
El modelo de casos de
uso
representa
los
requisitos funcionales
La primer disciplina que se
desarrolla en cada iteracin es la
de los requerimientos. Los
requerimientos del sistema son
plasmados a travs de casos de
uso en un Modelo de Casos de
Uso.
Ejemplo de un Modelo de casos de uso de

un sistema Cajero Automtico.
UNIDAD 1

Para cada caso de uso debe especificarse sus caminos o secuencias de acciones
posibles:
Ejemplo: secuencia de acciones para un camino del uso de sacar dinero.
-
El cliente del banco se identifica.

El cliente elige de que cuenta sacar dinero y especifica la cantidad
El sistema deduce la cantidad de la cuenta y entrega el dinero
Los casos de uso tambin se utilizan como contenedores para los requisitos no
funcionales.
Creacin de un modelo de anlisis a partir de los casos de uso

El modelo de anlisis es opcional. En este modelo se describen un conjunto de
clases del anlisis que se utiliza para realizar una descripcin abstracta de la
realizacin de los casos de uso de un modelo de casos de uso.
Este modelo crece a medida que se analizan ms y ms casos de uso.
Ejemplo de la realizacin de un caso de uso en el modelo de anlisis.
UNIDAD 1

Una clase puede participar en varias realizaciones.
Durante el analisis se utilizan diagramas de colaboracin para describir la

realizacin de un caso de uso.
Cada clase debe cumplir todos los roles de colaboracion: las responsabilidades de
una clase son la recopilacin de todos los roles que cumple en todas las
realizaciones de casos de uso.
Creacin del modelo de diseo a partir del modelo de analisis

UNIDAD 1

El modelo de diseo se crea tomando el modelo de analisis como entrada

principal, y se lo adapta a un entorno de implementacion particular.
Este modelo incluye clasificadores, relaciones y realizaciones de casos de uso y
existe una relacion de traza entre cada artefacto de diseo que debe adecuarse al
entorno de implementacin especfico.
Loas clases del diseo refinan las clases del analisis.

En el modelo de diseo debemos identificar la interaccin detallada entre los
objetos de diseo que tiene lugar en la realizacin del caso de uso. Utilizaremos
diagramas de secuencia para representar esta inteaccin.
Diagram de secuencia que representa el caso de uso Sacar dinero en el modelo de diseo.
UNIDAD 1

Agrupacin de clases en subsistemas

Un subsistema es un agrupamiento semnticamente til de clases o de otros
subsistemas.
Los subsistemas de bajo nivel se denominan subsistemas de servicio. Estos
subsistemas constituyen una unidad manejable de funcionalidad opcional.
Los subsistemas pueden disearse en forma descendente o ascendente.
El ascendente se realiza a partir de la agrupacin de clases ya identificadas. El
descendente implica la definicin previa de los sistemas de ms alto nivel y las
interfaces entre ellos, antes de que se hayan identificado las clases.
Ejemplo:
<<subsystem>> Interfaz del CA: agrupa todas las clases que proporciona la
interfaz grfica del CA:
Lector de tarjetas
Dispositivo de visualizacin
Teclado
Alimentador de la salida
Sensor de salida
Contador de efectivo
Gestor de cliente
<<subsystem>> Gestin de transacciones

o Gestion de transacciones
o <<service subsystem>> Gestin de retirada de efectivo
Retirada de efectivo
<<subsystem>> Gestin de cuentas
o Clase persistente
o Gestor de Cuentas
o Cuenta
Colocar todas la clases de interfaz en un subsistema permitira reemplazar el
subsistema completo para adecuerlo a otra interfaz sin mayores cambios en el
resto del sistema.
UNIDAD 1

Los subsistemas implementan interfaces. Las interfaces se representan por un

circulo vinculado con una lnea de trazo continuo a la clase dentro del subsistema
que proporciona la interfaz.
Creacin del modelo de implementacin a partir del modelo de diseo.

Este modelo esta conformado por componentes, que incluyen los ejecutables
(activex, javabeans,.exe, etc ) y otro tipo de componentes como los componentes
de fichero (cdigo fuente, shell scripts, etc.), componentes de tabla (bases de
datos), etc.
Un componente se define como una parte fsica y reemplazable del sistema que
cumple y proporciona la relalizacin de un conjunto de interfaces.
Ejemplo de componentes en una clase de diseo
UNIDAD 1

Prueba de casos de uso

Verificar que el sistema implementa correctamente su especificacin.
El modelo de prueba esta compuesto por casos de prueba y procedimientos de
prueba.
Un caso de prueba es un conjunto de entradas de prueba, condiciones de
ejecucin y resultados esperados, desarrollados por un objetivo concreto, tal como
probar un camino concreto a travs de un caso de uso o verificar que cumple un
requisito especfico.
Un procedimiento de prueba es la especificacin de cmo llevar a cabo la
preparacin, ejecucin, y evaluacin de los resultados de un caso de prueba
particular.
Ejemplo:
Un caso de prueba especifica la entrada, los resultados esperados y otras
condiciones relevantes para verificar el flujo bsico del caso de uso Sacar Dinero.
Entradas:
-
La cuenta 12-121-1211 del cliente de banco tiene un saldo de $ 350

El cliente del banco se identifica correctamente
El cliente del banco solicita la retirada de $ 200 de la cuenta 12-121-1211
Hay suficiente dinero en el cajero automtico
Resultados:
-
El saldo de la cuenta 12-121-1211 disminuye a $ 150

El cliente del banco recibe $ 200 del cajero automatico
Condiciones:
-
No se permite que ningun otro caso de uso (instancias de) acceda a la

cuenta 12-121-1211 durante la ejecucin del caso de prueba.
Un proceso centrado en la arquitectura

Importancia y necesidad de una arquitectura
Se necesita uan arquitectura para:
-
Comprender el sistema
Organizar el desarrollo
UNIDAD 1

Fomentar la reutilizacin
Hacer evolucionar el sistema
Desarrollo de la arquitectura
Se desarrolla mediante iteraciones, principalmente en la etapa de elaboracin.
El resultado de la fase de elaboracin es la lnea de la arquitectura.
Los casos de uso son relevantes para la arquitectura.
Al final de la fase de elaboracin hemos desarrollado modelos del sistema que
representan los casos de uso ms importantes y sus realizaciones desde el punto
de vista de la arquitectura.
Esta agregacin de modelos es la lnea base de la arquitectura. Es un sistema
pequeo y delgado. Tiene las versiones de todos los modelos que un sistema
terminado contiene al final de la fase de cnstruccin. Incluye el mismo esqueleto
de subsistemas, componentes y nodos de un sistsme definitivo, pero no existe
toda la musculatura. Es un sistema ejecutable.
Descripicin de la arquitectura.
La lnea base de la arquitectura es la versin interna del sistema al final de la fase
de elaboracin. El conjunto de modelos que describen esta lnea base se
denomina Descripcin de la Arquitectura y su objetivo es guar al equipo de
desarrollo a travs del ciclo de vida del sistema.
La descripcin puede ser un extracto de modelos o una reescritura de los
extractos de forma que se ms fcil leerlos.
La descripcin de la arquitectura tiene cinco secciones: una vista del modelo de
casos de uso, una del modelo de analisis (opcional/descartable), una vista del
modelo diseo, una vista del modelos despliegue y una vista del modelo de
implementacin.
Vista de la arquitectura del modelo de casos de uso
Presenta los actores y casos de uso ms importantes.
Ejemplo:
El el CA el caso de uso ms importante es Sacar Dindero, sin l no tendra sentido
el CA. Para definir la arquitectura por tanto, se sugiere que el caso de uso sacar
dinero se implemente en su totalidad durante la fase de elaboracin.
UNIDAD 1

Vista de la arquitectura del modelo de diseo

Presenta los clasificadores ms importantes para la arquitectura pertenecientes al
modelo de diseo: los subsistemas e interfaces ms importantes, as como
algunas clases muy importantes, fundamentalmente clases activas.
Tambien presentan como se realizar los casos de uso en trminos de esos
clasificadores.
Vista de la arquitectura del modelo de despliegue

Presenta los nodos interconectados y las clases activas que se ejecutan en ellos
identificados durante el diseo. Esto puedo mostrarse por diagramas de
despliegue.
Ejemplo:
Vista de la arquitectura de despliegue CA.
Se incluyen los siguientes nodos y objetos activos:
-
Nodo: cliente CA Objeto activo: Gestor de clientes

Nodo: Servidor de aplicaciones CA Objeto activo: Gestor de
transacciones
Nodo: Servidor de datos CA Objeto activo: Gestor de Cuentas
UNIDAD 1

Vista de la arquitectura del modelo de implementacin

Es una correspondencia directa de los modelos diseo y despliegue.
Cada subsistema de servicio del diseo normalmente termina siendo un
componente por cada tipo de nodo en el que deba instalarse.
Un proceso iterativo e incremental

Desarrollo de pequeos pasos
Una clave importante del RUP (Proceso Unificado Rational) consiste en desarrollar
un producto software en pequeos manejables:
-
Planificar un poco
Especificar, disear, e implementar un poco
Integrar, probar y ejecutar un poco en cada iteracin
Por qu un desarrollo iterativo e incremental?
Para prevenir riesgos crticos

Para poner en marcha una arquitectura que gue el desarrollo del software
Para gestionar de buena forma los cambios del software
Para construir el sistema a lo largo del tiempo en lugar de una sola vez
cerca del final
Para proporcionar un proceso de desarrollo ms eficaz
La iteracin generica
Una iteracin es un miniproyecto, un recorrido ms o menos completo a lo largo
de todos los flujos de trabajo y que obtiene como resultado una vision interna del
sistema y su desarrollo.
Bibliografa
El proceso unificado de desarrollo software, AUS Gustavo Torossi, pp. 1-20
UNIDAD 1


Proceso Unificado

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Proceso Unificado

Caricato da

Copyright:

Formati disponibili

Proceso Unificado de Desarrollo de Software

Dirigido por casos de uso

TUTOR: CARLOS ARTURO CANCHALA E.

Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos a

El ciclo de vida del proceso unificado

Inicio: Define el alcance del proyecto

Cada fase se divide en iteraciones y en cada iteracin se desarrollo en secuencia

Adm. Configuracin y cambios

Cada disciplina est asociada a un conjunto de modelos que se desarrollan. Estos

Establecen una firme comprensin del problema a solucionar

TUTOR: CARLOS ARTURO CANCHALA E.

Elimina los mayores riesgos

El resultado de esta fase es la lnea base de la arquitectura.

El cuerpo bsico del sw en la forma de un prototipo arquitectural

Esta fase finaliza con el hito de la arquitectura del ciclo de vida.

Esta fase finaliza con el hito de capacidad operativa inicial.

TUTOR: CARLOS ARTURO CANCHALA E.

Un Proceso dirigido por casos de uso

Ejemplo de un Modelo de casos de uso de

TUTOR: CARLOS ARTURO CANCHALA E.

El cliente del banco se identifica.

Creacin de un modelo de anlisis a partir de los casos de uso

TUTOR: CARLOS ARTURO CANCHALA E.

Una clase puede participar en varias realizaciones.

Durante el analisis se utilizan diagramas de colaboracin para describir la

Creacin del modelo de diseo a partir del modelo de analisis

TUTOR: CARLOS ARTURO CANCHALA E.

El modelo de diseo se crea tomando el modelo de analisis como entrada

Loas clases del diseo refinan las clases del analisis.

TUTOR: CARLOS ARTURO CANCHALA E.

Agrupacin de clases en subsistemas

<<subsystem>> Gestin de transacciones

TUTOR: CARLOS ARTURO CANCHALA E.

Los subsistemas implementan interfaces. Las interfaces se representan por un

Creacin del modelo de implementacin a partir del modelo de diseo.

TUTOR: CARLOS ARTURO CANCHALA E.

Prueba de casos de uso

La cuenta 12-121-1211 del cliente de banco tiene un saldo de $ 350

El saldo de la cuenta 12-121-1211 disminuye a $ 150

No se permite que ningun otro caso de uso (instancias de) acceda a la

Un proceso centrado en la arquitectura

TUTOR: CARLOS ARTURO CANCHALA E.

TUTOR: CARLOS ARTURO CANCHALA E.

Vista de la arquitectura del modelo de diseo

Vista de la arquitectura del modelo de despliegue

Nodo: cliente CA Objeto activo: Gestor de clientes

TUTOR: CARLOS ARTURO CANCHALA E.

Vista de la arquitectura del modelo de implementacin

Un proceso iterativo e incremental

Por qu un desarrollo iterativo e incremental?

Para prevenir riesgos crticos

TUTOR: CARLOS ARTURO CANCHALA E.

Potrebbero piacerti anche