qual è il significato di iterativo in RUP?

La prima cosa da tenere a mente è che Rational Unified Process è un framework di processo. Fornisce alcuni vincoli per consentire alle organizzazioni di costruire il proprio processo, con la personalizzazione per consentire alle organizzazioni di scegliere ciò che è appropriato per le loro esigenze.

Penso che l'immagine su l'articolo di Wikipedia sia una buona rappresentazione della struttura del processo.

Le tue quattro fasi: Inception, Elaboration, Construction, and Transition sono sequenziali. In un dato progetto, sarai in ognuno una volta. Tuttavia, in ogni fase e all'interno di ogni fase di una fase, trascorrerai diverse quantità di tempo nelle discipline 9 (6 di ingegneria e 3 di supporto).

Puoi vedere questo nel diagramma. Sebbene alcuni aspetti non siano mostrati. Ad esempio, il diagramma mostra solo una iterazione di Inception, ma potrebbero essercene molti. Alcune discipline si prestano meglio a Inception rispetto ad altre discipline, ad esempio Project Management, Business Modeling, Requisiti, Ambiente, Gestione della configurazione. La fase Inception ha i criteri per il completamento - concordato sull'ambito, i casi d'uso primari identificati, un processo di sviluppo gestito, linee di base del piano di progetto, ecc. Ogni iterazione potrebbe avere un'enfasi diversa sul lavoro che deve raggiungere i criteri di completamento, ovvero i tipi di e lo sforzo messo nelle discipline varierà all'interno di ogni iterazione.

Lo stesso vale per le fasi di elaborazione, costruzione e transizione. Ognuno può avere una o più iterazioni che mostrano progressi verso gli obiettivi finali di quella fase.

Normalmente un'iterazione è un "set di funzionalità" o modifica. Tieni presente che questo è tutto astratto.

Quindi per prima cosa "iterazione" è creare un pulsante. La tua seconda iterazione è rendere un pulsante blu. La terza iterazione è far pronunciare un pulsante "Ciao".

Il modo in cui svolgi ogni iterazione è dove entrano le tue "discipline". Ricorda che ogni disciplina verrà utilizzata in modo diverso in ogni fase dell '"iterazione".

Quindi no, non dovresti "rimbalzare" nelle tue discipline. "Finisci" fai un pulsante, POI "finisci" (raffina) fai un pulsante blu.

Ad esempio, la fase di "Inception" può essere molto pesante in "business modeling", ma nel momento in cui si esegue la "transizione" restano pochi modelli di business da fare. Ciò non significa che non sia possibile utilizzare "business modeling" nella fase di transizione, significa solo che non ce n'è molto da fare.

Ricorda che le discipline non sono passi ma set di abilità.

Quindi fai un semplice esempio "Disegna una casa".

All'inizio puoi usare la disciplina delle "forme base", ma nella fase di elaborazione, quando decidi di farne una casa rossa, non usi più le forme base.

Ancora una volta, tuttavia, si tratta di costrutti generici e astratti che puoi utilizzare per applicare alla tua attività come ritieni opportuno. Non si suppone che siano regole o ruoli rigidi e spiegazzati che devono essere seguiti (sebbene il tuo libro possa delineare alcuni di essi).

RUP è stato inventato come alternativa all'approccio tradizionale a cascata. Al giorno d'oggi la cascata è considerata rischiosa, poiché puoi scoprire troppo tardi che qualcosa che hai deciso all'inizio non funzionerà correttamente.

Se si guarda oltre la terminologia elaborata, RUP è una serie di mini-cascate. Ad ogni iterazione, fai l'architettura, il design, la codifica e il test. La prima iterazione dovrebbe fornire qualcosa che sia almeno abbastanza buono da dimostrare, anche se mancano alcune funzionalità importanti. Si raccomanda di affrontare tempestivamente anche le funzionalità rischiose, in modo che se ci sono problemi, si hanno più iterazioni per risolverli.

Le iterazioni successive rivisitano l'architettura e il design, aggiungono un nuovo codice per le funzionalità mancanti, quindi eseguono il test fino ad ora.

Mi aspetto che ogni disciplina sia coinvolta in ogni iterazione, sebbene le iterazioni successive tendano naturalmente a coinvolgere più design e codifiche di basso livello e meno requisiti e architetture.

Diversamente dai metodi agili, RUP presuppone che tu abbia una specifica abbastanza matura prima di iniziare, e puoi pianificare quante iterazioni dovresti avere. Ma riconosce che non riuscirai a fare tutto bene la prima volta.