1.

Waterfall model e Component-Based Software Engineering Il modello a cascata il primo modello di software process ed conosciuto come waterfall model a causa del susseguirsi di una fase dopo laltra. Lo sviluppo diviso in fasi, ogni fase dovrebbe essere completata prima che inizi la successiva, ma nella pratica gli stadi sono sovrapposti e si scambiano informazioni lun laltro. I principali stadi di questo modello sono: Analisi e definizione dei requisiti; Progettazione del sistema e del sw; Implementazione e test delle unit; Integrazione e test del sistema; Operativit e manutenzione. I presupposti su cui si basa il modello sono: i requisiti devono essere conosciuti fin dallinizio; i requisiti cambiano molto raramente; la progettazione pu essere condotta in via puramente astratta. I vantaggi del modello a cascata sono due: ogni fase del processo produce la relativa documentazione; trasparenza: ogni fase porta a dei risultati che sono tangibili e verificabili sia dal cliente che dal project manager. Gli svantaggi sono: i presupposti non sono sempre rispettati; la troppa documentazione; un flusso unidirezionale troppo rigido (necessario luso del feedback tra le fasi); i problemi si propagano tra le varie fasi del processo; una tarda deployment nasconde rischi tecnici concettuali personali (la persona non vede nulla di reale fino alla fine) e il testing arriva troppo tardi; difficile fare cambiamenti durante il processo (alternativa: indebolimento tramite utilizzo del feedback, ma crea il problema tale per cui le frequenti iterazioni/cambiamenti rendano difficili i check-points). Il modello a cascata dovrebbe essere utilizzato solo quando i requisiti sono ben compresi ed difficile che cambino radicalmente durante lo sviluppo del sistema. Il modello CBSE propone un approccio orientato al riutilizzo di componenti software gi implementate da terze parti (sistemi COTS). Lobiettivo quindi implementare un sistema come integrazione di componenti preconfezionati. I principali stadi di questo modello sono: specifica dei requisiti; analisi dei componenti; modifica dei requisiti; progettazione del sistema con riutilizzo; sviluppo e integrazione; convalida del sistema. Il modello CBSE ha come vantaggio la riduzione della quantit di sw da sviluppare, riducendo cos i costi e i rischi, e portando anche a consegne pi veloci.

Svantaggi: Sono per inevitabili alcuni compromessi nei requisiti che possono produrre un sistema che non soddisfa le reali necessit degli utenti. Inoltre si perde il controllo sullevoluzione del sistema, poich le nuove versioni dei componenti riutilizzati non sono sotto il controllo dellorganizzazione che li usa. 2. Emergent properties Le emergent properties sono propriet di un sistema che emergono solo quando i componenti del sistema sono stati integrati. Queste sono spesso conseguenze delle relazioni tra i componenti e si possono misurare solo quando il sistema stato integrato [assemblato]. Esempi di propriet emergenti sono: volume, affidabilit, protezione, riparabilit, usabilit. Le propriet emergenti possono essere di due tipi: funzionali: appaiono quando tutte le parti di un sistema lavorano assieme per raggiungere un obiettivo comune; non funzionali: si riferiscono al comportamento del sistema nel suo ambiente operativo. 3. UML CLASS DIAGRAMS Un diagramma delle classi descrive il tipo degli oggetti che fanno parte di un sistema e le varie tipologie di relazioni statiche tra di essi. I diagrammi delle classi mostrano anche le propriet e le operazioni di una classe e i vincoli che si applicano ai collegamenti tra gli oggetti. Le classi vengono rappresentate con dei box suddivisi in 3 sezioni che contengono rispettivamente: 1. il nome della classe (scritto in grassetto); 2. i suoi attribute; 3. le sue operazioni. Le propriet rappresentano le caratteristiche strutturali di una classe. In prima analisi si pu pensare che le propriet corrispondano ai campi delle classi, ma in realt le propriet sono un unico concetto, rappresentato con due nozioni molto diverse: attributi e associazioni. Le operazioni sono le azioni che la classe sa eseguire, e in genere si fanno corrispondere direttamente ai metodi della classe. Le operazioni che manipolano le propriet della classe (getter e setter) di solito non sono incluse nel diagramma perch si possono dedurre. 4. UML STATECHARTS DIAGRAMS Gli statecharts diagrams descrivono come un sistema risponde agli eventi interni o esterni. Essi mostrano gli stati del sistema e gli eventi che causano una transizione da uno stato allaltro; non mostrano il flusso di dati allinterno del sistema; sono usati per modellare i sistemi real-time, poich questi sono spesso gestiti da stimoli dellambiente del sistema. Un modello di macchina a stati di un sistema presume che, in ogni momento, il sistema si trovi in uno dei tanti stati possibili. Quando viene ricevuto un input, questo pu generare una transizione a uno stato diverso.

5. V-model e Evolutionary development Il V-model una variante del waterfall model; un modello iso-standard che regola tutte le attivit e i prodotti come i product states e relazioni durante lo sviluppo e la manutenzione. Il V-model composto da diversi sotto-modelli e descrive lo sviluppo del sistema, il management della configurazione e lamministrazione del progetto (comprare, pia nificare). Il processo ha una forma a V. Questo modello mostra le relazioni tra ogni fase del processo di sviluppo e la sua fase associata di testing. Levolutionary development si basa sullidea di sviluppare unimplementazione iniziale (prototipo), esporla al cliente e perfezionarla attraverso molte versioni finch non si ottiene un sistema adeguato. Ci sono due tipi di sviluppo evoluzionistico: 1. sviluppo esplorativo: lobiettivo del processo lavorare con i clienti per esaminare i loro requisiti e fornire un sistema finale. Lo sviluppo inizia dalle parti del sistema che sono chiare e si evolve aggiungendo nuove funzionalit proposte dal cliente; 2. prototipo usa e getta: lobiettivo capire i requisiti del cliente e quindi svilupparli per una migliore definizione del sistema: i prototipi sperimentano i requisiti poco chiari. I principali stati di questo modello sono: analisi dei requisiti; sviluppo del prototipo; convalida; necessario un nuovo prototipo? o S: cambiamento della definizione del prototipo e ritorno a sviluppo del prototipo o No: installazione e uso; manutenzione e ritorno alla ridefinizione del prototipo. Un approccio evoluzionistico allo sviluppo del sw molto efficace nel soddisfare le immediate necessit del cliente e il vantaggio che ne deriva consiste nella possibilit di sviluppare le specifiche in modo incrementale. Svantaggi: 1. poca trasparenza: difficile giudicare il progresso, non ci sono check-points; 2. codice poco strutturato: esso viene continuamente modificato; 3. richiede un team motivato e capace. Si utilizza per piccoli o medi sistemi interattivi, come parti di sistemi pi grandi o per sistemi di breve durata. 6. Traceability La tracciabilit la propriet di una specifica che riguarda le relazioni tra i requisiti, le loro fonti e il progetto del sistema. Esistono 3 tipi di tracciabilit: 1. tracciabilit della sorgente: collegamenti tra i requisiti, il loro fondamento logico e gli stakeholder che li hanno indicati; 2. tracciabilit dei requisiti: collegamenti tra requisiti dipendenti allinterno del documento; 3. tracciabilit del progetto: collegamenti tra i requisiti e i moduli del progetto in cui sono implementati.

7. UML USE CASE DIAGRAMS Gli use cases sono usati come linguaggio di alto livello per lanalisi dei requisiti. Sono una traccia UML basata su scenari che identificano gli attori in uninterazione e che descrivono linterazione stessa. Quindi uno use case un insieme di scenari uniti da un comune obiettivo (gli use cases cercano di descrivere tutte le possibili interazioni del sistema). Ogni use case composto da: un attore primario; una pre-condizione (condizione in entrata): descrive ci di cui un caso duso dovrebbe assicurarsi prima che il caso duso possa aver inizio; una post-condizione (condizione in uscita o garanzia): descrive ci che il sistema assicura alla fine dello svolgimento di un caso duso; un trigger: specifica precisamente levento che d origine al caso duso. 8. Functional e non-functional requirements I requisiti funzionali sono elenchi di servizi che il sistema deve fornire, indicano come dovrebbe reagire a particolari input e come dovrebbe comportarsi in particolari situazioni (descrivono quello che il sistema dovrebbe fare). Questi requisiti dipendono dal tipo di sw che si sta sviluppando dai futuri utenti e dallapproccio generale usato dallorganizzazione mentre li scrive. Le specifiche dei requisiti funzionali di un sistema dovrebbero essere complete (tutti i servizio richiesti dal cliente devono essere definiti) e coerenti (i requisiti non devono avere definizioni contraddittorie). I requisiti non-funzionali sono vincoli sui servizi o sulle funzioni offerti dal sistema. Includono vincoli temporali, sul processo di sviluppo e sugli standard. I requisiti non funzionali non riguardano direttamente le specifiche funzioni del sistema; essi possono riferirsi a propriet del sistema come affidabilit, tempi di risposta e occupazione di spazio, ma possono anche definire vincoli come le capacit dei dispositivi di I/O e la rappresentazione dei dati utilizzata nelle interfacce del sistema. Questi requisiti sono pi essenziali di quelli funzionali, specificano o limitano le propriet complessive del sistema (prestazioni, disponibilit); se questi requisiti non sono soddisfatti lintero sistema inutilizzabile. 9. People Capability Maturity Model PCMM E una struttura che serve a migliorare la gestione del personale in una organizzazione, poich fornisce una struttura per la motivazione, il riconoscimento, la standardizzazione e il miglioramento delle pratiche professionali. Obiettivi: migliorare la capacit delle organizzazioni del sw aumentando le capacit della loro forza lavoro; assicurare che la capacit di sviluppo del sw sia un attributo dellorganizzazione e non dei singoli; allineare le motivazioni dei singoli a quelle dellorganizzazione; conservare le persone con la conoscenza e le abilit pi importanti. Questo un modello a 5 livelli: 1. iniziale: gestione delle persone; 2. ripetibile: creazione di politiche per lo sviluppo delle capacit dello staff; 3. definito: standardizzazione dei principi fondamentali di gestione del personale nellorganizzazione;

4. gestito: obiettivi quantitativi per la gestione del personale; 5. ottimizzazione: concentrazione continua sul miglioramento della competenza individuale e della motivazione della forza lavoro. 10. Function points e Objects points Sono le metriche pi conosciute per la stima della produttivit del sw; entrambi misurano la funzionalit del codice e non la sua portata. Function points: la produttivit del codice espressa dal numero di FP implementati per persona ogni mese. Un punto funzione una combinazione di caratteristiche del sistema. Il numero totale di FP si calcola misurando o stimando i seguenti elementi del programma: input e output esterni; le interazioni utente; le interfacce esterne; i file utilizzati dal sistema. I FPs possono essere utilizzati per stimare la LOC (linea di codice/dimensione del codice) e sono molto soggettivi poich dipendono da chi fa le stime. Objects points: sono utilizzati nel modello di stima COCOMO II (dove sono chiamati punti applicativi). Il numero di punti oggetto in un programma una stima ponderata di vari elementi: numero di schermate separate che sono visualizzate; numero di rapporti prodotti dal sistema; numero di program modules. Gli OPs sono pi facili da stimare poich si occupano solamente di schermate, rapporti e moduli in linguaggi di programmazione. 11. Fase di testing: component testing, system testing e acceptance testing. La fase di testing consiste nel mostrare che il sistema conforme alle sue specifiche e che soddisfa le aspettative del cliente. Comprende i processi di controllo ad ogni stadio del processo sw. TEST DEI COMPONENTI: i singoli componenti sono testati indipendentemente gli uni dagli altri; i componenti possono essere entit semplici come funzioni o classi di oggetti, o raggruppamenti logici di queste unit. TEST DEL SISTEMA: si testa il sistema come un tuttuno; particolarmente importante risulta essere il testing delle propriet complessive del sistema (si integrano i componenti per formare il sistema). TEST DI ACCETTABILITA: lo stadio finale del processo di testing. Il sistema viene testato con le informazioni fornite dai clienti per verificare che soddisfi le necessit del cliente stesso. 12. ANSI/IEEE-STANDARD STD-830-1993 Tale standard collegato con il Software Requirements Specification (SRS). Esso deve soddisfare 8 attributi di qualit: 1. non ambiguo: ogni requisito ha una sola interpretazione possibile, sia per chi lo definisce (chi scrive) sia per chi lo usa (chi legge). 2. corretto: ogni requisito rappresenta fedelmente nel sistema completo qualcosa che stato richiesto. 3. completo: contiene i requisiti di tutte le funzionalit del sistema, e specifica, per tutte le possibili classi si input, la risposta del sistema. 4. verificabile: ogni requisito deve essere chiaro. Se un requisito non esprimibile in termini verificabili nel momento in cui lo SRS viene definito, dovrebbe essere definito un momento del ciclo di vita del software entro cui il requisito deve essere presentato in una forma verificabile. 5. coerente: 2 o pi requisiti non devono essere in conflitto. 6. modificabile: la struttura e lo stile sono tali che ogni cambiamento ai requisiti pu essere fatto facilmente, completamente, coerentemente. 7. reperibile: ogni requisito deve essere identificabile univocamente.

8. ranked: ogni requisito ha un identificatore per indicare limportanza o la stabilit di quel particolare requisito (bisogna stabilire limportanza dei requisiti). 13. Risk management Il risk management collegato allidentificazione dei rischi e alla ricerca dei metodi per minimizzare i loro effetti sul progetto. Ci sono 3 categorie di rischio collegate: 1. project risks: influenzano la tempistica o le risorse del progetto; 2. product risks: influenzano la qualit o le prestazioni del sw che si sta sviluppando (es. un componente acquistato che non funziona come previsto); 3. business risks: influenzano lorganizzazione che sta sviluppando o acquistando il sw (es. un concorrente che introduce un nuovo prodotto). I punti essenziali del Risk Management sono: 1. Risk identification: identificazione dei tre tipi di rischi sopra descritti; 2. Risk analysis: analisi della probabilit e dellimportanza delle conseguenze di ogni rischio; 3. Risk planning: pianificazione di soluzioni per evitare o ridurre il danno prodotto; 4. Risk monitoring: monitoraggio della probabilit di ogni rischio e delleventuale danno durante lo svolgimento del progetto. 14. 7 sezioni principali di un PRODUCT SKETCH 1)descrizione del problema e obiettivi. 2)funzionalit: creare, cambiare, cancellare,,, altri comandi, le cose che si possono fare. 3)profilo utente: chi utilizzer questo sistema. 4)criteri di accettazione: tempo di esecuzione, correttezza, sicurezza delle funzionalit. 5)sviluppo, come si presenta e manutenzione degli ambienti, interfacce e altre considerazioni. 6)architettura generale: qui si trova la soluzione. 7)fonti delle informazioni: manuali, glossari... 15. CRC CARDS Le CRC CARDS sono un approccio alternativo (del 1989) per esplorare velocemente diverse possibilit di interazione, senza perdere tempo a continuare a disegnare e cancellare diagrammi. In pratica si distribuiscono le carte al team di sviluppo e si sceglie uno use case scenario: 1. si simula lo scenario dallinizio alla fine, scambiandolo, quando necessario, tra i collaboratori; 2. in questo modo si possono trovare responsabilit e collaboratori mancanti; 3. in seguito si aggiungono attributi e metodi. Su ogni CRC CARD bisogna specificare: class: nome della classe; responsabilities: brevi frasi che riassumono una delle cose che un oggetto deve fare (meno responsabilit ci sono meglio ), collaborators: rappresentano le classi con cui quella descritta deve interagire (cose o persone che aiutano a realizzare le responsabilit). NB.se ci sono troppe responsabilit o collaboratori si creano nuove classi. 16. SEQUENCE DIAGRAMS, descrivendo in particolare le strutture FORK e STAIR I sequence diagrams mostrano come gli oggetti interagiscono in scenari di esecuzione, scambiando messaggi. Lavorano bene con le CRC-CARDS perch mostrano come le responsabilit sono portate avanti con la collaborazione; e inoltre descrivono gli aspetti

temporali del comportamento delloggetto. Questi diagrammi derivan o dai flussi di eventi (flow of events) degli use cases e rappresentano il comportamento in termini di interazioni. Sintassi: nome degli oggetti; linea di vita degli oggetti che attraversa la pagina verticalmente e ha una barra di attivazione che indica quando loggetto attivo nellinterazione; frecce che indicano un passaggio di messaggi e su cui possibile scrivere; creazione di oggetti tramite le frecce; distruzione di oggetti indicata da una x. Restrizioni: la suddivisione in punti possibile, ma difficile; non c supporto per la gerarchia; no liveness, specifica solo cosa pu accadere e non cosa deve accadere. FORK structure: il comportamento dinamico posto in un singolo oggetto (di solito il <<control>>). Questo conosce tutti gli altri oggetti e spesso li usa per comandi e chiarimenti. I vantaggi sono: le operazioni possono cambiare ordine; ci si aspetta di aggiungere nuove operazioni come risultato di nuovi requisiti. STAIR structure: il comportamento dinamico distribuito. Ogni oggetto delega delle responsabilit ad altri oggetti, conosce solo una parte degli altri oggetti e sa quali oggetti pu aiutare con uno specifico comportamento. I vantaggi sono: le operazioni hanno un forte legame; le operazioni saranno sempre fatte nello stesso ordine. 17. Milestones e Deliverables Le milestones e i deliverables fanno parte project planning organization; nellactivity organization le attivit dovrebbero essere organizzate in modo da produrre tangibili output per il management per giudicare il processo; tuttavia, poich il sw intangibile bisogna fornire informazioni riguardo allo stato del sw che si sta sviluppando sotto forma di report e documenti. Le milestones sono punti cardine riconoscibili nellattivit del processo sw. Ad ogni milestones dovrebbe esserci un output formale, come un report, ovvero un breve resoconto di cosa stato completato. I deliverables sono i risultati del progetto, che di solito vengono consegnati al cliente alla fine di alcune fasi principali, come le specifiche o la progettazione. Le consegne in genere sono milestones, ma le milestones non sono necessariamente delle consegne. 18. Si illustrino sinteticamente le caratteristiche principali dellapproccio code-andfix e si spieghi perch non pu essere adottato per progetti di sistemi a larga scala. Lapproccio code-and-fix stato utilizzato per molto tempo e ha funzionato finch i progetti erano di piccole dimensioni. Code-and-fix si basa su tre punti fondamentali: 1. Stesura del codice 2. Miglioramento (debug, bug fixes, aggiunta di funzionalit,) 3. Ritorno al passo 1

Questo tipo di approccio non pu essere utilizzato per progetti su larga scala per i seguenti motivi: Poca affidabilit: code-and-fix non prevede la modellazione del progetto e la sua documentazione. Questo rende praticamente impossibile ad una persona esterna al team di lavorare al progetto e quindi si crea un grosso problema nel caso in cui un programmatore abbandoni lazienda Spesso le aspettative sono differenti tra il programmatore e lutente finale. Poca mantenibilit: il codice mal strutturato e non documentato rende di fatto impossibile mantenerlo durante il suo ciclo di vita. 19. Si illustrino sinteticamente le caratteristiche principali e i vantaggi e svantaggi delle PERT Charts e delle GANTT Charts. I PERT Chart sono grafi orientati aciclici utilizzati per raffigurare in modo piu semplice la programmazione delle attivit del progetto. Un grafo PERT formato da nodi e archi. I nodi possono essere attivit (raffigurate con rettangoli) o milestone (raffigurate con ovali). Sopra le attivit si indica il tempo stimato per compiere la stessa. Sulle milestone si indica la data stimata di raggiungimento. Gli archi rappresentano le dipendenze tra le attivit. Il vantaggio pi importante del PERT Chart il fatto di conoscere il critical path in modo quasi istantaneo, e di conseguenza si riesce a individuare subito le attivit che bisogna ridimensionare per ridurre il percorso critico (tempo minimo necessario per il raggiungimento della fine del progetto). I GANTT Chart sono diagrammi a barre che danno una visione immediata delle tempistiche da rispettare. In questo diagramma troviamo una timeline sulla parte alta che si estende dalla data di inizio del progetto fino alla data di consegna. Ogni attivit caratterizzata da una barra orizzontale associata al suo nome e si estende dalla sua data di inizio a quella di fine. Le attivit e le milestone sono ordinate per data di inizio in modo crescente. Il diagramma GANTT molto utile per scegliere le attivit che possono essere parallelizzate e quali possono essere estese senza alterare il critical path. 20. Si illustrino sinteticamente le caratteristiche principali dellalgorithmic cost modeling. Lalgoritmic cost modeling un modello utilizzato per stimare il costo di un progetto. Esso dipende da vari parametri e diventa via via pi accurato con lo svolgersi del progetto. Il costo di un progetto pu essere stimato dalla seguente formula definita nel COCOMO 81: Costo = A x SIZEB x M Dove: A: costante definita dallazienda SIZE: stima della grandezza del progetto espressa in LOC o FP+OP B: correzione della grandezza del progetto. Di solito un valore vicino a 1, e esprime la non-linearit del parametro SIZE M: coefficiente che esprime propriet del prodotto finale, del processo produttivo e degli impiegati. Il COCOMO 2 da una stima del costo in termini di persona-mese:

Dove:

PM: costo persona-mese NAP: numero di application points PROD: object-point productivity

21. Si illustrino sinteticamente le caratteristiche principali del requirements engineering process.