Commenti alle Attività Generiche

Attività Generiche (Pressman) Principali: Comunicazioni; Pianificazione; Modellazione; Costruzione, Dispiegamento Collaterali: controllo (monitoraggio del progetto), gestione dei rischi; valutazione della qualità; revisioni tecniche formali; misurazioni; gestione delle configurazioni; gestione del riuso; preparazione e produzione del prodotto Il tentativo è concentrarsi il più possibile sulla natura principale delle attività, limitando le informazioni sulla sequenza delle attività

Attività Generiche - Pressman Communication (Comunicazioni) Planning (Pianificazione) Modeling (Modellazione) –Requirements specification (modellazione analitica) –Design (modellazione progettuale) Construction (Costruzione) –Code generation (generazione codice) –Testing (collaudo) Deployment (Implementazione!!!!)

Comunicazioni E’ un’attività necessaria alla comprensione dei requisiti che mette in evidenza la fondamentale comunicazione tra differenti ruoli Può essere utile per la negoziazione dei tempi e dei costi di progetto Può essere utile per la valutazione dei tipo di modello di processo Produce, nella visione di Pressman, il documento dei requisiti; l’attività di modellazione produce (e non solo) invece il modello di analisi dei requisiti E’ tuttavia ragionevole che una seppur minima attività di modellazione potrebbe svolgersi internamente alla comunicazione se la modellazione è svolta con l’obiettivo di comunicare e cioè di deduzione dei requisiti (§5.2); ed è anche ragionevole che nella comunicazione vi sia una, seppur minima, attività di pianificazione (§5.2)

Modellazione L’attività di modellazione è, secondo Pressman, quell’attività necessaria alla specifica dei requisiti usando una qualche notazione, a partire dal documento dei requisiti; l’attività di modellazione si estende poi anche alla progettazione del software Due elementi fondamentali che possono essere modellati secondo Pressman: –I requisiti del software, –Il software entrambe sotto le condizioni di tempi, costi e risorse, al fine di valutare le alternative possibili, in accordo alla qualità accettabile del prodotto software Ma non è pensabile che questa attività venga fatta in modo indipendente dalle comunicazioni con il committente (§7.4)

Visione per Attività Generiche Operative Fattibilità (comunicazione) Determinazione (Raccolta) dei requisiti (può comprendere la deduzione e la negoziazione dei requisiti) (comunicazione) Specifica dei requisiti (modellazione analitica) Progettazione del software (modellazione progettuale) Codifica (costruzione) Test (costruzione) Installazione (dispiegamento) Manutenzione Verifica e Validazione Pianificazione e Contollo

Visione per Attività Operative Vi sono ambiguità legate al modello di processo e alla tipologia del software da sviluppare: –si tratta del software stesso ovvero di un suo prototipo Determinazione dei requisiti --- di cosa? Progettazione --- di cosa? –la determinazione dei requisiti può in certi casi contenere molti elementi di specifica dei requisiti o, eventualmente, coincidere (ed infatti talvolta le due attività si trovano sotto il nome di analisi dei requisiti) infatti, la specifica dei requisiti (o parte di essa) permette di verificare (anche formalmente) l’esistenza di conflitti (inconsistenze) tra requisiti distinti e quindi, diventa strumento fondamentale anche per determinare i requisiti stessi Le attività generiche operative danno un’idea della sequenza e di cosa effettivamente deve essere fatto

Relazioni tra Attività Generiche Fattibilità: –Comunicare (quanto basta) –Pianificare (quanto basta) –Modellare (quanto basta) Determinazione dei requisiti: –Comunicare (molto) –Pianificare (dipende) –Modellare (dipende) –Costruire (dipende) Specifica dei requisiti: –Comunicare (quanto basta) –Pianificare (dipende) –Modellare analiticamente (molto) Fare il meno possibile per capire se si può fare (ovvero come farlo al meglio)! Fare il più possibile per capire cosa si deve fare esattamente! Fare il più possibile per descrivere precisamente cosa deve essere fatto, in modo da poterlo fare!

Visione per Obiettivi Ingegneria di sistema –Permette di capire esattamente cosa dovrebbe fare il sistema=software+ambiente del software (requisiti del sistema) Ingegneria dei requisiti (del software) –Sulla base di cosa dovrebbe fare il sistema, determina e specifica i requisiti del software Ingegneria della progettazione (del software) –Sulla base della specifica dei requisiti del software, tenendo presente gli aspetti di qualità del software, specifica l’architettura del software e, su questa base, specifica le componenti software più semplici

Ingegnerie ed Attività Le tre ingegnerie prevedono sia più attività generiche operative sia più attività generiche secondo Pressman Meglio concentrarsi sulle Ingegnerie che risultano relativamente meno ambigue e con obiettivi ben definiti

Esempio Punto di partenza: la richiesta del committente Possibile contenuto della richiesta del committente: –Cosa, dal suo punto di vista, si vorrebbe fare (problem statement) –Con quali vincoli etc. –La motivazione del perché si vorrebbe fare (cioè il contesto in cui si andrà ad inserire sia il software che dovrà essere sviluppato, in relazione all’ambiente in cui tale software opererà: Software+Ambiente=Sistema) –Quando si vorrebbe avere e quanto dovrebbe costare –Eventuali sistemi esistenti ed eventuale visione d’insieme di tali sistemi (correlazioni) –I benefici che potrebbero ottenersi –In quali condizioni il software risultante può essere considerato un successo

Richiesta di Esempio (I) Realizzare un sistema di supporto alla vendita di biglietti, con o senza prenotazione, per treni, in modo che sia utilizzabile via web anche direttamente dall’utente finale Il tempo di consegna è tre anni dalla data d’inizio (esclusa la fattibilità) Il costo, del solo sviluppo del software, dovrebbe essere attorno a 5 M euro Il costo della fattibilità dovrebbe essere attorno a Euro. Si pensa rendere un servizio utile alla clientela e permettere una razionalizzazione delle risorse aziendali interne Il successo dell’iniziativa è dovuto ai seguenti fattori: –Il sistema è usato dagli utenti –Il sistema verifica rigidamente che per ogni pagamento esiste un unico biglietto

Richiesta di Esempio (II) Si vuole sviluppare un sistema per il controllo del movimento di ascensori Il costo previsto non deve essere superiore a 1 M Euro e deve essere terminato in 1,5 anni Il sistema deve essere robusto e evitare qualunque tipo di incidente