Rup Completo

5/23/2018 Rup Completo

1/52

Universidad de Costa RicaSede Guanacaste

Bachillerato en Informtica Empresarial.

IF7100. Ingeniera de Software.M.C.I Kenneth Snchez Snchez.

Proceso Unificado RacionalR.U.P

Grupo # 1:

Bustos Muoz Stacy de los ngeles A91109Cordero Gmez Elvis Michael A81885Gallegos Barrantes Fabricio A82499

I ciclo 2012

Liberia, 09 de Mayo del 2012


2/52

1

Tabla de Contenido

OBJETIVO GENERAL: .................................................................................................................................... 3

OBJETIVOS ESPECFICOS:.............................................................................................................................. 3

METODOLOGA. ........................................................................................................................................... 4

INTRODUCCIN. .......................................................................................................................................... 5

1. PROCESO PARA EL DESARROLLO DE SOFTWARE .................................................................................. 6

1.1. DEFINICIN DE PROCESO ......................................................................................................................... 6

1.2. PROCESO DE DESARROLLO DE SOFTWARE.................................................................................................... 6

1.3. LAS CUATRO PEN EL DESARROLLO DE SOFTWARE:PERSONAS,PROYECTO,PRODUCTO Y PROCESO....................... 7

2. RESEA HISTRICA DEL PROCESO UNIFICADO RACIONAL (RUP). ........................................................ 9

3. PROCESO UNIFICADO RACIONAL (RUP) ............................................................................................. 12

3.1. INTRODUCCIN AL PROCESO UNIFICADO RACIONAL (RUP) .......................................................................... 12

3.2. PROCESO UNIFICADO RACIONAL (RUP),QU ES? .................................................................................... 133.3. DIMENSIONES. .................................................................................................................................... 14

3.4. CARACTERSTICAS. ................................................................................................................................ 15

3.5. LA VIDA DEL PROCESO UNIFICADO RACIONAL. ........................................................................................... 16

3.6. EL PRODUCTO DEL PROCESO UNIFICADO RACIONAL.................................................................................... 16

4. PRINCIPIOS DEL PROCESO UNIFICADO RACIONAL (RUP). ................................................................... 18

4.1. RUP:DIRIGIDO POR CASOS DE USO. ......................................................................................................... 18

4.2. RUP:CENTRADO EN LA ARQUITECTURA.................................................................................................... 20

4.3. RUP:ITERATIVO E INCREMENTAL............................................................................................................ 22

5. FASES................................................................................................................................................. 255.1. FASE DE INICIO .................................................................................................................................... 26

5.2. FASE DE ELABORACIN.......................................................................................................................... 28

5.3. FASE DE CONSTRUCCIN........................................................................................................................ 30

5.4. FASE DE TRANSICIN ............................................................................................................................ 32

6. FLUJOS DE TRABAJO .......................................................................................................................... 34

6.1. CAPTURA DE REQUISITOS....................................................................................................................... 34

6.2. ANLISIS ............................................................................................................................................ 35

6.3. DISEO .............................................................................................................................................. 37

6.4. IMPLEMENTACIN................................................................................................................................ 38

6.5. PRUEBA ............................................................................................................................................. 40

7. ARTEFACTOS...................................................................................................................................... 42

7.1. CONJUNTOS DE ARTEFACTOS.................................................................................................................. 42

7.2. ARTEFACTOS DE REQUERIMIENTOS .......................................................................................................... 42

7.3. ARTEFACTOS DE ANLISIS ...................................................................................................................... 43

7.4. ARTEFACTOS DE DISEO: ....................................................................................................................... 44

7.5. ARTEFACTOS DE IMPLEMENTACIN.......................................................................................................... 45


3/52

2

7.6. ARTEFACTOS DE PRUEBA........................................................................................................................ 46

CONCLUSIN. ............................................................................................................................................ 48

GLOSARIO. ................................................................................................................................................. 49

BIBLIOGRAFA. ........................................................................................................................................... 50

TABLA DE EVALUACIN. ............................................................................................................................ 51


4/52

3

Objetivo General:

Explicar la metodologa de trabajo del Proceso Unificado Racional (RUP), comoproceso de desarrollo de sistemas de software.

Objetivos Especficos: Describir a manera introductoria, una resea histrica del contexto en el que surgi

la metodologa RUP.

Conceptualizar el Proceso Unificado Racional, sus caractersticas, ciclo de vida, y elproducto final que genera.

Definir los principios que forman los cimientos sobre el que se edific lametodologa RUP.

Describir las fases de trabajo en las que se subdivide el Proceso Unificado Racional Describir los flujos de trabajo que interactan a travs de las fases del Proceso

Unificado Racional. Describir los artefactos que emplea el RUP en cada una de sus fases.


5/52

4

Metodologa

La metodologa empleada en el siguiente trabajo con el propsito de cumplir losobjetivos planteados para esta investigacin, es de carcter bibliogrfico, puesto que lainformacin que se tom para la elaboracin de la misma, proviene de libros, tesis

universitarias, entre otros elementos de ndole bibliogrfica.

Al utilizar esta metodologa, se garantiza en gran medida que la informacin que sepresenta dentro de este trabajo de investigacin sea veraz y segura con el fin de sustentaresta investigacin.


6/52

5

Introduccin

La tendencia actual en el software lleva a la construccin de sistemas ms grandes yms complejos. Por ello, la utilizacin de metodologas para el desarrollo de aplicacioneses casi imposible omitirla, debido a la gran necesidad de control de variables que conlleva

el mismo desarrollo, y para la ordenada elaboracin de las aplicaciones, por lo tanto,seguir metodologas y estndares nos llevan a estar en competitividad en todo momento.

Es de suma importancia conocer el modo como se interrelacionan metodologas conestndares y herramientas siguiendo un nico propsito, el cual consiste en la elaboracinde aplicaciones de manera eficiente, ordenada y con el menor nmero de defectos.

Entre los desarrolladores de software, existe la necesidad de desarrollar su trabajo bajouna forma que les permita coordinar sus actividades de trabajo; se requiere de un procesoque les permita integrar todas las facetas que presenta el desarrollo de software, una

metodologa comn que les permita tener una gua para ordenar las actividades de unequipo, que ofrezca criterios tanto para el control de los productos software como lasactividades del proyecto de desarrollo como tal.

El empleo de un proceso bien definido y gestionado en el desarrollo de software, es unamxima que establecera una diferencia entre proyectos de software que se finiquiten conun resultado de alta calidad y otros que fracasen. La metodologa RUP nos proporciona unestndar basado en el Lenguaje Unificado de Modelado (UML), la cual presta de guas parapoder documentar e implementar de una manera eficiente, todas las guas para un buendesarrollo, todo esto dentro de las respectivas fases en las que se desarrolla.


7/52

6

1. Proceso para el desarrollo de software1.1.Defi ni cin de procesoUn proceso es un conjunto de actividades o eventos (coordinados u organizados) que se

realizan o suceden (alternativa o simultneamente) bajo ciertas circunstancias con un findeterminado. Este trmino tiene significados diferentes segn la rama de la ciencia o latcnica en que se utilice.

1.2.Proceso de desarrol lo de softwareUn proceso define quin est haciendo qu, cundo, y cmo alcanzar un determinado

objetivo. En la ingeniera de software el objetivo es construir un producto software omejorar uno existente. Un proceso efectivo proporciona normas para el desarrollo eficientede software de calidad. Captura y presenta las mejores prcticas que el estado actual de la

tecnologa permite. En consecuencia, reduce el riesgo y hace el proyecto ms predecible. Elefecto global es el fomento de una visin y una cultura comunes.

Es necesario un proceso que sirva como gua para todos los participantes clientes,usuarios, desarrolladores y directores ejecutivos. No nos sirve ningn proceso antiguo;necesitamos uno que sea el mejor proceso que la industria pueda reunir en este punto de suhistoria. Por ltimo, necesitamos un proceso que est ampliamente disponible de forma quetodos los interesados puedan comprender su papel en el desarrollo en el que se encuentranimplicados.

Ahora bien, dentro del mbito que nos compete desarrollarnos, Qu es un proceso dedesarrollo de software? Veamos;

Proceso de negocio o caso de uso de negocio, de un negocio

de desarrollo de software. Conjunto total de actividades

necesarias para transformar los requisitos de un cliente en un

conjunto consistente de artefactos que representan un producto

software y en un punto posterior en el tiempo para

transformar cambios en dichos requisitos en nuevas versiones

del producto software (Jacobson, Booch, & Rumbaugh, 2000)

A manera de sntesis, un proceso de desarrollo de software es el conjunto de actividadesnecesarias para transformar los requisitos de un usuario en un sistema de software.

Figura 1.2.1Proceso de desarrollo de software.
http://es.wikipedia.org/wiki/Sistema_din%C3%A1micohttp://es.wikipedia.org/wiki/Cienciahttp://es.wikipedia.org/wiki/T%C3%A9cnicahttp://es.wikipedia.org/wiki/T%C3%A9cnicahttp://es.wikipedia.org/wiki/Cienciahttp://es.wikipedia.org/wiki/Sistema_din%C3%A1mico


8/52

7

Un proceso de desarrollo de desarrollo de software debera tambin ser capaz deevolucionar durante muchos aos. Durante esta evolucin debera limitar su alcance, en unmomento del tiempo dado, a las realidades que permitan las tecnologas, herramientas,personas y patrones de organizacin.

Tecnologas. El proceso debe construirse sobre las tecnologas lenguajes deprogramacin, sistemas operativos, computadores, estructuras de red, entornos dedesarrollo, etc.

Herramientas.Los procesos y las herramientas deben desarrollarse en paralelo; lasherramientas son esenciales en el proceso. Dicho de otra forma, un procesoampliamente utilizado puede soportar la inversin necesaria para crear lasherramientas que lo soporten.

Personas.Un creador del proceso debe limitar el conjunto de habilidades necesariaspara trabajar en el proceso a las habilidades que los desarrolladores actuales poseen,o apuntar aquellas que los desarrolladores pueden obtener rpidamente.

Patrones de organizacin. Aunque los desarrolladores de software no pueden serexpertos tan independientes como los msicos de una orquesta, estn muy lejos delos trabajadores autmatas en los cuales Frederick W. Taylor baso su direccin

cientfica hace cien aos. El creador del proceso debe adaptar el proceso a lasrealidades del momentohechos como las empresas virtuales; el trabajo a distanciaa travs de lneas de alta velocidad; la mezcla (en empresas pequeas) de socios dela empresa, empleados asalariados, trabajadores por obra y subcontratas deoutsourcing; y la prolongada escasez.

Los ingenieros del proceso deben equilibrar estos cuatro conjuntos de circunstancias.Adems, el equilibrio debe estar presente no solo ahora, sino tambin en el futuro; elcreador del proceso debe disearlo de forma que pueda evolucionar, de igual forma queel desarrollador de software intenta desarrollar un sistema que no slo funciona esteao, sino que evoluciona con xito los aos venideros. Un proceso debe madurardurante varios aos antes de alcanzar el nivel de estabilidad y madurez que le permitirresistir a los rigores del desarrollo de productos comerciales, manteniendo a la vez, unnivel razonable de riesgo en su utilizacin. El desarrollo de un producto nuevo esbastante arriesgado en s mismo como para aadirle el riesgo de un proceso que estpoco validado por la experiencia de su uso. En estas circunstancias un proceso puede

ser estable. Sin este equilibrio de tecnologas, herramientas, personas y organizacin, eluso del proceso sera bastante arriesgado.

1.3.Las cuatro P en el desarrollo de software: personas, proyecto,producto y proceso

El resultado final de un proyecto software es un producto que toma forma durante sudesarrollo gracias a la intervencin de muchos tipos distintos de personas. Un proceso de


9/52

8

desarrollo de software gua los esfuerzos de las personas implicadas en el proyecto, a modode plantilla que explica los pasos necesarios para terminar el proyecto. Tpicamente elproceso est automatizado por medio de una herramienta o de un conjunto de ellas. Vasela figura 1.3.1.

A lo largo de esta investigacin los trminos personas, proyecto, producto,proceso, yherramientas, que definimos a continuacin:

Personas. Los principales autores de un proyecto software son los arquitectos,desarrolladores, ingenieros de prueba, y el personal de gestin que les da soporte,adems de los usuarios, clientes, y otros interesados.

Proyecto. Elemento organizativo a travs del cual se gestiona el desarrollo desoftware. El resultado de un proyecto es una versin de un producto.

Producto. Artefactos que se crean durante la vida del proyecto, como los modelos,cdigo fuente, ejecutables y documentacin.

Proceso. Un proceso de ingeniera de software es una definicin del conjuntocompleto de actividades necesarias para transformar los requisitos de un usuario enproducto. Un proceso es una plantilla para crear proyectos.

Herramientas. Software que se utiliza para automatizar las actividades definidas enel proceso.

Figura 1.3.1Las cuatro P en el desarrollo de software.


10/52

9

2. Resea histrica del Proceso Unificado Racional (RUP)El Proceso Unificado est equilibrado por ser el producto final de tres dcadas de

desarrollo de uso prctico. Su desarrollo como producto sigue un camino desde el procesoObjectory (Primera publicacin en 1987) pasando por el proceso Objectory de Rational

(Publicado en 1997) hasta el Proceso Unificado de Rational (Publicado en 1998). Sudesarrollo ha recibido influencias de muchas fuentes. No se pretende tratar de identificartodas (realmente no sabemos cules son todas), trabajo que dejamos a la investigacin delos arquelogos del software.

Figura 2.1El desarrollo del Proceso Unificado.


11/52

10

Durante la dcada de 1980 y al principio de la dcada siguiente, los mtodos ylenguajes de programacin orientados a objetos (OO) obtuvieron una amplia difusin entrela comunidad de la ingeniera del software. Durante el mismo periodo se propuso unaamplia variedad de anlisis y diseo orientados a objetos (AOO y DOO) y se introdujo unmodelo de proceso orientado a objetos de propsito general. Al igual que la mayora de los

paradigmas "nuevos" para la ingeniera del software. Los seguidores de cada uno de losmtodos de AOO y DOO argumentaban acerca de cul de ellos era el mejor, pero ningnmtodo o lenguaje domin la escena de la ingeniera del software.

Al principio de la dcada de 1990, James Rumbaugh, Grady Booch e Ivar Jacobsoncomenzaron a trabajar en un "mtodo unificado" que combinara las mejores caractersticasde cada uno de sus mtodos individuales y adoptara caractersticas adicionales quepropusieran otros expertos. El resultado fue el lenguaje de modelado unificado (UML,porsus siglas en ingls) -que contiene una notacin robusta para el modelado y el desarrollo desistemas OO-. Para 1997, el UML se convirti en un estndar de la industria para el

desarrollo de software orientado a objetos. Al mismo tiempo, Rational Corporation y otrasfirmas desarrollaron herramientas automticas para apoyar los mtodos del UML.

El UML proporciona la tecnologa necesaria para apoyar la prctica de la ingeniera delsoftware orientada a objetos, pero no provee el marco de trabajo del proceso que gue a losequipos en la aplicacin de la tecnologa. En los aos siguientes, Jacobson, Rumbaugh yBooch desarrollaron el proceso unificado, un marco de trabajo para la ingeniera delsoftware orientada a objetos, mediante la utilizacin del UML. En la actualidad, el procesounificado y el UML se emplean de forma amplia en proyectos OO de todos los tipos. Elmodelo iterativo e incremental que propone el RUP puede y debe adaptarse para satisfacer

necesidades de proyecto especficas.

Como consecuencia de la aplicacin del UML se puede producir un arreglo deproductos de trabajo (por ejemplo, modelos y documentos). Sin embargo, stos los reducenlos ingenieros de software para lograr que el desarrollo sea ms gil y reactivo ante elcambio.


12/52

11

Figura 2.2Lnea de tiempo de los acontecimientos que dieron paso a la aparicin del Proceso Unificado Racional.

1967

SDL se

convierte enun estndar

1987

ProcesoObjectory

1.0

1995

Unin entreJacobson,Booch y

Rumbaughpara

desarrollarUML

1996

ProcesoObjectory

de Rational4.1

1998

Proceso

Unificado deRational 5.0

1999

ProcesoUnificado deRational 5.5

2000

ProcesoUnificado de

Rational2000


13/52

12

3. Proceso Unificado Racional (RUP)La tendencia actual en el software lleva a la construccin de sistemas ms grandes y

ms complejos. Esto es debido en parte al hecho de que los computadores son ms potentescada ao, y los usuarios, por tanto, esperan ms de ellos. Esta tendencia tambin se ha visto

afectada por el uso creciente de Internet para el intercambio de todo tipo de informacin de texto sin formato, fotos, diagramas y multimedia. Nuestro apetito de software an mssofisticado crece a medida que vemos cmo pueden mejorarse los productos de una versina otra. Queremos un software que est mejor adaptado a nuestras necesidades, pero esto, asu vez, simplemente hace el software ms complejo. En breve querremos ms.

Tambin lo querremos ms rpido. El tiempo de salida al mercado es otro conductorimportante.

Conseguirlo, sin embargo, es difcil. Nuestra demanda de software potente y complejo

no se corresponde con cmo se desarrolla el software. Hoy, la mayora de la gentedesarrolla software mediante los mismos mtodos que llevan utilizndose desde hace msde 25 aos. Esto es un problema. A menos que renovemos nuestros mtodos no podremoscumplir con el objetivo de desarrollar el software complejo que se necesita actualmente.

El problema del software se reduce a la dificultad que afrontan los desarrolladores paracoordinar las mltiples cadenas de trabajo de un gran proyecto de software. La comunidadde desarrolladores necesita una forma coordinada de trabajar. Necesita un proceso queintegre las mltiples facetas del desarrollo. Necesita un mtodo comn, un proceso que:

Proporcione una gua para ordenar las actividades de un equipo. Dirija las tareas de cada desarrollador por separado y del equipo como un todo. Especifique los artefactos que deben desarrollarse. Ofrezca criterios para el control y la mediacin de los productos y actividades del

proyecto.

La presencia de un proceso bien definido y bien gestionado es una diferencia esencialentre proyectos hiperproductivos y otros que fracasan. El Proceso Unificado Racional(RUP) el resultado de ms de 30 aos de experiencia es una solucin al problema delsoftware. Este apartado proporciona una visin general del Proceso Unificado Racional

completo.3.1.I ntroduccin al Proceso Uni fi cado Racional (RUP)De manera informal, un proceso de desarrollo de software describe un enfoque para la

construccin, desarrollo y, posiblemente, mantenimiento del software. El ProcesoUnificado se ha convertido en un proceso de desarrollo de software de gran xito para laconstruccin de sistemas orientados a objetos. En particular, se ha adoptado ampliamente el


14/52

13

Proceso Unificado de Rational o RUP (Rational Unified Process), un refinamientodetallado del Proceso Unificado.

El Proceso Unificado (UP) combina las prcticas comnmente aceptadas como buenas

prcticas, tales como ciclo de vida iterativo y desarrollo dirigido por el riesgo, en una

descripcin consistente y bien documentada. Es un marco de trabajo genrico que puedeespecializarse para una gran variedad de sistemas software, para diferentes reas deaplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentestamaos de proyecto.

El Proceso Unificado est basado en componentes, lo cual quiere decir que el sistemasoftware en construccin est formado por componentes software interconectados a travsde interfaces bien definidas.

El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling

Language, UML) para preparar todos los esquemas de un sistema software. De hecho,UML es una parte esencial del Proceso Unificadosus desarrollos fueron paralelos.

No obstante, los verdaderos aspectos definitorios del Proceso Unificado se resume entres frases clave dirigido por casos de uso, centrado en la arquitectura, e iterativo eincremental.

3.2.Proceso Uni f icado Racional (RUP), Ques?Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de

Rational) es un producto del proceso de ingeniera de software que proporciona un enfoque

disciplinado para asignar tareas y responsabilidades dentro de una organizacin deldesarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve lasnecesidades de los usuarios dentro de un presupuesto y tiempo establecidos.

El Proceso Unificado Racional (RUP), desde una perspectiva ms tcnica y un anlisisms profundo con relacin en sus bases y principios se puede definir de la siguientemanera, veamos;

Proceso de desarrollo de software basado en el Lenguaje

Unificado de Modelado, y que es iterativo, centrado en la

arquitectura y dirigido por los casos de uso y los riesgos.

Proceso que se organiza en cuatro fases: inicio, elaboracin,

construccin y transicin, y que se estructura en torno a cinco

flujos de trabajo fundamentales: recopilacin de requisitos,

anlisis, diseo, implementacin y pruebas. Proceso que se

describe en trminos de un modelo de negocio, el cual est a su

vez estructurado en funcin de tres bloques de construccin


15/52

14

primordiales: trabajadores, actividades y artefactos.

(Jacobson, Booch, & Rumbaugh, 2000)

El RUP no es un proceso apropiado para todos los tipos de desarrollo sino querepresenta una nueva generacin de procesos genricos. Las innovaciones ms importantes

son la separacin de fases y los flujos de trabajo, y el reconocimiento de que la utilizacinde software en un entorno del usuario es parte del proceso. Las fases son dinmicas y tienenobjetivos. Los flujos de trabajo son estticos y son actividades tcnicas que no estnasociadas con fases nicas sino que pueden utilizarse durante el desarrollo para alcanzar losobjetivos de cada fase.

3.3.DimensionesEn funcin de sus fases y flujos de trabajo que analizaremos posteriormente dentro de

este documento, el Proceso Unificado Racional presenta dos dimensiones:

El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida delproceso.

El eje vertical representa las disciplinas, que agrupan actividades definidaslgicamente por la naturaleza.

La primera dimensin representa el aspecto dinmico del proceso y se expresa entrminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensinrepresenta el aspecto esttico del proceso: cmo se describe en trminos de componentesde proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles.

En la figura 3.3.1 se puede observar como vara el nfasis de cada disciplina en uncierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en iteracionestempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones pasamosms tiempo en poner en prctica la realizacin del proyecto en s.


16/52

15

Figura 3.3.1Dimensiones del Proceso Unificado Racional

3.4.CaractersticasEl Proceso Unificado Racional se define y caracteriza por tres principios claves y

fundamentales: iterativo e incremental, dirigido por casos de uso y centrado en laarquitectura(a los cuales nos referiremos de manera ms amplia en el punto cuatro de este

documento), no obstante, aunado a estos principios bsicos, el RUP presenta caractersticasque lo definen an ms como proceso de desarrollo de software:

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo ycmo)

Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitecturabasada en componentes

Control de cambios Modelado visual del software Verificacin de la calidad del softwareCabe destacar que el RUP Incluye artefactos (que son los productos tangibles del

proceso como por ejemplo, el modelo decasos de uso,el cdigo fuente, etc.) y roles (papelque desempea una persona en un determinado momento, una persona puede desempeardistintos roles a lo largo del proceso).
http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_componenteshttp://es.wikipedia.org/wiki/Caso_de_usohttp://es.wikipedia.org/wiki/Caso_de_usohttp://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_componentes


17/52

16

3.5.La vida del Proceso Unif icado RacionalEl Proceso Unificado Racional se repite a lo largo de una serie de ciclos que

constituyen la vida de un sistema, como se muestra en la figura 3.5.1. Cada ciclo concluyecon una versin del producto para los clientes

Cada ciclo consta de cuatro fases: inicio, elaboracin, construccin y transicin (lascuales abordaremos en el punto 5 de este documento). Cada fase se subdivide a su vez eniteraciones, como se ha dicho anteriormente. Vase la figura 3.5.2.

Figura 3.5.1La vida de un proceso consta de ciclos desde su nacimiento hasta su muerte.

Figura 3.5.2Un ciclo con sus fases e iteraciones.

3.6.El Producto del Proceso Unifi cado RacionalEn el contexto del Proceso Unificado Racional, el producto que se obtiene es un sistema

software. El trmino producto aqu hace referencia al sistema entero y no slo al cdigoque se entrega.


18/52

17

Cada ciclo produce una nueva versin del sistema, y cada versin es un productopreparado para su entrega. Consta de un cuerpo de cdigo fuente incluido en componentesque puede compilarse y ejecutarse, adems de manuales y otros productos asociados. Sinembargo, el producto terminado no slo debe ajustarse a las necesidades de los usuarios,sino tambin a las de todos los interesados, es decir, toda la gente que trabajar con el

producto. El producto software debera ser algo ms que el cdigo mquina que se ejecuta.

El producto terminado incluye los requisitos, casos de uso, especificaciones nofuncionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual artefactos modelados con el Lenguaje Unificado de Modelado. De hecho, incluye todos loselementos que ya se han mencionado, debido a que son esos elementos los que permiten alos interesados clientes, usuarios, analistas, diseadores, programadores, ingenieros deprueba, y directores especificar, disear, implementar, probar y utilizar un sistema. Esms son esos elementos los que permiten a los usuarios utilizar y modificar el sistema degeneracin en generacin.

Aunque los componentes ejecutables sean los artefactos ms importantes desde laperspectiva del usuario, no son suficientes por s solos. Esto se debe a que el entornocambia. Se mejoran los sistemas operativos, los sistemas de bases de datos y las mquinasque los soportan. A medida que el objetivo del sistema se comprende mejor, los propiosrequisitos pueden cambiar. De hecho, el que los requisitos cambien es una de las constantesdel desarrollo de software. Al final los desarrolladores deben afrontar un nuevo ciclo, y losdirectores deben financiarlo. Para llevar a cabo el siguiente ciclo de manera eficiente, losdesarrolladores necesitan todas las representaciones del producto software.


19/52

18

4. Principios del Proceso Unificado Racional (RUP)En definitiva, el RUP es una metodologa de desarrollo de software que intenta

integrar todos los aspectos a tener en cuenta durante todo el ciclo de vida delsoftware, con el objetivo de hacer abarcables tanto pequeos como grandes proyectos

software. Adems proporciona herramientas para todos los pasos del desarrollo ascomo documentacin en lnea para sus clientes.

El Proceso Unificado Racional est fundamentado en tres principios clave, mismos, quelo dotan de una estructura y metodologa robusta, capaz de satisfacer las necesidades deorganizacin y coordinacin de las actividades que competen en el desarrollo de softwarede alta calidad. Estos principios son:

Dirigido por casos de uso.El objetivo del Proceso Unificado Racional es guiar a losdesarrolladores en la implementacin y distribucin eficiente de sistemas que se

ajusten a las necesidades de los clientes. La eficiencia se mide en trminos de coste,calidad, y tiempo de desarrollo. El paso desde la determinacin de las necesidadesdel cliente hasta la implementacin no es trivial. En primer lugar, las necesidadesdel cliente no son fciles de discernir. Esto nos obliga a que tengamos algn modode capturar las necesidades de usuario de forma que puedan comunicarse fcilmentea todas las personas implicadas en el proyecto. Despus, debemos ser capaces dedisear una implementacin funcional que se ajuste a esas necesidades. Por ltimo,debemos verificar que las necesidades del cliente se han cumplido mediante laprueba del sistema. Debido a esta complejidad, el proceso se describe como unaserie de flujos de trabajo que construyen el sistema gradualmente.

Centrado en la arquitectura. Iterativo e incremental.Estos principios sientan las bases de toda gestin de actividades que se coordine en los

equipos de trabajo de desarrollo de software dentro del marco del Proceso UnificadoRacional. En los siguientes puntos de este apartado se analizarn y explicarn cada uno deestos principios de forma ms amplia.

4.1.RUP: dir igi do por casos de usoCon esto se refiere a la utilizacin de los Casos de Uso para el desenvolvimiento ydesarrollo de las disciplinas con los artefactos, roles y actividades necesarias. Los Casos

de Uso son la base para la implementacin de las fases y disciplinas del RUP. Un Caso deUso es una secuencia de pasos a seguir para la realizacin de un fin o propsito, y serelaciona directamente con los requerimientos, ya que un Caso de Uso es la secuencia depasos que conlleva la realizacin e implementacin de un Requerimiento planteado por elCliente.


20/52

19

Un sistema software ve la luz para dar servicio a sus usuarios. Por tanto, para construirun sistema con xito debemos conocer lo que sus futuros usuarios necesitan y desean.

El trmino usuario no slo hace referencia a usuarios humanos, sino a otros sistemas.En este sentido, el trmino usuario representa alguien o algo (como otro sistema fuera del

sistema en consideracin) que interacta con el sistema que estamos desarrollando. Unejemplo de interaccin sera una persona que utiliza un cajero automtico. l (o ella)insertar una tarjeta de plstico, responde a las preguntas que le hace la mquina en supantalla, y recibe una suma de dinero. En respuesta a la tarjeta del usuario y a suscontestaciones, el sistema lleva a cabo una secuencia de acciones que proporcionan alusuario un resultado importante, en este caso la retirada del efectivo.

Una interaccin de este tipo es un caso de uso. Un caso de uso es un fragmento defuncionalidad del sistema que proporciona al usuario un resultado importante. Los casos deuso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad del

sistema. Puede decirse que una especificacin funcional contesta a la pregunta Qu debehacer el sistema? La estrategia de los casos de uso puede describirse tres palabras al final deesta pregunta para cada usuario? Estas tres palabras albergan una implicacinimportante. Nos fuerza a pensar en trminos de importancia para el usuario y no slo entrminos de funciones que sera bueno tener. Sin embargo los casos de uso no son slo unaherramienta para especificar los requisitos de un sistema. Tambin guan su diseo,implementacin y prueba; esto es guan el proceso de desarrollo. Basndose en el modelode casos de uso, los desarrolladores crean una serie de modelos de diseo e implementacinque llevan a cabo los casos de uso. Los ingenieros de prueba, prueban la implementacinpara garantizar que los componentes del modelo de implementacin implementan

correctamente los casos de uso. De este modo los casos de uso no slo inician el proceso dedesarrollo sino que le proporcionan un hilo conductor. Dirigido por casos de uso quieredecir que el proceso de desarrollo sigue un hiloavanza a travs de una serie de flujos detrabajo que parten de los casos de uso. Los casos de uso se especifican, se disean, y loscasos de uso finales son la fuente a partir de la cual los ingenieros de prueba construyen suscasos de prueba.

Los casos de uso han sido adoptados casi universalmente para la captura de requisitosde sistemas software en general, y de sistemas basados en componentes en particular, perolos casos de uso son mucho ms que una herramienta para capturar requisitos como ya seha visto. Dirigen el proceso de desarrollo en su totalidad. Los casos de uso son la entradafundamental cuando se identifican y especifican clases, casos de prueba, subsistemas einterfaces, y cuando se planifican las iteraciones del desarrollo y la integracin del sistema.Para cada iteracin, nos gua a travs del conjunto completo de flujos de trabajo, desde lacaptura de requisitos, pasando por el anlisis, diseo e implementacin, hasta la prueba, enlazando estos diferentes flujos de trabajo.


21/52

20

La captura de requisitos tiene como objetivos: encontrar los verdaderos requisitos yrepresentarlos de un modo adecuado para los usuarios, clientes y desarrolladores.Entendemos por verdaderos requisitos aquellos que cuando se implementen aadirn elvalor esperado para los usuarios. Con representarlos de un modo adecuado para los

usuarios, clientes y desarrolladores queremos decir en concreto que la descripcin

obtenida de los requisitos debe ser comprensible por usuarios y clientes

Ahora bien,Por qucasos de uso?, veamos;

Existen varios motivos por los cuales los casos de uso son buenos, se han hechopopulares y se han adoptado universalmente. Las dos razones fundamentales son:

Proporcionan un medio sistemtico e intuitivo de capturar requisitos funcionalescentrndose en el valor aadido para el usuario.

Dirigen todo el proceso de desarrollo debido a que la mayora de las actividadescomo el anlisis, diseo y prueba se llevan a cabo partiendo de los casos de uso. Eldiseo y la prueba pueden tambin planificarse y coordinarse en trminos de casosde uso. Esta caracterstica es an ms evidente cuando la arquitectura se haestabilizado en el proyecto, despus del primer conjunto de iteraciones.

Aunque es cierto que los casos de uso guan el proceso, no se desarrollan aisladamente.Se desarrollan a la vez que la arquitectura del sistema. Es decir, los casos de uso guan laarquitectura del sistema y sta influye en la seleccin de casos de uso. Por ende, tanto laarquitectura del sistema como los casos de uso maduran segn avanza el ciclo dedesarrollo.

4.2.RUP: centrado en la arqui tecturaLos casos de uso solamente no son suficientes. Se necesitan ms cosas para conseguir

un sistema de trabajo. Esas cosas son la arquitectura. Podemos pensar que la arquitecturade un sistema es la visin comn en la que todos los empleados (desarrolladores y otrosusuarios) deben estar de acuerdo, o como poco, deben aceptar. La arquitectura nos da unaclara perspectiva del sistema completo, necesaria para controlar el desarrollo.

El papel de la arquitectura de software es parecido al papel que juega la arquitectura enla construccin de edificios. El edificio se contempla desde varios puntos de vista:

estructura, servicios, conduccin de la calefaccin, fontanera, electricidad, etc. Estopermite a un constructor ver una imagen completa antes de que comience la construccin.Anlogamente, la arquitectura en un sistema software se describe mediante diferentes vistasdel sistema en construccin.

Necesitamos una arquitectura, bien. Pero, qu quiere decir exactamente arquitectura

de sistemas software? El concepto de arquitectura software incluye los aspectos estticos y


22/52

21

dinmicos ms significativos del sistema. La arquitectura surge a las necesidades de laempresa, como la perciben los usuarios y los inversores, y se refleja en los casos de uso. Sinembargo, tambin se ve influida por muchos otros factores, como la plataforma en la quetiene que funcionar el software (arquitectura hardware, sistema operativo, sistema degestin de base de datos, protocolos para comunicaciones en red), los bloques de

construccin reutilizables de que se dispone (por ejemplo un marco de trabajo parainterfaces grficas de usuario), consideraciones de implantacin, sistemas heredados, yrequisitos no funcionales (por ejemplo, rendimiento, fiabilidad). La arquitectura es unavista del diseo completo con las caractersticas ms importantes resaltadas, dejando losdetalles de lado. Debido a que lo que es significativo depende en parte de una valoracin,que a su vez, se adquiere con la experiencia, el valor de una arquitectura depende de laspersonas que se hayan responsabilizado de su creacin. No obstante, el proceso ayuda alarquitecto a centrarse en los objetivos adecuados, como la comprensibilidad, la capacidadde adaptacin al cambio, y la reutilizacin.

Cmo se relacionan los casos de uso y la arquitectura?Cada producto tiene tanto unafuncin como una forma. Ninguna es suficiente por s misma. Estas dos fuerzas debenequilibrarse para obtener un producto con xito. En esta situacin la funcin corresponde alos casos de uso y la forma a la arquitectura. Debe haber interaccin entre los casos de usoy la arquitectura. Es un problema del tipo el huevo y la gallina. Por un lado los casos deuso deben encajar en la arquitectura cuando se llevan a cabo. Por otro lado, la arquitecturadebe permitir el desarrollo de todos los casos de uso requeridos. Ahora y en el futuro. Enrealidad tanto la arquitectura como los casos de uso deben evolucionar en paralelo.

Por tanto, los arquitectos moldean el sistema para darle forma. Es esta forma, la

arquitectura, la que debe disearse para permitir que el sistema evolucione, no slo en sudesarrollo inicial, sino tambin a lo largo de las futuras generaciones. Para encontrar esaforma, los arquitectos deben trabajar sobre la comprensin general de las funciones clave,es decir, sobre los casos de uso claves del sistema. Estos casos de uso clave pueden suponersolamente entre el 5 y el 10 por ciento de todos los casos de uso, pero son los significativos,los que constituyen las funciones fundamentales del sistema. De manera resumida podemosdecir que el arquitecto:

Crea un esquema en borrador de la arquitectura, comenzando por la parte de laarquitectura que no es especfica de los casos de uso (por ejemplo, la plataforma).Aunque esta parte de la arquitectura es independiente de los casos de uso, elarquitecto debe poseer una comprensin general de los casos de uso antes decomenzar la creacin del esquema arquitectnico.

A continuacin, el arquitecto trabaja con un subconjunto de los casos de usoespecificados, con aquellos que representen las funciones clave del sistema endesarrollo. Cada caso de uso se especifica en detalle y se realiza en trmino desubsistemas, clases, y componentes.


23/52

22

A medida que los casos de uso se especifican y maduran, se descubre ms de laarquitectura. Esto a su vez, lleva a la maduracin de ms casos de uso.

Este proceso contina hasta que se considere que la arquitectura es estable.

Ahora bien,Por quse debe centrar en la arquitectur a?, veamos;El saber identificar que hace un sistema, casi siempre con poca o ninguna

documentacin, y que cdigo pueden reutilizar los desarrolladores, aade complejidad aldesarrollo.

Se necesita una arquitectura para:

Comprender el sistema. Organizar el desarrollo. Fomentar la reutilizacin. Hacer evolucionar el sistema.Los casos de uso dirigen la arquitectura para hacer que el sistema proporcione la

funcionalidad y usos deseados, alcanzando a la vez objetivos de rendimiento razonables.Una arquitectura debe ser completa, pero tambin debe ser suficientemente flexible comopara incorporar nuevas funciones, y debe soportar la reutilizacin del software existente.

4.3.RUP: I terativo e incrementalUn proceso de desarrollo de software debe tener una secuencia de hitos claramente

articulados para ser eficaz, que proporcionen a los directores y al resto del equipo delproyecto los criterios que necesitan para autorizar el paso de una fase a la siguiente dentrodel ciclo del producto.

Dentro de cada fase, el proceso pasa por iteraciones e incrementos que nos conducen aesos criterios.

El desarrollo de un producto software comercial supone un gran esfuerzo que puededurar entre varios meses hasta posiblemente un ao o ms. Es prctico dividir el trabajo en

partes ms pequeas o miniproyectos. Cada miniproyecto es una iteracin que resulta en unincremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y losincrementos, al crecimiento del producto. Para una efectividad mxima, las iteracionesdeben estar controladas; esto es, deben seleccionarse y ejecutarse de una forma planificada.Es por esto por lo que son mini-proyectos.

Este tercer principio proporciona la estrategia para desarrollar un producto software enpasos pequeos manejables:


24/52

23

Planificar un poco. Especificar, disear, e implementar un poco. Integrar, probar, y ejecutar un poco cada iteracin.Si estamos contentos con un paso, continuamos con el siguiente. Entre cada paso,

obtenemos retroalimentacin que nos permite ajustar nuestros objetivos para el siguientepaso. Despus se da el siguiente paso, y despus otro. Cuando se han dado todos los pasosque habamos planificado, tenemos un producto desarrollado que podemos distribuir anuestros clientes y usuarios.

Las iteraciones en las primeras fases tratan en su mayor parte con la determinacin delmbito del proyecto, la eliminacin de los riesgos crticos, y la creacin de la lnea base dela arquitectura. Despus, a medida que avanzamos a lo largo del proyecto y vamosreduciendo gradualmente los riesgos restantes e implementando los componentes, la formade las iteraciones cambia, dando incrementos como resultados.

Un proyecto de desarrollo software transforma una delta (un cambio) de los requisitos

de usuario en una delta del producto software. Con el mtodo de desarrollo iterativo eincremental esta adaptacin de los cambios se realiza poco a poco. Dicho de otra forma,dividimos el proyecto en un nmero de miniproyectos, siendo cada uno de ellos unaiteracin. Cada iteracin tiene todo lo que tiene un proyecto de desarrollo de software:planificacin, desarrollo en una serie de flujos de trabajo (requisitos, anlisis y diseo,implementacin y prueba), y una preparacin para la entrega.

Pero una iteracin no es una entidad completamente independiente es una etapa dentro

de un proyecto, y se ve fuertemente condicionada por ello. Decimos que es un miniproyectoporque no es por s misma algo que nuestros usuarios nos hayan pedido que hagamos.Adems, cada uno de estos miniproyectos se parece al antiguo ciclo de vida en cascadadado que se desarrolla a travs de actividades en cascada. Podramos llamar unaminicascada a cada iteracin.

El ciclo de vida iterativo produce resultados tangibles en forma de versiones internas(aunque preliminares), y cada una de ellas aporta un incremento y demuestra la reduccinde los riesgos con los que se relaciona. Estas versiones pueden presentarse a los clientes yusuarios en cuyo caso proporcionan una retroalimentacin valiosa para la validacin del

trabajo.Los jefes de proyecto tratarn de ordenar las iteraciones para conseguir una va directa

en la cual las primeras iteraciones proporcionen la base del conocimiento para lassiguientes. Las primeras iteraciones del proyecto consiguen incrementar la comprensin delos requisitos, el problema, los riesgos, y el dominio de la solucin, mientras que lasrestantes aaden incrementos que al final conformarn la versin externa, es decir elproducto para el cliente. El xito fundamental para los jefes de proyecto es conseguir


25/52

24

una serie de iteraciones que siempre avanzan; es decir, que nunca hay que volver dos o tresiteraciones atrs para corregir el modelo debido a algo que hemos aprendido en la ltimaiteracin. No queremos escalar una montaa de nieve que se funde, dando dos pasosadelante y resbalando uno hacia atrs.

En resumen, un ciclo de vida se compone de una secuencia de iteraciones. Algunas deellas, especialmente las primeras, nos ayudan a comprender los riesgos, determinar aviabilidad, construir el ncleo interno del software, y realizar el anlisis de negocio. Otras,en especial las ltimas, incorporan incrementos hasta conseguir un producto preparado parasu entrega.

Las iteraciones ayudan a la direccin a planificar, a organizar, a hacer el seguimiento ya controlar el proyecto. Las iteraciones se organizan dentro de las cuatro fases (quedesarrollaremos ms adelante en el punto 5), cada una de ellas con necesidades concretasde personal, financiacin y planificacin, y con sus propios criterios de comienzo y fin. Al

comienzo de cada fase, la direccin puede decidir cmo llevarla a cabo, los resultados quedeben entregarse, y los riesgos que deben reducirse.

Ahora bien,por quun desarrol lo iterati vo e incr emental?Veamos;

En dos palabras: para obtener un mejor software. Dicho con unas cuantas palabras ms,para cumplir los hitos principales y secundarios con los cuales controlaremos el desarrollo.Y dicho con algunas palabras ms:

Para tomar las riendas de los riesgos crticos y significativos desde el principio. Para poner en marcha una arquitectura que gue el desarrollo del software. Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables

cambios en los requisitos y en otros aspectos.

Para construir el sistema a lo largo del tiempo en lugar de hacerlo de una sola vezcerca del final, cuando el cambiar algo se ha vuelto costoso.

Para proporcionar un proceso de desarrollo a travs del cual el personal puedetrabajar de manera ms eficaz.

Y finalmente,Por quRUP se edif ica sobre los cimientos de estos tres principi osfundamentales?

Estos conceptos los de desarrollo dirigido por los casos de uso, centrado en laarquitectura, iterativo e incremental son de igual importancia. La arquitecturaproporciona la estructura sobre la cual guiar las iteraciones, mientras que los casos de usodefinen los objetivos y dirigen el trabajo de cada iteracin. La eliminacin de una de lastres ideas reducira drsticamente el valor del Proceso Unificado Racional. Es como untaburete de tres patas. Sin una de ellas el taburete se cae.


26/52

25

5. FasesCada ciclo se desarrolla a lo largo del tiempo. Este tiempo, a su vez, se divide en cuatro

fases, como se muestra en la figura 5.1. A travs de una secuencia de modelos, losimplicados visualizan lo que est sucediendo en esas fases. Dentro de cada fase, los

directores o los desarrolladores pueden descomponer adicionalmente el trabajo eniteraciones con sus incrementos resultantes. Cada fase termina con un hito. Cada hito sedetermina por la disponibilidad de un conjunto de artefactos; es decir, ciertos modelos odocumentos han sido desarrollados hasta alcanzar un estado predefinido.

Los hitos tienen muchos objetivos. El ms crtico es que los directores deben de tomarciertas decisiones cruciales antes de que el trabajo pueda continuar con la siguiente fase.Los hitos tambin permiten a la direccin, y a los mismos desarrolladores, controlar elprogreso del trabajo segn pasa por esos cuatro puntos clave. Al final, se obtiene unconjunto de datos a partir del seguimiento del tiempo y esfuerzo consumido en cada fase.

Estos datos son tiles en la estimacin del tiempo y los recursos humanos para otrosproyectos, en la asignacin de los recursos durante el tiempo que dura el proyecto, y en elcontrol del progreso contrastado con las planificaciones.

La figura 5.1 muestra en la columna izquierda los flujos de trabajo (que sernexplicados en el punto 6 de este documento) requisitos, anlisis, diseo, implementacin yprueba. Las curvas son una aproximacin (no deben considerarse muy literalmente) dehasta dnde se llevan a cabo los flujos de trabajo en cada fase. Recurdese que cada fase sedivide normalmente en iteraciones o mini proyectos. Una iteracin tpica pasa por loscinco flujos de trabajo.


27/52

26

Figura 5.1Los cinco flujos de trabajo (requisitos, anlisis, diseo, implementacin y prueba). Tienen lugarsobre las cuatro fases: inicio, elaboracin, construccin y transicin.

Figura 5.2Trminos orientados a la planificacin del RUP en sus fases.

5.1.Fase de I nicioEl objetivo global de la fase de inicio es poner en marcha el proyecto. Antes de esta

fase puede que tenga simplemente una idea interesante rondndole la cabeza. La fase de


28/52

27

inicio puede tratarse de algo tan sencillo como una persona que recopile unadeclaracin de objetivos, esboce una arquitectura usando diversos diagramas, desarrolleun anlisis de negocio razonable. O puede ser tan complejo como un proyecto deinvestigacin completo. Lo importante es que no consideremos la fase de inicio comoalgo que ha de desarrollarse de una nica forma.

Durante la fase de inicio se desarrolla una descripcin de la fase final a partir de unabuena idea y se presenta el anlisis de negocio para el producto. Esencialmente esta faseresponde a las siguientes preguntas:

Cules son las principales funciones del sistema para sus usuarios msimportantes?

Cmo podra ser la arquitectura del sistema? Cul es el plan de proyecto y cunto costar desarrollar el producto?La respuesta de la primera pregunta se encuentra en un modelo de casos de usosimplificado que contenga los casos de uso ms crticos. Cuando lo tengamos, la

arquitectura es provisional, y consiste tpicamente en un simple esbozo que muestra lossubsistemas ms importantes. En esta fase se identifican y priorizan los riesgos msimportantes, se planifica en detalle la fase de elaboracin y se estima el proyecto de maneraaproximada.

Intentamos desarrollar el anlisis inicial de negocio para considerar el sistema previstoen trminos econmicos, es decir, estimaciones iniciales de costes, agenda y recuperacinde la inversin. Nos preguntaremos:

Compensarn las ganancias procedentes del uso o la venta del producto software,los costos de su desarrollo?

Llegar el producto al mercado (o a su aplicacin interna) a tiempo de obtener esasganancias?


29/52

28

Figura 5.1.1El trabajo de una iteracin en la fase de inicio transcurre a travs de los cinco flujos de trabajofundamentales. Los tamaos relativos de los rectngulos solo indican qu flujos de trabajo requieren ms

atencin.

5.2.Fase de ElaboracinSegn entramos en la fase de elaboracin, dejamos atrs un hito principal que seala

tres logros:

Hemos formulado la arquitectura inicial. Hemos identificado los problemas ms serios o crticos. Hemos realizado el anlisis inicial de negocio con el suficiente grado de detalle

como para entrar en sta segunda fase.

Durante la fase de elaboracin, se especifican en detalle la mayora de casos de uso delproducto y se disea la arquitectura del sistema. La relacin entre la arquitectura delsistema y el propio sistema es primordial. Una manera simple de expresarlo es decir que laarquitectura es anloga al esqueleto cubierto por la piel pero con muy poco msculo(software) entre los huesos y la piel, solo lo necesario para permitir que el esqueleto hagamovimientos bsicos. El sistema es el cuerpo entero con esqueleto, piel y msculo. Portanto, la arquitectura se expresa en forma de vistas de todos los modelos del sistema, los


30/52

29

cuales juntos representan al sistema entero. Esto implica que hay vistas arquitectnicas delmodelo de casos de uso, anlisis, diseo, implementacin, y de despliegue. La vista delmodelo de implementacin incluye componentes para probar que la arquitectura esejecutable. Durante esta fase del desarrollo se realizan los casos de uso ms crticos que seidentificaron en la fase de inicio. El resultado de esta fase es una lnea base de la

arquitectura.

Al final de la fase de elaboracin, el director de proyecto est en disposicin deplanificar las actividades y estimar los recursos necesarios para terminar el proyecto. Aqula cuestin fundamental es: Son suficientemente estables los casos de uso, la arquitectura yel plan, y estn los riesgos suficientemente controlados como para que seamos capaces decomprometernos al desarrollo mediante un contrato?

En esta fase los principales objetivos son:

Recopilar la mayor parte de los requisitos que an queden pendientes, formulandolos requisitos como casos de uso.

Establecer una base de arquitectura slida (la lnea base de la arquitectura) paraguiar el trabajo durante las fases de construccin y transicin, as como en lasposteriores generaciones del sistema.

Continuar la observacin y control de los riesgos crticos que an queden, eidentificar los riesgos significativos hasta el punto de que se pueda estimar suimpacto en el anlisis de negocio, y en particular en la puesta econmica.

Completar los detalles de plan de proyecto.Esta fase supone desarrollar alrededor del 80 por ciento de los casos de uso y abordar

los riesgos que interfieran en la consecucin de este objetivo. En esta fase presentaremos elentorno de desarrollo, no slo para llevar acabo las actividades de esta fase, sino para estarpreparados para la fase de construccin. As al final de esta fase, habremos acumulado lainformacin necesaria para planificar la fase de construccin. Tambin, en ese momentotendremos informacin suficiente para realizar un anlisis de negocio fiable, trabajo quecomenzamos durante la fase de inicio.


31/52

30

Figura 5.2.1El trabajo de una iteracin en la fase de elaboracin discurre a lo largo de los cinco flujos detrabajo fundamentales. La mayor parte del esfuerzo se realiza durante la recopilacin de requisitos, anlisis y

diseo; es necesario comprender la mayora de los requisitos y disear el sistema. En comparacin,implementacin y pruebas precisa menos recursos.

5.3.Fase de construccinEl propsito primordial de esta fase es dejar listo un producto software en su versin

operativa inicial, a veces llamada versin beta. El producto debera tener la calidad

adecuada para su aplicacin y asegurarse de cumplir los requisitos. La construccin deberatener lugar dentro de los lmites del plan de negocio.

Durante la fase de construccin se crea el producto. En esta etapa, la lnea base de laarquitectura, crece hasta convertirse en el sistema completo. La descripcin evolucionahasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios.El grueso de los recursos requeridos son empleados durante esta fase del desarrollo. Sinembargo, la arquitectura del sistema es estable, aunque los desarrolladores puedendescubrir formas mejores de estructurar el sistema, ya que los arquitectos recibirnsugerencias de cambios arquitectnicos de menor importancia. Al final de esta fase, elproducto contiene todos los casos de uso que la direccin y el cliente han acordado para eldesarrollo de esta versin. No obstante, puede que no est completamente libre de defectos.Muchos de estos defectos se descubrirn y solucionaran durante la fase de transicin. La


32/52

31

pregunta decisiva es: cubre el producto las necesidades de algunos usuarios de manerasuficiente como para hacer una primera entrega?

Durante la fase de construccin, el jefe de proyecto, el arquitecto y los desarrolladoresse aseguran de establecer la prioridad de los casos de uso, que son agrupados en

construcciones e iteraciones y desarrollados segn un orden que evita las vueltas atrs.

Adems, mantendrn actualizada la lita de riesgos, mediante su continuo refinamiento,de forma que refleje los riesgos reales del proyecto. Su objetivo es acabar esta fase contodos los riesgos mitigados (exceptuando aquellos que se derivan de la operacin, que sontratados en la fase de transicin). El arquitecto vigila que la construccin se ajuste a laarquitectura y si es necesario modifica dicha arquitectura para incorporar los cambios quesurgen durante el proceso de construccin.

Figura 5.3.1El trabajo de una iteracin durante la fase de construccin discurre a lo largo de los cinco flujosde trabajo fundamentales. Aqu se detallan y analizan los requisitos restantes, pero la carga de trabajo en estosflujos, es relativamente leve. La mayor parte de este trabajo fue realizada en las dos fases anteriores; el diseo

juega un papel importante y es en esta fase en la que tiene lugar la mayor parte del trabajo de los flujos deimplementacin y pruebas. (El tamao de las barras tiene un carcter meramente ilustrativo, y ser distinto en

diferentes proyectos).


33/52

32

5.4.Fase de TransicinUna vez que el proyecto entra en la fase de transicin, el sistema ha alcanzado la

capacidad operativa inicial.

La fase de transicin cubre el perodo durante el cual el producto se convierte enversin beta. En la versin beta un nmero reducido de usuarios con experiencia prueba elproducto e informa de defectos y deficiencias. Los desarrolladores corrigen los problemas eincorporan algunas de las mejoras sugeridas en una versin general dirigida a la totalidadde la comunidad de usuarios. La fase de transicin conlleva actividades como lafabricacin, formacin del cliente, el proporcionar una lnea de ayuda y asistencia, y lacorreccin de los defectos que se encuentren tras la entrega. El equipo de mantenimientosuele dividir esos defectos en dos categoras. Los que tienen suficiente impacto en laoperacin para justificar una versin incrementada (versin delta) y los que puedencorregirse en la siguiente versin normal.

Esta fase se centra en implantar el producto en su entorno de operacin. La forma enque el proyecto lleva a cabo su objetivo vara con la naturaleza de la relacin del productocon su mercado.

En esta fase no se busca reformular el producto. El cliente y el equipo del proyectodeberan haber incorporado cambios significativos en los requisitos durante las fasesanteriores. Por el contrario, el equipo busca pequeas deficiencias que pasarondesapercibidas durante la fase de construccin y que pueden ser corregidas en el marco dela lnea base de la arquitectura existente.

En el caso de productos para muchos usuarios (para el mercado del software

enlatado) estos servicios se construyen en el programa de instalacin que es parte delproducto, complementado con el servicio de asistencia tcnica.

La fase de transicin finaliza con el lanzamiento del producto.


34/52

33

Figura 5.4.1El trabajo de una iteracin durante la fase de transicin discurre a lo largo de los cinco flujos detrabajo fundamentales. (El tamao de las barras tiene un carcter meramente ilustrativo, y ser distinto en

diferentes proyectos). Los flujos de trabajo e implementacin y pruebas son los que reciben mayor atencinen esta fase. Es aqu donde los defectos encontrados durante las pruebas beta o las de aceptacin se

identifican, corrigen y prueban de nuevo. En unos pocos casos ser necesario redisear, para corregir losdefectos, lo que llevara a un pequeo aumento en el flujo de trabajo de diseo. Los requisitos no se ven muy

afectados.


35/52

34

6. Flujos de trabajo6.1.Captura de RequisitosLlamamos captura de requisitosal acto de descubrimiento.Es el proceso de averiguar,

normalmente en circunstancias difciles. De hecho, es tan difcil que todava no es pococomn para los equipos de un proyecto el comenzar a escribir cdigo (lo cual es bastantefcil) antes de que hayan firmado simplemente lo que se supone debe hacer el cdigo (locual es difcil de determinar).

La captura de requisitos entendida como un flujo de trabajo, tiene como propsitoesencial orientar el desarrollo hacia el sistema correcto. Esto se lleva a cabo mediante ladescripcin de los requisitos del sistema de forma tal que se pueda llegar a un acuerdo entreel cliente (incluyendo los usuarios) y los desarrolladores del sistema, acerca de lo que elsistema debe hacer y lo que no.

La posibilidad de tener puntos de partida tan dispares como una vaga nocin y unaespecificacin de requisitos detallada sugiere que los analistas necesitan ser capaces deadaptar sus tcnicas a la captura de requisitos en cada situacin. Los diferentes puntos departida plantean tipos diferentes de riesgos, por lo que los analistas deberan elegir lastcnicas que reduzcan esos riesgos de la mejor forma.

Aparte de las diferencias en los puntos de partida, ciertos pasos son factibles en lamayora de los casos, lo que nos permite sugerir un flujo de trabajo arquetpico. Este flujode trabajo incluye los siguientes pasos, que en realidad no se llevan a cabo separadamente:

Enumerar los requisitos candidatos. Comprender el contexto del sistema. Capturar requisitos funcionales. Capturar requisitos no funcionales.

La figura 6.1.1 ilustra cmo el flujo de trabajo de captura de requisitos y sus artefactosresultantes adquieren formas durante las distintas fases y sus iteraciones.


36/52

35

Figura 6.1.1El trabajo de los requisitos se hace fundamentalmente durante el inicio y la elaboracin.

Durante la fase de in icio, los analistas capturan la mayora de los casos de uso paradelimitar el sistema y el alcance del proyecto y para detallar los ms importantes(menos del 10 por ciento).

Durante la fase de elaboracin, los analistas capturan la mayora de los requisitosrestantes para que los desarrolladores puedan estimar el tamao del esfuerzo de

desarrollo que se requerir. El objetivo es haber capturado sobre un 80 por ciento delos requisitos y haber descrito la mayora de los casos de uso al final de esta fase deelaboracin. (Obsrvese que slo entre un 5 y un 10 por ciento de los requisitosdebera estar implementado en la lnea base en ese momento.)

Los requisitos restantes de captura (e implementan) durante la fase de construccin. Casi no hay captura de requisitos en la fase de transicin, a menos que haya

requisitos que cambien.

6.2.AnlisisDurante este flujo de trabajo, analizamos los requisitos que se describieron en la

captura de requisitos, refinndolos y estructurndolos. El objetivo de hacerlo es conseguiruna comprensin ms precisa de los requisitos y una descripcin de los mismos que seafcil de mantener y ayude a estructurar el sistema entero, incluyendo su arquitectura.

Las iteraciones iniciales de la elaboracin se centran en el anlisis (vase lafigura6.2.1). Eso contribuye a obtener una arquitectura estable y slida y facilita una


37/52

36

comprensin en facilidad de los requisitos, el nfasis pasa en cambio al diseo y a laimplementacin.

Figura 6.2.1El anlisis.

El propsito y objetivo del anlisis debe alcanzarse de algn modo en todo proyecto.

Pero la manera exacta de ver y de emplear el anlisis puede diferir de un proyecto a otro, ynosotros distinguimos tres variantes bsicas:

1. El proyecto utiliza el modelo de anlisis para describir los resultados del mismo, ymantiene la consistencia de este modelo a lo largo de todo el ciclo de vida delsoftware. Esto puede hacerse, por ejemplo, de manera continua en cada iteracin delproyecto.

2. El proyecto utiliza el modelo de anlisis para describir los resultados del anlisispero considera a este modelo como una herramienta transitoria e intermedia. Msadelante, cuando el diseo y la implementacin estn en marcha durante la fase de

construccin, se deja de actualizar el anlisis. En su lugar, cualquier tema deanlisis que an quede se resuelve como parte integrada dentro del trabajo de

diseo en el modelo de diseo resultarte.3. El proyecto no utiliza en absoluto el modelo de anlisis para describir los resultados

del anlisis. En cambio el proyecto analiza los requisitos como parte integrada en lacaptura de requisitos o en el diseo. En el primero de los casos, har falta un mayorformalismo en el modelo de casos de uso. Esto puede ser justificable si el cliente es


38/52

37

capaz de comprender los resultados, aunque creemos que rara vez se da el caso. Elsegundo caso podra complicar el trabajo de diseo, sin embargo, esto puede serjustificable si, por ejemplo, los requisitos son muy simples y/o son bien conocidos,si es fcil identificar la forma del sistema (incluyendo su arquitectura), o si losdesarrolladores cuentan con una cierta comprensin, intuitiva pero correcta, de los

requisitos, y son capaces de construir un sistema que los encarne de una manerabastante directa.

6.3.DiseoEn el diseo modelamos el sistema y encontramos su forma (incluida la arquitectura)

para que soporte todos los requisitos incluyendo los requisitos no funcionales y otrasrestricciones que se le suponen. Una entrada esencial en el diseo es el resultado delanlisis, esto es, el modelo de anlisis. El modelo de anlisis proporciona una comprensin

detallada de los requisitos. Y lo que es ms importante, impone una estructura del sistemaque debemos esforzarnos por conservar lo ms fielmente posible cuando demos forma alsistema. En concreto los propsitos del diseo son:

Adquirir una comprensin en profundidad de los aspectos relacionados con losrequisitos no funcionales y restricciones relacionadas con los lenguajes deprogramacin.

Crear una entrada apropiada y un punto de partida para actividades deimplementacin subsiguientes capturando los requisitos o subsistemas individuales,interfaces y clases.

Ser capaz de descomponer los trabajos de implementacin en partes ms manejablesque puedan ser llevadas a cabo por diferentes equipos de desarrollo, teniendo encuanta la posible concurrencia

Capturar las interfaces entre los subsistemas antes en el ciclo de vida del software. Ser capaces de visualizar y reflexionar sobre el diseo utilizando una notacin

comn.

Crear una abstraccin sin costuras de la implementacin del sistema, en el sentidode que la implementacin es un refinamiento directo del diseo que rellena loexistente sin cambiar la estructura.


39/52

38

Figura 6.3.1 El diseo.

El diseo es el centro de atencin al final de la fase de elaboracin y el comienzo de lasiteraciones de construccin. Esto contribuye a una arquitectura estable y slida y a crear un

plano del modelo de implementacin. Ms tarde, durante la fase de construccin, cuando laarquitectura es estable y los requisitos estn bien entendidos el centro de atencin sedesplaza a la implementacin.

No obstante, el modelo de diseo est muy cercano al de implementacin, lo que esnatural para guardar y mantener el modelo de diseo a travs del ciclo de vida completo delsoftware. Esto es especialmente cierto en la ingeniera de ida y vuelta, donde el modelo dediseo se puede utilizar para visualizar la implementacin y para soportar las tcnicas deprogramacin grfica.

6.4.Implementacin

En la implementacin empezamos con el desarrollo del diseo e implementamos elsistema en trminos de componentes, es decir, ficheros de cdigo fuentes, scripts,ficherosde cdigo binario, ejecutables y similares.


40/52

39

Afortunadamente, la mayor parte de la arquitectura del sistema es capturada durante eldiseo, siendo el propsito principal de la implementacin el desarrollar la arquitectura y elsistema como un todo. De forma ms especfica, los propsitos de la implementacin son:

Planificar las integraciones de sistema necesarios en cada iteracin. Seguimos paraello un enfoque incremental, lo que da lugar a un sistema que se implementa en unasucesin de pasos pequeos y manejables.

Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama dedespliegue. Esto se basa fundamentalmente en las clases activas encontradasdurante el diseo.

Implementar las clases y subsistemas encontrados durante el diseo. En particular,las clases se implementan como componentes de fichero que contienen cdigofuente.

Probar los componentes individualmente, y a continuacin integrarloscompilndolos y enlazndolos en uno o ms ejecutables, antes de ser enviados paraser integrados y llevar a cabo las comprobaciones del sistema.

La implementacin es el centro durante las iteraciones de construccin, aunque tambinse lleva a cabo trabajo de implementacin durante la fase de elaboracin, para crear la lneabase ejecutable de la arquitectura, y durante la fase de transicin para tratar efectos tardoscomo los encontrados con distribuciones betas del sistema (como se indica en la figura6.4.1 con un pico en la columna de transicin).

Figura 6.4.1 La implementacin.


41/52

40

Ya que el modelo de implementacin denota la implementacin actual del sistema entrminos de componentes y subsistemas de implementacin, es natural mantener el modelode implementacin a lo largo de todo el ciclo de vida del software

6.5.PruebaEn el flujo de trabajo de la prueba verificamos el resultado de la implementacin

probando cada construccin, incluyendo tanto construcciones internas como intermedias,as como las versiones finales del sistema a ser entregadas a terceros. Ms concretamentelos objetivos de la prueba son:

Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas deintegracin y las pruebas de sistema. Las pruebas de integracin son necesarias paracada construccin dentro de la iteracin, mientras que las pruebas de sistema sonnecesarias solo al final de la iteracin.

Disear e implementar las pruebas creando los casos de prueba que especifican quprobar, creando los procedimientos de prueba que especifican como realizar laspruebas y creando, si es posible, componentes de prueba ejecutables paraautomatizar las pruebas.

Realizar las diferentes pruebas y manejar los resultados de cada pruebasistemticamente.

Durante la fase de inicio puede hacerse parte de la planificacin inicial de las pruebascuando se define el mbito del sistema. Sin embargo, las pruebas se llevan a cabo sobretodo cuando una construccin (como un resultado de implementacin) es sometida a

pruebas de integracin y de sistema. Esto quiere decir que la realizacin de prueba se centraen las fases de elaboracin cuando se prueba la lnea base de la arquitectura y deconstruccin, cuando el grueso del sistema est implementando. Durante la fase detransicin el centro se desplaza hacia la construccin de defectos durante los primeros usosy a las pruebas de regresin. Vase la figura 6.5.1

Debido a la naturaleza iterativa del esfuerzo de desarrollo, algunos de los casos deprueba que especifican como probar las primeras construcciones pueden ser utilizadastambin como casos de prueba de regresin que especifican como llevar a cabo las pruebasde regresin sobre las construcciones siguientes. El nmero de pruebas de regresin

necesarias crece por tanto de forma estable a lo largo de las iteraciones, lo que significa quelas ltimas iteraciones requerirn un gran esfuerzo en pruebas de regresin. Es natural, portanto, mantener el modelo de pruebas a lo largo del ciclo de vida del software completo,aunque el modelo de pruebas cambia constantemente debido a:

La eliminacin de caos de prueba obsoletos (y los correspondientes procedimientosde prueba y componentes de prueba).


42/52

41

El refinamiento de algunos casos de prueba en casos de prueba de regresin. La creacin de nuevos casos de uso para cada nueva construccin.

Figura 6.5.1 Las pruebas.


43/52

42

7. ArtefactosUn artefacto es una pieza de informacin tangible que es creada, modificada y usada

por los trabajadores al realizar actividades; representa un rea de responsabilidad, y escandidata a ser tenida en cuenta para el control de la configuracin. Un artefacto puede ser

un modelo, un elemento de un modelo o un documento.

Los artefactos son el resultado parcial o final que es producido y usado por los actoresdurante el proyecto. Son las entradas y salidas de las actividades, realizadas por los actores,los cuales utilizan y van produciendo estos artefactos para tener guas. Un artefacto puedeser un documento, un modelo o un elemento de modelo.

7.1.Conjuntos de artefactosSe tiene un conjunto de artefactos definidos en cada una de las disciplinas y utilizadas

dentro de ellas por lo actores para la realizacin de las mismas, a continuacin se definencada una de estas categoras o grupos de artefactos dentro de las disciplinas del RUP:

Requerimientos Los artefactos de requerimientos del sistema capturan y presentanla informacin usada en definir las capacidades requeridas del sistema.

Anlisis y diseo del sistema Los artefactos para el anlisis y del diseo capturany presenta la informacin relacionada con la solucin a los problemas sepresentaron en los requisitos fijados.

Implementacin Los artefactos para la implementacin capturan y presentan larealizacin de la solucin presentada en el anlisis y diseo del sistema.

Pruebas Los artefactos desarrollados como productos de las actividades de pruebay de la evaluacin son agrupadas por el actor responsable, con el cual se lleva unconjunto de documentos de informacin sobre las pruebas realizadas y lasmetodologas de pruebas aplicadas.

7.2.Ar tefactos de requerimientosLos artefactos fundamentales que se utilizan en la captura de requisitos son el modelo

de caso de uso, que incluye los casos de uso y los actores. Tambin puede haber otros tipos

de artefactos, como prototipos de interfaz de usuario. Artefacto: modelo de casos de uso. El modelo de casos de uso permite que los

desarrolladores de software y los clientes lleguen a un acuerdo sobre los requisitos,es decir, sobre las condiciones y posibilidades que debe cumplir el sistema. Elmodelo de casos de uso sirve como acuerdo entre clientes y desarrolladores, yproporciona la entrada fundamental para el anlisis, el diseo y las pruebas.


44/52

43

Un modelo de casos de uso es un modelo del sistema que contiene actores casos deuso y sus relaciones.

Artefacto: descripcin de la arquitectura (vista del modelo de casos de uso). Ladescripcin de la arquitectura del modelo de casos de uso, que representa los casosde uso significativos para la arquitectura.

La vista de la arquitectura del modelo de casos de uso debera incluir los casos deuso que describan alguna funcionalidad importante y crtica, o que impliquen algnrequisito importante que deba desarrollarse pronto dentro del siclo de vida delsoftware.

Artefacto: glosario. Podemos utilizar un glosario para definir trminos comunesimportantes que los analistas (y otros desarrolladores) utilizan al describir elsistema. Un glosario es muy til para alcanzar un consenso entre los desarrolladoresrelativo a la definicin de los diversos conceptos y nociones, y para reducir engeneral el riesgo de confusiones.

Habitualmente podemos obtener un glosario a partir de un modelo de negocio o unmodelo del dominio.

Artefacto: prototipo de interfaz de usuario. Los prototipos de interfaz de usuarionos ayudan a comprender y especificar las interacciones entre actores humanos y elsistema durante la captura de requisitos. No solo nos ayuda a desarrollar unainterfaz grfica mejor, sino tambin a comprender mejor los casos de uso. A la horade especificar la interfaz de usuario tambin pueden utilizarse otros artefactos, comolos modelos de interfaz grfica y los esquemas de pantallas.

7.3.Artefactos de Anlisis Artefacto: modelo de anlisis. El modelo de anlisis se representa mediante un

sistema de anlisis que denota el paquete de ms alto nivel del modelo. Lautilizacin de otros paquetes de anlisis es por tanto una forma de organizar elmodelo de anlisis en partes ms manejables que representan abstracciones desubsistemas y posiblemente capas completas del diseo del sistema. Dentro delmodelo de anlisis, los casos de uso se describen mediante clases de anlisis y susobjetos. esto se representa mediante colaboraciones dentro del modelo de anlisisque llamamos realizaciones de casos de uso-anlisis.

Artefacto: realizacin de casos de uso-anlisis. Una realizacin de caso de uso-anlisis es una colaboracin dentro del modelo de anlisis que describe cmo selleva a cabo y se ejecuta un caso de uso determinado en trminos de las clases delanlisis y sus objetos del anlisis e interaccin. una realizacin de caso de usoproporciona por tanto una traza directa hacia un caso de uso concreto del modelo decasos de uso.


45/52

44

Artefacto: paquete del anlisis. Los paquetes del anlisis proporcionan un mediopara organizar los artefactos del modelo de anlisis en piezas manejables. Unpaquete de anlisis puede constar de clases de anlisis, de realizaciones de caso deuso, y de otros paquetes del anlisis (recursivamente)

Artefacto: descripcin de la arquitectura (vista del modelo de anlisis): ladescripcin de la arquitectura contiene una vista de la arquitectura del modelo deanlisis que muestra artefactos significativos para la arquitectura. La descripcin dela arquitectura contiene una vista arquitectnica del modelo de anlisis.

7.4.Artefactos de Diseo: Artefacto: modelo de diseo. El modelo de diseo es un modelo de objetos que

describe la realizacin fsica de los casos de uso centrndose en cmo los requisitosfuncionales y no funcionales, junto con otras restricciones relacionadas con el

entorno de implementacin, tienen impacto en el sistema a considerar. Adems, elmodelo de diseo sirve de abstraccin en la implementacin del sistema y es, de esemodo, utilizada como una entrada fundamental de las actividades deimplementacin.

Artefacto: clase del diseo.Una clase de diseo es una abstraccin sin costuras deuna clase o construccin similar en la implementacin del sistema.

Artefacto: realizacin de caso de uso-diseo. Una realizacin de caso de uso diseo es una colaboracin en el modelo de diseo que describe como se realiza uncaso de uso especfico, y cmo se ejecuta en trminos de clases de diseo y sus

objetos. Una realizacin de caso de uso-diseo proporciona una traza directa a unarealizacin de caso de uso-anlisis en el modelo de anlisis. Ntese que unarealizacin de caso de uso-diseo de esta forma tambin puede tener una traza a uncaso de uso en el modelo de casos de uso a travs de una realizacin de caso de uso-anlisis.

Artefacto: subsistema de diseo. Los subsistemas de diseo son una forma deorganizar los artefactos del modelo de diseo en piezas ms manejables. Unsubsistema puede constar de clases del diseo, realizaciones de caso de uso,interfaces, y otros subsistemas (recursivamente). Por otro lado, un subsistema puedeproporcionar interfaces que representan la funcionalidad que exportan en trminos

de operaciones. Artefacto: interfaz. Las interfaces se utilizan para especificar las operaciones que

proporcionan las clases del diseo.Las interfaces constituyen una forma de separar la especificacin de lafuncionalidad en trminos de operaciones de sus implementaciones en trminos demtodos. Esta distincin hace independiente de la implementacin de la interfaz acualquier cliente que dependa de ella. Podemos sustituir una implementacin


46/52

45

completa de una interfaz como puede ser una clase o un subsistema del diseo, porotra implementacin sin tener que cambiar los clientes.

Artefacto: descripcin de la arquitectura (vista del modelo de diseo). Ladescripcin de la arquitectura del modelo de diseo, que muestra sus artefactosrelevantes para la arquitectura.

Artefacto: modelo de despliegue. El modelo de despliegue es un modelo deobjetos que describe la distribucin fsica del sistema en trminos de cmo sedistribuye la funcionalidad entre los nodos de cmputo. El modelo de despliegue seutiliza como entrada fundamental en las actividades de diseo e implementacindebido a que la distribucin del sistema tiene una influencia principal en su diseo.

Artefacto: descripcin de la arquitectura (vista del modelo de despliegue). Ladescripcin de la arquitectura contiene una vista de la arquitectura del modelo dedespliegue, que muestra sus artefactos relevantes para la arquitectura.Debido a su importancia, debera mostrarse todos los aspectos del modelo de

despliegue en la vista arquitectnica, incluyendo la correspondencia de loscomponentes sobre los nodos tal como se identific durante la implementacin.

7.5.Ar tefactos de implementacin Artefacto: modelo de implementacin. El modelo de implementacin describe

cmo los elementos del modelo de diseo, como las clases, se implementan entrminos de componentes, como ficheros de cdigo fuente, ejecutables, etc. Elmodelo de implementacin describe tambin como se organizan los componentes deacuerdo con los mecanismos de estructuracin y modularizacin disponibles en el

entorno de implementacin y en el lenguaje de programacin utilizados, y cmodependen los componentes unos de otros.

Artefacto: componente. Un componente es el empaquetamiento fsico de loselementos de un modelo, como son las clases en el modelo de diseo.

Artefacto: subsistema de implementacin. Los subsistemas de implementacinproporciona una forma de organizar los artefactos del modelo de implementacin entrozos ms manejables. Un subsistema puede estar formado por componentes,interfaces, y otros subsistemas (recursivamente). Adems, un subsistema puedeimplementar las interfaces que representan la funcionalidad que exportan en formade operaciones.

Artefacto: interfaz. Las interfaces pueden ser utilizadas en el modelo deimplementacin para especificar las operaciones implementadas por componentes ysubsistemas de implementacin. Adems, como se mencion anteriormente, loscomponentes y los subsistemas de implementacin pueden tener dependencias deuso sobre interfaces.


47/52

46

Artefacto: descripcin de arquitectura (vista del modelo de implementacin).La descripcin de arquitectura contiene una visin de la arquitectura del modelo deimplementacin, el cual representa sus artefactos significativos arquitectnicamente.

Artefacto: plan de integracin de construcciones. Es importante construir elsoftware incrementalmente en pasos manejables, de forma que cada paso d lugar apequeos problemas de integracin o prueba. El resultado de cada paso es llamadoconstruccin, que es una versin ejecutable del sistema, usualmente una parte

especfica del sistema. Cada construccin es entonces sometida a pruebas deintegracin antes de que se cree ninguna otra construccin. Para prepararse ante elfallo de una construccin se lleva un control de versiones de forma que se puedavolver atrs a una construccin anterior.

7.6.Ar tefactos de prueba Artefacto: modelo de pruebas. El modelo de pruebas principalmente cmo se

prueban los componentes ejecutables (como las construcciones) en el modelo deimplementacin con pruebas de integracin y de sistema. El modelo de pruebaspuede describir cmo han de ser probados aspectos especficos del sistema, porejemplo, si la interfaz de usuario es utilizable y consistente o si el manual de usuariodel sistema cumple con su cometido. El modelo de pruebas es una coleccin decasos de prueba, procedimientos de prueba y componentes de prueba.

Artefacto: caso de prueba.Un caso de prueba especifica una forma de probar elsistema, incluyendo la entrada o resultado con que se ha de probar y las condicionesbajo las que ha de probarse.

Artefacto: procedimiento de prueba. Un procedimiento de prueba especificacmo realizar uno o varios casos de prueba o partes de stos. Por ejemplo, unprocedimiento de prueba puede ser una instruccin para un individuo sobre cmo hade realizar un caso de prueba manualmente, o puede ser una especificacin de cmointeraccionar manualmente con una herramienta de automatizacin de pruebas paracrear componentes ejecutables de prueba.

A

Rup Completo

Documents

Transcript of Rup Completo