WATERFALL MODEL

Lo sviluppo diviso in fasi, ognuna delle quali teoricamente non pu iniziare prima della conclusione della precedente. Le fasi sono: - ANALISI E DEFINIZIONE DEI REQUISITI - PROGETTAZIONE DEL SISTEMA E DEL SOFTWARE - IMPLEMENTAZIONE E TEST DELLE UNITA - INTEGRAZIONE E TEST DEL SISTEMA - OPERATIVITA E MANTENIMENTO I presupposti sono: - REQUISITI CONOSCIUTI FIN DALLINIZIO - REQUISITI CAMBIANO RARAMENTE - PROGETTAZIONE PURAMENTE ASTRATTA Vantaggi: - OGNI FASE PRODUCE LA SUA DOCUMENTAZIONE - SI ALLINEA AD ALTRI MODELLI DI PROCESSI INGEGNERISTICI Svantaggi: - PRESUPPOSTI NON SEMPRE RISPETTATI - TROPPA DOCUMENTAZIONE; TESTING LONTANO - FLUSSO UNIDIREZIONALE TROPPO RIGIDO - PROBLEMI INIZIALI SI TRASCINANO FINO ALLA FINE (FEEDBACK) - DIFFICILE FARE CAMBIAMENTI

MODELLO CBSE Si fonda su una larga base di componenti prefabbricati. Stadi: - Specifica dei requisiti - Analisi dei componenti - Modifica dei requisiti - Progettazione sistema - Sviluppo e integrazione - Convalida MODELLO A V Variante del Waterfall, costruito a partire da diversi sottomodelli. EVOLUTIONARY DEVELOPMENT Si basa sullidea di sviluppare unimplementazione iniziale (prototipo), esporla ai clienti e perfezionarla di conseguenza, dandone molte versioni fino ad ottenere il risultato cercato. Due tipi: esplorativo e usa-e-getta.

REQUISITI FUNZIONALI I requisiti funzionali sono elenchi di servizi che il sistema deve fornire. Indicano come dovrebbe reagire a particolari input e in particolari situazioni. I requisiti NON funzionali sono vincoli sui servizi o sulle funzioni offerte dal sistema. Se non sono soddisfatti, il sistema inutilizzabile. PROPRIETA EMERGENTI Propriet complessive di un sistema che emergono solo dopo lintegrazione dei componenti. Funzionali: - Appaiono quando i componenti lavorano insieme per un certo obiettivo Non funzionali: - Si riferiscono al comportamento nel suo ambiente operativo Volume, affidabilit, sicurezza CRC CARDS Approccio alternativo per esplorare diverse possibilit di interazione. Fasi: - Distribuire carte allo staff - Simulazione scenario, dato un certo use-case - Eventuali modifiche e aggiunte

CODE AND FIX E un modello di sviluppo del software. Fasi: 1) Scrivere codice 2) Provarlo e correggerlo, per farlo funzionare 3) GO TO punto 1 Non applicabile a grandi progetti per: - Scarsa affidabilit - Cambio di programmatore complica molto le cose - Difficile da mantenere - Pu non rispettare le aspettative dellutente finale, se non il programmatore stesso. RISK MANAGEMENT Riguarda lidentificazione di rischi e la minimizzazione dei loro effetti. Categorie: - PROJECT risks: influenzano la tempistica e le risorse - PRODUCT risks: la qualit o le prestazioni SW - BUSINESS risks: lorganizzazione che sta sviluppando o acquistando SW.

PERT E GANTT PERT una tecnica con la quale si monitorizzano le attivit di un progetto, attraverso una rappresentazione reticolare. Svantaggi: - Non considera la disponibilit delle risorse - E costoso Il diagramma di GANTT un diagramma a barre dove nellasse x si ha il tempo, mentre nellasse y le attivit Con delle barre si indicano le attivit dal momento in cui iniziano alla fine. Con barre ombreggiate si identificano attivit che hanno margine di errore, e di conseguenza non fanno parte del cammino critico. Svantaggi: - Cammino critico non evidente - Non indica relazioni di interdipendenza e vincoli di sequenza.

ALGORITHMIC COST MODELING Costo = A * SizeB * M (organizzazione, valutazione dim. Codice, coeff di costo per progetti grandi, Esperienza del team) COCOMO 81 e COCOMO 2 Modello che collega una metrica (la dimensione del codice) al costo del progetto. Problema: stimare la lunghezza del codice in anticipo difficile. FUNCTION-OBJECT POINTS Entrambi vengono utilizzati per stimare la produttivit del software. Funcion points: - Produttivit espressa in FP per persona ogni mese - Tiene conto di: I/O esterni Interazione utente Interfacce esterne File utilizzati Object points: Stima ponderata di: # di schermate utilizzate # di rapporti prodotti # di program modules

REQUIREMENTS ENGINEERING PROCESS Stabilire i servizi di cui lutente necessita da un sistema e i vincoli sotto i quali questo opera ed sviluppato. Fasi: - Studio di fattibilit - Elicitazione e analisi - Specifica - Convalida

MILESTONE E DELIVERABLES Poich il SW intangibile, sono necessari report e documenti per verificare lo stato del SW. Milestone: - Pietre miliari, punti cardine riconoscibili nel processo software - Ad ognuna associato un report Deliverables: - Documenti per il cliente - Consegnati alla fine di fasi importanti

PCMM (People Comparability Maturity Model) Serve a migliorare la gestione del personale. Obiettivi: - Migliorare organizzazione SW - Fars che il prodotto sia frutto di un lavoro di squadra - Meritocrazia Livelli: - Gestione staff - Sviluppo capacit staff - Gestione staff secondo standard - Obiettivi dello staff - Miglioramento capacit singoli e gruppo TESTING Dei componenti: o Componenti presi singolarmente o Possono essere entit semplici o raggruppamenti Del sistema: o Si integrano i componenti o Si testa il sistema nel complesso, con le propriet che ne derivano Dellaffidabilit: o Si testa il sistema per verificare le aspettative dellutente

TRACCIABILITA Possibilit di ricostruire la relazione fra i diversi documenti prodotti nel corso di un progetto. Tipi: - della sorgente - dei requisiti - del progetto