Ingegneria del Software - Istituto di Calcolo e Reti ad Alte

Transcript

Redazione e Presentazione
di Progetti Informatici
Corso di Laurea in Informatica
Facoltà di Scienze Matematiche, Fisiche e Naturali
Massimo Ruffolo
E-mail: [email protected]
Web: http://www.icar.cnr.it/ruffolo
Istituto di CAlcolo e Reti ad alte prestazioni
del Consiglio Nazionale delle Ricerche (ICAR-CNR)
Exeura s.r.l. – Spin-off dell’Università della Calabria
Massimo Ruffolo – RPPI 2006/2007
1
Ingegneria del Software
Cenni sulle metodologie:
Zachman Framework
Feature Driven Development
Extreme Programming
COSM
La metodologia Exeura
2
•1
Ingegneria del Software:
Zachman Framework
3
Ingegneria del Software
Il valore di una metodologia sta nell’Approccio strutturato
alla realizzazione di un servizio/prodotto, ciò consente di:
identificare al meglio gli obiettivi intermedi e finali
ottimizzare l’impiego di risorse (risparmiare tempo e
danaro)
controllore i risultati intermedi e finali (non perdere di
vista li obiettivi)
…
4
•2
Zachman Framework
VA En terp rise
Arch itectu re
D AT A
Wh at
F U N C TI ON
How
S C OPE
(C ON TEX TU AL )
T hings Im portant
to the Bus ines s
Proc ess es
Perform ed
Plan n er
Entity = C lass of
Bus iness T hing
EN TER PR I S E
MOD EL
(C ON C EPTU AL )
Sem antic M odel
Own er
S YS TEM M OD EL
(L OGI C AL )
N ETW OR K
W h ere
PEOPL E
Who
TI M E
W h en
M OTI VA TI ON
Why
Im portant
Organiz ations
F unc tion = C lass of
Business Process
N ode = M ajor
Business Locations
People = Major
Organiz ations
T ime = M ajor
Bus iness Ev ent
Ends/Means =
M ajor Bus iness Goals
Business Process
M odel
Business Logis tic s
Sy s tem
Work F low M odel
M as ter Sc hedule
Bus iness Plan
Ent = Bus ines s E ntity
Proc = Bus iness Process
R el = Bus ines s R elationship I/O = Bus iness R es ourc es
N ode = Bus iness Loc ation
Link = Bus iness Link age
People = Organiz ation Unit T ime = Bus iness Ev ent
Work = Work Product
Cy c le = Bus iness Cyc le
End = Bus iness O bjec tiv e
M eans = Business Strategy
Logic al Data
M odel
Dis tributed Sy s tem
Arc hitec ture
Hum an Interface
Arc hitecture
Bus iness R ule
M odel
Applic ation
Arc hitec ture
Ev ents Signific ant
to the B us iness
B ased o n wo rk b y
Jo h n A. Z ach man
Business
locations
Bus iness Goals
and Strategy
Proc essing
Struc ture
S C OPE
(C ON TEX TU AL )
Ent = Data Entity
R el = Data Relations hip
Proc = Applic ation Func tion N ode = IS F unc tion
People = Role
I/O = U ser View s
Link = Line C haracteris tics Work = Deliv erable
T ime = Sy s tem Ev ent
Cy c le = Proc ess ing Cycle
End = Struc tural Assertion
M eans = Ac tion As sertion
TEC H N OL O GY
MOD EL
(PH YSI C AL )
Phy s ical Data
M odel
Sy s tem
Design
C ontrol
Struc ture
R ule
Des ign
B u ild er
Ent = Segm ent/T able
R el = Pointer/Key
T ime = Ex ec ute
Cy c le = C om ponent Cy c le
End = C ondition
M eans = Ac tion
T im ing
Definition
R ule
Des ign
Data
D ET AI L ED
R EPR ES EN T ATI ON S Definition
(OU T-OF -C ON TE XT)
Pres entation
Arc hitecture
Proc = C om puter F unc tion
I/O = Data Elem ents /Sets
N ode = Hardw are/Softw are People = Us er
Link = Line S pec ific ations Work = Screen F orm at
Program
N etw ork
Arc hitec ture
Sec urity
Arc hitecture
B u ild er
D ET AI L ED
R EPR ES EN T ATI ON S
(OU T-OF -C ON TE XT)
Ent = F ield
R el = Address
Proc = Language S tatem ent N ode = Addres s es
Link = Protoc ols
I/O = C ontrol Block
People = Identity
Work = J ob
T ime = Interrupt
Cy c le = M ac hine Cy cle
End = Sub-C ondition
M eans = Step
F U N C TI ONI N G
EN TER PR I S E
Data
F unc tion
N etw ork
Organiz ation
Sc hedule
Strategy
Ent =
R el =
Proc =
I/O =
N ode =
Link =
People =
Work =
T ime =
Cy c le =
End =
M eans =
F U N C TI ON
How
N ETW OR K
W h ere
PEOPL E
Who
TI M E
W h en
D esig n er
TEC H N OL O GY
M OD EL
(PH YSI C AL )
Su b -C on tracto r
D AT A
Wh at
Own er
S YS TEM M OD EL
(L OGI C AL )
D esig n er
T ec hnology
Arc hitec ture
Plan n er
EN TER PR I S E
M OD EL
(C ON C EPTU AL )
Su b -C on tracto r
F U N C TI ONI N G
EN TER PR I S E
M OTI VA TI ON
Why
5
Zachman Framework
Row 1 – Scope
External Requirements and Drivers
Business Function Modeling
Row 2 – Enterprise Model
What
How
Where
Who
When
Why
Business Process Models
1
Contextual
Contextual
Row 3 – System Model
2
Conceptual
Conceptual
3
Logical
Logical
4
Physical
Physical
5
As Built
As Built
6
Functioning
Logical Models
Requirements Definition
Row 4 – Technology Model
Physical Models
Solution Definition and Development
Row 5 – As Built
As Built
Deployment
Functioning
What
How
Where
Who
When
Why
Row 6 – Functioning Enterprise
Functioning Enterprise
Evaluation
6
•3
Framework Rules
Basic Model = Entities and Relationships
Rule 1:
Relationship
Entity
Columns have no order
Entity
Rule 2:

Each column has a simple, basic model
Rule 3:

Basic model of each column is unique
What
Rule 4:

Each row represents a distinct view
Rule 5:

Each cell is unique
Rule 6:

Combining the cells in one row
How
Where
Who
When
Why
Contextual
Contextual
Conceptual
Conceptual
Logical
Logical
Physical
Physical
As Built
As Built
Functioning
Functioning
What
forms a complete description from
that view
How
Where
Who
When
Why
7
Zachman Framework – Row 1
Scope/Planner’s View
•
Motivation/Why

Function/How

Data/What
Business goals, objectives and performance
measures related to each function
•
•
External Requirements and Drivers
Business Function Modeling
High-level business functions
What

High-level data classes related to
each function
People/Who
Stakeholders related to each function
Network/Where
VA locations related to each function
1
How
Where
Who
When
Why
Contextual
Contextual
Conceptual
Conceptual
Logical
Logical
Physical
Physical
As Built
As Built
Functioning

Time/When
Functioning
What
How
Where
Who
When
Why
Cycles and events related to each
function
8
•4
Enterprise Model/Designer’s View
•
Motivation/Why

Function/How
Business processes

Data/What
Business data

Policies, procedures and standards for each
process
•
•
•
Business Process Models
Business Function Allocation
Elimination of Function Overlap and
Ambiguity
What
People/Who
VA roles and responsibilities in each
process
2
Network/Where
VA locations related to each process
How
Where
Who
When
Why
Contextual
Contextual
Conceptual
Conceptual
Logical
Logical
Physical
Physical
As Built
As Built
Functioning

Time/When
Events for each process and sequencing
of integration and process improvements
Functioning
What
How
Where
Who
When
Why
9
System Model/Designer’s View
•

Motivation/Why
VA policies, standards and procedures
associated with a business rule model
Function/How
Logical representation of information
systems and their relationships
•
•
•
Logical Models
Project Management
Requirements Definition
Data/What
Logical data models of data and data
relationships underlying VA information
People/Who
Logical representation of access privileges
constrained by roles and responsibilities
Network/Where
Logical representation of the distributed
system architecture for VA locations
Time/When
Logical events and their triggered responses
constrained by business events and their responses
What
3
How
Where
Who
When
Why
Contextual
Contextual
Conceptual
Conceptual
Logical
Logical
Physical
Physical
As Built
As Built
Functioning
Functioning
What
How
Where
Who
When
Why
10
•5
Technology Model/Builder’s View
•
Motivation/Why
VA business rules constrained by information
systems standards
•
•
•
Physical Models
Technology Management
Solution Definition and Development
Function/How
Specifications of applications that operate
on particular technology platforms

What
Data/What
Database management system (DBMS) type
requirements constrained by logical data models

People/Who
Specification of access privileges to
specific platforms and technologies

4
Network/Where
Specification of network devices and their
relationships within physical boundaries

How
Where
Who
When
Why
Contextual
Contextual
Conceptual
Conceptual
Logical
Logical
Physical
Physical
As Built
As Built
Functioning
Functioning
What
How
Where
Who
When
Why
Time/When
Specification of triggers to respond to system
events on specific platforms and technologies

11
As Built/Integrator’s View
•

Motivation/Why
VA business rules constrained by specific
technology standards
•
•
•
As Built
Configuration Management
Deployment
Function/How
Programs coded to operate on specific
technology platforms
What
Data/What
Data definitions constrained by physical
data models
People/Who
Access privileges coded to control access
to specific platforms and technologies
Network/Where
Network devices configured to conform to
node specifications
5
How
Where
Who
When
Why
Contextual
Contextual
Conceptual
Conceptual
Logical
Logical
Physical
Physical
As Built
As Built
Functioning
Functioning
What
How
Where
Who
When
Why
Time/When
Timing definitions coded to sequence
activities on specific platforms and technologies
12
•6
Functioning Enterprise/User’s View
•
Motivation/Why

Function/How
Functioning computer instructions

Data/What
Data values stored in actual databases

•
•
•
Operating characteristics of specific
technologies constrained by standards
What
People/Who
VA personnel and key stakeholders
working within their roles and responsibilities
Network/Where
Sending and receiving messages
Time/When
Timing definitions operating to sequence
activities
Functioning Enterprise
Operations Management
Evaluation
6
How
Where
Who
When
Why
Contextual
Contextual
Conceptual
Conceptual
Logical
Logical
Physical
Physical
Integrated
Integrated
Functioning
Functioning
What
How
Where
Who
When
Why
13
VA Zachman
Framework Portal
14
•7
Feature Driven Development (FDD)
15
FDD
E’ una via di mezzo fra metodologia leggera e approccio tradizionale
Propone una robusta fase di analisi e progettazione, integrata con un
modello di sviluppo agile
Si focalizza sullo sviluppo di funzionalità "tangibili" per il cliente; di fatto la
Feature è una funzionalità che deve avere un valore per il committente e che
"guida" il ciclo di sviluppo
16
•8
FDD
17
FDD
Ideata da Jeff De Luca e Peter Coad. E’ una via di mezzo
fra metodologia leggera e approccio tradizionale.
Propone una robusta fase di analisi e progettazione,
integrata con un modello di sviluppo agile
E’ una forma di sviluppo “guidata” dalle funzionalità da
realizzare
E’ strettamente basata sull’utilizzo di UML e in particolare
sulla versione “colorata” di UML ideata dagli autori
Sono disponibili diversi strumenti di supporto free, alcuni
anche open source
Esiste una community molto attiva che si occupa di questa
metodologia e dei sui strumenti
18
•9
FDD
Pur essendo molto meno conosciuta di Extreme
Programming è forse il miglior approccio metodologico allo
sviluppo del software
Dal confronto diretto emerge sorprendentemente che
Feature Driven Development è addirittura più flessibile di
Extreme Programming anche se la prima ha una fase di
progettazione “classica” che la seconda elimina proprio per
guadagnarne in flessibilità
19
FDD
I dettagli delle fasi di sviluppo sono pochi e semplici. Un
progetto è diviso in cinque fasi, dette processi:
sviluppare un modello generale
criteri d’ingresso: avere scelto gli esperti del problema, i capiprogrammatori ed il capo-architetto
attività: il project manager deve formare il team di modellazione; il
team di modellazione deve offrire una panoramica del dominio del
problema, preparare i documenti funzionali e, diviso in piccoli gruppi,
sviluppare il modello; il capo-architetto deve rifinire il modello
generale ad oggetti insieme al team di modellazione e scrivere le
note al modello insieme ai capi-programmatori;
verifica: il team di modellazione deve effettuare un accertamento
interno ed esterno con riferimento agli esperti di business ed ai futuri
utenti
criteri d’uscita: avere definito il modello ad oggetti avendo quindi a
disposizione i diagrammi delle classi, i metodi e gli attributi delle
classi, la sequenza delle classi (se esiste), le note al modello
20
•10
FDD
costruire una lista di funzionalità
criteri d’ingresso: avere scelto gli esperti del problema, il capoprogrammatore ed i capi-architetti
attività: il project manager deve formare il team della lista delle
funzionalità che deve comprendere i capi-programmatori del team di
modellazione; il team della lista delle funzionalità deve definire la
lista delle funzionalità in termini di azione-risultato-oggetto
verifica: il team della lista delle funzionalità deve effettuare un
accertamento interno ed esterno con riferimento agli esperti di
business ed ai futuri utenti
criteri d’uscita: avere definito la lista delle funzionalità avendo
quindi a disposizione la lista delle aree oggetto, la lista delle attività
di business per ogni area oggetto, la lista delle funzionalità che
soddisfino tutti i punti di ogni lista delle attività;
21
FDD
Pianificare per funzionalità
criteri d’ingresso: è stato portato a termine il processo “costruire
una lista di funzionalità”
attività: il project manager deve formare il team di progettazione
che comprende capi-programmatori e manager dello sviluppo; il
team di progettazione deve definire la sequenza di sviluppo,
assegnare le attività di business ai capi-programmatori ed assegnare
le classi agli sviluppatori
verifica: il team di progettazione deve effettuare un’autoverifica sul
lavoro svolto
criteri d’uscita: avere definito un piano di sviluppo comprendente
le attività di business con le date di completamento ed i capiprogrammatori responsabili assegnati, la date di completamento
delle aree oggetto (derivate da quelle delle attività di business), la
lista delle classi con relativi sviluppatori
22
•11
FDD
Progettare per funzionalità
criteri d’ingresso: è stato portato a termine il processo “pianificare per
funzionalità”
attività: ogni capo-programmatore forma il team delle funzionalità; ogni
esperto del problema definisce la strada per affrontare il problema e
risolverlo; il team delle funzionalità studia i documenti dei requisiti delle
proprie funzionalità; il team di progettazione sviluppa i diagrammi di
sequenza; il capo-programmatore raffina il modello ad oggetti per definire
se scrivere o modificare classi, metodi, attributi; il team delle funzionalità
scrive le classi e gli header dei metodi
verifica: il team delle funzionalità ispeziona il progetto in tutti i suoi
aspetti funzionali e temporali
criteri d’uscita: avere definito un pacchetto di progettazione completo
che comprenda un documento esplicativo dell’intero progetto con le
specifiche referenziate (se esistono riferimenti), i diagrammi di sequenza,
le alternative di progetto (se esistono), il modello ad oggetti completo di
classi, metodi e attributi, gli header di classi e metodi, una todo list con un
calendario delle scadenze per ogni attività ed ogni membro del team
23
FDD
Sviluppare per funzionalità
criteri d’ingresso: è stato portato a termine il processo “pianificare
per funzionalità” ed è stato ispezionato con successo il progetto in
tutti i suoi aspetti funzionali e temporali
attività: il team delle funzionalità implementa classi e metodi,
ispeziona il codice ed effettua i test unitari; il capo-programmatore
decide (dopo i test unitari) insieme al team delle funzionalità quali
classi siano “promuovibili” come utili alla costruzione del progetto in
riguardo alle funzionalità richieste
verifica: il capo-programmatore sovrintende affinché siano
completate effettivamente in tutti i punti dal team delle funzionalità
l’ispezione dei codici ed la soddisfazione dei test unitari
criteri d’uscita: avere ottenuto classi e metodi che siano stati
ispezionati e testati con successo, infine promossi all’integrazione nel
progetto (ovviamente a copertura di tutte le funzionalità previste
24
•12
FDD
Feature Driven Development non richiede esplicitamente
la stesura di documentazione, ma obbliga all’utilizzo
dei diagrammi UML. Questo per avere una base
decisionale che sia stabile durante tutto il processo di
sviluppo, solo in seconda battuta sarà utile per scrivere una
documentazione formale, se richiesta
Nel corso del progetto ci sono molti documenti che devono
essere disponibili per i diversi attori, quindi la miglior
soluzione è organizzare un sito web interno che
contenga tutte le informazioni sul progetto: la lista di
sviluppatori ed esperti del problema, il modello UML con i
commenti, i forum di discussione, le convenzioni di scrittura
del codice, la lista degli strumenti e delle librerie usate, i
report dei test unitari, lo status del progetto, la timeline
comprensiva della pianificazione futura, ecc...
25
FDD
Durante lo sviluppo, organizzato in iterazioni brevi, si
forma una struttura gerarchica con figure a metà strada
fra il project manager e gli sviluppatori: i capiprogrammatori. Questi sono a capo di ogni singola
iterazione, che quindi possono essere numerose e
procedere parallelamente, scegliendo anche il team
(composto da 3-5 persone) che se ne occuperà
L’esperienza dei capi-programmatori e la frammentazione
del lavoro in iterazioni, sono i meccanismi di controllo e
regolazione di Feature Driven Development. All’inizio di
ogni iterazione si organizzano delle riunioni di
progettazione che servono a far confrontare i membri
del team e ad ottenere la documentazione del codice
26
•13
FDD
La stesura del codice prevede l’utilizzo rigoroso di uno
standard comune di scrittura e il ricorso ad i test unitari,
che possono essere organizzati a discrezione dei capiprogrammatori
Date le numerose riunioni effettuate prima di cominciare a
scrivere il codice, questa attività diventa qualcosa di meccanico,
infatti Feature Driven Development scoraggia l’uso di pratiche
tipo il Refactoring mentre incoraggia la condivisione del
codice prodotto (in maniera particolare della documentazione
relativa) fra i diversi programmatori
Per la revisione del codice si va oltre il Pair Programming visto
che la condivisione all’interno del team dell’iterazione
permette una verifica molto più ampia. In ogni caso è proprio
per permettere la miglior revisione possibile del codice che i team
di sviluppo devono essere poco numerosi e che le iterazioni
devono essere brevi, fra 1 e 3 settimane
27
FDD
Il rilascio delle versioni è previsto per la fine di ogni
iterazione, raramente di più iterazioni, ma ciò permette di
coinvolgere molto di meno il cliente rispetto a quanto
facciano le altre metodologie leggere. E permette anche di
non consegnare alcune versioni intermedie quando le
condizioni al contorno non lo rendano possibile, ad esempio
in caso di software medici embedded
Tenere una traccia dello status del progetto è un compito
reso semplice da Feature Driven Development in quanto si
ha a disposizione sin dall’inizio la lista delle funzionalità da
implementare ed ogni iterazione ha dei pesi ben definiti per
ogni passo
28
•14
FDD
FDD usa Colored UML. Per UML colorato si intende un UML
standard con le classi divise in quattro categorie individuate
da quattro colori diversi:
giallo (indica un Ruolo, ricoperto da persona o da
organizzazione, come ad esempio i differenti tipi di utente di
un servizio)
blu (indica una Descrizione modello-catalogo, ad esempio il
tipo di oggetto in un database ma non il singolo oggetto)
verde (indica un Luogo o un Oggetto, ad esempio il singolo
oggetto del database di prima)
rosa (indica i Tempi, un momento o un intervallo associati ad
un processo, ad esempio ad un azione su di un oggetto del
database)
Le classi ausiliari e le interfacce restano standard e non sono
colorate
29
FDD
30
•15
Extreme Programming (XP)
31
XP
È un insieme di regole di sviluppo software sviluppate
originariamente dal lavoro congiunto di Kent Beck,
fondatore del Three Rivers Institute, e Ward Cunningham
La chiave della metodologia è lavorare fianco a fianco con il
cliente per anticipare i frequenti cambiamenti alle specifiche
e di sviluppare in contemporanea con la scrittura del codice
i test unitari atti a verificare la correttezza dei risultati
restituiti dal codice stesso
32
•16
XP
Si possono individuare dodici regole base di Extreme
Programming:
Progettare con il cliente
Test funzionali e unitari
Refactoring (riscrivere il codice senza alterarne le funzionalità
esterne)
Progettare al minimo
Descrivere il sistema con una metafora, anche per la descrizione
formale
Proprietà del codice collettiva (contribuisce alla stesura chiunque sia
coinvolto nel progetto)
Scegliere ed utilizzare un preciso standard di scrittura del codice
Integrare continuamente i cambiamenti al codice
Il cliente deve essere presente e disponibile a verificare (sono consigliate
riunioni settimanali)
Open Workspace
40 ore di lavoro settimanali
Pair Programming (due programmatori lavorano insieme su un solo computer)
33
XP
James Donovan Wells mantiene una delle risorse più ricche
sull’argomento. Indica in particolare quattro linee guida:
Comunicazione (tutti possono parlare con tutti, persino
l’ultimo dei programmatori con il cliente)
Semplicità (gli analisti mantengano la descrizione
formale il più semplice e chiara possibile)
Feedback (sin dal primo giorno si testa il codice)
Coraggio (si dà in uso il sistema il prima possibile e si
implementano i cambiamenti richiesti man mano).
34
•17
XP
Quattro sono le fasi del progetto, ognuna delle quali con le
sue regole interne:
Pianificazione (User Stories, Release Planning, Small
Releases,
Project
Velocity,
Load
Factor,
Iterative
Development, Iteration Planning, Move People Around, Daily
Stand Up Meeting, Fix XP)
Progettazione (Simplicity, System Metaphor, CRC Cards,
Spike Solution, Never Add Early, Refactoring)
Sviluppo (Customer Always Available, Standards, Unit Test
First, Pair Programming, Sequential Integration, Integrate
Often, Collective Code Ownership, Optimize Last, No
Overtime)
Testing (Unit Test Framework, Bug’s found, Functional Test
o Acceptance Tests).
35
XP
36
•18
COSM
37
COSM
E’ soggetta a copyright
Integra il framework di Zachman e la FDD con
considerazioni provenienti dal mondo del PM e del BPM
Prevede la stesura di una corposa documentazione
E’ centrata sulla realizzazione di architetture SOA
(component based architecture)
38
•19
La Metodologia Exeura
39
La modellazione UML
L’output UML è costituito da un package
chiamato Modello Progettuale contenente:
• un’analisi fisica rappresentata mediante un package
denominato Schema Architettura.
• un’analisi dinamica rappresentata mediante un
package denominato Schema Funzioni e un package
denominato Schema Attori.
• un’analisi statica rappresentata mediante un package
denominato Schema Dati e un package denominato
Schema Viste.
•20
Lo schema funzioni/1
Le funzioni vengono rappresentate
mediante package innestati di
Usecase diagram nei quali vengono
espressi i legami con attori e dati
Lo schema funzioni/2
Gli aspetti dinamici delle funzioni
vengono modellati mediante una serie
di Activity diagram nei quali si
rappresenta la sequenza di esecuzione
degli usecase
41
Lo schema attori
Le figure che interagiscono con il
sistema vengono definite in uno
Usecase diagram che modella anche
le tassonomie dei ruoli
Lo schema architettura
La struttura architetturale del sistema
da implementare viene modellata
mediante Deployment diagram nei
quali si modellano nodi, componenti
e relative interazioni
42
•21
Lo schema dati
La struttura del database sul quale
viene sviluppato il sistema è
modellata in un Class diagram che
rappresenta gli attributi, le tabelle e le
relative relazioni
Lo schema viste
Utilizzando lo stereotipo di viste,
specifiche porzioni di dati vengono
messe a disposizione delle funzioni
che ne faranno uso
43
La modalità di applicazione
La costruzione del modello
progettuale avviene in maniera
incrementale.
Si può iniziare
•
considerando le aree funzionali
richieste per il sistema
•
analizzando le tipologie di utenti
che dovranno essere supportate
con l’implementazione delle nuove
funzionalità.
Anche la progettazione dell’area dei dati e viste è incrementale e parte da una
descrizione a livello abbozzato, per poi passare a uno scheletro di schema
globale in cui si dettagliano le viste che costituiscono il contatto con l’area
funzionale
44
•22
L’ambiente
di lavoro
La modellazione
UML può essere
supportata
utilizzando la
piattaforma
ENTERPRISE
ARCHITECT
fornita dalla
Sparxsystems
www.sparxsystems.com
45
•23