Rational Unified Process: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Recupero di 0 fonte/i e segnalazione di 1 link interrotto/i.) #IABot (v2.0.9.5 |
|||
| (46 versioni intermedie di 36 utenti non mostrate) | |||
Riga 1:
Il '''Rational Unified Process''' (RUP) (che è una estensione dello '''Unified Process''') è un [[modello di
==Contesto==▼
▲== 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
== Concetti fondamentali ==
Nel RUP, il [[ciclo di vita del software
*''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'')
*''Fase di costruzione'' (c''onstruction phase'')
*''Fase di transizione'' (t''ransition phase'')
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
=== ''Fase iniziale'' ===
▲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 ''[[deadline]]'' precise.
=== ''Fase di elaborazione'' ===
▲L'''Inception Phase'' si può considerare come una particolare elaborazione e precisazione del concetto generale di [[analisi di fattibilità]]. Lo scopo principale è quello di delinare 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|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]]'', detta "Lifecycle Objective Milestone", esso dovrà essere abbandonato o ridefinito.
La fase di elaborazione definisce la struttura complessiva del sistema. Questa fase comprende l'[[Analisi del dominio|analisi di dominio]] e
▲La fase di elaborazione definisce la struttura complessiva del sistema. Questa fase comprende l'[[analisi di dominio]] e un 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
*
* dev'essere completata una
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.
=== ''
In questa fase viene portato a termine il grosso degli sviluppi. Viene prodotta la prima [[release (informatica)|release]] del sistema. La milestone di questa fase si chiama "Initial Operational Capability" e rappresenta la prima disponibilità delle funzionalità del sistema in termini di implementazione.
=== ''
Nella fase di transizione, il sistema passa dall'ambiente dello sviluppo a quello del [[cliente finale]]. Vengono condotte le attività di [[training]] degli utenti e il [[beta testing]] del sistema a scopo di verifica e validazione. Si deve in particolare verificare che il prodotto sia conforme alle aspettative descritte nella fase di ''Inception''. Se questo non è vero si procede a ripetere l'intero ciclo; altrimenti, si raggiunge la ''milestone'' detta "Product Release" e lo sviluppo termina.
=== 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 ==
Il metamodello applicato dal RUP per descrivere e controllare un processo utilizza quattro concetti cosiddetti "statici", ovvero che sono definiti nello stesso modo per tutti i processi:
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 163 ⟶ 161:
-->
== Voci correlate ==
* [[Ingegneria del software]]
* [[
* [[Componente software]]
* [[Ciclo di vita del software]]
Line 176 ⟶ 173:
* [[Metodologia agile]]
* [[Open Unified Process]]
* [[Project management]]
== 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-106.ibm.com/developerworks/rational/library/content/RationalEdge/jan01/WhatIstheRationalUnifiedProcessJan01.pdf Descrizione del RUP] presso "The Rational Edge" ([[pdf]])
* [http://sce.uhcl.edu/helm/rationalunifiedprocess/ Rational Unified Process]
▲* [http://www.methodsandtools.com/archive/archive.php?id=32 "Understanding the Unified Process"]
{{Controllo di autorità}}
[[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:UML]]
[[Categoria:Metodi formali]]
▲
| |||