Esempio rischi della specifica dei requisiti

Transcript

1 Esempio rischi della specifica dei requisiti PF ChiusuraTBD Operatori soddisfatti Dettagli migliorati Qualità migliorata Problema contratto 0.1 Tutti in un mese In gran parte soddisfatti Redistribuzione specifica Sì Sì 0.3 ¾ in 1.5 mesi ¾ soddisfatti Miglioramento significativo 75% 75% 0.5 ½ in 3 mesi ½ soddisfatti Qualche miglioramento 50% 50% 0.7 ¼ in 4 mesi ¼ soddisfatti Piccoli cambiamenti 25% 25% 0.9 Pochi in 6-9 mesi Ancora scontenti Nessun cambiamento No No

2 Esempio rischi della specifica dei requisiti CF Costo Schedule Performance 0.1 Impatto minimo Minimo Preoccupazione minima 0.3 Incremento del 5% Slittamento di 1 mese Piccola riduzione nella performance 0.5 Incremento del 10% Slittamento di 1-3 mese Qualche riduzione nella performance 0.7 Incremento del 25% Slittamento di 3 mesi Riduzione significativa nella performance 0.9 Incremento del 50% Slittamento di più di 3 mesi Performance insoddisfacente

3 Esempio rischi della specifica dei requisiti Ray stima che PF = ( )/ 5 = 0.34 CF = ( )/3 = 0.5 RF = PF + CF (PF * CF) = (0.34 * 0.50) = 0.67 Un fattore di rischio di 0.67 è moderato, ma vicino al limite 0.7, e sebbene accettabile, non può essere ignorato

4 Esempio rischi della specifica dei requisiti Lista di alcune idee per il piano di contenimento 1. Assegnare alcuni degli migliori ingegneri del software esperti in quell area per assistere gli ingegneri del team nel chiudere i TBD 2. Coinvolgere operatori di esperienza nel lavoro di design 3. Incoraggiare il manager a redistribuire la specifica 4. Rendere noto al cliente del problema potenziale e che cosa si sta facendo per correggere la situazione 5. Negoziare un cambiamento dello schedule 6. Dividere la specifica in due moduli separati e produrli sequenzialmente

5 Seconda Fase del Progetto Raffinamento del modello analitico: definizione dei requisiti, comprensione del dominio delle informazioni, del dominio funzionale e del dominio comportamentale Costruzione modello progettuale: definizione architettura, interfaccia utente e componenti

6 Passi di modellazione analitica Revisione dei requisiti funzionali e non funzionali, delle caratteristiche degli utenti 2. Espansione e raffinamento degli scenari utente. Definizione di tutti gli attori. Rappresentazione del modo in cui gli attori interagiscono con il software Estrazione delle funzioni e delle caratteristiche dagli scenari utente Revisione degli scenari utente per verificarne la completezza e la precisione 3. Modellazione del dominio delle informazioni. Rappresentazione di tutti gli oggetti principali e definizione attributi e relazioni 4. Modellazione del dominio funzionale. Mostrare il modo in cui le funzioni modificano gli oggetti. Raffinamento delle funzioni (introdurre anche possibili sottofunzioni) Revisione dei modelli funzionali

7 Passi di modellazione analitica Modellazione del dominio comportamentale. Identificazione degli eventi esterni che introducono dei cambiamenti comportamentali nel sistema. Revisione dei modelli comportamentali 6. Analisi e modellazione dell interfaccia utente Creazione prototipi delle immagini a schermo 7. Riconsiderazione della completezza, coerenza ed eventuali omissioni per tutti i modelli

8 Principi di modellazione analitica 1. Il dominio delle informazioni di un problema deve essere ben rappresentato e ben compreso 2. Occorre definire le funzioni svolte dal software 3. Occorre rappresentare il comportamento del software, quale conseguenza di eventi esterni 4. I modelli analitici devono essere partizionati 5. Il compito dell analisi deve procedere dalle informazioni essenziali verso l implementazione

9 Passi di modellazione progettuale 1 1. Esaminare il modello del dominio informativo per progettare i dati 2. Utilizzando il modello analitico, selezionare uno stile architettonico appropriato per il software 3. Suddividere il modello analitico in sottosistemi progettuali e allocare questi sottosistemi nell architettura. Assicurarsi che ogni sottosistema sia funzionalmente coeso. Progettare le interfacce del sotto sistema. Allocare le classi o le funzioni di analisi a ciascun sottosistema 4. Creare un insieme di classi o componenti del progetto. Tradurre ogni descrizione di una classe analitica in una classe progettuale. Controllare ogni classe progettuale rispetto a criteri progettuali; considerare problemi di ereditarietà. Definire i metodi e i messaggi associati a ciascuna classe progettuale. Revisione delle classi progettuali 5. Progettare ogni interfaccia necessaria per i sistemi o dispositivi esterni.

10 Passi di modellazione progettuale 1 6. Progettare l interfaccia utente. Specificare la sequenza di attività sulla base degli scenari utente. Creare un modello comportamentale dell interfaccia. Revisione del progetto dell interfaccia. 7. Condurre la progettazione al livello delle componenti. Specificare tutti gli algoritmi a un livello di astrazione basso. Definire le strutture dati al livello dei componenti. Revisione di ciascun componente

11 Principi di modellazione progettuale 1. Il progetto deve essere una conseguenza diretta del modello analitico 2. Considerare sempre l architettura 3. Concentrarsi sul design dei dati 4. Le interfacce (esterne ed interne) devono essere progettate con cura 5. I componenti devono esibire indipendenza funzionale 6. I componenti non devono presentare accoppiamento stretto 7. I modelli di design devono essere facilmente comprensibili

12 Specifica architetturale Lo scopo primario di questo documento è la descrizione architetturale del sistema. Introduzione Glossario Descrizione generale e contesto d uso del prodotto Definizione del prodotto Disegno generale dell architettura Decomposizione funzionale (top-down) generica Decomposizione ad oggetti Casi d uso Modellazione strutturale Modellazione dinamica e comportamentale Breve descrizione dei singoli componenti Tipo e funzione dei componenti Interfaccia e dati trattati Relazioni con altri componenti Relazione della specifica con i requisiti

13 Modello analitico -> Modello progettuale sc e na r i o- ba se d e l e me nt s use-cases - text use-case diagrams activity diagrams swim lane diagrams Analysis Model f l ow- or i e nt e d e l e me nt s data flow diagrams control-flow diagrams processing narratives In t e rf a c e D e sig n Co m p o n e n t - L e v e l D e sig n c l a ss- ba se d e l e me nt s class diagrams analysis packages CRC models collaboration diagrams be ha v i or a l e l e me nt s state diagrams sequence diagrams A rc h it e c t u ra l D e sig n D a t a / Cla ss D e sig n Design Model

14 Qualità della progettazione 1. Un progetto deve esibire una struttura di architettura che (a) sia stata creata utilizzando modelli di progettazione riconoscibili (b) sia costituita da componenti che esibiscono buone caratteristiche di progettazione 2. Deve essere modulare 3. Deve contenere una rappresentazione distinta dei dati, dell architettura delle interfacce e dei componenti 4. Deve condurre a strutture dati che siano appropriate per il modello da implementare 5. Deve condurre ad interfacce che riducano la complessità delle comunicazioni fra moduli ed ambiente esterno

15 Concetti fondamentali Astrazione (la soluzione viene espressa a grandi linee): astrazione procedurale, dei dati Architettura: organizzazione dei componenti del programma, il modo in cui questi componenti interagiscono e la struttura dei dati utilizzati dai componenti Pattern: struttura progettuale per la risoluzione di una classe di problemi simili Modularità: attributo del software qualora sia suddiviso in più componenti detti moduli Information hiding: i moduli comunicano fra loro le sole informazioni necessarie Indipendenza funzionale: i moduli hanno funzione unica Raffinamento: introduzione di dettagli Rifattorizzazione: tecnica di riorganizzazione che semplifica il design

16 Dal modello analitico al progettuale high a na ly sis mode l class diagrams analysis packages CRC models collaborat ion diagrams dat a f low diagrams cont rol-f low diagrams processing narrat ives use-cases - t ext use-case diagrams act ivit y diagrams sw im lane diagrams collaborat ion diagrams st at e diagrams sequence diagrams class diagrams analysis packages CRC models collaborat ion diagrams dat a f low diagrams cont rol-f low diagrams processing narrat ives st at e diagrams sequence diagrams Requirement s: const raint s int eroperabilit y t arget s and conf igurat ion de sign mode l low design class realizat ions subsyst ems collaborat ion diagrams ref inement s t o: design class realizat ions subsyst ems collaborat ion diagrams t echnical int erf ace design Navigat ion design GUI design component diagrams design classes act ivit y diagrams sequence diagrams ref inement s t o: component diagrams design classes act ivit y diagrams sequence diagrams design class realizat ions subsyst ems collaborat ion diagrams component diagrams design classes act ivit y diagrams sequence diagrams deployment diagrams archit ect ure element s int erface element s component -level element s deployment -level element s process dimension

17 Architettura basata sui dati

18 Architettura a flusso di dati

19 Architettura call and return

20 Architettura a livelli