Progettazione dei sistemi informatici
Gestione dei progetti
CARLO BELLETTINI [email protected]
Organizzazione del corso
✤
3 lezioni:
✤
Presentazione dei processi classici Ingegneria del Software
✤
Presentazione delle metodologie agili
✤
Laboratorio
Alcune riflessioni di metadidattica
✤
Attenzione terminologica
✤
Periodo di attenzione continuativo limitato
✤
Stimolare curiosità ad approfondire
✤
Stimolare il ragionamento
✤
Stimolare la prova diretta
Processi di produzione del sw
✤
Negli anni ’50-’60 si è colta la necessità di superare metodi di
produzione artigianale
✤
Studio quindi di tecniche e metodologie che potessero migliorare e
“assicurare” software di qualità
Principali problemi
✤
Numero e tipo persone coinvolte
✤
✤
✤
il programmatore non è il cliente e questo crea problemi di
comunicazione
Dimensioni del software
✤
milioni di linee di codice
✤
migliaia di anni uomo
SOFTware
✤
malleabilità porta a moltiplicarsi di versioni e evoluzioni
The mythical man/month
https://archive.org/stream/mythicalmanmonth00fred
Fred Brooks
L’approccio ingegneristico
Target
Metric
Method
Process
Tool
Closer to target?
NO
OK
accept
modify
Measurements
Perché studiare un processo?
✤
Convinzione che un buon processo produca un prodotto di qualità
✤
✤
quali sono le qualità a cui miriamo nel software?
✤
che funzioni
✤
che sia bello
✤
che mi faccia diventare ricco
quali sono le qualità del processo che possono influenzare?
Cosa vuol dire “che funziona”
✤
✤
✤
che fa quello che è stato chiesto
R.Glass’ Law (L1):
Requirements deficiences are the prime source of projects failures
✤
CORRETTEZZA
✤
e se mi è stato chiesto qualcosa di sbagliato? incompleto?
che mi posso fidare di lui
✤
AFFIDABILITÀ
✤
come misurarla? rispetto a cosa?
che non fa male
✤
INNOCUITÀ (SAFETY) e/o ROBUSTEZZA
Cosa vuol dire “bello”?
✤
facile da usare
✤
✤
USABILITÀ
veloce
✤
✤
Nielsen-Norman’s Law (L26):
Usability is quantifiable
EFFICIENZA nell’uso delle risorse
pulito
✤
VERIFICABILITÀ
Come fa a farmi diventare ricco?
✤
non rifare qualcosa di già fatto
✤
RIUSABILITÀ di componenti
✤
✤
McIlroy’s Law (L15):
Software reuse reduces cycle time and increases
productivity and quality
minori costi e maggiore affidabilità
semplificare gli interventi post consegna
✤
M. Lehman’s Laws (L27 e L28):
A system that is used will be changed
MANUTENIBILITÀ
An evolving system increases its
✤
correzione errori (RIPARABILITÀ) complexity unless work is done to reduce it
✤
estensione dei requisiti (EVOLVIBILITÀ)
✤
adattamento a nuove situazioni
Come deve essere un processo?
✤
resistere agli imprevisti
✤
✤
veloce
✤
✤
ROBUSTEZZA
PRODUTTIVITÀ
cogliere l’attimo
✤
TEMPISMO
Waterfall Process
✤
Fine anni ‘50, ma diventato “famoso” nei ‘70
✤
Una famiglia di processi
Requisiti
Progetto
Codifica
Testing
Prodotto
Problemi di comunicazione
Pianificare: caso semplice?
Who’s Afraid of The Big Bad Waterfall?
in https://leanpub.com/leprechauns
Fountain Life-Cycle
(Henderson-Sellers 1993)
“Problemi” con modelli incrementali
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/dec00/
FromWaterfalltoIterativeDevelopmentDec00.pdf
✤
✤
Viene complicato il lavoro di planning
✤
Lo stato del processo è meno visibile
✤
Bisogna pianificare tutte le iterazioni
Si riconosce che bisogna rimettere mano a ciò che si è fatto
✤
✤
Il sistema può non convergere
Cosa è una iterazione, quanto dura?
✤
Rischio di voler mettere troppo nella prima iterazione
✤
Rischio di overhead dovuto a troppe iterazioni
✤
Rischio di avere un eccessivo overlapping tra le iterazioni
✤
Non si ha tempo di avere feedback dell’utente
COTS: Component Off The Shelf
Modello prototipale
✤
Prototipo usa e getta (throw away)
✤
Pubblici o esterni
✤
Per capire meglio i requisiti e/o far compiere scelte all’utente
✤
✤
Boehm’s Law (L3)
Prototyping (significantly)
reduces requirements and design
errors,
especially for user interfaces
interfacce
Privati o interni
✤
Per esplorare nuovi strumenti, linguaggi, diverse scelte per problema
difficili
✤
progetti pilota, testbed