Está en la página 1de 42

PROCESO UNIFICADO

PROCESO DE DESARROLLO DE SOFTWARE


Conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software

Es un proceso de desarrollo de software

Est basado en componentes, lo cual quiere decir que el sistema software en construccin est formado por componentes software interconectados a travs de interfaces bien definidas

Utiliza Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema software.

Dirigido por casos de uso

Centrado en la arquitectura

Iterativo e incremental

Los verdaderos aspectos definitorios del Proceso Unificado se resumen en 3 frases claves

Centrado en la arquitect ura

Iterativo e
incremental

Dirigido por casos de uso

Dirigido por casos de uso

Alguien o algo como otro sistema fuera del sistema en consideracin que interacta con el sistema que estamos desarrollando

Centrado en la arquitect ura

Iterativo e
incremental

Dirigido por casos de uso

Dirigido por casos de uso

Centrado en la arquitect ura

Iterativo e
incremental

Dirigido por casos de uso

Dirigido por casos de uso

CAPTURA DE REQUISITOS: cul es el problema? ANLISIS: qu debe hacerse? qu sistema debemos construir? DISEO: cmo podemos solucionar el problema? CODIFICACIN: trasladar el diseo a programas... PRUEBAS: ... que funcionen... IMPLANTACIN: ... en un entorno productivo ... MANTENIMIENTO: ... y que pueden estar sujetos a posibles modificaciones o mejoras posteriores!

Centrado en la arquitect ura

Iterativo e
incremental

Dirigido por casos de uso

Dirigido por casos de uso

Centrado en la arquitect ura

Iterativo e
incremental

Dirigido por casos de uso

Dirigido por casos de uso

Es un fragmento de funcionalidad del sistema que proporciona el usuario un resultado importante

Representan los requisitos funcionales


Todos los casos de uso juntos representan un modelo de casos de uso el cual describe la funcionalidad total del sistema

Que debe hacer el sistema para cada usuario? Pensar en trminos de importancia para el usuario

Centrado en la arquitect ura

Iterativo e
incremental

Dirigido por casos de uso

Dirigido por casos de uso

Los casos de uso no son solo una herramienta para especificar los requisitos de un sistema.
GUAN EL PROCESO DE DESARROLLO

IMPLEMENTACIN

SU DISEO

PRUEBA

TAMBIN GUAN

Centrado en la arquitect ura

Iterativo e
incremental

Dirigido por casos de uso

Dirigido por casos de uso

Desarrolladores

Los ingenieros de prueba


Prueban la implementacin para garantizar que los componentes del modelo de implementacin implementan correctamente los casos de uso, es decir construyen sus casos de prueba a partir de los casos de uso

Basndose en casos de uso crean una serie de modelos de diseo e implementacin que lleva a cabo los casos de uso y revisan cada uno de los sucesivos modelos para que sean conformes al modelo de casos de uso.

Centrado en la arquitect ura

Iterativo e
incremental

Dirigido por casos de uso

Dirigido por casos de uso

Inician el proceso de desarrollo Guan el proceso de desarrollo Se desarrollan a la vez que la arquitectura del sistema y esta influye en la seleccin de los casos de uso

Dirigido por casos de uso

Iterativo e
incremental

Centrado en la arquitectura

Centrado en la arquitectura

La arquitectura software es parecido al papel que juega la arquitectura en la construccin de edificios, ya que permite al constructor ver la imagen completa antes de que comience la construccin

Dirigido por casos de uso

Iterativo e
incremental

Centrado en la arquitectura

Centrado en la arquitectura

Dirigido por casos de uso

Iterativo e
incremental

Centrado en la arquitectura

Centrado en la arquitectura

Incluye los aspectos estticos y dinmicos ms significativos


Siguiere las necesidades de la empresa, como las perciben los usuarios y los inversores y se refleja en los casos de uso Es una vista del diseo completo con las caractersticas ms importantes resaltadas, dejando los detalles de lado

Dirigido por casos de uso

Iterativo e
incremental

Centrado en la arquitectura

Centrado en la arquitectura

Se ve influida por muchos factores como:


La plataforma en que tiene que funcionar el software Los bloques de construccin de que se dispone consideraciones de implantacin

Sistemas heredados y requisitos no funcionales

Dirigido por casos de uso

Iterativo e
incremental

Centrado en la arquitectura

Centrado en la arquitectura

El valor de una arquitectura depende de las personas que se hayan responsabilizado de su creacin este proceso ayuda al arquitecto a centrarse en los objetivos adecuados, como la: Comprensibilidad La capacidad de adaptacin al cambio La reutilizacin

Dirigido por casos de uso

Iterativo e
incremental

Centrado en la arquitectura

Centrado en la arquitectura

ARQUITECTURA

CASOS DE USO

Cada uno tiene una funcin y una forma Ninguna es suficiente por s misma Las dos deben equilibrarse Debe existir interaccin entre ellos Los casos de uso deben encajar en la arquitectura cuando se llevan a cabo y por otro lado la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos ahora y en el futuro Deben evolucionar en paralelo

Dirigido por casos de uso

Iterativo e
incremental

Centrado en la arquitectura

Centrado en la arquitectura

De manera resumida podemos decir que el arquitecto:


Crea un esquema de borrador de la arquitectura, comenzando por la parte de la arquitectura que no es especfica de los casos de uso. Aun que esta parte de la arquitectura es independiente de los casos de uso, el arquitecto debe poseer una comprensin general de los casos de uso antes de comenzar la creacin del esquina arquitectnico A continuacin , el arquitecto trabaja con un subsistema de los casos de uso especificados, con aquellos que representen las funciones clave del sistema en desarrollo. Cada caso de uso seleccionado se especifica en detalle y se realiza en trminos de subsistemas
ESTE PROCESO CONTINA HASTA QUE SE CONSIDERE QUE LA ARQUITECTURA ES ESTABLE

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

Es prctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas pequeas o mini proyectos.
Cada mini proyecto es una iteracin que resulta en un incremento. Las iteraciones hace 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.

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

Los desarrolladores basan la seleccin de lo que implementarn en cada iteracin en dos cosas:

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

En cada iteracin los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseo utilizando la arquitectura seleccionada como gua, para implementar dichos casos de uso. Si la iteracin cumple sus objetivos, se contina con la prxima. Sino deben revisarse las decisiones previas y probar un nuevo enfoque.

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

Las actividades se encadenan en una mini-cascada con un alcance limitado por los objetivos de la iteracin

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

Captura de requisitos: Modelo de casos de uso, Modelo de Dominio, ... Anlisis: Diagrama de secuencia del sistema, Contratos, Modelo Conceptual... Diseo: Diagramas de interaccin, Diagrama de Clases Implementacin: Cdigo fuente (Clases y mtodos) Pruebas: verificacin de la implementacin

Captura de requisitos: Modelo de casos de uso, Modelo de Dominio, ... Anlisis: Diagrama de secuencia del sistema, Contratos, Modelo Conceptual... Diseo: Diagramas de interaccin, Diagrama de Clases Implementacin: Cdigo fuente (Clases y mtodos) Pruebas: verificacin de la implementacin

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

La iteracin controlada reduce el riesgo a los costes de un solo incremento. Reduce el riesgo de retrasos en el calendario atacando los riesgos mas importantes primero. Acelera el desarrollo. Los trabajadores trabajan de manera ms eficiente al obtener resultados a corto plazo. Tiene un enfoque ms realista al reconocer que los requisitos no pueden definirse completamente al principio.

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

Utilizar iteraciones cortas de 2 a 4 semanas incrementa la productividad del proyecto, dado que el equipo trabaja de forma ms eficiente cuando tiene objetivos a corto plazo. As mismo, con iteraciones cortas la precisin de las estimaciones aumenta. El tamao depende de: Los condicionantes del proyecto. La necesidad de tener feedback ms o menos rpido. Que no se degrade la relacin trabajo til / gestin operativa (por ejemplo reuniones, actividades necesarias que no producen valor directo, etc.). Utilizar iteraciones regulares, de manera que todas sean un timebox de la misma duracin.

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

El equipo aprende a calcular la velocidad de desarrollo, la cantidad de trabajo que puede hacer en una iteracin (sin tener que hacer extrapolaciones si las iteraciones no fuesen regulares). El cliente puede proyectar cuantas iteraciones se necesitan para tener cada entrega, en funcin de la velocidad de desarrollo del equipo (el trabajo que pudo completar en iteraciones anteriores del mismo tamao), y tomar decisiones al respecto.

Dirigido por casos de uso

Centrado en la arquitectu ra

Iterativo e incremental
Iterativo e incremental

Permite gestionar y sincronizar de manera sencilla las necesidades del proyecto con respecto a las de otros proyectos (integracin con el trabajo realizado por otros equipos, comparticin de personas que son difciles de asignar a un nico equipo). Las iteraciones coincidiendo con mese naturales permiten sincronizar el trabajo del equipo con el de otros departamentos y con el resto de la organizacin (por ejemplo, la organizacin puede tener medidas de resultados y objetivos a nivel trimestral o cuatrimestral).

El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versin del sistema. FASES Cada ciclo constas de cuatro fases: inicio, elaboracin, construccin, y transicin.

Cada ciclo produce una nueva versin del sistema, y casa versin es un producto preparado para su entrega.

Consta de un cuerpo de cdigo fuente incluido en componentes que puede compilarse y ejecutarse, adems de manuales y otros productos asociados Debe ajustarse a las necesidades de los usuarios es decir de toda la gente que trabajar con el producto.
El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba Incluye un modelo de prueba y el modelo visual

Cada fase se subdivide en iteraciones. En cada iteracin se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.

Cada fase finaliza con 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. Los hitos tienen muchos objetivos. El ms crtico es que los directores deben tomar ciertas decisiones antes de que el trabajo contine con la siguiente fase. Los hitos tambin permiten controlar la direccin y progreso del trabajo. Al final se obtiene un conjunto de datos a partir del seguimiento del tiempo y esfuerzo consumidos en cada fase. Estos datos son tiles para la estimaciones en futuros proyectos.

Durante la fase de inicio se desarrolla una descripcin del producto final, y se presenta el anlisis del negocio. Esta fase responde las siguientes preguntas: Cules son las principales funciones del sistema para los usuarios mas importantes? Cmo podra ser la mejor arquitectura del sistema? Cul es el plan del proyecto y cuanto costar desarrollar el producto? En esta fase se identifican y priorizan los riesgos mas importantes. El objetivo de esta fase es ayudar al equipo de proyecto a decidir cuales son los verdaderos objetivos del proyecto. Las iteraciones exploran diferentes soluciones posibles, y diferentes arquitecturas posibles. Puede que todo el trabajo fsico realizado en esta fase sea descartado. Lo nico que normalmente sobrevive a la fase de inicio es el incremento del conocimiento en el equipo.

Los artefactos que tpicamente sobreviven a 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. La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida. Este hito es alcanzado cuando el equipo de proyectos y los stakeholders llegan a un acuerdo sobre: - Cul es el conjunto de necesidades del negocio, y que conjunto de funciones satisfacen estas necesidades. - Una planificacin preliminar de iteraciones. - Una arquitectura preliminar.

Debe poder responderse las siguientes cuestiones: - Se ha determinado con claridad el mbito del sistema? Se ha determinado lo que va a estar dentro del sistema y fuera de el sistema? - Se ha llegado a un acuerdo con todas las personas involucradas (stakeholders) sobre los requisitos funcionales del sistema? - Se vislumbra una arquitectura que pueda soportar estas caractersticas? - Se identifican los riesgos crticos? Se prev forma de mitigarlos? - El uso del producto justifica la relacin costo-beneficio? - Es factible para su organizacin llevar adelante el proyecto? - Estn los inversores de acuerdo con los objetivos?

Durante la fase de elaboracin se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura. Las iteraciones en la fase de elaboracin: - Establecen una firme comprensin del problema a solucionar. - Establece la fundacin arquitectural para el software. - Establece un plan detallado para las siguientes iteraciones. - Elimina los mayores riesgos. El resultado de esta fase es la lnea base de la arquitectura. En esta fase se construyen tpicamente 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.

La fase de elaboracin finaliza con el hito de la Arquitectura del Ciclo de Vida. Este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre: - Los casos de uso que describen la funcionalidad del sistema. - La lnea base de la arquitectura - Los mayores riesgos han sido mitigados - El plan del proyecto Al alcanzar este hito debe poder responderse a preguntas como: - Se ha creado una lnea base de la arquitectura? Es adaptable y robusta? Puede evolucionar? - Se han identificado y mitigado los riesgos ms graves? - Se ha desarrollado un plan del proyecto hasta el nivel necesario para respaldar una agenda, costes, y calidad realistas? - Proporciona el proyecto, una adecuada recuperacin de la inversin? - Se ha obtenido la aprobacin de los inversores?

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un rea especfica dentro del proyecto total. Las ms importantes son: Requerimientos, Anlisis, Diseo, Codificacin, y Prueba. El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visin tradicional en cascada.

Libro: El proceso Unificado de Desarrollo de Software de Ivar Jcobson, Grandy booch, James Rumbaugh http://adimen.si.ehu.es/~rigau/teaching/EHU/ISHAS/Curs20082009/Apunts/IS.2.pdf http://www.proyectosagiles.org/desarrollo-iterativo-incremental http://www.ecomchaco.com.ar/UTN/disenodesistemas/apuntes/oo/ApunteR UP.pdf http://kybele.escet.urjc.es/Documentos/ISI/Proceso%20Unificado%20I%20% 282006%29.pdf http://gabrielpizarro.files.wordpress.com/2008/07/uml_logopatterns.jpg http://dc.exa.unrc.edu.ar/nuevodc/materias/sistemas/2007/TEORICOS/TEO RIA_6_PU_CR_2007.pdf http://www.unibe.edu.do/carreras/tic/ingenieria.pdf

También podría gustarte