Raccolta specifiche
Progettazione Large (architettura) e Small (suddivisione in moduli e sottomoduli)
Definizione dell'architettura del sistema (facilitata dall'applicazione di pattern architetturali)
Produce in output documenti di specifica del progetto (in UML se ad oggetti)
Programmazione e unit testing (verifica singola unità)
Ovvero lo sviluppo di un singolo modulo ed il testing dello stesso mediante:
moduli stub moduli fittizzi: simula dei moduli da cui dipende quello esistente (mock objects). Così isolo solo gli errori presenti nel mio modulo.
moduli guida i test veri e propri: dei moduli che chiamano il modulo da testare e ne testano l'output (e gli eventuali errori previsti).
Tecniche di testing (verranno analizzate nella 4a parte):
Analisi statica
Analisi dinamica
Esecuzione simbolica
Debugging
Integrazione continua e test di sistema
Sostituisco i moduli stub e testo l'intera applicazione
Test di accettazione: test dell'utente. Se il viene superato questo test il prodotto é valido.
Se non avessi un cliente devo trovare dei sottoinsiemi indicativi di clienti.
Alpha test: distribuisco a potenziali clienti fidati (in genere interi)
Beta test: distribuisco a dei clienti fidati
Post release:
Manutenzione
Produce in output un versione migliore a quella precedente.
Fasi trasversali:
Documentazione
Scrivere la documentazione mentre si scrive il codice
Verifica e controllo di qualità
Testing e altre verifiche ad hoc
Gestione del processo (manageriale)
Incentivi, assunzioni, responsabilità, eccezioni
Gestione configurazioni
Gestire team e versioni di moduli.
Non deve succedere che un team cambi un una libreria e le cui modifiche blocchino un altro team.
 |
Una dopo l'altra le seguenti fasi:
Requisiti -> Progetto -> Codifica -> Testing -> Prodotto
Sono 5 processi separati e consecutivi (non si può tornare indietro). Ognuno produce documenti che sono l'input della fase successiva.
Questo modello non prevede la manutenzione (disastro!)
Problemi: rigidità, congelamento dei prodotti (stima dei costi fatta solo nelle prime fasi), monoliticità (tengo all'unico rilascio), manutenzione fatta solo sul codice.
Modello a V
 | Le frecce grigie rapperesentano validazioni da parte dell'utente, mente quelle bianche dei controlli da parte del programmatore |
Modello a Fontana
 | Come il modello a cascata, ma ad ogni modifica riparto dall'analisi dei requisiti e procedo via via oltre. |
Modello prototipale
Lavorare molto sulla creazione di un prototipo. Affrontando una prima volta i problemi saprò come affrontarli dopo.
Throw away: una volta fatto andrebbe buttato e il progetto riparte da zero.
L2: La prototipizzazione ridurece sensibilmente le richieste e gli errori di progettazione (specialmente per l'interfaccia utente)
Problemi dei modelli incrementali:
Planning complicato: necessario pianificare tutte le iterazioni
Rischio di caricare troppo la prima iterazione
Rischio di avere troppe iterazioni
Rischio di avere troppe sovrapposizioni tra un'iterazione e l'altra
http://www.rational.com/products/whitepapers/102016.jsp
Modello flipper
E' poco più che una provocazione: completamente indefinito, equivale a nessun modello!
Modelli trasformazionali
Dalle specifiche formali si arriva al prodotto finale tramite dei passi nei quali ogni volta le specifiche vengono specializzate, ottimizzate, rese più concrete, riviste.
Purtroppo sono modelli molto "costosi" in termini di tempo!
Per questo sono applicabili solo a parti di progetti molto critiche.
Usati pochissimo.
Meta-modello a spirale
Basato sui rischi: concentrato sulla valutazione del rischio (di fallimento del progetto, ecc.)
Ogni iterazione é scomposta in 4 fasi:
- Determinazione obiettivi, alternative, vincoli (? progettazione)
- Valutazione alternative, identificazione rischi (? revisione della progettazione)
- Sviluppo e verifica (?sviluppo e test)
- Pianificazione fase successiva
Ogni giro di spirale corrisponde ad un ciclo completo delle 4 fasi (che sono rappresentate nei piani).
Il raggio della spirale (numero di passaggi nelle 4 fasi) corrisponde al costo.
Modello Win Win
Derivato dal modello a spirale, aggiunge 3 fasi per la definizione delle specifiche.
Ci si rende conto che la definizione delle specifiche é come una lotta fra il committente e chi produce. Scopo di questo modello fare sì che alla fine sia il committente, sia chi produce abbiano la sensazione di averla avuta vinta sulle specifiche.
Modello COTS (Componente Off The Shelf)
Conosciuta anche come RAD (Rapid Application Development) o Progettazione per componenti.
Da importanza al riuso di codice tra un progetto ed un altro. Classificare e ricercare i moduli
- Analisi delle richieste
- Analisi dei possibili componenti
- Modifica delle richieste (per cercare di usare componenti trovati)
- Design del sistema concentrandosi sulla riutilizzabilità
- Sviluppo ed integrazione dei componenti
- Validazione del risultato
Le fasi sottolineate sono quelle caratteristiche del modello COTS
Nessun commento:
Posta un commento