Contenuti
„ Il linguaggio di modellazione UML
„ Rational Unified Process.
„ Model Driven Architecture.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Con le slides che seguono l’intento è quello di introdurre gli strumenti e i metodi per la
modellazione a partire dal linguaggio di modellazione Unified Modeling Language, con i suoi
costrutti fondamentali, passando attraverso il Rational Unified Process, inteso come metodologia di
riferimento per lo sviluppo di un progetto software e, per finire, la Model Driven Architecture,
standard OMG che ha come scopo la definizione delle soluzioni in modo indipendente dalla
piattaforma tecnologica su cui verranno poi realizzate.
Linguaggio di modellazione : UML
„ Uno standard de facto che ormai si è affermato è
il linguaggio di modellazione UML (Unified
Modeling Language).
„ Le specifiche di UML sono di proprietà del
consorzio noprofit OMG (Object Management
Group).
„ UML non è un metodo, ma un insieme di
diagrammi e notazioni grafiche e testuali
attraverso le quali è possibile documentare quasi
tutti gli artefatti necessari durante l’Analisi.
Gaetanino PAOLONE
Sistemi informativi aziendali
L’UML, Unified Modeling Language, è un linguaggio per descrivere, specificare e documentare
i prodotti del processo di sviluppo del software. Può essere utilizzato per sistemi di tipo e grandezza
differenti ed è caratterizzato da un alto potere espressivo in accordo con la prospettiva Object
Oriented. UML, infatti consente di rappresentare e di mantenere diverse viste di uno stesso sistema
descrivendo gli oggetti che lo compongono da diversi punti di osservazione, strutturale e
comportamentale e a diversi livelli di astrazione.
Unified Modelling Language
Ivar Jacobson
Grady Booch
Gaetanino PAOLONE
James Rumbaugh
Sistemi informativi aziendali
Unified Modeling Language
• un linguaggio (e notazione) universale, per rappresentare un
qualunque sistema
• uno standard OMG (Object Management Group), dal
nov.1997
• gli autori:
– Grady Booch
– Ivar Jacobson
– Jim Rumbaugh
• i co-proponenti: Microsoft, IBM, Oracle, HP, Platinum,
Sterling, Unysis (e tanti altri)
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Evoluzione dello UML
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Il progetto dello UML, originariamente, fu avviato da Grady Booch e James Rumbaugh, con
l’intento di produrre un nuovo metodo, detto inizialmente “metodo unificato”, che raccogliesse il
meglio dei metodi di Booch e OMT-2, del quale Rumbaugh ne era stato uno dei principali
promotori. Nel 1995 si unì a loro Ivar Jacobson, fautore del metodo denominato OOSE (Object
Oriented Software Engineering): il terzetto si era così costituito.
La prima versione, la famosissima 1.0, fu disponibile nel gennaio 1997. Visto l’enorme successo
riscosso, nell’ambito del mondo reale ed in quello accademico, e considerato il relativo
riconoscimento a livello di standard (UML 1.0 è stato proposto al Object Management Group nel
gennaio 1997), gli stessi ideatori dichiararono ormai conclusa la loro esperienza in questo ambito
tanto da dedicarsi a nuove sfide.
Allo stato attuale lo sviluppo dell’UML è affidato alle varie task force appartenenti all’OMG, le
famose Revision Task Force, dirette da Chris Kobyrn. Obiettivo di tale gruppo è accogliere ed
analizzare suggerimenti provenienti dalle industrie, correggere inevitabili imperfezioni, colmare
eventuali lacune e così via.
L’evoluzione dello UML è mostrata nella slide, attraverso il diagramma dei package, uno degli
strumenti messi a disposizione dal linguaggio. Le linee tratteggiate etichettate con la parola
“refine” rappresentano uno stereotipo della relazione di dipendenza. Molto semplicemente indicano
che un aggiornamento apportato ad un oggetto indipendente (quello a cui puinta la freccia) implica
una revisione e verosimilmente una modifica dell’oggetto dipendente.
Unified Modelling Language: questioni generali
„ Diagramma e specifica:
ƒ i diagrammi sono una “semplificazione” della
realtà, che segue una sintassi precisa;
ƒ ogni diagramma può presentare una vista
(parziale) del sistema.
„ Distinzioni di livello:
ƒ
ƒ
classe e oggetto;
interfaccia.
„ Meccanismi di estensibilità
ƒ
stereotipo: estensione del vocabolario,
estende la semantica di un costrutto.
Gaetanino PAOLONE
Sistemi informativi aziendali
UML: principi ispiratori
„ Modellazione del progetto prima dello sviluppo;
„ La modellazione è essenziale in ogni attività
ingegneristica complessa, in quanto permette di
astrarre e semplificare:
ƒ “we build models so that we can better
understand the system we are developing” [Booch
et al: The UML User Guide];
ƒ “we build models of complex systems because we
cannot comprehend such a system in its entirety”
[Booch et al: The UML User Guide].
Gaetanino PAOLONE
Sistemi informativi aziendali
Il primi principio a cui si ispira UML riguarda la modellazione del progetto svolta prima di
passare allo sviluppo, ovviamente in questo modo la modellazione non è finalizzata a se stessa, ma
ha lo scopo di produrre un software migliore.
In secondo luogo, ci si basa sul fatto che la modellazione è un’attività essenziale per il corretto
svolgimento di qualsiasi attività ingegneristica, in quanto permette di astrarre e di semplificare.
Finalità della modellazione
„ Visualizzazione di un sistema (così com'è o
come lo si vorrebbe);
„ Specifica della struttura e/o del
comportamento di un sistema;
„ Definizione delle linee guida per la
costruzione di un sistema;
„ Documentazione delle decisioni prese;
Gaetanino PAOLONE
Sistemi informativi aziendali
Cos’è UML (e cosa non è)
„ è un linguaggio di progettazione;
„ serve a progettare un nuovo sistema;
„ è universale;
„ è un linguaggio e non un metodo;
„ definisce una notazione standard;
continua…
Cos’è UML (e cosa non è)
continua…
„ non definisce un processo;
„ è utilizzato con metodi diversi;
„ è un linguaggio non proprietario;
„ ha ricevuto il contributo di altri metodologi;
„ l’OMG ne cura l’evoluzione;
Gaetanino PAOLONE
Sistemi informativi aziendali
Definiamo ora cos’è (e cosa non è) UML.
− è un linguaggio di progettazione, e non un linguaggio di programmazione come Java,
VisualBasic, C++,...;
− quindi serve a progettare un nuovo sistema, o a apportare modifiche alla progettazione di un
sistema esistente, senza perdersi nei dettagli dei linguaggi di programmazione;
− è 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 e a componenti;
− è un linguaggio, non un metodo come quelli di Yourdon e De Marco, o di Rumbaugh o
Jacobson;
− definisce una notazione standard, basata su un metamodello integrato degli “oggetti” che
compongono un sistema software;
− non prescrive una sequenza di processo, cioé non dice “prima bisogna fare questa attività,
poi quest’altra”;
− quindi può essere (ed è) utilizzato da persone e gruppi che seguono metodi diversi (è
“indipendente dai metodi”);
− è un linguaggio non proprietario, standard, i suoi autori (Grady Booch, Jim Rumbaugh e
Ivar Jacobson) non hanno il copyright su UML;
− la versione diventata standard OMG (Object Management Group) ha ricevuto i contributi di
molti altri metodologi, e delle più importanti società di software mondiali;
− la sua evoluzione è a carico dell’OMG, e soggetta a procedure ben definite per ogni
cambiamento.
UML: meta-modello e diagrammi
„ UML fa riferimento ad un meta-modello;
„ permette di creare modelli rivolti ai sistemi da
progettare;
„ molti elementi sono rappresentati da un’icona;
„ gli elementi del meta-modello appartengono a
diversi diagrammi;
Gaetanino PAOLONE
Sistemi informativi aziendali
UML è basato su un meta-modello integrato, composto da numerosi elementi collegati tra loro,
secondo regole precise. Grazie a queste regole, è possibile creare modelli particolari per le singole
applicazioni da progettare.
Molti elementi (ad esempio l’elemento “classe”) hanno un’icona che li rappresenta graficamente
e possono comparire in diagrammi di diverso tipo.
Diagrammi UML 1.1
„ Diagrammi “strutturali”:
ƒ diagramma delle classi (class);
ƒ diagramma dei componenti (component);
ƒ diagramma di distribuzione dei componenti
(deployment);
„ Diagrammi “comportamentali”:
ƒ diagramma dei casi d’uso (use case);
ƒ diagramma di sequenza (sequence);
ƒ diagramma di collaborazione (collaboration);
ƒ diagramma di transizione di stato (statechart);
ƒ diagramma delle attività (activity);
Gaetanino PAOLONE
Sistemi informativi aziendali
Diagrammi UML 2.0
„ Diagrammi “strutturali”:
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
diagramma delle classi (class);
diagramma degli oggetti (object);
diagramma dei package;
diagramma dei componenti (component);
diagramma delle strutture composite (composite structure);
diagramma di distribuzione dei componenti (deployment);
„ Diagrammi “comportamentali”:
diagramma dei casi d’uso (use case);
diagramma di stato (statechart);
diagramma delle attività (activity);
diagramma di sequenza (sequence);
diagramma di comunicazione (communication);
diagramma di temporizzazione (timing);
diagramma di sintesi dell’interazione(interaction overview);
Gaetanino PAOLONE
interaction
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Sistemi informativi aziendali
Diagrammi UML 2.0
Diagramma
UML 2.0
Diagramma
strutturale
Diagramma
delle classi
Diagramma
dei componenti
Diagramma
degli oggetti
Diagramma
di dislocazione
Diagramma
use case
Diagramma di struttura Diagramma
composita
dei package
Diagramma di
comunicazione
Gaetanino PAOLONE
Diagramma
comportamentale
Diagramma di
sequenza
Diagramma
State machine
Diagramma di
interazione
Diagramma
di temporizzazione
Diagramma di
attività
Diagramma
interaction overview
Sistemi informativi aziendali
UML nella sua ultima versione 2.0 comprende 13 diagrammi ufficiali che vengono classificati
come mostrato nella slide in funzione dell’aspetto del sistema che si propongono di descrivere:
− diagrammi strutturali, che consentono di modellare la struttura del sistema;
− diagrammi comportamentali, che descrivono il comportamento assunto dal sistema.
La classificazione dei diagrammi non è rigida tant’è che è possibile ritrovare la stessa tipologia
di diagramma per descrivere aspetti differenti del medesimo sistema.
Diagrammi: viste
Vista strutturale
diagramma delle classi
diagrammi degli oggetti
diagramma dei package
diagramma di struttura composito
diagramma dei componenti
diagramma di deployment
Vista dinamica
diagrammi di interazione
- diagramma di sequenza
- diagramma di comunicazione
- diagramma di interaction overview
- diagramma di temporizzazione
diagramma state machine
diagramma protocol state machine
0RVWUDFRPHLOVLVWHPD
Gaetanino PAOLONE
HYROYHQHOWHPSR
Vista comportamentale
diagramma use case
diagramma attività
Sistemi informativi aziendali
Oltre alla vista strutturale e comportamentale, è possibile descrivere anche come il sistema
evolve nel tempo, offrendo una vista dinamica del sistema.
Diagramma dei casi d’uso
Diagramma dei casi d'uso: vendita per corrispondenza
effettua ordine
Venditore
verifica stato avanzamento
Customer
attore: un utilizzatore del
sistema (essere umano,
altro sistema, …)
Gaetanino PAOLONE
caso d’uso: una
particolare modalità
di utilizzo del sistema
Sistemi informativi aziendali
Nella slide è riportato un esempio elementare di diagramma dei casi d’uso.
E’ facile identificare due costrutti fondamentali in UML: il costrutto attore, che rappresenta un
utilizzatore del sistema (sia esso un essere umano o un altro sistema) e il costrutto caso d’uso, a
descrivere una particolare modalità di utilizzo del sistema.
Le linee che uniscono questi due costrutti indicano che l’attore interessato interagisce col sistema
attuando la modalità di utilizzo descritta dal caso d’uso.
Casi d’uso : a cosa servono
„ rappresentano le modalità di utilizzo del sistema da
parte di uno o più utilizzatori (attori);
„ descrivono l’interazione tra attori e sistema, non la
“logica interna” della funzione;
„ sono espressi in forma testuale, comprensibile anche
per i non “addetti ai lavori” ;
„ possono essere definiti a livelli diversi (sistema o parti
del sistema);
„ ragionare sui casi d’uso aiuta a scoprire i requisiti;
Gaetanino PAOLONE
Sistemi informativi aziendali
Ruolo dei casi d’uso
Acquirente
Venditore
requisiti
caso d’uso:
effettua ordine
unità di rilascio
modelli di analisi e disegno
Ordine
DataArrivo
Numero
Prezzo
verifica( )
evadi( )
Cliente
nome
indirizzo
0..*
Gaetanino PAOLONE
casi
di test
1
StabilisciCredito( )
Sistemi informativi aziendali
Una volta tradotti i requisiti in casi d’uso, questi sono il collegamento con il modello fisico delle
classi che dall’analisi arriva alla progettazione, con i casi di test e con le unità di rilascio.
Livello di utilizzo degli use case
„ Caso d’uso di business: descrive l’interazione
con il sistema (in attesa di una risposta o di un
evento).
„ Caso d’uso di sistema: implica l’interazione
con il software.
Gaetanino PAOLONE
Sistemi informativi aziendali
Il costrutto caso d’uso può essere utilizzato a livello di business e a livello di sistema. In
ciascuno di questi due casi sarà assegnato uno stereotipo diverso in modo da poter distinguere
quando il costrutto descrive l’interazione con il sistema (in attesa di una risposta o di un evento) o
l’interazione con il software.
Relazioni fra Attori e Use Case
relazione di
associazione
„ Un attore può essere in relazione con:
„
uno use case
use case 1
(relazione di associazione)
Attore 1
„
un altro attore (relazione di generalizzazione)
„
L’attore specializzato eredità le associazioni dell’attore base e può interagire con
gli use case associati a quest’ultimo.
attore
base
use case 1
Attore 1
relazione di
specializzazione
use case 2
attore
specializzato
Attore 2
Gaetanino PAOLONE
Sistemi informativi aziendali
Gli attori possono essere in relazione con:
− un caso d’uso;
− un altro attore.
Nel primo caso la relazione è di associazione e sta ad indicare che l’attore interagisce col sistema
attuando la modalità di utilizzo descritta dal caso d’uso.
La relazione che lega un attore ad un altro attore è invece una generalizzazione secondo la quale
l’attore specializzato eredita le associazioni dell’attore base e può interagire con i casi d’uso
associati a quest’ultimo.
Esempio di Generalizzazione fra Attori
diagramma use case
senza relazione fra gli attori
Crea conto
corrente
Cassiere
Modifica conto
corrente
Cancellazione
conto corrente
diagramma use case
con la relazione fra gli attori
Funzionario
Crea conto
corrente
Operatore
Modifica conto
corrente
Cancellazione
conto corrente
Cassiere
Funzionario
Le relazioni fra gli attori aumentano la leggibilità dei diagrammi e forniscono un modello logico
più articolato. In questo esempio viene introdotto il concetto di attore Operatore che può creare un
conto o modificare un conto. Entrambi gli attori Cassiere e Funzionario specializzano Operatore (e
quindi ereditano la possibilità di creare o modificare un conto), il primo non aggiunge nessuna
funzionalità il secondo ha in più la possibilità di chiudere un conto.
Diagramma dei casi d’uso di un Bancomat
Bancomat
Lista movimenti
Preleva
Utente
Stampa saldo
Attiva bancomat
Disattiva bancomat
Operatore
Gaetanino PAOLONE
Leggi registrazioni
Consorzio
Banche
Sistemi informativi aziendali
Questo esempio mostra come un semplice diagramma contenga tutte le informazioni
fondamentali del sistema bancomat. Mette in luce quali sono le attività che possono essere eseguite
e soprattutto chi ha la capacità di svolgerle.
Casi d’uso e scenari
„ Uno scenario definisce un comportamento
elementare all’interno del caso d’uso ovvero
rappresenta un percorso del caso d’uso;
„ per ogni caso d’uso si possono avere n scenari;
Gaetanino PAOLONE
Sistemi informativi aziendali
Le Relazioni fra Use Case
„ Sistemi di grandi dimensioni o articolati
forniscono responsabilità che potrebbero:
ƒ condividere comportamenti comuni;
ƒ essere estese da altre responsabilità.
„ In queste situazioni l’uso di relazioni tra gli Use
Case può comportare un enorme risparmio di
tempo per la modellazione fattorizzando i
comportamenti comuni oppure riusando degli
use case esistenti.
Gaetanino PAOLONE
Sistemi informativi aziendali
Le Relazioni fra Use Case
„ Le relazioni fra Use Case sono:
„
inclusione
incorpora il
comportamento di uno
use case in un altro
„
estensione
estende uno use case
con un comportamento
opzionale
„
generalizzazione
consente di specializzare
uno use case
Gaetanino PAOLONE
Sistemi informativi aziendali
Uno dei vantaggi più significativi derivanti dall’impiego dei casi d’uso, riguarda la possibilità di
legarli attraverso delle relazioni di inclusione, estensione o generalizzazione, che permettono di
esprimere, in maniera chiara, applicazioni caratterizzate da una certa complessità.
Qualora un caso d’uso risultasse abbastanza complesso da annettere numerosi scenari (ognuno
dei quali rappresenta un comportamento opzionale) sarebbe possibile distinguere più casi d’uso
legati da una relazione di estensione; al contrario si può verificare che un caso d’uso ne includa un
altro, in questo caso la relazione sarà di inclusione, infine, alcune funzionalità del sistema
potrebbero essere specializzate con altre a cui corrisponderanno altrettanti casi d’uso legati alla
funzionalità “padre” da una relazione di generalizzazione/specializzazione.
Diagramma delle classi
Libro
cod_libro
titolo
data edizione
ISDN
data acquisizione
richiesta( )
restituzione( )
create( )
pubblicato da
1
0..*
variazione dati editore( )
1..*
scritto da
0..*
0..*
Libro prezioso
valore : lire = 0
classe: una
collezione di
oggetti, con
propri attributi
ed operazioni
Editore
ragione sociale
nome breve
indirizzo sede
telefono
Autore
nome : type = initval
cognome : type = initval
anno nascita
anno morte
variazione anagrafica( )
valorizza( )
Gaetanino PAOLONE
0..*
Prestito
Utente
variazione anagrafica(
)
Sistemi informativi aziendali
Diagramma delle classi
E’ la descrizione di un insieme di oggetti che
condividono gli stessi attributi, operazioni,
metodi, relazioni e semantiche.
UML usa il termine caratteristiche per indicare
le proprietà e le operazioni di una classe.
Le proprietà rappresentano le caratteristiche
strutturali di una classe.
Gaetanino PAOLONE
Sistemi informativi aziendali
Il diagramma delle classi è uno strumento fondamentale per le metodologie Object Oriented ed è
utilizzato in diversi momenti del ciclo di vita di un sistema informativo per modellarne la struttura
statica a diversi livelli di astrazione: per descrivere modelli concettuali nelle attività di analisi, per
definire delle specifiche nel corso del progetto, per definire particolari tecniche di implementazione.
Un diagramma delle classi descrive il tipo degli oggetti che fanno parte di un sistema, le varie
tipologie di relazioni statiche tra di essi (di dipendenza, associazione, generalizzazione e
realizzazione), le proprietà, ossia le caratteristiche strutturali come gli attributi e le associazioni, le
operazioni di una classe, i vincoli che si applicano ai collegamenti tra gli oggetti di una classe e le
interfacce.
Diagramma delle classi
diagramma delle classi
Classe1
I diagrammi delle classi
mostrano le classi che
modellano un dominio
del pproblema e le loro
relazioni.
Classe6
Classe2
Classe3
assoc1
Classe4
assoc2
Classe5
assoc4
assoc3
diagramma degli oggetti
I diagrammi degli oggetti
mostrano le istanze delle
classi in particolari istanti
temporali.
ist1:classe2
attz = “val”
:classe3
attk = “val”
attj = “val”
:classe4
attw = “val”
:classe6
attx = “val”
atty = “val”
Gaetanino PAOLONE
Sistemi informativi aziendali
Un diagramma degli oggetti equivale ad una fotografia del sistema in un particolare momento della sua
vita descrivendo insiemi di oggetti, le loro relazioni e il loro stato. Dal momento che mostra istanze piuttosto
che classi, un diagramma degli oggetti viene spesso chiamato diagramma delle istanze. L’utilità associata a
tale diagramma è duplice:
−
facilita la comprensione degli aspetti strutturali del sistema nel suo complesso, in quanto fornisce
una rappresentazione esemplificativa in termini di istanze degli oggetti del sistema piuttosto che
di classi cui tali istanze appartengono;
−
offre la possibilità di visualizzare lo stato di una porzione del sistema e la configurazione che tale
porzione assume in un determinato momento del suo ciclo di vita permettendo l’esamina di quali
oggetti sono presenti, quale stato tali oggetti assumono e quali sono le relazioni tra di loro in
modo da verificare il corretto funzionamento del sistema.
I diagrammi di interazione
diagramma di sequenza
I diagrammi di sequenza sono
diagrammi
di
interazione
focalizzati
sull’ordinamento
temporale dei messaggi inviati
agli oggetti.
inst1:classe1
:classe2
:classe3
msg1
:classe5
«create»
msg2
:classe6
msg3
msg4
msg5
«delete»
diagramma di comunicazione
I diagrammi di collaborazione
sono
diagrammi
di
interazione
focalizzati
sull’organizzazione spaziale
degli oggetti.
2 : msg2
1 : msg1
:classe2
istanza:classe1
3 : msg3
8 : msg8
7: msg7
:classe3
5 : msg5
:classe4
4 : msg4
:classe5
6 : msg6
:classe6
Gaetanino PAOLONE
Sistemi informativi aziendali
Un diagramma di interazione descrive il comportamento di gruppi di oggetti che collaborano tra loro per
svolgere un determinato compito, o meglio rappresenta il flusso di controllo tra gli oggetti per la
realizzazione di una funzione del sistema descritta in un caso d’uso.
La specifica dei diagrammi di interazione comporta l’assegnazione di responsabilità agli oggetti, in
quanto il fatto stesso che un oggetto sia in grado di rispondere ad un messaggio inviato da un altro oggetto,
indica una decisione progettuale di assegnazione delle responsabilità.
Nella sua versione più recente UML definisce quattro diversi formalismi per la descrizione delle
interazioni: il diagramma di sequenza, di comunicazione (o collaborazione), di temporizzazione e di sintesi
dell’interazione.
In particolare il diagramma di sequenza è la tipologia più utilizzata dei diagramma di interazione e
documentano il comportamento di un singolo scenario. Un diagramma di sequenza infatti include un certo
numero di oggetti, o meglio di partecipanti, e i messaggi scambiati tra essi durante l’esecuzione del caso
d’uso. A ciascun partecipante è associata una linea tratteggiata verticale, o lifeline, sulla quale sono
posizionate delle barre di attivazione utilizzate come punto di partenza e di arrivo dei messaggi da e verso il
partecipante.
La forza che scaturisce dall’uso dei diagrammi di sequenza si riassume nella chiarezza con cui la
sequenza delle chiamate evidenzia le modalità e le differenze di interazione tra i partecipanti illustrando cosa
fa ognuno di essi.
I diagrammi di comunicazione enfatizzano lo scambio di dati tra i partecipanti. Ogni oggetto è
rappresentato tramite un’icona e collegato agli altri oggetti tramite links, i messaggi scambiati sono preceduti
da un numero, secondo un particolare stile di numerazione progressivo o nidificato, ad indicare la sequenza
con cui avvengono le chiamate.
Invece di indicare ogni partecipante con la sua linea di vita e rappresentare l’ordine dei messaggi in base
alla posizione lungo l’asse verticale, come nel diagramma di sequenza, quelli di comunicazione permettono
di disegnare i partecipanti in qualsiasi posizione aggiungendo collegamenti per mostrare le connessioni.
Volendo spiegare la differenza in modo più razionale, si può affermare che i diagrammi di sequenza
esprimono meglio la successione delle chiamate, mentre quelli di comunicazione pongono l’accento sul
collegamento tra gli oggetti.
Diagramma di sequenza
interfaccia richiesta
: Utente
: interfaccia
biblioteca
consente
all'utilizzatore di
richiedere in prestito
uno o più libri
1: RichiestaPrestito
2:
L'utente fornisce i dati
relativi al libro (ai libri)
che vuole in prestito.
Il sistema verifica se
6: err: utente non censito (
l'utente è censito,
5:
controllo
richiesta
: Utente
: Libro
: Prestito
messaggio
oggetto
3: ControlloUtentePerPrestito (
4:
7: PrestitiDelCliente ( )
Verifica quindi se ha 10: err: utente deve restituire
libri in prestito da
restituire, o se ne ha
già tre in prestito,
segnala l'impossibilità
del prestito.
Altrimenti il sistema
controlla se i libri sono 15: err: libro già in prestito
disponibili, e se lo
sono li fornisce
all'utente, altrimenti
segnala l'errore
specifica di
scenario
(caso d’uso)
Gaetanino PAOLONE
attività
dell’oggetto
8:
9:
11: richiesta (cod_libro)
13:
14:
12: Prestito ( )
Sistemi informativi aziendali
Diagramma di sequenza: a cosa serve
• evidenzia il modo in cui uno scenario (uno specifico
percorso in un caso d’uso) viene risolto dalla
collaborazione tra un insieme di oggetti
• specifica la sequenza dei messaggi che gli oggetti si
scambiano
• può specificare nodi decisionali e iterazioni
• diagrammi di sequenza e diagrammi di collaborazione (di
comunicazione) esprimono informazioni simili, ma le
evidenziano in modo diverso
Gaetanino PAOLONE
Sistemi informativi aziendali
Diagramma di sequenza
• Asse verticale: tempo, dall'alto verso il basso
• Asse orizzontale: oggetti, da sinistra verso destra in ordine
decrescente di importanza; nella prima colonna l'oggetto che
avvia la collaborazione
• Due caratteristiche importanti, per ciascun oggetto
ƒ la "linea della vita"
ƒ il "focus of control": evidenzia il periodo di tempo
durante il quale un oggetto sta eseguendo un'azione,
direttamente o utilizzando una procedura subordinata
Gaetanino PAOLONE
Sistemi informativi aziendali
Ancora …
diagramma state machine
Inizio del ciclo di
vita dell’oggetto
I
diagrammi
statechart
mostrano la macchina a stati
che modella la logica di
controllo di un oggetto.
Stato A
evento / azione
evento / azione
Stato B
evento / azione
Stato C
evento / azione
Fine del ciclo di
vita dell’oggetto
diagramma delle attività
Attività 1
I diagrammi delle attività
mostrano i flussi fra le
attività, cioè fra azioni non
atomiche.
[condizione]
Attività 5
[condizione]
Attività 4
Attività 2
Attività 3
Gaetanino PAOLONE
Negli approcci Object Oriented il comportamento assunto da un singolo oggetto durante il suo ciclo di
vita viene riassunto in un diagramma di macchina a stati. Un oggetto può assumere diversi stati nel contesto
dei casi d’uso ai quali partecipa e i suddetti diagrammi servono proprio a chiarire la logica con la quale
avviene il passaggio da uno stato all’altro.
Gli elementi principali di questo diagramma sono tutti i possibili stati e le transizioni che indicano i
possibili passaggi di stato. Più stati possono essere raggruppati in superstati allo scopo di indicare in modo
semplice un comportamento comune dell’oggetto in stati differenti, ad esempio transizioni che si svolgono in
modo identico da e verso un gruppo di stati.
Ovviamente non è pensabile produrre un diagramma per ogni classe, il che risulterebbe oneroso e al
tempo stesso inutile, ma ci si limita a quelle che hanno una logica interna interessante e complessa in modo
da migliorare la comprensione del loro funzionamento.
I diagrammi di attività sono in grado di modellare gli aspetti dinamici di un sistema in quanto
rappresentano l’insieme di azioni da svolgere per ottenere un certo risultato. Per questa ragione vengono
utilizzati per descrivere una logica procedurale, processi di business e workflow.
Le attività che prendono parte a un diagramma di questo tipo hanno inizio a partire dal nodo iniziale e
terminano in uno o più punti che indicano la fine della sequenza. Le relazioni che collegano un’attività
all’altra rappresentano il passaggio del flusso di controllo e possono essere di varia natura: è possibile che
più sequenze di azioni vengano svolte contemporaneamente, in questo caso i flussi di attività saranno
introdotti da un fork, ossia un elemento grafico che ha un solo flusso in ingresso e tanti flussi in uscita quanti
sono i flussi di controllo eseguiti in modo concorrente; ovviamente ovunque ci sia parallelismo sorge anche
la necessità di sincronizzarsi, ovvero di ricomporre i vari flussi in uno unico. Per esprimere tale esigenza si
ricorre all’elemento grafico di join caratterizzato da più flussi in ingresso e un solo flusso in uscita. In certi
casi infine l’esecuzione di un’attività potrebbe essere stabilita di volta in volta in seguito al verificarsi di una
certa condizione: opportuni punti di decisione daranno quindi luogo a flussi distinti ciascuno contraddistinto
da guardie tutte mutuamente esclusive. Un merge servirà a segnalare la fine del comportamento
condizionale.
In questo modo il diagramma delle attività si limita a specificare le regole essenziali di ordinamento,
quelle che non possono essere violate, lasciando al responsabile del processo descritto la libertà di scegliere
l’ordine di esecuzione delle azioni. Questo è molto utile in fase di modellazione di business, dal momento
che in tale ambito spesso si verifica che i processi sono svolti in parallelo. Inoltre, sempre per far fronte ad
esigenze che emergono durante l’attività di modellazione, ricorrendo alla divisione del diagramma in
partizioni risulta possibile associare ad una singola organizzazione o ad una classe già identificata la
responsabilità di ciascuna delle azioni presenti nel diagramma.
È evidente dunque che questo tipo di diagramma può essere utilizzato per mostrare il comportamento di
organizzazioni il cui sistema software si trova ad interagire con processi molto complessi e più in generale
per analizzare in dettaglio le attività previste all’interno di uno use case, evidenziando i vincoli di
sequenzialità fra diverse attività o invece la possibilità di eseguire alcune attività in parallelo.
Diagramma di stato
transizione
di stato
evento
stato iniziale
stato
acquisizione libro( dati libro, autori,
editore )
acquisito
prestito( data )
restituzione( data
restituzione )
in prestito
scadenza termini
cancellazione
libro( ISDN )
stato finale
restituzione( data
restituzione )
sollecito
in ritardo
cancellazione libro( ISDN )
Gaetanino PAOLONE
Sistemi informativi aziendali
Diagramma di stato: a cosa serve
• specifica il ciclo di vita degli oggetti di una classe,
definendo le regole che lo governano
• quando un oggetto si trova in un certo stato può essere
interessato da determinati eventi (e non da altri)
• come risultato di un evento l’oggetto può passare ad un
nuovo stato (transizione)
Gaetanino PAOLONE
Sistemi informativi aziendali
Esempio di Diagramma di Attività con Swimlanes
Cliente
stato di
sincronizzazione
(fork)
Vendita
Magazzino
Richiesta prodotto
Ricezione ordine
stato di
sincronizzazione
(join)
Pagamento
Evasione ordine
Consegna ordine
Archiviazione ordine
Gaetanino PAOLONE
Sistemi informativi aziendali
Diagramma delle attività: a cosa serve
• a rappresentare sistemi di workflow, oppure la logica interna
di un processo (di qualunque livello, dai business process ai
processi di dettaglio)
• permette di rappresentare processi paralleli e la loro
sincronizzazione
• è un caso particolare di diagrammi di stato, in cui ogni stato
è uno stato di attività
Gaetanino PAOLONE
Sistemi informativi aziendali
Diagramma delle attività
• Attivitj: esecuzione non atomica (in una macchina a stati);
include azioni (esecuzione di operazioni, calcoli, invio di
messaggi,«)
• Diagramma delle attivitj: descrive il flusso fra attivitj
• I diagrammi delle attivitj sono quindi più dettagliati dei
diagrammi d¶interazione (diagramma delle sequenze e
diagramma di collaborazione)
Gaetanino PAOLONE
Sistemi informativi aziendali
Diagramma di flusso oggetto-azione
Cliente
Vendite
Magazzino
richiedi
servizio
ordine
[effettuato]
ricevi
ordine
ordine
[inserito]
paga
ordine
[completato]
ricevi
merce
ordine
[spedito]
Gaetanino PAOLONE
completa
ordine
spedisci
merce
Sistemi informativi aziendali
Diagramma di flusso oggetto-azione: a cosa serve
• a rappresentare le interazioni tra processi e oggetti
• è un caso particolare di diagramma di attività
• è un vero e proprio flow chart
Gaetanino PAOLONE
Sistemi informativi aziendali
Considerazioni:
„ UML è uno standard, e questo è un bene
(uniformità nei concetti e nelle notazioni utilizzate,
interoperabilità tra strumenti, indipendenza dai
produttori, dalle tecnologie, dai metodi)
„ UML è articolato: può rappresentare qualunque
sistema, a diversi livelli di astrazione
„ UML è complesso: va adattato ("ritagliato") in
base alle specifiche esigenze dei progettisti e dei
progetti, utilizzando solo ciò che serve nello
specifico contesto
Gaetanino PAOLONE
Sistemi informativi aziendali
Systems Modeling Language
„ è un linguaggio di modellazione che supporta la
specifica, l’analisi, il design, la verifica e la
validazione di un ampio insieme di sistemi
complessi che possono includere:
ƒ hardware
ƒ servizi
ƒ software
ƒ personale
ƒ informazioni
ƒ impianti
Gaetanino PAOLONE
Sistemi informativi aziendali
System Modeling Language è uno standard di OMG per la rappresentazione dei sistemi
complessi “non solo software”.
Lo standard per la rappresentazione del software deriva da UML, pertanto SysML può essere
considerato un profilo di UML, cioé una sua estensione ufficiale per la rappresentazione di sistemi
complessi, costituiti da componenti hardware e software.
La prima versione di SysML (1.0) è del settembre 2007, la 1.1 del maggio 2008, mentre lapiù
recente, la 1.2 del giugno 2010.
Systems Engineering: non solo requisiti
“Systems Engineering is an interdisciplinary approach and means to enable the
realization of successful systems. It focuses on defining customer needs and required
functionality early in the development cycle, documenting requirements, then
proceeding with design synthesis and system validation while considering the complete
problem. Systems Engineering integrates all the disciplines and specialty groups
into a team effort forming a structured development process that proceeds from
concept to production to operation. Systems Engineering considers both the
business and the technical needs of all customers with the goal of providing a quality
product that meets the user needs.”
INCOSE (Intl. Council on Systems Engineering)
Il Systems Engineer deve avere:
•
•
visione interdisciplinare: i sistemi non sono fatti SOLO
di software, ma anche di hardware, di meccanica, etc.
capacità di mediazione tra le esigenze del business e i vincoli
tecnici, con un occhio alle nuove opportunità tecnologiche.
Gaetanino PAOLONE
Sistemi informativi aziendali
Cerchiamo di capire che cosa si intende veramente per Systems Engineering.
Quella nel riquadro è la definizione che ne dà la INCOSE, l’International Council on Systems
Engineering, un ente internazionale e indipendente che da molti anni si occupa della definizione di
metodologie per il Systems Engineering. E’ chiaro che quello che emerge è che il sistemista ha un
ruolo estremamente importante nella progettazione di sistemi complessi. Al “sistemista” è richiesto
avere:
− una visione interdisciplinare: i sistemi non sono fatti SOLO di software, ma anche di
hardware, di meccanica, etc..;
− la capacità di mediazione tra le esigenze del business e i vincoli tecnici, con un occhio
alle nuove opportunità tecnologiche.
System Engineering è, dunque, un approccio interdisciplinare e mezzi per consentire la
realizzazione di sistemi di successo. Esso si concentra sulla definizione delle esigenze dei clienti e
delle funzionalità richieste nelle prime fasi del ciclo di sviluppo, sul documentare i requisiti, quindi
di procedere con la progettazione di sintesi e di convalida del sistema, mentre si prende in
considerazione il problema nel suo complesso. Systems Engineering integra tutte le discipline e
gruppi specializzati in un lavoro di squadra strutturato formando un processo di sviluppo che parte
dal concetto di produzione operativa. Systems Engineering ritiene sia il business e le esigenze
tecniche di tutti i clienti l'obiettivo per fornire un prodotto di qualità che soddisfi le esigenze degli
utenti.
Systems Modeling Language
Riuso di parte del meta-modello
UML 2.1
Tra i nuovi elementi introdotti:
• il requisito testuale
• il blocco
• il constraint block
6\V0/'LDJUDP
%HKDYLRU
'LDJUDP
$FWLYLW\
'LDJUDP
6HTXHQFH
'LDJUDP
5HTXLUHPHQW
'LDJUDP
6WDWH0DFKLQH
'LDJUDP
8VH&DVH
'LDJUDP
6WUXFWXUH
'LDJUDP
%ORFN'HILQLWLRQ
'LDJUDP
6DPHDV80/
0RGLILHGIURP80/
,QWHUQDO%ORFN
'LDJUDP
3DFNDJH'LDJUDP
3DUDPHWULF
'LDJUDP
1HZGLDJUDPW\SH
Gaetanino PAOLONE
Sistemi informativi aziendali
Il SysML è basato su un subset del meta-modello di UML 2.1 con delle specifiche estensioni, di
qui l’omogeneità e l’inter-operabilità dei con i modelli di design.
Tra le numerose novità introdotte dallo standard, abbiamo tre nuove entità di modello:
− il requisito testuale, che permette di visualizzare e relazionale l’elemento fondamentale
del Requirement Engineering e le relazioni che esistono con gli elementi di design del
modello UML (superando ampiamente i limiti e gli usi impropri degli use case che
spesso venivano usati come rappresentazioni dei requisiti nel modello);
− il blocco, che è una estensione della classe. Questa così come è non poteva andare bene
per il System Engineering perché pensata espressamente per i sistemi software. Il blocco
serve a descrivere le parti del sistema e la struttura interna delle parti;
− il constraint block, che non è semplicemente la possibilità di vincolare gli elementi
UML che era già presente in UML (esempio il linguaggio formale OCL), ma qualcosa di
più e specifico per il Systems Engineering perché permette di modellare proprietà,
formule e quantità invarianti della struttura interna del sistema.
Insieme alle nuove entità, sono state aggiunti i corrispondenti nuovi diagrammi che forniscono
la prospettiva visuale (punti di vista) dei Requisiti (Requirement Diagram), della struttura del
sistema (Definition e Internal Block Diagram), dei vincoli parametrici (Constraint Block
Diagram).
Processo di sviluppo: note introduttive
Business Modeling
Analisi e Definizione
dei Requisiti
Analisi
Concetuale
Progettazione
Implementazione
Test
e collaudi
Gaetanino PAOLONE
Sistemi informativi aziendali
Il processo di sviluppo di un sistema software è costituito da un insieme di passi che consentono
di muoversi dalle attività di Business Modeling e Analisi dei requisiti fino all’Implementazione e
alla consegna del sistema guidando i diversi team di lavoro durante l’intero ciclo di vita del sistema
informatico.
Il Modello a Cascata
Business Modeling
Analisi e Definizione
dei Requisiti
Analisi
Concetuale
Progettazione
A cascata vuol dire che
lo sviluppo del sistema
procede attraverso una
fase alla volta: una fase
viene terminata
completamente e quindi
si passa alla successiva.
Gaetanino PAOLONE
Implementazione
Test
e collaudi
Sistemi informativi aziendali
Inizialmente si riteneva che lo sviluppo di un sistema potesse essere condotto mediante un approccio
sequenziale, cosiddetto a cascata , che consta di una sequenza di fasi strutturata in analisi dei requisiti,
progetto, sviluppo, collaudo, integrazione e manutenzione. Ciascuna di queste fasi produce un ben preciso
output che viene utilizzato come input per la fase successiva.
Sebbene il modello a cascata ebbe un enorme successo negli anni settanta quando venne teorizzato e
viene utilizzato ancora oggi, la complessità crescente dei sistemi da realizzare ha reso impraticabile questo
approccio. Infatti le attività di analisi e progettazione di un “grande sistema” si presentano di lunghezza e
complessità tali da ritardare oltremodo l’avvio del sistema e da comportare rischi di obsolescenza del sistema
prima che lo stesso entri nella fase realizzativa.
Il Modello Incrementale
Incrementale
vuol dire creare
qualcosa pezzo
per pezzo e
integrare i pezzi
un po’ alla volta
per realizzare il
sistema finale.
Gaetanino PAOLONE
Sistemi informativi aziendali
Tale modello deriva dalla “fusione” del modello a cascata e di quello iterativo, infatti prevede lo
svolgimento sequenziale di quattro fasi - analisi dei requisiti, progetto, codifica e test (o collaudo)- che si
ripetono in blocco in modo che in uscita da ogni sequenza di svolgimento delle fasi si ottenga una versione
funzionante del sistema, migliore della precedente. L’utilizzo di questo modello supera i limiti del modello a
cascata e consente una progettazione adeguata in quanto conduce ad un sistema solido. Tale approccio è
consigliabile quando si ha fin dall’inizio una visione abbastanza chiara dell’intero progetto, perché occorre
fare in modo che la realizzazione della generica versione k risulti utile per la realizzazione della versione
k+1.
Piano metodologico di riferimento
Disciplina
Modello
•Business Modeling
ƒLinguaggio naturale
ƒUML
Elaborato
Business Use Case diagram
Documento di Visione
•Analisi e definizione dei
requisiti
•Analisi concettuale
•Progettazione
•Realizzazione
•Verifica
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Le attività che costituiscono la realizzazione di un progetto informatico sono quelle riportate
nella prima colonna della tabella.
A ciascuna di queste attività corrisponde un modello, ossia un insieme di artefatti creati come il
risultato di un processo di astrazione che viene adottato per eliminare i dettagli inessenziali ai fini
della specifica attività condotta e per comunicare i risultati e agevolarne la comprensione.
In questo modo ciascuna attività svolta prevede l’emissione di “prodotti-elaborato” che
consentono di descrivere nel dettaglio quanto previsto nell’ambito di ciascuna di esse.
Metodologia di riferimento
„ Il RUP è un processo per lo sviluppo del software, definito e
commercializzato da Rational nel 1999 (nel 2003 la Rational è
stata acquisita da IBM), che provvede a disciplinare
l'assegnazione dei compiti e delle responsabilità nel contesto di
un progetto software.
„ Un processo di sviluppo del software identifica un insieme di
attività necessarie per trasformare le esigenze dell'utente in
un'applicazione software.
(VLJHQ]H
XWHQWH
3URFHVVRGL
VYLOXSSRGHO
VRIWZDUH
$SSOLFD]LRQH
9LVXDO80/OQN
VRIWZDUH
Gaetanino PAOLONE
Sistemi informativi aziendali
Anche se RUP (Rational Unified Process) viene spesso chiamato processo è in realtà
un’infrastruttura per la definizione di processi che fornisce un vocabolario e una struttura generica utile per
discutere i processi software. Per questo la prima cosa da fare quando si sceglie di adottare il RUP è definire
il caso di sviluppo, ossia il particolare processo adottato per il progetto corrente. Infatti a seconda delle
esigenze del progetto, del tipo di sistema che si deve costruire e delle sue dimensioni oltre che della
tecnologia utilizzata, varieranno l’esatta sequenza dei passi da compiere e i prodotti rilasciati durante il
processo.
A prescindere dal particolare caso di sviluppo il RUP è un processo iterativo e incrementale: il sistema
non viene rilasciato un’unica volta alla fine del processo ma in passi successivi. Questo permette dei
vantaggi significativi quanto più aumenta la complessità del sistema da sviluppare. Innanzitutto la
comprensione del problema da risolvere non avviene in un’unica fase iniziale ma in passi successivi con il
raffinamento e la crescita incrementale di un medesimo modello nel corso di cicli successivi. Inoltre
l’approccio iterativo garantisce la possibilità di accogliere nuove esigenze o modifiche negli obiettivi per i
quali viene sviluppato il sistema e di affrontare e risolvere già nelle fasi iniziali i rischi collegati allo sviluppo
del sistema quali i rischi tecnologici, professionali e organizzativi.
Le Discipline del RUP
„ Una disciplina (processo) definisce tutte le
attività attraverso le quali viene prodotto un
insieme di artefatti.
„ Un artefatto (elaborato) è un insieme di
informazioni usato o prodotto dal processo di
sviluppo del software.
„ Una disciplina è descritta da:
discipline
ƒ Elementi di base
ƒ Concetti
ƒ Workflow
ƒ Elenco delle attività
ƒ Elenco degli artefatti
ƒ Elenco delle linee guida
Gaetanino PAOLONE
Sistemi informativi aziendali
Il RUP prevede le discipline, o core workflows, ciascuna delle quali definisce le attività
attraverso le quali vengono prodotti gli artefatti. Queste discipline servono anche a raggruppare
logicamente i vari elementi della componente statica e sono a loro volta suddivise in engineering
workflows e supporting workflows
Un artefatto è un insieme di elementi del progetto realmente tangibili (elaborato) usato o prodotto dal
processo di sviluppo del software. Un aretfatto può presentarsi sotto moletplici forme: come Modelli o
Elementi di modelli (ad esempio diagramma dei casi d’uso e dunque caso d’uso, classe,...), come
documenti generici o codici sorgente, come eseguibili (ossia come prototipi funzionanti).
Ogni disciplina è descritta tramite diversi elementi acui corrisponde una specifica rappresentazione
grafica.
Gli Elementi di RUP
„ Il RUP è descritto usando quattro elementi:
ƒ
Workflow
(quando)
ƒ
Worker
(chi)
ƒ
Attività
(come)
ƒ
Artefatti
(cosa)
:RUNHU
$WWLYLWj
(ODER
UDWR
:RUNIORZ
Gaetanino PAOLONE
Sistemi informativi aziendali
Il RUP è rappresentato usando quattro elementi di modellazione:
− i workflow, che chiariscono quando le cose vengono realizzate;
− i worker, che rappresentano chi fa il lavoro, sia esso una singola persona o un gruppo di
lavoro;
− le attività, che esprimono come viene svolto il lavoro;
− gli artefatti, che mostrano cosa viene fatto.
Un workflow è una sequenza di attività che produce un risultato osservabile; ovvero è quella cosa che,
raggruppandoli logicamente, va oltre il semplice elenco di ruoli, attività e artefatti, andando a palesare le
interazioni tra essi. In UML sono espressi come sequence diagram, collaboration diagram o activity
diagram.
I workflow sono solitamente espressi in varie forme, comunemente abbiamole Discipline, ovvero
workflow di alto livello e i Workflow Details che sono i workflow presenti all’interno delle
discipline
I worker, o ruoli, sono come un “cappello” che una persona o un gruppo indossa. Una persona o un
gruppo può ricoprire più ruoli e un ruolo può essere ricoperto da più persone.
Una attività relativa a uno specifico ruolo è una unità di lavoro da svolgere, caratterizzata da un preciso
traguardo espresso come modifica o creazione di artefatti. Le attività possono essere ripetute da parte dello
stesso ruolo più volte sullo stesso artefatto, anche se il ruolo non è lo stesso individuo.
Un artefatto è un insieme di elementi del progetto realmente tangibili (elaborato) usato o prodotto dal
processo di sviluppo del software. Un aretfatto può presentarsi sotto moletplici forme: come Modelli o
Elementi di modelli (ad esempio diagramma dei casi d’uso e dunque caso d’uso, classe,...), come
documenti generici o codici sorgente, come eseguibili (ossia come prototipi funzionanti).
Le Fasi del RUP
Gaetanino PAOLONE
Sistemi informativi aziendali
Le quattro fasi del ciclo di vita del processo RUP sono:
1. ideazione: obiettivo di questa fase è comprendere profondamente il contesto del business,
quindi definire il dominio del problema e scoprire tutti i requisiti di alto livello. In questa
fase è possibile effettuare una stima preliminare dei tempi e dei costi relativi al progetto
che si vuole intraprendere contestualmente all’identificazione degli eventuali rischi
connessi;
2. elaborazione: la fase di elaborazione ha la responsabilità di affrontare la maggior parte
delle difficoltà legate all’aspetto tecnologico del sistema. Devono essere affrontate le
problematiche relative al design, all’implementazione, al testing, alla scelta
dell’architettura di base e delle interfacce, ponendo particolare attenzione sulle
comunicazioni inter-processo e alla persistenza dei dati;
3. costruzione: in questa fase avviene l’implementazione del software; vengono prodotte
varie release interne e alla fine si deve ottenere una prima versione beta funzionante e
completa di documentazione, materiale di supporto all’utilizzo e pronta per
l’installazione;
4. transizione: alla fine del ciclo di vita ci si occupa del testing complessivo e delle
modifiche di poco conto. Si affrontano il fine-tuning e le piccole modifiche legate al
feedback ottenuto dall’utente finale (se si è operato in modo corretto in tutte le fasi queste
modifiche saranno inezie, poiché le modifiche importanti e strutturali devono già essere
emerse nelle fasi precedenti).
Schematizzazione del RUP
Gaetanino PAOLONE
Sistemi informativi aziendali
Il processo è strutturato su due dimensioni:
− la struttura dinamica, ovvero la dimensione temporale del processo, l’asse orizzontale in
figura che mostra come il processo, espresso come cicli, fasi, iterazioni e milestones si
distribuisce su tutto il ciclo di vita del progetto;
− la struttura statica: è l’asse verticale in figura e raggruppa logicamente in workflow gli
elementi del processo (attività, discipline, ruoli e artifatti).
Fasi e Milestone
„ Una fase ha le seguenti caratteristiche:
ƒ identifica il periodo di tempo fra due milestone principali del
processo;
ƒ durante la fase vengono soddisfatti un insieme ben definito
di obiettivi;
ƒ durante la fase vengono completati degli artefatti;
ƒ include le decisioni per passare alla fase successiva.
„ Un milestone principale ha le seguenti caratteristiche:
ƒ è un evento a livello di sistema definito al termine di ogni
fase di sviluppo per dare visibilità a elementi significato a
livello di sistema;
ƒ sincronizza le prospettive gestionali e ingegneristiche;
ƒ verifica che gli obiettivi della fase siano stati raggiunti.
Gaetanino PAOLONE
Sistemi informativi aziendali
Sviluppare un Progetto in Modo Iterativo
„ Sviluppare un progetto in maniera iterativa vuol
dire eseguire in modo ripetitivo un insieme di
processi o di attività orientati al miglioramento di
un prodotto parziale fino a farlo diventare prodotto
finale.
8QDLWHUD]LRQH qXQDXQLWjGLJHVWLRQHVRWWRSURJHWWR
DOO¶LQWHUQRGLXQSURJHWWRJOREDOHFRVWLWXLWDGDXQDVHTXHQ]D
GLVWLQWDGLDWWLYLWjFKHSURGXFRQRXQDUHOHDVH
Gaetanino PAOLONE
Sistemi informativi aziendali
Sviluppare un Progetto in Modo Iterativo
„ Una release è un insieme relativamente completo e
consistente di artefatti, contenente possibilmente
una versione eseguibile del sistema (build).
„ Una release rappresenta un rilascio formale del
risultato di un’iterazione e pertanto deve essere
formalmente pianificata.
Gaetanino PAOLONE
Sistemi informativi aziendali
Nella categoria dei modelli iterativi rientrano tutti i processi di sviluppo che permettono di ritornare ad
una fase del procedimento già affrontata in precedenza. Per ogni fase “iterabile” si tende a partire con un
abbozzo della soluzione che verrà successivamente raffinata al passaggio seguente.
Schematizzazione di un’Iterazione
Gaetanino PAOLONE
Sistemi informativi aziendali
Il RUP® si basa su un approccio di tipo iterativo e incrementale che consiste in una serie di step, detti
iterazioni, ripetuti per raffinarne il prodotto. Ciascuna iterazione può coinvolgere tutti o solo alcuni dei
settori dello sviluppo, dalla raccolta dei requisiti all’analisi passando per le fasi di design e implementazione.
L’output di una iterazione equivale all’input dell’iterazione successiva che, a sua volta, restituisce un
output più raffinato facendo così evolvere il prodotto fino ad ottenere il prodotto finale, completo e
perfettamente funzionante. Ogni iterazione ha un focus on differente a seconda dell’avanzamento del
progetto: le prime iterazioni sono comunemente incentrate sulla raccolta dei requisiti e sull’analisi mentre le
iterazioni svolte sul prodotto ad uno stadio più maturo si concentrano principalmente sulle fasi di
implementazione e test.
Questo tipo di approccio permette di aggredire in modo molto efficace le criticità tipiche dello sviluppo
del software ed in particolar modo permette di:
−
evidenziare i problemi gravi in maniera molto precoce, permettendo così di porvi rimedio
efficacemente e a basso costo;
−
aumentare gli scambi informativi con i clienti, in modo da individuarne le reali
aspettative e i reali requisiti del sistema;
−
anticipare i test sul prodotto in modo da valutare in maniera oggettiva lo stato di
avanzamento del progetto ed evidenziare precocemente le incoerenze tra requisiti e
prodotto;
− migliorare il processo di sviluppo stesso utilizzando le conoscenze acquisite dai gruppi di
lavoro nel corso del progetto.
Il Modello Iterativo
„ Il modello iterativo indica che un sistema,
un sottosistema, un componente, ecc.,
viene realizzato in più passi in modo che a
ogni passo una parte di essi venga creata
estendendo e arricchendo in modo
consistente un’altra parte già realizzata.
Gaetanino PAOLONE
Sistemi informativi aziendali
Fasi del RUP e Iterazioni
Gaetanino PAOLONE
Sistemi informativi aziendali
Model Driven Architecture: che cosa è MDA?
„ L’MDA ha come scopo la definizione delle
soluzioni in modo indipendente dalla piattaforma
tecnologica.
ƒ ciò garantisce la portabilità delle stesse soluzioni
ai medesimi problemi presenti anche in progetti
diversi;
ƒ il concetto di piattaforma è molto di più esteso di
quello che si potrebbe pensare: oltre a OS e HW,
comprende anche framework di simulazione e di
testing;
MDA invita a progettare un intero sistema con modelli
diversi, uno per ogni livello di astrazione, assicurando in
cambio una completa portabilità della soluzione grazie a
delle trasformazioni tra modelli di diverso livello.
Gaetanino PAOLONE
Sistemi informativi aziendali
Model Driven Architecture è uno standard OMG che ha come scopo la definizione delle
soluzioni in modo indipendente dalla piattaforma tecnologica su cui viene realizzata. Ciò garantisce
la portabilità delle stesse soluzioni ai medesimi problemi presenti anche in progetti diversi.
Il concetto di piattaforma è molto di più esteso di quello che si potrebbe pensare, include, oltre
a OS e HW, anche framework di simulazione e di testing. Quindi far migrare una stessa
applicazione da una piattaforma all’altra può includere:
− simulare e testare una applicazione embedded su un normale PC (piattaforma =
OS+dispositivi HW);
− instrumentare il codice per valutare la copertura dei test (piattaforma + framework di
testing).
MDA invita a progettare un intero sistema con modelli diversi, uno per ogni livello di
astrazione, assicurando in cambio una completa portabilità della soluzione grazie a delle
trasformazioni tra modelli di diverso livello.
Model Driven Architecture: i modelli definiti da MDA
&,0
• CIM, Computation Independent Model
0RGHO!!
7UDVIRUPD]LRQH
GLUHWWD
3,0
• PIM, Platform Independent Model
0RGHO!!
360
360
360
0RGHO!!
0RGHO!!
PSM
Bridge
&RGH!!
&RGH!!
Code
Bridge
0RGHO!!
&RGH!!
• PSM, Platform Specific Model
• CODE
MDA contempla la possibilità di trasformazioni dirette.
Gaetanino PAOLONE
Sistemi informativi aziendali
In MDA esistono almeno quattro livelli di astrazione, ognuno del quale coperto da uno specifico
tipo di modello. [ATTENZIONE, non stiamo parlando assolutamente di strati software!!!].
− CIM, Computation Independent Model, descrive quello che occorre fare, ma da punto di
vista dell’analista (Modello dei requisiti e regole di business);
− PIM, Platform Independent Model, descrizione della soluzione ma dal punto di vista
dell’implementatore a prescindere dalla specifica piattaforma (nel senso più esteso del
termine);
− PSM, Platform Specific Model, è il modello della soluzione che tiene conto anche della
piattaforma.La stessa soluzione può essere condivisa da più PIM di progetti diversi
anche se implemenati su piattaforme diverse. Inoltre la stessa soluzione può essere
realizzata con diversi PSM, uno per piattaforma implementativa. Parti di una singola
soluzione potrebbero dover funzionare su più piattaforme diverse contemporaneamente:
tanti PSM collegati tra loro da bridge;
− CODE,è una sorta di modello “degenere”.
MDA contempla anche “trasformazioni dirette”, come ad esempio tra PIM e CODE.
(Ovviamente il PSM potrebbe essere comunque generato, ma solo per documentazione e
debugging).
Model Driven Architecture: le trasformazioni MDA
3,0
„ Trasformazione di modello:
0RGHO!!
è un processo di conversione di
un modello in uno o più modelli
che descrivono, ad un altro livello
di astrazione, lo stesso sistema
?
?
360
„ Trasformazione possibili:
0RGHO!!
- Manuale – look-up table
- Automatica - Ricerca e sostituzione
- Automatica - Basata sul formalismo
- Automatica - Basata sul modello (informazioni)
- etc.
A
B
Le trasformazioni sono componibili !!
Gaetanino PAOLONE
Sistemi informativi aziendali
Per trasformazione di modello si intende il processo di conversione di un modello in uno o più
modelli che descrivono lo stesso sistema. Né il meccanismo né le regole di trasformazione sono
state specificate in MDA, pertanto anche se si auspica di renderla automatica, la trasformazione può
anche essere manuale e può necessitare di informazioni addizionali.
Poiché MDA non definisce le trasformazioni, possiamo considerarle nel modo più generale,
ovvero qualcosa che mette in relazione un elemento di un insieme con quello di un altro. Le
trasformazioni possibili di un model item di un modello in un altro sono:
− manuale - look-up table;
− automatica - ricerca e sostituzione;
− automatica - basata sul formalismo;
− automatica - basata sul modello (informazioni);
− etc, nel senso che sicuramente se ne possono immaginare delle altre.
Model Driven Architecture: applicazioni gestionali
PROBLEMI DA RISOLVERE:
ƒ Gli obiettivi di business devono essere
rispettati dai dipertimenti IT;
ƒ Le piattaforme possono cambiare nel
tempo (evoluzione tecnologica,
integrazione di infrastrutture IT, etc.);
ƒ La piattaforma non dovrebbe
condizionare gli obiettivi di business.
Gli elementi del CIM sono
concettualmente “vicini” a quelli
implementati
ƒ Il CIM non solo specifica il sistema, ma
descrive anche le business rules;
ƒ Si ritiene veramente possibile una
trasformazione automatica e diretta del
CIM in codice (!?!)
Gaetanino PAOLONE
&,0
0RGHO!!
3,0
0RGHO!!
360
0RGHO!!
&RGH!!
Sistemi informativi aziendali
I principali problemi da risolvere hanno a che fare:
− con gli obiettivi di business, i quali devono essere rispettati dai dipartimenti di IT;
− con le piattaforme Middleware, le quali possono cambiare nel tempo (evoluzione
tecnologica, integrazione di infrastrutture IT, etc.) ;
− con la piattaforma, che non dovrebbe condizionare gli obiettivi di business (ma quasi
sempre lo fa).
Gli elementi del CIM sono concettualmente “vicini” a quelli implementati dal Middleware,
infatti il CIM non solo specifica il sistema, ma descrive anche le business rules, pertanto si ritiene
veramente possibile una trasformazione automatica e diretta del CIM in codice (!?!).
Integrazione
Manutenzione
Prodotto
Testing
Profile
Customer Care
63(0
Implementazione
Qualità
Business
Management
Testing
System Engineering
63(0
Project Management
La progettazione industriale: l’influenza del successo di UML
Come per il Systems Engineering con il SysML, anche altre
discipline di progettazione si affidano alla modellazione e
alla visione “unificante” dell’UML.
Gaetanino PAOLONE
Sistemi informativi aziendali
Sulla scorta dello straordinario esempio di UML nel Software Engineering, anche le altre
discipline ingegneristiche che contribuiscono alla realizzazione di sistemi complessi sono oggi
fortemente orientate alla ricerca di un linguaggio di modellazione capace di unificare le proprie
diverse metodologie e pratiche di progettazione, meglio se questo avviene sulla stessa strada
tracciata da OMG con UML, ancora meglio se si riesce ad usare UML per i propri scopi o anche
adattarlo ed estenderlo al proprio specifico contesto.
Contenuti
„ Il Business Modelling.
„ Analisi e Definizione dei Requisiti.
„ Analisi Concettuale.
„ Progettazione.
„ Realizzazione e verifica.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Con le slides che seguono verranno esaminate le discipline del RUP relative al Business
Modeling, all’ Analisi e Definizione dei Requisiti, all’ Analisi Concettuale, alla Progettazione e alla
Realizzazione e Verifica.
Business Modeling: quando
1. Progettazione di un nuovo Sistema
Informativo per una nuova azienda.
2. Reingegnerizzazione di un Sistema
Informativo esistente:
„
„
Ottimizzazione dei flussi informativi.
Estensione del sistema azienda.
3. Automazione del Sistema Informativo di una
azienda.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
I motivi che inducono ad intraprendere l’attività di Business Modeling possono essere i seguenti:
− la progettazione del sistema informativo per una nuova azienda;
− la reingegnerizzazione del sistema informativo in essere, dovuta o alla necessità di
ottimizzare i flussi informativi o in caso di estensione del sistema azienda;
− l’automazione del sistema informativo di un’azienda.
In tutti questi casi il punto da cui partire per individuare la soluzione più adatta alla specifica
circostanza è la modellazione di business.
Obiettivo del Business Modeling
„ L’obiettivo del Business Modelling è la
realizzazione di modelli del dominio del
problema che descrivano logicamente la
proposta di soluzione del sistema (il cosa
deve fare) che sarà dettagliata e realizzata
durante la progettazione e la realizzazione.
„ Vengono prodotti degli elaborati (diagrammi
statici e dinamici, per esempio rappresentati
con la notazione UML) che costituiscono una
rappresentazione del problema che deve
essere risolto.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Approcci al Business Modeling
Other approaches
Business Process
Modeling
Language
Unified Modeling
Language
Business Analysis
System Analysis
Our approach
Unified Modeling Language
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Business Modeling
„ Quando gli elaborati sono completati,
relativamente all’iterazione alla quale di sta
lavorando, il modello globale viene verificato:
„ eseguendo il sistema sulla carta
„ avvalendosi del consiglio di esperti del
dominio.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Una volta terminata la singola iterazione, gli elaborati prodotti vengono sottoposti a verifica.
Questo passaggio serve a garantire la perfetta aderenza del modello di business ai requisiti espressi.
Sia che la modellazione sia finalizzata alla creazione di un sistema informativo nuovo, sia che si
tratti di un processo di reingegnerizzazione, è importante che il modello rispecchi fedelmente i
caratteri e la natura del sistema azienda che si vuole svilupppare o di quello già in essere, in quanto
dal modello stesso scaturirà la soluzione.
Piano metodologico
„ Permette la definizione di:
1.
2.
3.
Attività da svolgere.
Modelli da utilizzare.
Elaborati da produrre.
„ Rappresenta il riferimento per lo sviluppo di un
progetto.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Avvalersi di un piano metodologico equivale ad avere chiare:
− le attività da svolgere;
− i modelli da utilizzare;
− gli elaborati da produrre.
Ciò naturalmente facilita lo svolgimento dell’intero processo di sviluppo del sistema.
Piano metodologico di riferimento
Disciplina
•Business Modeling
Modello
Elaborato
ƒLinguaggio naturale
ƒUML
Organization Unit Diagram
Business System diagram
Business Use Case diagrams
Business Use Case Realization diagrams
Business Objects diagram
Activity diagrams
Documento di Visione
•Analisi e definizione dei
requisiti
•Analisi concettuale
•Progettazione
•Realizzazione
•Verifica
Business Modelling: stessi elaborati per un progetto di creazione, reingegnerizzazione ad automazione di un
Sistema Informativo Aziendale
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Il piano metodologico scelto come riferimento è quello riporato in tabella.
La prima colonna elenca le discipline, ovvero le attività da compiersi; la seconda colonna
suggerisce i modelli da utilizzare per ogni singola attività, mentre l’ultima colonna conterrà tutti i
possibili elaborati da produrre.
Per quanto riguarda la disciplina di Business Modeling i modelli da utilizzare sono il linguaggio
naturale e UML. Tutti gli elaborati producibili (Organization Unit Diagram, Business System
Diagram, Business Use Case Diagram, Business Use Case Realization Diagram, Business Object
Diagram, Activity Diagram e il Documento di Visione) valgono sia che si tratti di modellare un
nuovo sistema informativo (creazione), reingegnerizzare o automatizzare un sistema già esistente.
Piano per la progettazione del Sistema Informativo Aziendale
1. Business Modeling:
„
„
Business Modeling.
Analisi e definizione dei requisiti.
2. Realizzazione del progetto.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Business Modelling: come
„ Per ogni Organization Unit Æ Business Systems di livello 1.
„ Per ogni Business System di livello i Æ Business Systems
di livello i+1 fino al grado k.
„ Per ogni Business System di livello K Æ Classi di Attori.
„ Per ogni Classe di Attori Æ Business Use Cases (BUCs),
attraverso l’individuazione dei Business Goals.
Business Objects
„ Definizione delle Organization Unit.
„ Per ogni Business Use Case Æ Business Use Cases
Realization (BUCRs).
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Come svolgere la disciplina di Business Modeling?
E’ possibile riassumere l’attività di modellazione in una serie di passaggi.
Innanzitutto si tratta di individuare e definire le Organization Units, ossia le unità organizzative
che compongono il sistema azienda nella sua totalità. Per ogni Organization Unit individuata, si
trovano i Business Systems di livello 1. In pratica si tratta di esaminare ciascuna Organization Units
e suddividerla nelle sue sottoparti. Questa scomposizione viene ripetuta per ogni Business System
di livello i (che viene scomposto nei Business System di livello i+1) fino al grado k.
A questo punto per ogni Business System di livello k si rintracciano le diverse classi di attori e
per ciascuna classe si definiscono dapprima i Business Goals e successivamente, i Business Use
Case.
Infine per ogni Business Use Case, il livello di dettaglio aumenta attraverso l’individuazione dei
relativi Business Use Case Realization.
Business Modeling
„ La rappresentazione dei processi di business.
Diagrammi delle attività a due livelli di astrazione
„ Relazione tra elementi comportamentali e
strutturali del business.
• Matrice di corrispondenza
• Diagrammi di sequenza
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Business Modeling
„ Diagramma delle attività per i processi di business.
„ Diagramma delle attività per ogni Business Use Case.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Business Modeling (punto di partenza)
Enterprise
Department 1
Department n
Organization Unit
Business System
Sistemi Informativi Aziendali
Gaetanino PAOLONE
Business Systems Decomposition
Degree:
Gaetanino PAOLONE
1
2
…
k
Sistemi Informativi Aziendali
Il primo passo da compiere è esaminare l’azienda nella sua interezza (Enterprise) e individuare
gli n Departments che la compongono. Durante la modellazione l’azienda sarà rappresentata tramite
lo stereotipo di Organization Unit mentre le sue sottoparti, tramite Business Systems.
Analogamente, la scomposizione per livelli che verrà applicata a partire dai Business Systems di
livello 1, si ripeterà fino al livello k.
An incremental and iterative Methodology
Phase 1
IN
Activity
<<refine>>
Activity
Activity
Activity
Phase 2
Activity
Activity
OUT
Activity
Activity
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Innanzitutto è importante chiarire il concetto che sta dietro alla parola metodologia.
A differenza di un processo metodologico (che prevedendo una struttura rigida formata da un
punto di partenza a cui fa seguito una serie di steps predeterminati, si adatta bene solo al particolare
contesto per cui è stato definito), la metodologia ha una struttura flessibile, pertanto la si può
adattare a diverse circostanze.
Ciò premesso, verrà presentata la metodologia da noi proposta basata su un modello iterativo e
incrementale. In altre parole la metodologia proposta prevede delle fasi, ciascuna avente un artefatto
in ingresso (IN) e uno in uscita (OUT), e ogni fase è caratterizzata da un ciclo, nel quale si
susseguono le attività.
La scelta di seguire una logica iterativa e incrementale per la metodologia da proporre è stata
dettata dall’esigenza di tornare indietro alla fase precedente per migliorarne gli artefatti prodotti.
Solo in questo modo infatti, ciò risulta possibile: ad esempio, terminata la seconda fase (dopo aver
iterato il ciclo di attività un certo numero di volte) è possibile tornare indietro e migliorare i prodotti
in uscita dalla prima fase.
Business Use-Case Modeling
Phase1:
Business Use-Case Modeling
Phase 1
IN
Activity
Activity
Activity
These activities
aren’t sequential
but they are
iterative and
incremental
Activity
Next Phase
Sistemi Informativi Aziendali
Gaetanino PAOLONE
Business Use-Case Modeling
Phase1:
Business Use-Case Modeling
Define Organizations Units
Business
Actors
GOALS
Business
Use Case
BUC Actors Goals
These activities
aren’t sequential
but they are
iterative and
incremental
Next Phase
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Viene analizzata ora una singola fase, la prima, quella relativa alla modellazione a livello di
Business Use Case.
In questa fase l’analista descrive il progetto e produce un documento contenente i requisiti, in
collaborazione con tutti gli stakeholders. In particolare l’analista descrive le unità organizzative, i
processi e gli attori coinvolti nel sistema informativo.
L’input a questa prima fase coincide con quanto emerso dalla scomposizione del sistema
azienda, prima nelle diverse Organization Unit, poi nei Business Systems.
Le attività che, succedendosi, formano il ciclo sono le seguenti:
− individuazione dei Business Actors riassunti nel relativo diagramma degli attori;
− individuazione dei Business Goals, maggiormente dettagliati nel Business Goals
Document;
− individuazione dei Business Use Case e organizzazione degli stessi in uno o più Business
Use Case Diagram;
− determinazione delle relazioni tra gli attori di business e i relativi obiettivi passando
attraverso i BUCs e e successiva rappresentazione delle relazioni nel modello.
Queste attività non sono sequenziali, ma si realizzano secondo un meccanismo di tipo iterativo e
incrementale.
Una caratteristica molto importante del ciclo appena descritto riguarda la sua consistenza: infatti
se si introducesse un obiettivo, un attore o un BUC nel modello, deve comparire necessariamente
un’interazione che leghi questi elementi.
Business Modeling
Phase2:
Business Modeling
Phase 2
IN
Activity
Activity
Activity
Activity
Next Phase
Sistemi Informativi Aziendali
Gaetanino PAOLONE
Business Modeling
Phase2:
Business Modeling
Business Use Case Model
Phase 2
Business Use Case
Realization
Activity
Sequence
0..*
1
1:
2:
Business Object
Model
3:
0..1
For each
Business
Use Case
4:
5:
Activity
Documentation
These activities
aren’t sequential
but they are
iterative and
incremental
Next Phase
Gaetanino PAOLONE
Sistemi Informativi Aziendali
La fase di Business Modeling ha inizio al termine della fase precedente, ossia quando è stato
rilasciato il modello dei casi d’uso di business relativo al sistema informativo in esame.
In questa seconda fase si realizzano il modello degli oggetti di business (Business Object Model)
e il diagramma dei Business Use Case Realization.
Il software engineer analizza il sistema informativo nel suo complesso, focalizzando l’attenzione
su cosa fa il sistema e non su come dovrebbe essere fatto il sistema. In altre parole, durante la fase
di modellazione di business l’aspetto più importante su cui bisogna concentrarsi riguarda le
funzionalità del sistema, piuttosto che le soluzioni tecnologiche da adottare.
I prodotti delle attività di questa seconda fase sono:
− uno o più diagrammi di Business Use Case Realization;
− il modello degli oggetti di business;
− uno o più diagrammi di sequenza, che esprimono l’interazione tra i BUCR, gli attori di
business e gli oggetti di business);
− la documentazione, grazie alla quale fornire una descrizione esaustiva degli attori, dei
BUCRs e degli oggetti di business.
Il ciclo di attività che costituiscono questa seconda fase è un ciclo di controllo: gli artefatti di
ciascuna attività infatti, sono la rappresentazione del medesimo sistema, il sistema informativo.
Business Modeling
BUC0
BUC1
BUC2
BActivity1
{BO1, BO3,
BO4}
{BO2, BO5}
BActivity2
{BO2, BO3}
{BO1,
BO2}
BActivity0
C1=
BActivity3
Gaetanino PAOLONE
{BO3}
{BO1, BO4}
{BO5}
Sistemi Informativi Aziendali
Business Modeling
Una matrice di corrispondenza (C2) per ogni BUC
BUCR0
DActivity0
C2 =
DActivity1
BUCR2
{BO2,
BO5}
{BO2}
{BO1, BO4}
{BO1, BO3,
BO6}
DActivity2
Gaetanino PAOLONE
BUCR1
{BO5}
Sistemi Informativi Aziendali
La matrice di corrispondenza C1 mette in relazione le Business Activity con i BUCs tramite i
Business Objects.
Considerato un BUC, la matrice di corrispondenza C2 mette in relazione i suoi BUCRs con i
diagrammi di attività tramite i Business Objects.
Business Modeling Æ System Modeling
RUP
<trace>
<realize>
<realize>
CIM
CIM
<trace>
<realize>
<realize>
<trace>
PIM
Gaetanino PAOLONE
PIM
Sistemi Informativi Aziendali
Per quanto riguarda il passaggio dal Business Modeling al System Modeling si confrontano due differenti
approcci metodologici.
La metodologia tradizionale basata sul RUP (immagine a sinistra) propone una soluzione di carattere
iterativo e incrementale ricorrendo ad un framework di tipo model driven che pone i casi d’uso al centro
dell’attività di modellazione.
La metodologia a cui ci si riferisce è strutturata in quattro layers distinti ed è basata su un approccio topdown di tipo iterativo e incrementale che procede per raffinamenti successivi: i primi due layers di analisi dei
casi d’uso riguardano più specificamente la modellazione di business ed hanno l’obiettivo di fornire una
rappresentazione completa e approfondita della realtà aziendale; i due layers sottostanti invece, riguardano la
modellazione di sistema, che equivale alla rappresentazione del software destinato ad automatizzare il
sistema aziendale o un suo sottosistema.
Con l’applicazione della metodologia basata sul RUP si ha la possibilità di descrivere entrambi gli aspetti,
quello di business e quello di sistema, con ricchezza sempre maggiore di particolari e, soprattutto, viene
assicurato il passaggio da un modello all’altro senza perdita di informazioni. Il processo infatti è guidato dai
casi d’uso, use case driven, che ritroviamo sia a livello di business che di sistema, seppur rappresentati con
stereotipi differenti a sottolinearne la diversa valenza.
Il passaggio dal modello CIM (Computetional Indipendent Model), formato dai primi due layers,
al modello PIM (Platform Indipendent Model) avviene attraverso un’operazione di <trace>. La
logica da seguire è semplice: una volta individuati tutti i BUCRs (per ognuno dei BUCs) si
stabilisce quali di questi andranno automatizzati. In questo modo si individuano i SUCs e, con il
successivo <realize>, i SUCRs che completano il modello PIM.
La nostra proposta metodologica (immagine a destra) introduce alcune novità significative.
Analogamente all’approccio basato sul RUP, anche il nostro approccio prevede l’adozione di
quattro layers distinti, due per la modellazione a livello di business e due per la modellazione a livello di
sistema, entrambi collegati tra loro da una operazione di <realize>. Quello che cambia è la relazione che
intercorre tra modello di business e modello di sistema: viene introdotta infatti una doppia operazione di
<trace> che dai livelli di business conduce ai due livelli di modellazione del sistema. In questo
modo si possono riprodurre tutti i BUCs e i relativi BUCRs nella prospettiva di sistema,
trasformandoli rispettivamente nei SUCs e nei SUCRs. L’obiettivo dell’operazione di <trace>,
come nella metodologia basata sul RUP, resta quello di trasferire alla modellazione di sistema solo
ciò che è destinato all’automazione.
Business Modeling Æ System Modeling
RUP
<trace>
CIM
CIM
<trace>
<trace>
<trace>
PIM
Gaetanino PAOLONE
PIM
Sistemi Informativi Aziendali
Le modifiche introdotte con la nostra metodologia riguardano esclusivamente gli aspetti
comportamentali del sistema, lasciando inalterato l’approccio relativamente alla componente
strutturale. Questo equivale a dire che in entrambi i casi, sia che si scelga di adottare la metodologia
tradizionale basata sul RUP sia che si opti per quella innovativa da noi proposta, ogni Business
Entity verrà sottoposta a tracciatura dando luogo, a livello di sistema, ad una classe ad essa relativa.
Approccio metodologico RUP
Gestione Docum ento
<<communicate>>
<<communicate>>
<<com municate>>
<<communicate>>
Ges tione Prodotto/Servizio
ICCREA Responsabile
Banca
(f rom Actors)
(f rom Actors)
<<communicate>>
Gestione Modello di Documento
Gestione Documento
Gestione Struttura
<<realize>>
<<realize>>
<<realize>>
<<realize>>
<<realize>>
Smis tamento Documento
Ges tione Struttura Fisica
Ges tione Area Aziendale
(from Documento)
(from Area Azi en dale)
(from Area Azi en dale)
Business Modeling
System Modeling
<<trace>>
Caricamento Documento
ICCREA Acquisi tore
(from Actors)
Smistamento Documento
ICCREA Responsabile
(from Actors)
Validazi one Documento
Acquisizione Documento
(from Docum en to)
<<realize>>
<<realize>>
<<realize>>
<<realize>>
GestioneFascicoli
<<include>>
<<include>>
<<extend>>
AcquisizioneDocumento
Allega File
Approccio metodologico proposto
Gestione Docum ento
<<communicate>>
<<communicate>>
<<com municate>>
<<communicate>>
Ges tione Prodotto/Servizio
ICCREA Responsabile
Banca
(f rom Actors)
(f rom Actors)
<<communicate>>
<<trace>>
Gestione Modello di Documento
Caricamento Documento
ICCREA Acquisi tore
(from Actors)
Smistamento Documento
ICCREA Responsabile
(from Actors)
<<realize>>
Validazi one Documento
Gestione Documento
Gestione Struttura
<<realize>>
<<realize>>
<<trace>>
<<realize>>
<<realize>>
<<realize>>
Smis tamento Documento
Ges tione Struttura Fisica
Ges tione Area Aziendale
(from Documento)
(from Area Azi en dale)
(from Area Azi en dale)
Acquisizione Documento
(from Docum en to)
<<realize>>
<<realize>>
GestioneFascicoli
<<realize>>
<<include>>
<<include>>
<<extend>>
AcquisizioneDocumento
Allega File
Scendendo più nel dettaglio si può affermare che la modellazione di business ha inizio con la
rappresentazione del sistema aziendale scomposto in tutte le sue parti (aree, dipartimenti, divisioni,
uffici,…) svolta affidandosi ad un certo grado di astrazione per descrivere la realtà d’interesse. Considerate
tutte le unità organizzative, ciascuna con i suoi sistemi di business, per ognuno di questi vengono rilevati i
principali obiettivi e gli attori coinvolti nel loro raggiungimento per poi procedere all’analisi, quindi
all’individuazione, dei principali casi d’uso di business (BUC) con cui costruire il modello dei casi d’uso di
business (primo layer per entrambi gli approcci). Quest’ultimo fornisce una rappresentazione
sufficientemente esaustiva dell’aspetto comportamentale delle diverse unità organizzative.
In seguito ogni BUC individuato viene specializzato, nel layer successivo, con uno o più Business Use
Cases Realization (BUCRs) che vengono organizzati secondo il diagramma di realizzazione dei BUCs.
A questo punto, dal modello completo che descrive l’intero business, ci si focalizza unicamente su quella
parte destinata all’automazione desumendo i requisiti di sistema direttamente da quelli di business.
Questo può avvenire in due diversi modi.
Se si procede secondo l’approccio metodologico RUP, si esegue un’operazione di <trace> con la quale i
BUCRs vengono tracciati nella prospettiva di sistema divenendo dunque System Use Cases (SUCs), con lo
scopo di delineare i contorni del sistema informativo da automatizzare (terzo layer). A completamento della
fase di modellazione del sistema, ogni SUC verrà infine ulteriormente raffinato con almeno un SUCR,
organizzati secondo un diagramma di realizzazione dei SUCs appartenente all’ultimo dei quattro layers.
In alternativa, procedendo secondo l’approccio metodologico da noi proposto, si esegue una doppia
operazione di <trace> con la quale i BUCs vengono tracciati nella prospettiva di sistema divenendo SUCs
(terzo layer) e, parallelamente, i BUCRs vengono tracciati divenendo SUCRs (quarto layer).
System Modeling Æ Code Modeling
RUP
PIM
PIM
UseCaseRealization
Class
?
PSM Æ code
Gaetanino PAOLONE
PSM Æ code
Sistemi Informativi Aziendali
Summary of methodology
Summary of methodology
Le slides riassumono i contenuti della metodologia proposta.
Si parte innanzitutto dall’attività di modellazione dei BUCs che produce il Business Use Case
Model; analogamente dall’attività di analisi del business deriva il Business Analisys Model.
L’attività relativa all’analisi concettuale realizza il Conceptual Analisys Model. Infine l’attività di
progettazione produce il Design Model.
L’aspetto focale dei modelli introdotti cambia da caso a caso: al centro del Business Use Case
Model evidentemente ci saranno i BUCs, i quali verranno chiaramente identificati e descritti nel
modello, mentre il Business Analisys Model si concentrerà principalmente sui BUCRs. Per quanto
riguarda il Conceptual Analisys Model e il Design Model , invece, l’attenzione sarà focalizzata sui
casi d’uso (SUCs) e sui casi d’uso di realizzazione (SUCRs) rispettivamente.
Indipendentemente dallo stereotipo assegnatogli, il caso d’uso è il concetto intorno al quale
ruotano tutti e quattro i modelli ed equivale non solo alla rappresentazione formale dei requisiti
espressi dagli utenti del sistema, ma anche alla connessione tra i requisiti e il codice. In questo
modo la trasformazione che va dai requisiti al codice avviene senza perdita di informazioni e il
progetto può ritenersi completo: anche un solo requisito non tradotto da luogo ad un progetto
incompleto, quindi errato.
La nostra metodologia unitamente al nostro framework sono quindi strumenti che permettono di
realizzare un progetto esattamente aderente a ciò che è stato richiesto dal committente servendosi
del costrutto caso d’uso.
Bank Document Management System
Bank
Administration
Unit
Gaetanino PAOLONE
Document Management
Sistemi Informativi Aziendali
Un esempio relativo al sistema di gestione dei documenti di una banca.
Innanzitutto è stata rappresentata la banca (Bank) servendosi dello stereotipo Organization Unit.
A seguire la banca, intesa come una struttura gerarachica a n-livelli, è stata suddivisa nei relativi
Business Systems fino al livello k in cui è stato identificato il sottosistema inerente la gestione dei
documenti che sarà oggetto dell’attività di modellazione.
A questo punto si passa alla caratterizzazione del Business System Document Management
attraverso l’individuazione dei suoi BUCs.
Business Modeling: activity diagram I
Gaetanino PAOLONE
Sistemi Informativi Aziendali
A questo punto della modellazione il piano per la progettazione suggerisce la rappresentazione
dei processi di business tramite diagrammi di attività a due livelli di astrazione:
− i diagrammi di attività per i processi di business;
− i diagrammi di attività per ogni BUC.
Nella slide è mostrato un esempio di diagramma di attività al primo livello di astrazione, infatti
riguarda il processo di acquisizione e archiviazione del documento. Secondo quanto riportato nel
diagramma, il documento acquisito, viene prima validato ( a patto che risulti completo) e poi inviato
alla sede di archiviazione.
Document Management: Business Goals
<support>
Fast retrieval of docs
Document Management
<support>
Filing of documents
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Il Business System Document Management supporta due Business Goals: il sistema di gestione
da modellare deve permettere da un lato l’archiviazione dei documenti presso le sedi di
archiviazione stabilite, dall’altro il recupero rapido di tutti i documenti gestiti dalla banca.
Document Management: BUCRs
Document Management
Gaetanino PAOLONE
Sistemi Informativi Aziendali
La slide mostra il diagramma di realizzazione del BUC Document Acquisition.
Il documento da condividere con la banca può essere acquisito ad opera degli organi interni della
banca (BUCR Internal Document Acquisition), di una filiale (BUCR Branch Document
Acquisition) o di un cliente (BUCR Customer Document Acquisition). In tutti i casi, durante
l’acquisizione, risulta possibile gestire anche i fascicoli allegati al documento (BUCR Brief
Manager legato da una relazione di <extend> agli altri BUCRs). Inoltre ai fini dell’acquisizione
bisognerà gestire anche tutte le tipologie di documento possibili (BUCR Document Type Manager).
Business Modeling: activity diagram II
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Il piano per la progettazione suggerisce la rappresentazione dei processi di business tramite
diagrammi di attività a due livelli di astrazione:
− i diagrammi di attività per i processi di business;
− i diagrammi di attività per ogni BUC.
Nella slide sono mostrati due esempi di diagramma di attività al secondo livello di astrazione,
infatti uno (a sinistra) riguarda il BUC Document Acquisition dal punto di vista di un operatore
interno della banca, l’altro (a destra) rappresenta il medesimo BUC, ma dal punto di vista del
cliente.
Document Management: Double Tracing
<realize>
<realize>
Document Acquisition
<trace>
Internal Document
Acquisition
Document from supplier
<realize>
Document Acquisition
<realize>
<trace>
<trace>
<realize>
<extend>
Internal Document
Acquisition
Gaetanino PAOLONE
<extend>
Link File
Document from supplier
Sistemi Informativi Aziendali
Il passaggio dal Business Model al System Model è stato svolto applicando una doppia operazione di
<trace> coerentemente con quanto introdotto dalla recente proposta metodologica.
Per mostrare la potenza espressiva del nuovo approccio, la slide sottolinea che è possibile raggruppare
assieme in un unico diagramma dei casi d’uso le varie attività di <realize> e <trace> in modo da avere così
una visione globale di come le modalità operative aziendali sono portate avanti e come esse devono essere
automatizzate.
Business Modeling
Gaetanino PAOLONE
Sistemi Informativi Aziendali
La matrice di corrispondenza mette in relazione le Business Activity (prima colonna) con i
BUCs (prima riga) tramite i Business Objects (Document, Business Area, Document’s Type).
Business Modeling
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Considerato un BUC, in questo caso Document Acquisition, la matrice di corrispondenza mette
in relazione i suoi BUCRs (prima riga) con i diagrammi di attività (prima colonna) tramite i
Business Objects.
Piano metodologico di riferimento: automazione
Disciplina
Modello
•Business Modeling
ƒLinguaggio naturale
ƒUML
•Analisi e definizione dei
requisiti
Elaborato
ƒLinguaggio naturale
ƒUML
Trace Diagram: Class
Trace Diagram: Use Case
Trace Diagram: Use Case Realization
Trace Diagram: Actors
Use Cace Realization Diagram - Actor
Documento dei Requisiti
•Analisi concettuale
•Progettazione
•Realizzazione
•Verifica
Gaetanino PAOLONE
Sistemi Informativi Aziendali
La disciplina di Analisi e Definizione dei Requisiti ha l’obiettivo di documentare compiutamente
ciò che il sistema deve fare, in modo da garantire facilità di comunicazione tra cliente e
sviluppatori.
Per realizzare il trasferimento dei requisiti di business a livello dei requisiti software si procede
ad una duplice operazione di <trace> che interessa sia l’aspetto comportamentale che quello strutturale,
permettendo dunque che entrambi gli aspetti progrediscano parallelamente.
La logica da seguire nell’applicazione dell’operazione di tracciatura si riassume nella scelta di quali siano
le “parti” del business che necessitano di essere automatizzate: la prima operazione di <trace> interesserà
esclusivamente i BUCs che il Business Analyst ritiene debbano essere automatizzati, la seconda operazione
di <trace> in SUCRs sarà effettuata limitatamente ai BUCRs che, in qualche maniera, prendono parte
all’automazione del processo.
Allo stesso modo vengono tracciate tutte le classi di business nelle classi di dominio e tutti quegli attori di
business che comporteranno un corrispettivo a livello di sistema: si ottiene così un primo modello del
sistema nel quale i vari elementi saranno corredati da una breve descrizione.
La disciplina di Analisi e Definizione dei Requisiti si avvale del linguaggio naturale e UML. Gli
elaborati producibili (Trace Diagram Class, Trace Diagram Use Case, Trace Diagram Use Case
Realization, Trace Diagram Actors, Use Case Realization Diagram-Actors e il Documento dei
Requisiti) valgono nel caso in cui il processo di sviluppo in atto sia rivolto all’automazione di un
sistema già esistente.
Tracciabilità fra Requisiti e Use Case
„ Durante l’analisi e definizione dei requisiti, è importante
capire se qualche requisito non è stato considerato nel
modello degli use case e, viceversa, se c’è qualche use
case che non corrisponde a nessun requisito.
„ La verifica si può fare velocemente tramite una tabella di
mapping fra requisiti e use case.
8VHFDVH
Requisito
8&
5
5
8&
;
8&
;
;
5
5
8&
;
;
;
Piano metodologico di riferimento: automazione
Disciplina
Modello
Elaborato
•Business Modeling
ƒLinguaggio naturale
ƒUML
•Analisi e definizione dei
requisiti
ƒLinguaggio naturale
ƒUML
•Analisi concettuale
ƒ Linguaggio naturale
ƒ UML
ƒ Modello E-R
ƒ Prototyping
Diagrammi di Sequenza di I livello
Diagramma delle Classi View
Diagramma delle Classi (Attributi)
Diagramma Entità-Relazioni
Prototipo
Documento di Analisi
•Progettazione
•Realizzazione
•Verifica
Gaetanino PAOLONE
Sistemi Informativi Aziendali
L’obiettivo della disciplina di Analisi Concettuale è quello di definire come il sistema dovrà
essere realizzato. Pertanto ogni SUC precedentemente individuato verrà meglio descritto attraverso
l’individuazione dei possibili scenari, utili a chiarire il comportamento elementare del caso d’uso a
prescindere dall’automazione ricorrendo ai Sequence Diagrams; inoltre per ogni scenario verranno
individuate anche tutte le classi di oggetti di business coinvolte.
Infine vengono aggiunti ai SUCRs derivanti dal <trace>, quelli di natura puramente tecnologica e,
successivamente, creati i diagrammi di realizzazione a livello di sistema che mettano in evidenza il legame
che intercorre tra i SUCs e i relativi SUCRs.
Per fare quanto detto la disciplina di Analisi Concettuale si avvale del linguaggio naturale, UML,
del modello Entità-Relazione e del Prototyping.
Gli elaborati producibili (Diagramma di Sequenza di primo livello, Diagramma delle Classi,
Diagramma delle Classi con attributi, Diagramma Entità-Relazione, Prototipo e Documento di
Analisi) valgono nel caso in cui il processo di sviluppo in atto sia rivolto all’automazione di un
sistema già esistente.
Prototyping
,.,:,6,² ´,·OONQRZLWZKHQ,VHHLWµ
Durante la fase di Analisi Concettuale può essere utile ricorrere alla prototipazione per testare la
validità della soluzione, far emergere eventuali criticità o, più semplicemente, per mostrare un
prototipo della soluzione in via di sviluppo al committente.
Prototyping
ËO·LPSOHPHQWD]LRQHSDU]LDOHGLXQVLVWHPD
FRQORVFRSRGLDLXWDUHDFDSLUHPHJOLRL
UHTXLVLWLVLDDJOLXWHQWLFKHDJOL
VYLOXSSDWRUL
6FRSL
7LSRORJLH
—
Chiarire e completare i
requisiti
„ Prototipi orizzontali
—
Esplorare alternative
progettuali
„ Usa e getta
—
Sviluppare il prodotto finale
„ Evolutivi
„ Prototipi verticali
Prototyping
(YROXWLYR
9HUWLFDOH
2UL]]RQWDOH
8VDHJHWWD
‡ VHUYHSHUGLPRVWUDUHL
FDVLG·XVRFKHO·XWHQWH
SRWUHEEHDYHUHD
GLVSRVL]LRQHFKLDULUHH
UDIILQDUHLUHTXLVLWL
XWHQWH
‡ LPSOHPHQWDLSURFHVVL
FKLDYH
‡ LPSOHPHQWDSURFHVVL
DJJLXQWLYLVRORVXOODEDVHGL
SULRULWjDVVHJQDWH
‡ SHUHVSORUDUHH
YDOXWDUHLOORRNDQGIHHO
LQWHUIDFFLDXWHQWHH
VWUXWWXUDGHOOD
QDYLJD]LRQH
‡ DGHJXDLOVLVWHPD
YHORFHPHQWHDOOHQHFHVVLWj
GHOEXVLQHVV
‡ SHUGLPRVWUDUHOD
IDWWLELOLWjWHFQLFDGL
XQDVROX]LRQH
‡ LPSOHPHQWDLSURFHVVLVXSL
OLYHOOLDUFKLWHWWXUDOL
SURJUHVVLYDPHQWH
‡ LPSOHPHQWDHRWWLPL]]D
DOJRULWPLFRPSOHVVL
‡ WHVWHWXQLQJGHOOH
SHUIRUPDQFH
Fattori Critici per il Successo della Prototipazione
„ Stabilire, condividere e comunicare al cliente il tipo e
„
„
„
„
„
l’obiettivo del prototipo prima della sua realizzazione
Considerare le attività prototipali parte del piano di
progetto
Valutare la realizzazione di più prototipi
Non prototipare i requisiti che sono già chiari nei
prototipi “usa e getta”
Un prototipo non sostituisce completamente la
specifica dei requisiti
Creare i prototipi “usa e getta” nel modo più economico
e veloce possibile
Progettazione del Software
„ Definizione dell’architettura del sistema
„
individuazione dei sottosistemi
„
individuazione dei componenti software
„
„
descrizione delle interfacce dei sottosistemi
descrizione delle interfacce dei componenti
„
„
„
„
„
„
individuazione dei nodi di elaborazione
Individuazione delle classi di progettazione e delle relazioni
Descrizione della dinamica fra i componenti e fra le classi
Allocazione delle classi di progettazione nei componenti
Allocazione dei componenti nei sottosistemi
Definizione del modello di deployment
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Il concetto fondamentale relativamente alla progettazione del software è quello di architettura
software. Il primo passo da compiere consiste dunque nella scelta dell’architettura su cui basare il
successivo sviluppo del sistema, ovverosia nell’individuazione dei sottosistemi, dei componenti
software e dei nodi di elaborazione.
Inoltre durante la progettazione si procede all’individuazione delle classi di progettazione e delle
relative relazioni, alla descrizione della dinamica fra i componenti e fra le classi, all’allocazione
delle classi di progettazione nei componenti, all’allocazione dei componenti nei sottosistemi e nella
definizione del modello di deployment.
La Babele delle Architetture …
„ Il concetto di architettura è usato talmente in tante diverse
accezioni che risulta privo di senso se non lo si
contestualizza.
„ Tipologie di architetture:
„
„
„
„
„
„
„
„
„
architettura funzionale
architettura dei dati
architettura stratificata
architettura multi-tier
architettura orientata a oggetti
architettura basata su componenti
architettura web
architettura orientata ai servizi
…
La scelta relativa all’architettura da adottare per il progetto informatico da realizzare è al centro
della fase di progettazione. Tale scelta non è affatto banale se si considera che il concetto di
architettura risulta, se non contestualizzato, privo di senso e se si tiene conto della molteplicità di
tipologie di architetture possibili tra cui effettuare la scelta.
Cos'è un'Architettura del Software
„ L'architettura software di un programma o di
un'applicazione è l'insieme:
„ degli elementi software strutturali
„ delle proprietà degli elementi visibili esternamente
„ delle relazioni fra gli elementi.
„ Gli elementi che stanno diventando sempre più importanti
per le architetture sono:
Un pattern è una "idea"
„ i pattern e gli stili architetturali
che è stata provata
positivamente in un
contesto pratico e che
probabilmente sarà utile
in altri
Lo Stile Architetturale
„ Uno "Stile architetturale" è
l'insieme:
„
„
„
„
delle proprietà
dei vincoli
delle linee guida
delle decisioni progettuali
„ da seguire per la realizzazione
delle strutture e delle
interconnessioni all'interno dei
componenti e fra i componenti.
„ I principali stili architetturali di
riferimento per le applicazioni
software distribuite sono:
„
„
„
architettura basata sulle risorse – Resource-Oriented
Architecture (web)
architettura basata su componenti – Component-Based
Architecture
architettura basata sui servizi – Service-Oriented
Architecture.
Architettura Gotica
Stile Architetturale
Orvieto, Duomo
Milano, Duomo
Ecco cosa vuol dire
seguire uno stile architetturale!
Lo stile architetturale è un elemento importante dell’architettura pertanto la scelta di quest’ultima
risente anche dello stile architetturale che la contraddistingue. Uno stile architetturale è l’insieme
delle proprietà, dei vincoli, delle linee guida e delle decisioni progettuali da seguire per la
realizzazione delle architetture.
Architettura MVC
• Model
Incapsula le logiche di business e la rappresentazione delle informazioni
• View
Gestisce l’interfaccia utente dell’applicazione
• Controller
Coordina l’interazione tra Model e View e gestisce le azioni dell’utente
Gaetanino PAOLONE
Sistemi Informativi Aziendali
The software architecture
UseCase
Piano metodologico di riferimento: automazione
Disciplina
Modello
•Business Modeling
ƒLinguaggio naturale
ƒUML
•Analisi e definizione dei
requisiti
ƒLinguaggio naturale
ƒUML
•Analisi concettuale
ƒ Linguaggio naturale
ƒ UML
ƒ Modello E-R
ƒ Prototyping
•Progettazione
•Realizzazione
Elaborato
ƒ Linguaggio naturale
ƒ UML
ƒ Modello Relazionale
ƒ Prototyping
ƒAmbiente di sviluppo
Diagrammi di Sequenza di II livello
Diagramma delle Classi View
Diagramma delle Classi (Attributi e metodi)
Diagramma delle classi controller
Diagramma delle classi Entit
Diagramma Entità-Relazioni
Prototipo
Documento di Progettazione
ƒ Linguaggio di
programmazione
•Verifica
Gaetanino PAOLONE
Sistemi Informativi Aziendali
L’obiettivo della disciplina di progettazione è quello di definire esattamente come il sistema
dovrà essere realizzato nella fase successiva. A tal fine, la fase di progettazione restituisce più in
generale il modello di design il quale va a descrivere in modo dettagliato la struttura del sistema e
come il sistema deve essere costruito.
Esso rappresenta dettagliatamente i componenti del sistema e individua dove e come si
inseriscono nell’architettura prescelta. In questo modello sono presenti i sequence diagrams di
secondo livello, ossia ad un livello di dettaglio elevato tale da descrivere precisamente come le varie
componenti del sistema (design classes, oggetti, interfacce, design sub-systems) interagiscono.
Unitamente si avranno il diagramma delle classi (nelle diverse varianti), il diagramma EntitàRelazione, eventualmente il proptotipo e, certamente, il documento di progettazione.
La dinamicità del sistema può essere ulteriormente chiarita utilizzando gli state machine
diagrams mentre l’architettura software e fisica del sistema possono essere rappresentate
rispettivamente mediante i component diagrams e i deployment diagrams;
I modelli a servizio della fase di progettazione sono numerosi e comprendono il linguaggio
naturale,. UML, il modello relazionale, il prototyping e l’ambiente di sviluppo scelto.
Ancora una volta gli elaborati producibili elencati nella slide riguardano il caso in cui valgono
nel caso in cui il processo di sviluppo in atto sia rivolto all’automazione di un sistema già esistente.
Creazione di un nuovo Sistema Informativo Aziendale
Rimangono le stesse discipline?
Disciplina
Modello
Elaborato
•Business Modeling
•Analisi e definizione dei
requisiti
•Analisi concettuale
•Progettazione
•Realizzazione
•Verifica
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Si considera adesso il caso in cui l’intento sia quello di creare un sistema informativo ex-novo.
Anche in una simile circostanza si sceglie di avvalersi di un piano metodologico di riferimento che
faciliti il processo di sviluppo nonchè la gestione del progetto.
Le discipline inerenti al piano che sono già state esaminate a proposito dello sviluppo di un
progetto informatico derivante da un processo di automazione, valgono anche nel caso in cui si tratti
di creare un sistema informativo automatizzato a meno di qualche differenza nei modelli e negli
elaborati.
Business Modeling
Pre-condizione:
• modello organizzativo aziendale
Il Business Modelling è parte integrante della
progettazione del sistema organizzativo
aziendale
Stessi elaborati:
•
•
•
•
•
•
•
Organization Unit Diagram
Business System diagram
Business Use Case diagrams
Business Use Case Realization diagrams
Business Objects diagram
Activity diagrams
Documento di Visione
Gaetanino PAOLONE
No rilevazione
Ma progettazione
Sistemi Informativi Aziendali
Per poter procedere alla modellazione del business è necessario far riferimento al modello
organizzativo aziendale. Mentre questa condizione risulta sempre verificata nei casi in cui il
progetto informatico da definire e realizzare scaturisca da un processo di reingegnerizzazione o di
automatizzazione di un sistema informativo esistente, nel caso della creazione ex-novo del sistema
informativo bisognerà innanzitutto assicurarsi di poter far riferimento ad un modello organizzativo.
Qualora l’azienda per la quale si intende realizzare il sistema informativo non esistesse ancora e,
con essa, non esistesse alcun modello organizzativo, l’attività di Business Modeling non
consisterebbe nella rilevazione ma piuttosto nella progettazione del sistema organizzativo
aziendale.
Per quanto riguarda invece i modelli e gli elaborati della disciplina di Business Modeling,
restano uguali a quelli già visti in precedenza a proposito dell’automazione.
Analisi e Definizione dei requisiti
Requisiti:
• specifica del sistema informativo aziendale
da realizzare.
Obiettivi:
• specifica dei requisiti;
• analisi delle parti di sistema informativo da
automatizzare (make or buy);
a. adeguamento del business model a soluzioni
informatiche esistenti;
b. attuazione di un processo metodologico per lo
sviluppo di un progetto informatico.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Ai fini dell’Analisi e della Definizione dei Requisiti bisogna partire dalle specifiche del sistema
informativo aziendale che si intende realizzare, espressamente definite dal committente.
A partire dalle specifiche, gli obiettivi a cui si dovrà tendere riguarderanno innanzitutto la
specifica dei requisiti e, in un secondo momento, l’analisi delle sole parti del sistema informativo da
automatizzare.
Per ciascuna delle parti destinate all’automazione si tratterà di effettuare una valutazione make or
buy. Se la scelta ricade sulla soluzione make, bisognerà procedere all’attuazione di un processo
metodologico finalizzato allo sviluppo di un progetto informatico; alternativamente, se la scelta è di
tipo buy bisognerà adeguare il business model alle soluzioni informatiche esistenti.
„
Definizione delle Organization Unit.
„
Per ogni Organization Unit Æ Business Systems di livello 1.
„
Per ogni Business System di livello i Æ Business Systems di livello i+1 fino al grado k.
„
Per ogni Business System di livello K Æ Classi di Attori.
„
Per ogni Classe di Attori Æ Business Use Cases (BUCs), attraverso l’individuazione dei
Business Goals.
„
Per ogni Business Use Case Æ Business Use Cases Realization (BUCRs).
Automazione: a qualsiasi livello
Analisi e Definizione dei requisiti: come?
per ogni sottosistema da automatizzare:
• make or buy?
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Gli step sono gli stessi visti in precedenza con una sola differenza: arrivati al punto in cui per
ogni BUC si individuano i BUCRs, non solo bisognerà chiedersi quali parti del sistema saranno
automatizzate ma anche come sarà possibile la loro automazione, se attraverso la “costruzione” di
soluzioni applicative nuove oppure ricorrendo a quanto già disponibile sul mercato.
Analisi e Definizione dei requisiti: come?
Per ogni soluzione informatica acquistata:
• verifica di adeguamento dei requisiti;
• e quindi del business model.
Per ogni soluzione informatica da realizzare:
• verifica della porzione di business model;
• e quindi attuazione di un processo di
automazione.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Una volta stabilito in che modo debba avvenire l’automatizzazione delle parti del sistema, se
acquistando soluzioni informatiche già esistenti oppure realizzandone di nuove, seguirà una fase di
verifica, la quale diverge a seconda della soluzione scelta.
Piano metodologico di riferimento: creazione
Disciplina
Modello
•Business Modeling
ƒLinguaggio naturale
ƒUML
•Analisi e definizione dei
requisiti
Elaborato
ƒLinguaggio naturale
ƒUML
Trace Diagram (make and buy): Class
Trace Diagram (make and buy): Use Case
Trace Diagram (make and buy): Use Case
Realization
Trace Diagram (make and buy): Actors
Use Cace Realization Diagram – Actor
Diagrammi di business mdel rivisitati
Documento dei Requisiti
•Analisi concettuale
•Progettazione
•Realizzazione
•Verifica
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Nel caso di creazione di un sistema informativo ex-novo la disciplina di Analisi e Definizione dei
Requisiti si avvale del linguaggio naturale e UML.
Gli elaborati relativi al Trace Diagram Class, Trace Diagram Use Case, Trace Diagram Use Case
Realization e Trace Diagram Actors riguarderanno tutte le parti del business destinate
all’automazione, sia che questa abbia luogo secondo la soluzione make che secondo quella buy.
Analisi concettuale
Fasi:
1. Analisi concettuale relativa alle parti da
automatizzare con sviluppo di software.
2. Analisi concettuale relativa alle parti da
automatizzare con acquisto di software.
3. Analisi concettuale relativa alle parti da
non automatizzare.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Analisi concettuale: come?
Fasi:
1. Analisi concettuale relativa alle parti da
automatizzare con sviluppo di software.
(identica al processo di automazione)
2. Analisi concettuale relativa alle parti da
automatizzare con acquisto di software.
(analoga al processo di automazione:
verifica della corrispondenza tra modelli attesi e soluzione
informatica)
3. Analisi concettuale relativa alle parti da
non automatizzare.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Piano metodologico di riferimento: creazione
Disciplina
Modello
Elaborato
•Business Modeling
ƒLinguaggio naturale
ƒUML
•Analisi e definizione dei
requisiti
ƒLinguaggio naturale
ƒUML
•Analisi concettuale
ƒLinguaggio naturale
ƒUML
Elaborati per l'automazione
Sequence diagram dei casi d'uso non automatizati
Class Diagram
Activity Diagram
Modulistica
Documento di Analisi
•Progettazione
•Realizzazione
•Verifica
Gaetanino PAOLONE
Sistemi Informativi Aziendali
L’obiettivo della disciplina di Analisi Concettuale è quello di definire come il sistema
informatico dovrà essere realizzato. Pertanto l’Analisi Concettuale interesserà:
− le parti da automatizzare con sviluppo software (soluzione make);
− le parti da automatizzare con acquisto di software (soluzione buy);
− le parti da non automatizzare.
In particolare, l’Analisi Concettuale condotta relativamente alle parti da automatizzare con
sviluppo software durante la creazione di un nuovo sistema informativo equivale esattamente all’
Analisi Concettuale svolta in caso di automazione di un sistema già esistente. Dunque si tratterà di
descrivere ogni SUC precedentemente individuato attraverso l’individuazione dei possibili scenari, inoltre
per ogni scenario verranno individuate anche tutte le classi di oggetti di business coinvolte.
Infine verranno aggiunti ai SUCRs derivanti dal <trace>, quelli di natura puramente tecnologica e,
successivamente, creati i diagrammi di realizzazione a livello di sistema che mettano in evidenza il legame
che intercorre tra i SUCs e i relativi SUCRs.
Anche per quanto riguarda l’Analisi Concettuale per le parti da automatizzare con acquisto di
software, è possibile far riferimento al processo in caso di automazione. Si tratterà quindi di
verificare la corrispondenza tra i modelli attesi e la soluzione informatica che si è scelto di
acquistare.
Infine, dal momento che l’obiettivo dell’Analisi è quello di stabilire come il sistema dovrà essere
realizzato, bisognerà condurre l’Analisi anche per quel che riguarda le parti del sistema che non
verranno in alcun modo automatizzate.
Per fare quanto detto la disciplina di Analisi Concettuale si avvale del linguaggio naturale e UML.
Gli elaborati producibili (Elaborati per l'automazione, Diagramma di Sequenza dei casi d'uso non
automatizzati, Diagramma delle Classi, , Diagramma di Attività, Modulistica e Documento di
Analisi) valgono nel caso in cui il processo di sviluppo in atto sia rivolto alla creazione di un
sistema informativo ex-novo.
Piano metodologico di riferimento: creazione
Disciplina
Modello
Elaborato
•Business Modeling
ƒLinguaggio naturale
ƒUML
•Analisi e definizione dei
requisiti
ƒLinguaggio naturale
ƒUML
•Analisi concettuale
ƒLinguaggio naturale
ƒUML
•Progettazione
ƒLinguaggio naturale
ƒUML
Architettura informativa
Activity Diagram
Modulistica
Elaborati per l'automazione
•Realizzazione
ƒLinguaggio naturale
Architettura informativa
Modulistica
•Verifica
Gaetanino PAOLONE
Sistemi Informativi Aziendali
L’obiettivo della disciplina di Progettazione è quello di definire esattamente come il sistema
dovrà essere realizzato nella fase di Realizzazione. A tal fine, la fase di Progettazione restituisce,
più in generale, il modello di design il quale va a descrivere in modo dettagliato la struttura del
sistema e come il sistema deve essere costruito.
I modelli a cui è possibile ricorrere in fase di Progettazione sono il linguaggio naturale e. UML,
mentre gli elaborati producibili riguardano l’architettura informativa, i diagrammi di attività, la
modulistica e tutti gli elaborati per l’automazione.
Durante la fase di Realizzazione ci si avvale prevalentemente del linguaggio naturale per
produrre elaborati che definiscono l’architettura informativa e la modulistica, entrambi utili per la
successiva fase di Verifica.
Reingegnerizzazione del Sistema Informativo Aziendale
Quando?
I flussi non sono ben definiti.
Costi elevati di produzione dell'informazione.
Costi elevati di fruizione dell'informazione.
Introduzione di un nuovo sottosistema.
o semplicemente quando si è in presenza di un nuova strategia ...
Sistemi Informativi Aziendali
Gaetanino PAOLONE
Reingegnerizzazione di un Sistema Informativo Aziendale
Rimangono le stesse discipline?
Disciplina
Modello
Elaborato
• Business Modeling
ƒLinguaggio naturale
ƒUML
Organization Unit Diagram
Business System diagram
Business Use Case diagrams
Business Use Case Realization diagrams
Business Objects diagram
Activity diagrams
Documento di Visione
• Analisi e definizione dei
requisiti
ƒLinguaggio naturale
ƒUML
Use Case Realization Diagram - Actor
Documento dei Requisiti
•Business Design
ƒLinguaggio naturale
ƒUML
• Realizzazione e verifica
Gaetanino PAOLONE
Automazione????
Sistemi Informativi Aziendali
Reingegnerizzazione di un Sistema Informativo Aziendale
Business Modeling come rilevazione della situazione esistente
Analisi e definizione dei requisiti di intervento
Gaetanino PAOLONE
Sistemi Informativi Aziendali
In presenza di un processo di reingegnerizzazione del sistema informativo aziendale, dettato da
circostanze di varia natura (flussi informativi non ben definiti, costi di produzione
dell’informazione elevati, costi di fruizione dell’informazione elevati, introduzione di un nuovo
sottosistema, adozione di una nuova strategia,...) il piano metodologico di riferimento prevede le
discipline di Business Modeling, Analisi e Definizione dei Requisiti, Business Design e
Realizzazione e Verifica
Il processo di reingegnerizzazione riguarderà una parte o l’intero sistema informativo aziendale e
farà riferimento al modello organizzativo esistente. Di conseguenza l’attività di Business Modeling
si svolgerà come rilevazione della situazione esistente, esattamente come avviene nel caso di un
processo di automatizzazione del sistema informativo.
I modelli da utilizzare per il Business Modeling sono il linguaggio naturale e UML, mentre gli
elaborati producibili (Organization Unit Diagram, Business System Diagram, Business Use Case
Diagram, Business Use Case Realization Diagram, Business Object Diagram, Activity Diagram e il
Documento di Visione) sono gli stessi già visti in precedenza, sia nel caso di un processo di
automatizzione, sia nel caso della creazione di un nuovo sistema informativo.
Per la disciplina di Analisi e Definizione dei Requisiti saranno sufficienti il Diagramma Casi
d’uso di realizzazione-Attori e il Documento dei Requisiti per la definizione dei requisiti di
intervento.
Reingegnerizzazione di un Sistema Informativo Aziendale
Elaborati della progettazione di Business?
Disciplina
Modello
• Business Modeling
ƒLinguaggio naturale
ƒUML
• Analisi e definizione dei
requisiti
ƒLinguaggio naturale
ƒUML
•Business Design
• Realizzazione e verifica
Gaetanino PAOLONE
Elaborato
ƒLinguaggio naturale
ƒUML
Organization Unit Diagram
Business System diagram
Business Use Case diagrams
Business Use Case Realization diagrams
Business Objects diagram
Activity diagrams
Use Case Realization Diagram - Actor
Documento di Progettazione
Automazione????
Sistemi Informativi Aziendali
Per quanto concerne la disciplina di Business Design ci si avvale del linguaggio naturale e UML
per produrre Organization Unit Diagram, Business System Diagram, Business Use Case Diagram,
Business Use Case Realization Diagram, Business Object Diagram, Activity Diagra, Use Case
Realization Diagram Actor e il Documento di Progettazione a cui fare riferimento nellle fasi di
Realizzazione e Verifica.
Contenuti
„ Ciclo di vita dei sistemi informativi.
„ Studio di fattibilità.
Gaetanino PAOLONE
Sistemi Informativi Aziendali
Le slide che seguono trattano il ciclo di vita dei sistemi informativi con particolare attenzione
alla fase relativa allo studio di fattibilità di un progetto informativo.
Ciclo di vita dei sistemi informativi
„ Pianificazione
„ Reingegnerizzazione dei processi
„ Assessment e Benchmarking
„ Studio di fattibilità
„ Analisi e definizione dei requisiti del sistema
informativo
„ Progettazione
„ Realizzazione
„ Manutenzione
„ Gestione e conduzione
„ Project Management
Gaetanino PAOLONE
Sistemi informativi aziendali
E’ bene chiarire che la necessità di uno studio di fattibilità nasce quando un’idea progettuale si
presenta tale da richiedere opportuni approfondimenti e specificazioni per governarne la
complessità e diminuire l’incertezza dei risultati, prima di avviare le attività operative di progetto.
Lo studio di fattibilità serve dunque ad esaminare preliminarmente la fattibilità tecnica,
organizzativa ed economica di un’idea progettuale che si intende intraprendere valutando, al tempo
stesso, gli aspetti che possono eventualmente determinare scelte fra soluzioni progettuali diverse.
Lo studio di fattibilità prende pertanto spunto da una pre-esistente idea di progetto scaturita da un
ciclo di pianificazione e controllo, da un’iniziativa di reingegnerizzazione, dall’attività di
benchmarking o, ancora, dettata dalle nuove opportunità tecnologiche, per la quale gli impegni
economici, l’impatto organizzativo nonché i rischi associati risultano significativi.
Obiettivi
„ Obiettivo principale è quello di fornire ai centri di
responsabilità l’insieme delle informazioni
necessarie alle decisioni sul progetto. Deve quindi:
„
esplicitare le condizioni favorevoli all’effettuazione
del progetto;
„
definire i benefici attesi;
„
stimare i costi e i rischi;
„
delineare l’evoluzione del progetto dallo stato iniziale
a quello finale atteso, valutando le possibili
alternative.
Gaetanino PAOLONE
Sistemi informativi aziendali
L’obiettivo principale dello studio di fattibilità è quello di fornire ai centri di responsabilità
l’insieme delle informazioni necessarie alle decisioni sul progetto. Lo studio di fattibilità deve
quindi:
− esplicitare le condizioni favorevoli all’effettuazione del progetto per la realizzazione di
sistemi informativi automatizzati e l’erogazione di servizi informatici;
− definire esattamente i benefici attesi dal progetto e chiarire come e in quale misura essi
contribuiscano al raggiungimento degli obiettivi di miglioramento dell’organizzazione;
− stimare i costi di investimento e di esercizio che bisognerà sostenere e individuare e
valutare i rischi connessi;
− dare concretezza all’ipotesi progettuale delineando, ad un livello di dettaglio
proporzionale all’entità del progetto, come dovrà evolvere il processo di passaggio dallo
stato iniziale allo stato finale considerando alternative differenti.
Scopi di uno studio di fattibilità
„ L’individuazione delle applicazioni o progetti che
l’azienda intende realizzare non esaurisce il
processo di pianificazione delle tecnologie di
informazione.
„ La realizzazione di un qualunque sistema
informativo rappresenta per una azienda un
investimento che mobilita risorse:
„ finanziarie
„ umane
„ impiantistiche
Gaetanino PAOLONE
Sistemi informativi aziendali
Studio di fattibilità: primo tipo
„ Input: soluzione tecnico organizzativa gia’
data (ad esempio dal bpr)
„ Output:
„
„
„
„
„
„
fattibilita’ della soluzione
rischi
costi
benefici
make or buy
tipo di progetto
Gaetanino PAOLONE
Sistemi informativi aziendali
Studio di fattibilità: secondo tipo
„ Input: diagnosi dell’ esistente
„ Output intermedio:
„
un insieme di soluzioni tecnico organizzative
„ Output finale:
„
„
„
„
una soluzione scelta
analisi comparata della fattibilita’, dei rischi,
dei costi, dei benefici
scelta del make or buy
scelta del tipo di progetto
Gaetanino PAOLONE
Sistemi informativi aziendali
Studio di fattibilità: terzo tipo
„ Input: diagnosi dell’ esistente
„ Output intermedio:
„
un insieme di soluzioni tecnico organizzative
„ Output finale:
„
„
„
analisi comparata della fattibilita’ (senza scelta
della soluzione), dei rischi, dei costi, dei
benefici delle diverse soluzioni
scelta del make or buy
scelta del tipo di progetto
Gaetanino PAOLONE
Sistemi informativi aziendali
Possibili conclusioni dello studio di
fattibilità
„ Il progetto non si puo’ realizzare
„ Il progetto si puo’ realizzare, ma basta un
intervento organizzativo
„ Il progetto si puo’ realizzare con questa
soluzione, con questi costi, con questi rischi
„ Il progetto si puo’ realizzare, con queste
soluzioni comparate, scegli tu
Gaetanino PAOLONE
Sistemi informativi aziendali
La necessità di svolgere uno studio di fattibilità può scaturire da situazioni differenti, pertanto a
seconda della circostanza che induce allo studio si avranno output diversi.
Studio di fattibilità e “progetti impossibili”
„ Sono “impossibili” quei progetti per i quali la distanza tra stato iniziale e
stato finale è troppo elevata per garantire livelli di rischio accettabili.
„ In genere tale distanza deriva:
da insufficienti elementi di conoscenza della situazione
da un elevato grado di incertezza
„ da un elevato grado di complessità
„ Per superare tale situazione lo SF può:
„ modificare lo stato iniziale (recuperando e incrementando la
conoscenza della situazione attuale, diminuendo incertezza o
governando la complessità), attreverso sue specifiche attività
„ “spezzare” il progetto prevedendo progetti parziali (evolutivi in caso
di incertezza o incrementali in caso di complessità) al posto del
progetto unico
„ prevedere un piano di lavoro che comprenda specifici punti di
decisione (in tal caso il progetto deve prevedere modalità
contrattuali coerenti)
„
„
Gaetanino PAOLONE
Sistemi informativi aziendali
SF come strumento per migliorare i progetti
„ AIUTA LA VALUTAZIONE DEI PROGETTI E DELLE PRIORITA’
„ CHIARIFICA E DETTAGLIA GLI OBIETTIVI
„ MODIFICA LO STATO INIZIALE AUMENTANDO IL LIVELLO DI
CONOSCENZA
„ SPINGE AD UNA VISIONE NON SOLO TECNOLOGICA
„ FORNISCE IL QUADRO DI RIFERIMENTO DI PARTENZA PER LA
GESTIONE DEL PIANO DEI RILASCI, DELLE ATTIVITA’, DEI RISCHI
E PER LA VERIFICA DEI RISULTATI
„ DIMINUZIONE DELL’INCERTEZZA
„ GOVERNO DELLA COMPLESSITA’
„ ATTIVAZIONE DEL CONTROLLO DEL PROGETTO
RYYHUR
DIMINUZIONE DEI RISCHI
Gaetanino PAOLONE
Sistemi informativi aziendali
La qualità del prodotto/servizio
Occorre sempre ricordare che il sistema informatico
fornisce un servizio al sistema organizzativo: la
qualità può perciò essere misurata a vari livelli
Sistema informatico
Sistema informativo
Sistema organizzativo
Utenti interni
Utenti esterni
Sistema informatico
Percezioni della qualità
„ Utente: interessato alla QUALITÀ ESTERNA, relativa
alle modalità d’uso, alle prestazioni e agli effetti
derivanti dall’uso del software.
„ Sviluppatore: interessato alla QUALITÀ INTERNA,
relativa aagli aspetti tecnici legati allo sviluppo e alla
manutenzione del software.
„ Gestore del sistema: interessato agli aspetti di qualità
relativi ad installazione, configurazione ed esercizio
del sistema.
„ Committente: interessato alla QUALITÀ GLOBALE,
considerata come media pesata dei diversi aspetti di
qualità. Il sistema di pesatura dipende dal tipo di
sistema e dal tipo di organizzazione.
Gaetanino PAOLONE
Sistemi informativi aziendali
Valutazione delle alternative
Programma complessivo di
cambiamento
Risolto a monte in fase di pianificazione
Requisiti
Inesistenti, poiché derivati direttamente a
partire dalle esigenze e dagli obiettivi
Specifiche generali del
sistema
Oggetto dello studio di fattibilità
Modalità e specifiche
realizzative
Demandate alle offerte dei fornitori
Modalità realizzative “minori”
A proposito delle alternative da valutare in fase di studio di fattibilità, esse riguardano soluzioni
differenti in termini di:
− specifiche generali del sistema: che definiscono la natura della soluzione a livello di
architettura tecnologica -sistema centralizzato/decentralizzato-, dei dati e funzionale;
− modalità e specifiche realizzative: che modificano la natura strategica della soluzione
incidendo sui costi, sui tempi e sulle caratteristiche di qualità: si tratta di valutare
l’alternativa di acquistare pacchetti disponibili sul mercato, eventualmente da
personalizzare, o procedere ad una realizzazione ad hoc, tenendo conto della possibilità
di recuperare o meno componenti del sistema esistente (scelte make or buy).
Studio di fattibilità: contenuti
„ Situazione attuale;
„ Progetto di massima;
„ Analisi del rischio;
„ Analisi costi-benefici;
„ Progetto proposto;
„ Raccomandazioni per le fasi realizzative.
Gaetanino PAOLONE
Sistemi informativi aziendali
I contenuti dello studio di fattibilità variano secondo la natura del progetto analizzato. Tuttavia
risulta possibile la definizione di una struttura di riferimento che, con gli opportuni adattamenti, si
applica ad un ampio spettro di casi.
Tipicamente la struttura prevede sei sezioni: la situazione attuale, il progetto di massima,
l’analisi del rischio, l’analisi costi-benefici, il riepilogo del progetto proposto e le raccomandazioni
per le fasi realizzative.
Studio di fattibilità: la situazione attuale
1. Progetto di reingegnerizzazione:
Modello di business
2. Progetto di automazione:
Modello di business
Analisi portafoglio applicativo
3. Progetto di creazione:
Analisi di modelli similari.
Studio di fattibilità: la situazione attuale
La situazione attuale
Il contesto dello studio
•Ripresa della visione strategica in termini di servizi, organizzazione, tecnologia;
•Ripresa dei principali passaggi che hanno portato all’individuazione del progetto;
•Collocazione del progetto all’interno del piano di informatizzazione.
Descrizione della problematica
•Descrizione e rilevanza del problema/opportunità;
•Esigenze da soddisfare (rispetto a utenti interni e esterni).
Descrizione della situazione attuale del sistema informativo
•Individuazione e rappresentazione dei processi coinvolti;
•Individuazione e rappresentazione dei flussi informativi;
•Individuazione e rappresentazione della struttura organizzativa e dell’utenza coinvolta;
•Attuale livello di automazione.
Analisi e diagnosi della situazione attuale
•Individuazione dei fenomeni che costituiscono le cause del problema;
•Collocazione di tali fenomeni sulle diverse componenti del processo di servizio;
•Individuazione di metriche atte a rappresentare dei fenomeni critici e la loro evoluzione;
•Misurazione della situazione attuale.
Identificazione dei vincoli
•Quadro normativo di riferimento;
•Vincoli tempoprali e altri vincoli (economici, organizzativi, ...)
Definizione degli obiettivi del progetto
Il documento si apre con il paragrafo relativo al contesto di studio che serve ad inquadrare il
progetto analizzato nell’ottica più generale della strategia di sviluppo del sistema informativo. Si
tratterà pertanto di riprendere la visione strategica in termini di servizi, organizzazione e utilizzo
della tecnologia e, alla luce di ciò, illustrare brevemente il percorso che ha condotto
all’individuazione del progetto evidenziando gli aspetti più critici che motivano lo studio di
fattibilità intrapreso.
Il paragrafo di descrizione della problematica illustra i problemi o le opportunità da cui
scaturisce il progetto indicandone la rilevanza e stabilendone esattamente i confini. Sempre in
questa sezione è essenziale specificare le esigenze e le attese dell’utenza rispetto alla soluzione
progettuale in esame (aspetto questo che verrà ripreso al termine della realizzazione del progetto al
fine di verificare in che misura sono state soddisfatte le esigenze degli utenti).
Il paragrafo di descrizione della situazione attuale è di fondamentale rilevanza dal momento
che le successive fasi di analisi considereranno lo stato attuale qui descritto come base di partenza
per la stima dei rischi da assumere, dei costi da sostenere e dei benefici che sarà possibile trarre
dalla sua evoluzione futura. In particolare per la rappresentazione dei processi e dei flussi
informativi si può ricorrere ad un’ampia gamma di modelli già visti, mentre per l’individuazione
dell’utenza impattata e di come si distribuisce sulle varie strutture organizzative possono essere utili
sia un funzionigramma dell’organizzazione sia matrici di relazione tra processi e strutture
organizzative che evidenzino anche il livello di responsabilità nel processo delle varie strutture e il
livello di convolgimento. Infine per la descrizione dell’attuale sistema di automazione è opportuno
ricorrere alle consuete notazioni per la rappresentazione dell’architettura applicativa e tecnologica.
Il paragrafo di analisi e diagnosi della situazione attuale approfondisce la precedente
descrizione evidenziando i fenomeni critici su cui intervenire, individuandone le cause, da collocare
sulle varie componenti di processo, e definendone le metriche atte a misurarli. Per l’analisi e la
diagnosi di processi e di strutture organizzative esistono una pluralità di approcci, metodi e
tecniche. Tra di essi figurano approcci e metodi basati sull’esame della catena del valore (Activity
Based Costing), approcci e metodi orientati all’esame dei fattori critici di successo, approcci e
metodi derivanti dall’approccio totale alla qualità, approcci e metodi basati sull’utilizzo sistematico
del confronto con altre situazioni (benchmarking).
Il paragrafo di identificazione dei vincoli identifica e descrive le condizioni di ambiente non
modificabili che caratterizzano la situazione attuale: tali vincoli, appunto, possono essere di varia
natura, giuridico-amministrativa, economica, organizzativa o temporale. In questa sezione occorre
inoltre esplicitare le condizioni di necessaria invarianza in termini di distribuzione delle
responsabilità sui prodotti/servizi erogati, di coinvolgimento delle strutture organizzative, di numero
e di caratteristiche delle risorse da impiegare a regime e quant’altro risulti necessario. La delicata
opera di integrazione tra le spinte al cambiamento con i limiti imposti dalla situazione attuale che
prende forma proprio in questa sezione è una delle cause più comuni del fallimento dei progetti e
del loro mancato raggiungimento dei benefici attesi.
Infine nel paragrafo di definizione degli obiettivi del progetto gli obiettivi vanno espressi in
forma quantitativa e faranno riferimento a costi, tempi e caratteristiche qualitative misurabili. E’
quindi necessario descrivere gli obiettiv i e collegare ad ognuno di questi la metrica da utilizzare per
la verifica del suo raggiungimento, i valori attuali e quelli obiettivo, eventualmente scadenzati nel
tempo.
Il progetto di massima: livello di aggregazione
„ Lo studio di fattibilità deve essere realizzato a un
livello di dettaglio tale da rispondere ai quesiti per
cui è stato richiesto, quindi:
„
lo studio di fattibilità dovrà essere svolto un elevato
livello di aggregazione (intendendo che non tutte le
componenti del SI dovranno essere completamente
scomposte e descritte);
„
dovranno essere studiate solo le funzionalità
principali e i casi di utilizzo standard;
„
lo studio potrà riguardare solo la porzione più
importante del SI che presenta le principali criticità e
su cui incombono i principali dubbi.
Gaetanino PAOLONE
Sistemi informativi aziendali
Il progetto di massima consiste in una descrizione generale del sistema informativo previsto ad
un livello di dettaglio caratterizzato da un alto grado di aggregazione e generalizzazione e, dal punto
di vista della completezza, da un grado di definizione del progetto caratterizzato da un’estensione
parziale e non totale. Una simile scelta è dovuta essenzialmente al fatto che l’elaborazione del
progetto di massima all’interno dello studio di fattibilità risponde prima di tutto all’esigenza di
verificare la fattibilità e di stimare costi, benefici e tempi, ragion per cui la descrizione del progetto
sarà necessariamente ad uno stadio di definizione non esaustivo.
Studio di fattibilità: il progetto di massima
Il progetto di massima
Requisiti della soluzione
•Dettaglio del progetto previsto (dopo la reingegnerizzazione);
•Interventi previsti sulle componenti non informative del processo;
•Necessità di modifica della normativa;
•Requisiti del sistema informativo da realizzare: informazioni trattate, funzioni informatizzate,
modalità di lavoro, requisiti architetturali, requisiti di qualità.
Specifiche generali del sistema
•Specifiche applicative: architettura dati e architettura applicativa con esame e valutazione delle
eventuali alternative, interfaccia utente;
•Specifiche tecnologiche : architettura tecnologica, ambiente e strumenti di sviluppo con esame e
valutazione delle eventuali alternative.
Modalità di realizzazione
•Realizzazione o acquisizione con esame e valutazione delle eventuali alternative;
•Riuso di componenti esistenti con esame e valutazione delle eventuali alternative;
•Avvio del sistema;
•Esercizio e manutenzione del sistema con esame e valutazione delle eventuali alternative;
•Formazione e assistenza utenti.
Gaetanino PAOLONE
Sistemi informativi aziendali
Il progetto di massima sarà suddiviso in tre sezioni: la prima relativa ai requisiti della soluzione,
la seconda contenente le specifiche generali del sistema e l’ultima sulle modalità di realizzazione da
adottare.
In particolare bisognerà anzitutto dettagliare la soluzione, ossia esporre quanto prodotto dalla
reingegnerizzazione dei processi di servizio allo stato attuale. Naturalmente, prima di procedere alla
descrizione dei requisiti essenziali a cui il nuovo sistema informativo dovrà rispondere in termini
di informazioni trattate, funzioni informatizzate, modalità di lavoro previste, elementi architetturali
e caratteristiche qualitative da rispettare, sarà opportuno dedicare un paragrafo alla descrizione degli
interventi che bisognerà intraprendere in
fase realizzativa, sia che riguardino le componenti
informative sia quelle organizzative del processo.
Nella sezione relativa alle specifiche generali del sistema vanno evidenziate le caratteristiche
applicative e tecnologiche che sono essenziali per rispondere ai requisiti individuati. Oltre alla
specifica sui dati e sulle funzioni, di particolare interesse poiché essenziale per garantire
l’apprendibilità e la facilità d’uso della nuova soluzione, è la specifica dell’interfaccia utente che
riguarderà le modalità di presentazione e di navigazione all’interno delle applicazioni, la robustezza
del sistema rispetto ad operazioni improprie, la sicurezza. In questa fase, inoltre, si apre la questione
relativa alle alternative architetturali in termini tecnologici tra le quali quella più critica, in quanto
impatta più significativamente sui costi, riguarda la scelta tra il sistema centralizzato e quello
distribuito. Nello stesso tempo sarà necessario che lo studio espliciti i criteri con cui verranno
valutate le varie alternative, distinguendo tra criteri di qualità e criteri economici. Infine è
importante un riepilogo sintetico con l’esplicitazione della scelta proposta.
Il progetto di massima si conclude con la sezione dedicata alle modalità di realizzazione da
adottare. Il gruppo di lavoro, una volta definiti i requisiti di sistema che si deve realizzare, dovrà
esaminare innanzitutto l’offerta di mercato, selezionando un numero limitato di possibili fornitori e
vagliandone le proposte, e valutare in maniera comparata queste possibilità con la realizzazione exnovo (make or buy). In secondo luogo bisognerà valutare l’eventualità di un affidamento all’esterno
delle attività di conduzione, gestione e manutenzione del sistema informativo, nota come
outsourcing. Anche in questo caso è legittimo che lo studio di fattibilità affronti la questione sulla
base di un confronto in termini economici e di qualità.
A completamento della descrizione delle modalità di realizzazione, bisognerà risolvere un’altra
questione essenziale, ossia quella riguardante il riuso delle componenti esistenti a livello di
apparecchiature, dati e software applicativi. Tra tutti quello più critico è l’aspetto legato al riutilizzo
delle componenti software. In questo caso lo studio di fattibilità dovrà approfondire, con il dettaglio
sufficiente per una scelta ragionata, lo stato delle applicazioni che è possibile incorporare nel nuovo
sistema e decidere tra una semplice ristrutturazione o una vera e propria riprogettazione integrale.
Inoltre sempre in questa sezione si esaminano le problematiche relative alla messa in produzione
e all’avvio del nuovo sistema, nonché le necessità e le iniziative di formazione e assistenza degli
utenti.
Studio di fattibilità: analisi del rischio
Analisi del rischio
Fattori di rischio del progetto
•Complessità:
-complessità gestionale,
-dimensioni del progetto,
- altri fattori;
•Incertezza:
-incertezza dei requisiti,
-innovazione tecnologica.
Analisi del rischio di progetto
Modalità di gestione del rischio
Gaetanino PAOLONE
Sistemi informativi aziendali
Il rischio connesso a un progetto è dato dall’esistenza di eventi capaci di pregiudicare il buon
esisto del progetto come la sua mancata conclusione, l’ottenimento di prodotti difettosi, la
lievitazione dei costi, l’allungamento dei tempi o la difficile integrazione con il restante sistema
informativo. Pertanto uno dei compiti essenziali dello studio di fattibilità è quello di evidenziare i
rischi più importanti di un progetto e soprattutto di individuarne le cause allo scopo di indicare le
contromisure che devono essere intraprese nella gestione del progetto. Pertanto l’analisi del rischio
si esplica attraverso tre passi fondamentali:
1. individuazione dei principali fattori di rischio del progetto imputabili alla complessità e
all’incertezza dei requisiti o derivanti dall’uso di una nuova tecnologia, facendo
riferimento allo specifico contesto applicativo e organizzativo (rischi organizzativi) e al
sistema informatico (rischi tecnici);
2. valutazione sistematica di tutti i fattori di rischio individuati. La modalità operativa più
diffusa consiste nell’attribuire ad ogni fattore di rischio un coefficiente qualitativo (alto,
medio, basso) che classifica l’importanza di ogni singolo fattore e di ogni classe di
fattori;
3. definizione di una strategia che consente la gestione del rischio ai fini del buon
andamento del progetto. Tra le azioni possibili assumono particolare importanza le scelte
di segmentazione del progetto, la definizione dei punti di decisione e le modalità di
controllo del progetto.
Principali fattori di rischio
Fattore di rischio
Parametri
Interfunzionalità
Interventi su organizzazione e ruoli
Complessità
gestionale
Interventi su procedure di lavoro
Livello di inesperienza dell’utente sulla problematica
Livello di inesperienza dell’azienda sulla problematica
Partecipazione e supporto direzionale
Utilizzo di nuovo hardware
Innovazione
tecnologica
Utilizzo di nuovo software di ambiente
Utilizzo di soluzioni in ambiente TLC
Necessità di software ad hoc
Dimensione del
progetto
Numero di persone (es.basso [0,2], medio [3,6], alto [>6] )
Durata totale (utenti interni, esterni) espressa in mesi-uomo (es.basso [0,12],
medio [13,24], alto [>24] )
Dimensione economica:impegno economico espresso in milioni di €
Incertezza sui
requisiti
Stabilità dell’ambiente e dei processi
Disponibilità, chiarezza e stabilità dei requisiti
Livello di formalizzazione dei processi e delle procedure aziendali
Studio di fattibilità: il progetto proposto
Il progetto proposto
Segmentazione del progetto
•Realizzazione/installazione in soluzione unica;
•Realizzazione/installazione incrementale;
•Realizzazione/installazione evolutiva.
Riepilogo delle acquisizioni e realizzazioni previste
Piano di massima del progetto
•Piano dei rilasci;
•Punti di controllo;
•WBS, Pert, Gantt
Gaetanino PAOLONE
Sistemi informativi aziendali
Le scelte sulla segmentazione del progetto determinano la definizione puntuale e concreta del
progetto realizzativo comprensivo di un piano dei rilasci, dell’evidenza dei punti di decisione
previsti e di un piano di massima delle attività.
I criteri di segmentazione ossia i possibili approcci con cui affrontare le problematiche relative
alle fasi di realizzazione e installazione sono:
− realizzazione/installazione in soluzione unica: il nuovo sistema informativo viene
realizzato/installato
in
un’unica
versione,
generalmente
con
un’unica
attività
continuativa;
− realizzazione/installazione incrementale: la realizzazione/installazione avviene per parti
successive ciascuna delle quali contiene un sottoinsieme delle funzionalità e dei servizi
previsti. In questo caso i requisiti del sistema sono completamente definiti prima della
realizzazione iniziale e non variano nel corso delle successive installazioni;
− realizzazione/installazione evolutiva: la realizzazione/installazione avviene per versioni
successive, in cui ogni versione può contenere o tutte le funzionalità o un loro
sottoinsieme. In questo caso i requisiti del sistema possono essere variati tra due
successive versioni, dopo aver appreso nuove informazioni dal collaudo della versione
precedente.
Per la scelta tra i vari approcci si utilizzano dei procedimenti euristici basati sulle considerazioni
su incertezza e complessità derivanti dall’analisi del rischio, nonchè, naturalmente, dalla situazione
delle scadenze normative e contrattuali. In genere l’approccio evolutivo è indicato quando la
situazione è incerta, mentre l’approccio incrementale è adeguato a situazioni complesse ma non
incerte. Inoltre gli approcci incrementale e evolutivo sono da preferirsi quando ci sono tempi stretti,
ossia è necessario realizzare qualcosa al più presto, tipicamente per rispondere in tempo a nuove
esigenze normative.
Una volta fissati i criteri di segmentazione, il progetto realizzativo proposto risulta definito,
pertanto è possibile riepilogare definitivamente le attività realizzative, di cui si propone
l’immediata attivazione, e le acquisizioni previste. In ultimo, a completamento del progetto, si
illustra il piano di massima che costituirà la base di partenza per la stesura della prima versione del
piano di progetto.
Studio di fattibilità: analisi costi-benefici
Analisi costi-benefici
Valutazione dei benefici attesi
•Individuazione e descrizione dei benefici attesi;
•Individuazione ed esplicitazione delle metriche e dei valori attesi;
•Correlazione obiettivi-benefici.
Stima dei costi
•Individuazione delle principali voci di costo;
•Esplicitazione delle metriche utilizzate;
•Stima dell’impegno delle risorse umane;
•Stima dei costi di impianto e di esercizio.
Analisi dell’investimento
Gaetanino PAOLONE
Sistemi informativi aziendali
In questa fase di analisi si parte anzitutto con la valutazione dei benefici attesi, sia quelli
monetizzabili che quelli riconducibili in qualche modo alla modifica di un fenomeno osservabile e
quantificabile, esplicitando le metriche utilizzate per la loro misurazione, dichiarando i valori attesi
e correlando i benefici individuati con gli obiettivi generali del progetto espressi in precedenza.
Analogamente, il paragrafo successivo, dedicato alla stima dei costi di progetto, prevede
l’individuazione delle principali voci di costo, l’esplicitazione delle modalità di stima utilizzate e il
riepilogo della stima effettuata, sia come costi di realizzazione e d’impianto che come costi di
esercizio, riferita allo stesso periodo già utilizzato per la quantificazione dei benefici.
In questo modo sarà possibile effettuare il confronto tra i benefici e i costi associati al progetto
sul quale, da un lato, si basa la scelta tra possibili alternative e, dall’altro, è possibile basare una
giustificazione economica all’investimento necessario in fase decisionale.
Individuazione dei benefici
„ Benefici monetizzabili : quelli a cui è possibile
associare direttamente un valore di tipo monetario;
„ Benefici misurabili : pur non essendo possibile
associrgli direttamente un valore economico è
necessario individuare dei misuratori tramite i quali
si possa quantificarne il loro valore.
„
„
E’ necessario definire l’istante temporale a cui fare
riferimento attualizzando costi e benefici rispetto a tale
data.
Avendo a disposizione dati comparabili sarà possibile
effettuare un’analisi comparativa che indichi quale sarà la
redditività del progetto.
Gaetanino PAOLONE
Sistemi informativi aziendali
La stima dei costi
„ Costi per tipologia di risorsa:
„
„
„
„
costi delle tecnologie (hardware e software);
costi del personale;
costi dei servizi esterni;
altri costi.
„ Costi per missione:
„
„
costi di sviluppo;
costi di esercizio.
„ Costi interni ed esterni
Gaetanino PAOLONE
Sistemi informativi aziendali
I costi legati a un Sistema Informativo possono essere classificati utilizzando diversi criteri.
•
Costi per tipologia di risorsa:
− costi delle tecnologie (hardware e software);
− costi del personale: costi del personale informatico dedicato allo sviluppo,
gestione e manutenzione delle applicazioni, assistenza agli utenti, pianificazione e
amministrazione;
− costi dei servizi esterni: sono i costi legati a tutte le attività di manutenzione e
assistenza agli utenti;
− altri costi: non legati direttamente alle tecnologie informatiche (es.immobili,
materiali di consumo, ecc.).
•
Costi per missione:
− costi di sviluppo: tra i quali si distinguono i costi di costruzione (per la
progettazione e la realizzazione dunque gli oneri necessari per ottenere il sistema
da utilizzare) e i costi di avviamento (oneri legati alle attività per mettere in
esercizio il sistema acquisito);
− costi di esercizio: costi necessari per il corretto funzionamento dei sistemi e
l’utilizzo delle applicazioni da parte degli utenti.
Normalmente i costi di esercizio rappresentano il 70%-80% di tutti i costi informatici di
un’azienda (fonte Gartner Group).
•
Costi interni ed esterni:
− costi interni: tra i quali si distinguono i costi interni diretti (costi del personale
tecnico informatico impegnato nelle attività di sviluppo e di esercizio del sistema)
e i costi indotti (costi legati alle attività svolte dagli utenti finali per attività
connesse al progetto come ad esempio il tempo impiegato dagli utenti a caricare i
dati negli archivi, oppure a imparare l’utilizzo di un applicativo);
− costi esterni: sono relativi all’acquisizione di prodotti hardware e software e dei
servizi affidati a società esterne anziché svolti internamente.
La stima dei costi
Principali
voci di
costo
Quantificazione delle risorse
Valorizzazione
Costi
hardware
Dimensione degli impianti richiesti a partire dalle
caratteristiche funzionali, dai volumi elaborativi e
dalle prestazioni richieste dal sistema (capacity
planning).
•Valore di listino per fascia o
per specifica configurazione
+ sconti volume;
•Prezzo di mercato per unità
prestazionale (MIPS, GB).
Costi di
sviluppo
software
Dimensionamento dell’impegno in tempo uomo a
partire dalle caratteristiche qualitative e quantitative
del sistema da realizzare.
Vlorizzazione del tempo
uomo impeganto a costi
standard o tariffe di mercato.
Costi di
avviamento
Dimensionamento dell’impegno in tempo uomo a
partire dall’analisi delle singole attività pianificate.
Valorizzazione del tempo
uomo impegnato a costi
standard o tariffe di mercato.
Costi di
gestione dei
sistemi
Dimensionamento dell’impegno in tempo uomo a
partikre dall’analisi delle singole attività pianificate
sulla base delle caratteristiche qualitative e
quantitative dei sistemi da gestire e dei livelli di
servizi richiesti + altre risorse usate nell’erogazione
del servizio.
Valorizzazione del tempo
uomo impegnato a costi
standard o tariffe di mercato
+ valorizzazione altre risorse
utilizzate.
% del prezzo dell’hardware e
del software in
manutenzione.
Costi di
manutenzione
I procedimenti di stima e di valorizzazione dei costi varia a seconda del tipo di costo.
Studio di fattibilità: raccomandazioni per le fasi realizzative
Raccomandazioni per le fasi realizzative
Indicazioni per l’approvvigionamento
•Criteri per la determinazione della tipologia di fornitori;
•Criteri di selezione delle offerte;
•Indicazioni sulle modalità di approvvigionamento.
Indicazioni per la gestione del progetto
•Indicazioni per la gestione del piano di qualità;
•Indicazioni sul Project Management;
•Esigenze di negoziazione delle varianti.
Gaetanino PAOLONE
Sistemi informativi aziendali
In primo luogo si sviluppano le indicazioni per l’approvvigionamento che consistono non solo
nelle informazioni necessarie alla stesura dell’allegato tecnico al capitolato ma comprendono anche
i criteri per la determinazione della tipologia di fornitore, le modalità di approvvigionamento più
adeguate e i criteri di selezione delle offerte.
Si sottolinea che, per quanto concerne il capitolato tecnico, l’obiettivo è quello di porre le
aziende candidate nelle migliori condizioni possibili per esprimere la loro proposta e la loro offerta,
al fine di ottenere il meglio dal mercato. Pertanto sarà necessario fornire un quadro di chiarezza che
eviti incomprensioni e minimizzi esclusioni senza tuttavia giungere ad una definizione troppo
formale e definitiva del testo di capitolato e/o di contratto. Per quanto riguarda invece i criteri per la
determinazione della tipologia del fornitore, si parte dalla natura della fornitura richiesta per
giungere alla definizione delle caratteristiche preferibili dei fornitori in termini di solidità
finanziaria, dimensione e localizzazione, tipologia di prodotti/servizi offerti e capacità di
innovazione tecnologica, che poi potranno tradursi in requisiti vincolanti e in parametri di
valutazione delle offerte.
L’insieme delle raccomandazioni sulla tipologia del fornitore e sui criteri di valutazione delle
offerte conduce naturalmente anche a raccomandazioni sulla modalità di approvvigionamento, ossia
della scelta tra le varie procedure possibili.
Nell’ultimo paragrafo saranno elencate le indicazioni per la gestione del progetto realizzativo
derivanti principalmente dalla valutazione del rischio e dalle considerazioni sul piano di massima
del progetto.Gli elementi in generale più critici sui quali vale la pena soffermarsi con maggiore
attenzione riguardano essenzialmente la gestione del piano di qualità, l’organizzazione e la gestione
del progetto, le esigenze e le modalità di negoziazione delle varianti.
Per finire lo studio di fattibilità può eventualmente prevedere una sezione di sintesi contenente
tutti gli elementi e gli aspetti utili alla stesura formale del capitolato.
Riassumendo...
Sezione I: Analisi della situazione attuale
•Il contesto di studio
Sezione II: Progetti di massima
•Descrizione della problematica
•Requisiti della soluzione
•Descrizione della situazione attuale del SI •Specifiche generali del sistema
•Analisi e diagnosi della situazione attuale •Modalità di realizzazione
•Identificazione dei vincoli
Sezione III: Analisi dei rischi
•Definizione degli obiettivi di progetto
•Fattori di rischio del progetto
•Analisi del rischio di progetto
•Modalità di gestione del rischio
Sezione IV: Il progetto proposto
•Segmentazione del progetto
•Riepilogo delle acquisizioni e realizzazioni previste
•Piano di massima del progetto
Sezione VI:
Sezione V: Analisi costi-benefici
Raccomandazioni per le fasi
•Valutazione dei benefici attesi
realizzative
•Stima dei costi
•Indicazioni per
•Analisi dell’investimento
l’approvvigionamento
•Indicazioni per la gestione del
piano di qualità