Rational Unified Process: differenze tra le versioni

Versione delle 03:42, 20 feb 2012

Versione attuale delle 18:08, 29 giu 2024

(23 versioni intermedie di 18 utenti non mostrate)

Riga 1:

Il '''Rational Unified Process''' (RUP) (che è una estensione dello '''Unified Process''') è un [[modello di [[processosviluppo del software]] [[processodi softwaretipo iterativo|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 10 ⟶ 9:

* Incapacità di gestire la complessità

* Inconsistenze nei [[requisiti]], nel [[progetto]] o nelle [[implementare|implementazioni]]

* [[Collaudo]] insufficiente

* Valutazione soggettiva dello stato del processo

* Incapacità di affrontare il rischio

* Propagazione non controllata delle modifiche

* Insufficiente [[automazione]]

Il RUP si può descrivere come una collezione di ''[[bestBuona practicepratica|buone pratiche]]s'' 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.

=== ''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 ununa 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 dimostradimostri 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 76 ⟶ 74:

# modellizzazione visuale del software

# verifica della qualità del software

# controllo dei cambiamenti al software

===Sviluppo iterativo===

Line 141 ⟶ 139:

RUP does not cover any non-software aspects of development -- e.g., system engineering, product-line engineering, safety engineering.

If the users of RUP do not understand that RUP is a formal process that requires customization, they may perceive it as a weighty and expensive process. RUP was not intended, not envisioned and not promoted to be used straight "out of the box."

For the process to be implemented successfully, an Organizational Assessment and the production of a Development Case must be accomplished (usually with the help of Rational consulants) before beginning the process. This Development Case identifies the number and type of artifacts a project will produce -- often considerably less than an untailored RUP would require.

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ì }}

* [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://sce.uhcl.edu/helm/rationalunifiedprocess/ Rational Unified Process]

{{Controllo di autorità}}

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

* [http://www-106.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf Descrizione del RUP] presso "The Rational Edge" {{pdf}}

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

* [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"]

[[Categoria:Metodologie di sviluppo]]

[[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:MetodologieMetodi di sviluppo software]]

[[ar:العملية الموحدة لراشيونال IBM]]

[[Categoria:UML]]

[[cs:Rational Unified Process]]

[[daCategoria:UnifiedMetodi Processformali]]

[[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" -->

[[de:Rational Unified Process]]

[[en:IBM Rational Unified Process]]

[[es:Proceso Unificado de Rational]]

[[fa:فرآیند یکپارچه رشنال]]

[[fi:RUP]]

[[fr:Unified Process]]

[[id:RUP]]

[[ja:ラショナル統一プロセス]]

[[ko:래셔널 통합 프로세스]]

[[lt:RUP]]

[[nl:Rational Unified Process]]

[[no:Rational Unified Process]]

[[pl:Rational Unified Process]]

[[pt:IBM Rational Unified Process]]

[[ru:Rational Unified Process]]

[[sk:Rational Unified Process]]

[[sv:Rational Unified Process]]

[[uk:Rational Unified Process]]

[[uz:RUP]]

[[zh:IBM-Rational统一过程]]