Software Engineering & Re-Engineering Metodologie, Tecniche e Tools applicate alla produzione del software per ambienti Industriali e di Ricerca Docente : Ing. Secondulfo Giovanni Anno Accademico 2009-2010 28 Ottobre 2009 Ing. Giovanni Secondulfo Università di 1
Generalità Ciclo di vita Modularizzazione del progetto Strumenti di progetto Ciclo I nverso I llustrazione di case study 2
3
Cosa è l I nformatica Scienza della rappresentazione e della elaborazione ( trasformazione) dell informazione Studio sistematico degli algoritmi che descrivono e trasformano l informazione: teoria, analisi, progetto, efficienza, realizzazione e applicazione I l concetto astratto di elaborazione è quello di trasformazione di dati : Y= F(X) X,Y dati iniziali finali; F è la regola di trasformazione (nel senso più generico possibile). 4
Cosa è un prodotto Software Un insieme di linee di codice, che realizzano un insieme di programmi per computer La documentazione che descrive la struttura dell insieme I dati di configurazione che consento l installazione I l manuale di Utente 5
Cosa è l I ngegneria del Software La software engineering è una disciplina che cerca di fornire le regole per il processo di produzione del software, mediante un approccio sistematico ed organizzato del lavoro, usando tecniche e strumenti appropriati al problema da risolvere, dai vincoli presenti e dalle risorse disponibili 6
Metodologie La metodologia è l insieme che formalizza le regole e deve : essere un processo strutturato composto di varie fasi ognuna delle quali con un preciso obiettivo Disporre di tecniche per l individuazione delle alternative con gli adeguati criteri di scelta Fornire esaurienti input per il passo successivo a partire dagli output del passo precedente Disporre di tecniche descrittive atte a rappresentare nel modo più semplice e sintetico possibile gli input, i risultati intermedi e gli output di ciascun passo. 7
Perché è necessario un processo rigoroso Da un indagine condotta dal DoD (Department of Defense USA) si ottengono i seguenti risultati : 47 % Distribuito ma non usato 30 % Pagato ma non Distribuito 19 % Usato solo dopo rifacimenti o Abbandonato Rapidamente 3 % Usato solo dopo rifacimenti 2 % Usato appena consegnato 8
Perché dei Fallimenti I problemi più frequenti che si sono riscontrati sono: Specifiche incomplete / incoerenti Mancanza di separazione fra le fasi del progetto (specifica, progettazione, implementazione) Assenza del sistema di Validazione Manutenzione Complicata 9
Attività richieste nel processo di sviluppo softw are : I l ciclo di vita Si definisce ciclo di vita secondo lo standard I EEE 610.12 l intervallo di tempo che va da quando il software viene concepito, fino a che non è più utilizzabile, tale ciclo passa attraverso le fasi : Specifica Progettazione I mplementazione Validazione I nstallazione Manutenzione Smaltimento Alcune di queste si possono anche sovrapporre oppure percorse iterativamente. 10
Distribuzione tipica dello sforzo per un prodotto softw are 18 % Requisiti 19% Progettazione 34% Codifica 29% Testing Analisi ricavata su alcune centinaia di progetti di medio/ grandi dimensioni 11
Distribuzione dei Costi di un prodotto softw are Circa il 60% è legato allo sviluppo e il 40% è legato alla verifica e validazione Una distribuzione un po più analitica dei costi si può ricavare 25 % Codifica 40 % Testing: Module Test 25% System Test 15% 35 % Analisi: Requirements 10% Specification 10% Design 15% 12
Modelli di Ciclo di Vita del Software (1) Un modello del ciclo di vita del software è una caratterizzazione descrittiva o prescrittiva di come un sistema software viene o dovrebbe essere sviluppato; viene definito : Organizzazione del lavoro Organizzazione del personale Pianificazione del personale Dimensionamento del personale Assegnazione budget Schedulazione delle attività 13
Modelli di Ciclo di Vita del Software (2) Definisce e prescrive prodotti e documenti da rilasciare al committente Determina e classifica metodi e strumenti più adatti a supportare le attività previste Definisce strumenti e metodi per analizzare, stimare e migliorare il prodotto 14
Modelli di Ciclo di Vita del Software (3) Sono stati formalizzati vari modelli di ciclo di vita negli ultimi decenni Waterfall ( cascata) Prototyping I ncremental Delivery Spiral Model La scelta del modello è influenzata da vari aspetti: Organizzazione Aziendale Know-how Area applicativa Strumenti di supporto Ruoli Produttore/ Committente 15
I l modello waterfall trova ispirazione e grande applicazione nell industria manifatturiera è caratterizzato da : Progressione sequenziale (cascata) delle fasi senza ricicli La logica è quella di controllare i costi Diminuisce e separa le fase minimizzando o annullando le varie fasi Possibilità di uscite intermedie con documentazione o semilavorati Controllo rigido dell evoluzione del processo 16
Ogni fase raccoglie un insieme di attività omogenee per metodi, tecnologie, skill del personale Ogni fase è caratterizzata da attività (dette anche tasks), dai prodotti di tali attivita (detti anche deliverables) dai controlli applicabili alla fase ( detti anche quality control measures) La fine di ogni fase è un punto rilevante del processo ( detto anche milestone) I semilavorati di una fase (output) sono di input per la fase successiva I prodotti di una fase vengono congelati ovvero non sono più modificabili se non innescando un processo formale e sistematico di modifica 17
18
Vengono individuate due tipologie di prototipazione : Mock-ups : produzione completa dell interfaccia di utente. Consente di definire con completezza e senza ambiguità i requisiti. Breadboards : implementazione di sottosistemi di funzionalità critiche per il sottosistema, non nel senso della fattibilità ma in quello dei vincoli pesanti che sono posti nel funzionamento del sottosistema (carichi, tempi di risposta ), senza le interfacce di utente Produce feedbacks su come implementare le funzionalità. 19
Modello della Prototipazione 20
Ciclo di Vita : Modello Misto Cascata/ Prototipo L obiettivo è quello di lavorare con il cliente e far evolvere il prototipo verso il sistema finale La validazione dei requisiti è automatica 21
Ciclo di Vita del Software 22
Ogni output và sottoposto, prima del rilascio, ad una review ovvero, ad un riesame critico e validazione. L'obiettivo della review quello di individuare eventuali errori prima che questi possano filtrare verso altre fasi del ciclo di vita, nel qual caso la rimozione di questi avrebbe un costo sicuramente maggiore; pertanto la review può comportare un riciclo immediato sulla fase precedente. 23
L attività di validazione và affidata ad un team costituito da: producer sceglie il review leader, invia la documentazione ai partecipanti alla review, per un'analisi preventiva review leader il cui compito quello di ottenere una buona review, ovvero ottenere un report esaustivo su quanto emerso nella review review ers hanno il compito di supportare il producer nell'analisi critica dell'output, e proporre soluzioni ad eventuali errori recorder ha il compito di annotare quanto emerge nella review, e redigere il report finale 24
Fasi del Ciclo di Vita : System Requirement Analysis ( 1) I n questa fase vengono definiti i requisiti ed i vincoli del sistema, vengono prodotti : System Requirement : ovvero la elencazione completa delle funzionalità necessarie per la definizione del prodotto. Features Specification : ovvero la specificazione esterna di dettaglio delle funzionalità di cui al punto precedente. System Test : ovvero la definizione dei tests necessari alla verifica di tutte le funzionalità descritte al punto precedente. 25
Fasi del Ciclo di Vita : System Requirement Analysis ( 2) Questa fase come elementi materiali produrrà la lista di : oggetti da produrre; attività ; limiti del sistema e dell'implementazione; pianificazione di massima dei tempi di rilascio; criteri di validazione; documento di minispecifiche 26
Fasi del Ciclo di Vita : Prototipazione (1) Si intenderà per Prototipazione quel processo atto a realizzare un modello delle funzionalità del prodotto target, in modo da essere esercitato dall'utente finale, prima che questo sia stato progettato. Se l'esercizio copre tutte le funzionalità si realizza la Simulazione. Questa fase è assimilabile ad un processo di review della fase di Requirements Analysis, ed ha come input i documenti prodotti nella fase precedente il suo output sono i documenti stessi revisionati. Questa fase produce una milestone verso l'esterno costituita dall'accettazione formale delle specifiche da parte dell'utente e del gruppo di Progetto. 27
Fasi del Ciclo di Vita : Prototipazione (2) I n termini formali il processo si può rappresentare : 28
Fasi del Ciclo di Vita : Top Level Design (1) I n questa fase viene definita l'architettura del sistema (HW, SW, FW ) in funzione dei requirements e delle opportunità tecnologiche disponibili, e si ha la scomposizione in moduli del sistema con una valutazione in termini di pianificazione su cosa può essere sviluppato in all interno dell organizzazione e su cosa và acquisito dall'esterno. La possibilità di esternizzare o internizzare una produzione và effettuata in funzione delle possibilità di acquisire Know How riutilizzabile, e dei costi della realizzazione. 29
Fasi del Ciclo di Vita : Top Level Design (1) L'output di questa fase consiste in: Documento di Architettura ovvero la descrizione funzionale del sistema, la distribuzione delle funzioni tra i vari moduli. Requirements Specification dei Moduli ovvero andranno specificate le caratteristiche funzionali dei moduli e, per i moduli esterni, le caratteristiche di qualità in termini di documentazione, metriche, manutenibilità, riusabilità, costi ed elementi di supporto ( check list end user, supporto tecnico del fornitore.. ). I ntegration Test Specification ovvero descrizione funzionale dei tests necessari a verificare la corretta integrazione dei moduli. 30
Fasi del Ciclo di Vita : Top Level Design (2) Da un punto di vista delle metodologie questa fase può essere supportata da diversi approcci e/ o tecniche. Tecniche Process Oriented Structured Analysis ( SA ) Structured Analysis & Design Techniques (SADT) Jackson System Development ( JSD ) Tecniche Data Oriented : - Data Structured System Development ( DSSD ) - Data Modeling ( modello E-R di Chen ) Tecniche Object Oriented ( OOA ) Tecniche Formal Specification ( FST ) 31
Fasi del Ciclo di Vita : Detail Design (1) I n questa fase si effettua una microanalisi del singolo modulo o sottosistema, producendo un documento di Detail Design che descrive la struttura del singolo modulo; vengono specificati i Module Test da eseguire dopo la fase di codifica. La fase di Design deve essere vista come il cuore della software engineering, in questa fase viene costruita la qualità del software e solo un buon design consentirà una corretta manutenzione, inoltre una corretta rappresentazione è l'unica a consentire una valutazione della qualità del software prima della codifica; pertanto verrà definito anche lo standard di produzione del codice, in termini di linguaggio e di stile di codifica (ad es. assenza di goto, uso dei commenti, etc.), inoltre dovranno essere esplicitati in chiaro tutti i processi di astrazione procedurale e di astrazione dei dati onde evitare il mascheramento di conoscenza. 32
Fasi del Ciclo di Vita : Detail Design (2) I n funzione delle metodologie e tecniche adottate nella fase di Top Level Design verrà scelta il metodo e la relativa tecnica di rappresentazione per la fase di Detail Design. I n particolare risultano consolidate da tempo: Structured Design Carte di Struttura Program Design Lenguage ( PDL ) Data Flow Diagram ( DFD ) Procedural Design Object Oriented Design 33
Fasi del Ciclo di Vita : Coding Si intende per Coding la fase di Stesura del Codice, è evidente che non esiste un netto confine con la fase di Detail Design; infatti spingendo agli estremi la fase di microanalisi ed adottando un formalismo spinto e rigoroso si riesce ad avere un dossier in termini di statement, facilmente convertibile nel linguaggio scelto per la codifica; ciò tanto più vero quanto più sono evoluti gli strumenti di CASE adottati in questa fase, l'estremizzazione di questo concetto è la Produzione Automatica del codice. 34
Fasi del Ciclo di Vita : Module Test La fase di testing essenzialmente rivolta alla scoperta degli errori tramite l'esecuzione del software. Si ritiene opportuno precisare che per software di media complessità può essere arduo se non impossibile esercitare tutti i percorsi, per cui andranno effettuati dei test basati su tecniche statistiche atte ad esercitare tutti gli statement del codice. Sono allo stato attuale consolidate le tecniche seguenti: WHI TE BOX Testing : assicura il testing di tutti gli statement BLACK BOX Testing : verifica ingresso-uscita del comportamento del modulo I l Module Test si conclude con l'emissione di un report con la lista dei tests eseguiti e dei relativi risultati e/ o la check list delle funzioni esercitate. 35
Fasi del Ciclo di Vita : I ntegration (1) I n questa fase si provvede ad aggregare i vari moduli SW, FW e HW onde verificare il corretto funzionamento delle interfacce e dei moduli stessi nel contesto dell'architettura realizzata. Una corretta attività di integrazione andrà basata su una esatta definizione dell'ambiente di test in termini di componenti HW, FW, SW, test specification, dati e strumenti di prova. L'attività di integrazione, svolta sulla base dei tests approntati nella fase di Top Level Design, è tesa all' individuazione delle cause di eventuali malfunzionamenti e relative soluzioni proponibili. 36
Fasi del Ciclo di Vita : I ntegration (2) I l risultato delle attività di integrazione sarà concretizzato con l'emissione di: Test Specification Operativi, sulla base delle Test Specification Funzionali viene progettato l'ambiente di Test in termini di strumenti, dati di prove e sequenze operative; Fault Reports, in cui siano riportati sintomi e cause dei malfunzionamenti; Solution Proposal, con le soluzioni eventualmente adottate e proposte per il resourcing; Report Finale. Per le finalità dell'attività di integrazione, come sopra definite, l'output di questa fase provoca un riciclo sul Detail Design dei moduli. 37
Fasi del Ciclo di Vita : System Test L'obiettivo delle attività svolte per il System Test è quello di verificare tutte le funzionalità cosi come specificate dai System Requirements e secondo le modalità indicate nelle System Test Specifications. L'oggetto delle attività di System Test è la Release ovvero l'insieme dei componenti HW, FW, SW, documentazione, System Requirements e tutto quanto concorre alla completa definizione del sistema così come questo verrà poi rilasciato agli enti esterni a quelli di progetto. I l risultato finale di questa fase sarà la validazione della release o il rilevamento di malfunzionamenti; in tal caso se ne analizzeranno le cause e le possibili soluzioni; il tutto andrà infine formalizzato con dei Fault Reports & Change Proposal che serviranno per il riciclo del Top Level Design. 38
Fasi del Ciclo di Vita : Maintenance (1) I n quest'ultima fase del ciclo di vita vengono gestiti tutti quegli interventi sul prodotto successivi alla fine dello sviluppo. I tipi di interventi generalmente eseguiti sono correttivo atto ad eliminare errori logici o funzionali individuati con l'esercizio del prodotto (fixing); adattativo atto ad adeguare il software all'ambiente a fronte di nuove esigenze dell'utente ( enhancement); perfettivo: atto a migliorare la qualità del software in termini di perfomaces ( quality improvement); evolutivo: atto a modificare le caratteristiche del softw are in termini di funzionalità ( evolution). 39
Fasi del Ciclo di Vita : Maintenance (2) I n generale l'attività di manutenzione consisterà nel ripercorrere il ciclo di vita del software a partire da una fase che sarà funzione della natura delle modifiche da effettuare; il risultato finale sarà quindi una revisione sia del codice che della documentazione relativa. 40
Fasi del Ciclo di Vita : Object External Manifactured Choice Nella fase di Top Level Design, si può decidere di esternizzare la produzione di uno o più sottosistemi, in questa successiva fase viene operata la scelta del prodotto e/ o fornitore che meglio soddisfi i requirements precedentemente definiti; di fatto trattasi di un'indagine di mercato del particolare settore in cui l'applicazione si colloca. 41
Fasi del Ciclo di Vita : Acceptance Per l'accettazione del package O.E.M. verranno attivate le seguenti azioni: Check di consistenza software : riproduzione degli eseguibili in ambiente nativo atta a verificare la consistenza e completezza di quanto rilasciato, verifica di consistenza e completezza della documentazione a corredo. Verifica Funzionale : esercizio del package ed esecuzione di tests atti a verificarne la rispondenza ai requirements funzionali. Misura delle Metriche : valutazione secondo parametri oggettivi della qualità del softw are acquisito. Tale fase produce un report di accettazione del package, oppure un report di rigetto con le ragioni per cui il package viene rifiutato. 42
Reverse Engineering ( 1) I l termine REVERSE ENGI NEERI NG si confonde comunemente, ma non propriamente, con termini quali: il REUSE del software, la CONVERSI ON del software, il RECYCLI NG del software, la RESTRUCTURI NG del software, la REENGI NEERI NG del software; ma si può affermare senza ombra di smentita che la reverse engineering le ingloba tutte. Si definisce processo di REVERSE ENGI NEERI NG "quel processo in grado di ricostruire, a partire dal codice, la conoscenza in essa implementata ed il suo uso nel ciclo di vita del software ". 43
Reverse Engineering ( 2) I l processo di Reverse Engineering del software finalizzato alla manutenzione, riuso, o alla produzione, in modo da assicurare: la comprensione del softw are, la disponibilità di documenti affidabili e congruenti con l'implementazione, l'analisi dei cambiamenti, post-maintenance testing. Pertanto il Reverse Engineering un insieme di metodologie, teorie, tecniche, tecnologie in grado di supportare: I l progetto e l'implementazione di un processo di estrazione e di astrazione di informazioni dal codice esistente e la produzione di documentazione coerente con il codice L'aggiunta a questi documenti di conoscenza ed esperienza che non può essere ricostruita dal codice L'uso di quanto si è prodotto nel processo di Forward Engineering 44
Modello della Reverse Engineering 45
Reverse Engineering ( 3) Al termine del processo di estrazione ed astrazione è possibile individuare un delta ( ), ovvero l'insieme di eventuali modifiche da apportare al package acquisito e/ o a quanto già prodotto affinché questi siano integrabili nell'intero sistema. L'impatto del è cosi' caratterizzabile: potrebbe non esserci delta laddove il package è integrabile "as it is", potrebbe esserci un impatto sull'architettura, quindi occorre effettuare un Top Level Design del delta, potrebbe esserci impatto solo sulla implementazione per cui sufficiente passare al Detail Design del delta. 46
Funzioni di Supporto alla Sw Eng Source Control Memorizzazione di tutto quanto prodotto durante il processo di sviluppo (sources e documentazione) al fine di rendere riproducibile e riusabile il tutto. Configuration Control Definizione esatta di tutte le componenti (documenti, HW e SW, FW), sia per i prodotti intermedi che per la Release Finale 47
Case Study (1) 48
Case Study (2) 49
50
Grazie per l attenzione Ing. Giovanni Secondulfo e-mail : giovanni.secondulfo@inwind.it http://www.geocities.com/giosec/sweng.htm 51