Rational Unified Process: differenze tra le versioni

Versione delle 10:44, 5 apr 2015

Versione attuale delle 18:08, 29 giu 2024

(12 versioni intermedie di 9 utenti non mostrate)

Riga 1:

Il '''Rational Unified Process''' (RUP) (che è una estensione dello '''Unified Process''') è un [[modello di [[processosviluppo softwaredel iterativosoftware]] di tipo iterativo, sviluppato da [[Rational Software]] (oggi parte di [[IBM]]). Il RUP non definisce un singolo, specifico processo, bensì un [[framework]] adattabile che può dar luogo a diversi processi in diversi contesti (per esempio in diverse organizzazioni o nel contesto di progetti con diverse caratteristiche). È pensato soprattutto per progetti di grandi dimensioni. RUP è rilasciatoprodotto in formato di guida ipertestuale, ed è incluso nel prodotto IBM Rational Method Composer (RMC), che permette anche la personalizzazione del processo.

== Contesto ==

I creatori del RUP partirono dalla [[diagnosi]] di un campione di progetti software falliti, allo scopo di identificare cause tipiche o generali di fallimento. Quindi confrontarono questa informazione con la struttura dei processi software descritti in letteratura e applicati nella pratica, cercando di identificare le soluzioni proposte precedentemente. L'elenco dei motivi di fallimento identificati comprende per esempio:

Line 16 ⟶ 15:

* Insufficiente [[automazione]]

Il RUP si può descrivere come una collezione di ''[[bestBuona practicepratica|buone pratiche]]'' mirate a evitare questi e altri problemi, e come un ambiente di gestione dei processi che facilita l'applicazione di tali pratiche. Il processo fu progettato utilizzando strumenti tipici della [[progettazione del software]]; in particolare, esso fu descritto in termini di un [[metamodello]] ''[[Programmazione orientata agli oggetti|object-oriented]]'', espresso in [[UML]].

== Concetti fondamentali ==

Nel RUP, il [[ciclo di vita del software|ciclo di vita]] di un processo software viene suddiviso in ''cicli di sviluppo'', a loro volta scomposti in ''fasi''. Le fasi previste sono:

*''Fase iniziale'' (i''nception phase'')

Nel RUP, il [[ciclo di vita del software|ciclo di vita]] di un processo software viene suddiviso in ''cicli di sviluppo'', a loro volta scomposti in ''fasi''. Le fasi previste sono:

*''Fase di elaborazione'' (e''laboration phase'')

* ''InceptionFase di Phasecostruzione'' (c''faseonstruction inizialephase'')

* ''ElaborationFase Phasedi transizione'' (t''fase diransition elaborazionephase'')

* ''Construction Phase'' (''fase di costruzione'')

* ''Transition Phase'' (''fase di transizione'')

Ogni fase ha un certo insieme di obiettivi e si conclude con la realizzazione di un ''deliverable'' (prodotto) di qualche genere. Le fasi sono ulteriormente scomposte in ''iterazioni'', che sono associate a periodi temporali e hanno scadenze precise.

Line 31 ⟶ 29:

=== ''Fase iniziale'' ===

L'''InceptionLa Phase''fase iniziale si può considerare come una particolare elaborazione e precisazione del concetto generale di [[analisi di fattibilità]]. Lo scopo principale è quello di delineare nel modo più accurato possibile il ''business case'', ovvero comprendere il tipo di mercato al quale il progetto afferisce e identificare gli elementi importanti affinché esso conduca a un successo commerciale. Fra gli strumenti utilizzati ci sono un modello dei [[caso d'uso (informatica)|casi d'uso]], la pianificazione iniziale del progetto, la valutazione dei rischi, una definizione grossolana dei requisiti e così via. Se il progetto non supera questa ''[[Milestone (project management)|milestone]]'', detta "Lifecycle Objective Milestone", esso dovrà essere abbandonato o ridefinito.

=== ''Fase di elaborazione'' ===

La fase di elaborazione definisce la struttura complessiva del sistema. Questa fase comprende l'[[Analisi del dominio|analisi di dominio]] e una prima fase di [[progettazione (ingegneria del software)|progettazione]] dell'architettura. Questa fase deve concludersi con il superamento di una ''milestone'' detta "Lifecycle Architecture Milestone". A questo scopo devono essere soddisfatti i seguenti criteri:

* deve essere stato sviluppato un modello dei casi d'uso completo all'80%

* dev'essere fornita la descrizione dell'architettura del sistema

* dev'essere stata sviluppata un'"architettura eseguibile" che dimostri il completamento degli use case significativi

* '''dev'essere eseguita una revisione del business case e dei rischi

* dev'essere completata una''' pianificazione del progetto complessivo

Se il progetto non passa questa milestone, potrebbe ancora essere abbandonato, oppure dovrà essere rivisitato. Al termine di questa fase si transita infatti in una situazione di rischio più elevato, in cui le modifiche all'impostazione del progetto saranno più difficili e dannose.

Line 55 ⟶ 53:

=== Iterazioni ===

Tipicamente, un progetto gestito usando il RUP viene suddiviso in iterazioni. Questa scomposizione presenta numerosi vantaggi (in particolare rispetto alla valutazione dell'avanzamento del progetto e alla gestione dei fattori di rischio) ma implica un [[overhead]] specifico. Il RUP definisce una "Project Management Discipline" (disciplina di gestione dei progetti) a cui il [[project manager|responsabile di progetto]] può affidarsi per amministrare le iterazioni.

== Aspetti statici del RUP ==

Line 164 ⟶ 162:

== Voci correlate ==

* [[Ingegneria del software]]

* [[ProcessoSviluppo software]]

* [[Componente software]]

* [[Ciclo di vita del software]]

Line 179 ⟶ 176:

== Collegamenti esterni ==

* {{cita web | 1 = http://www.rational.com/ | 2 = Rational Software | accesso = 29 marzo 2006 | urlarchivio = https://web.archive.org/web/19971210075623/http://www.rational.com/ | dataarchivio = 10 dicembre 1997 | urlmorto = sì }}

* [http://www.rational.com/ Rational Software]

* [httphttps://www-106.ibm.com/developerworks/rational/library/content/RationalEdge03July/jan011000/WhatIstheRationalUnifiedProcessJan011251/1251_bestpractices_TP026B.pdf DescrizioneRational delUnified RUPProcess] presso "The Rational EdgeIBM" {{pdf}}

* [{{cita web|url=http://www.methodsandtools.com/archive/archive.phpisp?id=32 |titolo="Understanding the Unified Process"]|urlmorto=sì}}

* [http://www.x-tier.com/public/RUPUPIn10EasySteps.doc RUP/UP in 10 passi] - Sito X-tier SAE {{doc}}

* [http://sce.uhcl.edu/helm/rationalunifiedprocess/ Rational Unified Process]

* [http://www-128.ibm.com/developerworks/rational/library/oct05/kroll/ Sviluppo business-driven]

* [http://www.methodsandtools.com/archive/archive.php?id=32 "Understanding the Unified Process"]

{{Controllo di autorità}}

[[Categoria:Metodi di sviluppo software]]

[[Categoria:UML]]

[[Categoria:UML]] <!-- Non ridondante rispetto alla precedente, RUP ha a che vedere con UML solo marginalmente, deve essere "trovabile" anche direttamente da "ingegneria del software" -->

[[Categoria:Metodi formali]]

[[Categoria:UML]] <!-- Non ridondante rispetto alla precedente, RUP ha a che vedere con UML solo marginalmente, deve essere "trovabile" anche direttamente da "ingegneria del software" -->