Il processo di sviluppo

Lo sviluppo di sistemi OO
UML e (R)UP
(an overview)
http://www.rational.com
http://www.omg.org
1
Riassumento …
„
UML
• E’ un insieme di notazioni diagrammatiche che, utilizzate
congiuntamente, consentono di descrivere/modellare aspetti
diversi di un sistema con un approccio O-O
„
„
„
Struttura statica
Comportamento dinamico
Interazioni fra i diversi componenti del sistema
• Ricopre l’intero ciclo di vita dello sviluppo del software
• E’ uno standard aperto
• Standard OMG per la modellizzazione di sistemi Object-Oriented
sin dal 1997
• Unifica notazioni e metodologie preesistenti
„
„
„
G. Booch
J. Rumbaugh (OMT)
I. Jacobson
• E’ supportato da più strumenti
• Molti partner industriali … Digital, HP, IBM, Microsoft, Oracle,
Rational …
2
1
è un linguaggio di progettazione, non un linguaggio di programmazione (come
Java, VisualBasic, C++, …)
definisce una notazione standard fornadata su un metamodello
serve a progettare un nuovo sistema, o a apportare modifiche alla
progettazione di un sistema esistente, senza perdersi nei dettagli dei linguaggi
di programmazione durante la fase progettuale
è universale, nel senso che può rappresentare sistemi molto diversi senza
differenze legate alla tecnologia: dai sistemi web a quelli più tradizionali, dalle
vecchie applicazioni Cobol a quelle object oriented
3
UML è un linguaggio, non un metodo/processo
UML non suggerisce, né tantomeno prescrive una sequenza di utilizzo
dei diversi diagrammi, lascia anzi molte strade aperte, tra le quali i
progettisti sono liberi di scegliere
4
2
UP
„
Una metodologia per UML
• descrive cosa fare, come, quando e
perché
• comprende un certo numero di attività
da portare a termine in un certo ordine
• aiuta nella produzione di
documentazione di progetto esauriente
5
RUP
„
„
„
„
E’ la versione commerciale, prodotta da
Rational Software, di Unified Process, il
processo definito da Booch, Rumbaugh,
Jacobson (gli autori di UML)
E’ un framework di processo, da adattare
alle diverse tipologie di progetto
E’ utilizzato in contesti di business
estremamente competitivi, e in ambiti
applicativi eterogenei
Risponde agli obiettivi primari di time to
market, controllo del rischio e visibilità
degli stati di avanzamento
6
3
Caratteristiche primarie
„
Guidato dai casi d’uso. Essi costituiscono la base per:
• la definizione e negoziazione dei requisiti, e la loro validazione
da parte del committente
• la progettazione dell’architettura e dei componenti
• la definizione dei test di accettazione
• la pianificazione dei rilasci (in un’ottica incrementale) e quindi
del progetto
„
Centrato sull’architettura
• La definizione dell’architettura applicativa e tecnologica
costituisce il fondamento tecnico dell’applicazione e del
progetto
• Il consolidamento dell’architettura avviene solo quando si è
certi (se necessario, tramite sperimentazioni) della sua
fattibilità tecnica.
• Fino a quando l’architettura non è consolidata, non esistono
elementi sufficienti per determinare (con precisione sufficiente
alla definizione di un contratto) tempi, costi e rischi
dell’intervento progettuale
7
Caratteristiche primarie
„
Iterativo
• il progetto si articola in una serie di iterazioni (sequenze
di attività), che hanno lo scopo di ridurre
progressivamente i rischi di fallimento, a partire da
quelli principali (es. incomprensioni sui requisiti,
incertezze sull’architettura)
• in ogni iterazione si ripetono, in misura e percentuali
diverse, le medesime tipologie di attività (es. analisi dei
requisiti, design, implementazione, test)
„
Incrementale
• la realizzazione (ed eventualmente il rilascio)
dell’applicazione avviene in modo progressivo
• la pianificazione è guidata dai casi d’uso e dalle priorità
architetturali (es. precedenza ai componenti
infrastrutturali)
8
4
Caratteristiche primarie
„
Basato sui modelli
• RUP enfatizza lo sviluppo e il mantenimento di modelli
piuttosto che la produzione di montagne di documentazione
cartacea
„
Orientato agli oggetti
„
Basato sui componenti
• I modelli utilizzato sono UML
• I componenti sono moduli non banali, sottosistemi che
realizzano una funzione e possono essere assemblati in una
architettura ben definita
„
Orientato al controllo qualità e alla gestione dei rischi
„
Configurabile
• Sono parte inscindibile di ciascuna fase
• Nessun processo è adatto per tutte le situazioni; la
configurabilità si raggiunge attraverso la selezione delle viste e
dei diagrammi utili e attraverso la gestione delle iterazioni
9
Gli ingredienti di RUP
„
„
„
Un ruolo definisce il comportamento
e le responsabilità di un individuo o
un gruppo
Il comportamento è espresso in
termini di attività
Le responsabilità sono espresso in
termini di elaborati da produrre e
gestire
Deliverable
Ruolo
Attività
10
5
Tipi di deliverable
„
„
„
„
Set di gestione
•
•
•
•
•
•
elaborati di pianificazione (software development plan, studio economico, …)
elaborati operazionali (stato di avanzamento, descrizione versione, …)
Set dei requisiti
documento di visione
modello dei casi d’uso
modello di business
•
•
•
modello di design
modello architetturale
modello di test
•
•
codice sorgente ed eseguibili
file di dati
•
•
•
script di installazione
documentazione utente
materiale formativo
Set di progettazione
Set di implementazione
Set di rilascio agli utenti
11
Le due dimensioni di RUP
„
„
Lungo il tempo si sviluppano gli aspetti del
ciclo di vita. Vengono rapresentati gli
aspetti dinamici del processo: come
comincia e come si suddivide in cicli, fasi,
iterazioni e milestone
Lungo i componenti di processo, le attività
sono raggruppate logicamente. Si
rappresentano gli aspetti statici del
processo: come è descritto in termini di
componenti, attività, workflow, elaborati,
ruoli
12
6
Il modello
13
Le fasi
„
„
„
„
Inception: definisce gli obiettivi del progetto, ne
investiga la fattibilità, ne stima i costi, il
potenziale di mercato e i rischi, analizza i
prodotti concorrenti
Elaboration: pianifica il progetto e ne definisce
le caratteristiche funzionali, strutturali e
architetturali
Construction: sviluppa il prodotto attraverso
una serie di iterazioni, effettua il testing, prepara
la documentazione
Transition: consegna il sistema agli utenti finali
(include marketing, installazione, configurazione,
formazione, supporto, mantenimento)
14
7
Output primari delle fasi
„
Inception
• Documenti fattibilità
„
Elaboration
• SRS (Specifica dei Requisiti Software)
• Architettura consolidata e verificata
„
Construction
• Versione sistema in pre-produzione (Beta)
„
Transition
• Versione sistema in produzione
15
Tipologie di attività (workflow)
„
„
„
„
„
„
„
„
„
Business modeling: descrive la struttura e la dinamica
dell’organizzazione
Requisiti: descrive i requisiti e il loro cambiamento
Analisi e progetto: descrive le viste architetturali
Implementazione: considera lo sviluppo del sw e
l’integrazione
Test: descrive i casi prova e le metriche
Deployment: descrive la configurazione del sistema
Gestione configurazione: mantiene le versioni del sistema
Gestione progetto: descrive le strategie per gestire un
processo iterativo
Ambiente: descrive le infrastrutture di sviluppo
16
8
Fasi e workflow
17
Interazioni e workflow
18
9
Fasi, iterazioni e workflow
„
„
„
Le fasi sono sequenziali, e corrispondono a
milestone significativi per Committenti,
Utenti, Management
Le tipologie di attività non sono
rigidamente sequenziali, e vengono svolte
dal progetto in ogni iterazione
Il numero delle iterazioni dipende dalle
scelte del Project Manager e dai rischi del
progetto
19
Rischi
„
Rischi legati ai requisiti: il sistema può non implementare le
funzionalità richieste
• Creare al più presto una documentazione “scheletro” che
modelli i requisiti principali con diagrammi dei casi d’uso, delle
classi, delle attività
Rischi legati alle tecnologie: le metodologie e gli strumenti
da usare possono non essere sufficienti a produrre le
funzionalità
richieste
„
• Prototipare, sperimentando diversi strumenti
„
Rischi legati alle capacità: può essere difficile formare il
team di progetto con le conoscenze necessarie
• Pianificare un addestramento accurato
„
„
Rischi politici: le forze politiche e organizzative in gioco
nell’azienda committente possono ostacolare il progetto
??????
20
10
Personalizzazioni
„
„
RUP deve essere adattato, senza stravolgimenti,
alle esigenze e alle caratteristiche
dell’organizzazione
L’adattamento deve tenere conto di vari fattori:
• Tipologia di sistemi da realizzare (automazione,
gestionale, B2C)
• Cultura dell’organizzazione in cui viene calato
• Struttura organizzativa, ruoli, responsabilità
• Modalità di rapporto con i committenti
• Differenze tra progetti di nuovo sviluppo ed evoluzioni
„
L’adattamento deve avvenire in modo
progressivo, e costituisce a sua volta un
progetto, iterativo e incrementale
21
11