Ingegneria del Software Obiettivi della lezione: Definire cosa si intende per Ingegneria del Software Discutere i concetti di prodotto software e di processo software Spiegare il concetto di visibilità di processo Introdurre la nozione di responsabilità professionale Ingegneria del Software Le economie di tutti i paesi sviluppati dipendono dal software, e la maggior parte dei sistemi sono controllati da software L Ingegneria del Software ha a che fare con teorie, metodi e strumenti per progettare, costruire e mantenere sistemi software di grandi dimensioni Il software costa più dell hardware, e il mantenimento costa più dello sviluppo Obiettivo: sviluppo cost-effective del software
FAQ sull ingegneria del software Cos è il software? Quali sono gli attributi di un software di qualità? Cos è l ingegneria del software? Qual è la differenza tra ingegneria del software e informatica? Qual è la differenza tra ingegneria del software e ingegneria di sistema? Cosa si intende per processo di produzione del software? FAQ sull ingegneria del software Cos è un modello di processo di produzione software? Quali sono i costi nel processo di produzione software? Quali sono i metodi dell ingegneria del software? Quali sono le sfide che l ingegneria del software si trova ad affrontare?
Cos è un prodotto software? Qualcosa di più di un insieme di linee di codice Un insieme di programmi per computer Tutta la documentazione che descrive la struttura del sistema I dati di configurazione, che permettono di installarlo Il manuale utente Prodotti Software Prodotti Generici Sistemi stand-alone prodotti da un organizzazione di sviluppo e venduti sul mercato ad ogni cliente Prodotti Dedicati Sistemi che sono commissionati da un cliente specifico e sviluppati appositamente La maggior spesa di software riguarda sistemi generici, ma il maggior sforzo di sviluppo è su prodotti dedicati La differenza principale? Chi dà la specifica del prodotto (il produttore o il consumatore).
Attributi di un prodotto software Manutenibilità Capacità di evolvere in rapporto alla modifica di requisiti Affidabilità Correttezza Robustezza Verificabilità Sicurezza - Innoquità Efficienza (Produttività) Non deve sprecare risorse (memoria, tempo,...) Usabilità Deve avere interfaccia e documentazione appropriate Cosa l ingegneria del software? Software engineering è una disciplina che cerca di fornire le regole per il processo di produzione del software Un ingegnere del software dovrebbe: adottare un approccio sistematico e organizzato al proprio lavoro usare strumenti e tecniche appropriate, che dipendono dal problema che deve essere risolto, dai vincoli presenti e dalle risorse disponibili.
ingegneria del software e informatica L informatica è una scienza: il cuore sono i fondamenti teorici: linguaggi algoritmi complessità formalismi ecc. L ingegneria del software ha a che fare con aspetti più pratici : come pianificare e sviluppare la produzione di software di qualità. Ad un ingegnere del software le conoscenze di base dell informatica servono quanto la fisica ad un ingegnere elettrico ingegneria del software e ingegneria di sistema L ingegneria di sistema ha come oggetto tutti gli aspetti dello sviluppo di un sistema basato su computers, inclusi gli aspetti hardware, software e di processo. L ingegneria del software può essere vista come una parte dell ingegneria di sistema. Gli ingegneri del software collaborano alla specifica del sistema, alla progettazione architetturale all integrazione con le altre componenti.
Processo di produzione software Il processo di produzione software è un insieme di attività il cui fine complessivo è lo sviluppo di un prodotto software oppure la modifica di un prodotto software Attività richieste nel processo di sviluppo software Specifica Progettazione Implementazione Validazione Installazione Manutenzione Smaltimento
Caratteristiche del processo Comprensibilità Visibilità Supportabilità (CASE ) Accettabilità Robustezza Mantenibilità Rapidità Problemi nel processo di sviluppo del software Specifiche incomplete/incoerenti Mancanza di distinzione tra specifica, progettazione e implementazione Assenza di un sistema di validazione Il software non si consuma: la manutenzione non significa riparare alcune componenti rotte, ma modificare il prodotto rispetto a nuove esigenze
I costi di un prodotto software All incirca il 60% dei costi è legato allo sviluppo, il 40% sono costi per la verifica e validazione (testing). I costi variano a seconda del tipo di sistema che deve essere sviluppato e da requisiti quali la performance o l affidabilità del sistema. La distribuzione di costi nelle varie fasi del processo di produzione del software dipende dal modello di processo. Modelli di processo di produzione software Una rappresentazione semplificata del processo di produzione software a partire da una certa prospettiva Esempi di prospettiva da cui si può modellare il processo di produzione sw: Workflow - sequenza di attività Data-flow - flusso di informazione Role/action - chi fa cosa
Modelli di processo Modello a cascata Fasi distinte di specifica e di sviluppo Modello evolutivo Specifica e sviluppo interagiscono Modello trasformazionale Un sistema matematico è trasformato formalmente in una implementazione Sviluppo basato sul riutilizzo Il sistema è ottenuto combinando componenti esistenti Modello a cascata Definizione dei Requisiti Progettazione del Sistema e del Software Implementazione e testing delle singole unità Integrazione e testing di sistema Installazione e Manutenzione
Fasi del modello a cascata Analisi e definizione dei requisiti Progettazione del sistema e del software Implementazione e test delle singole unità Integrazione e test del sistema Installazione e mantenimento Il limite del modello a cascata è la difficoltà ad effettuare cambiamenti nel corso del processo Modello evolutivo Attività concorrenti Specifica Versione Iniziale Descrizione di massima Sviluppo Versioni Intermedie Validazione Versione Finale
Modello evolutivo Prototipazione di tipo evolutivo L obiettivo è lavorare con il cliente ed evolvere verso il sistema finale a partire da una specifica di massima. Lo sviluppo inizia con le parti del sistema che sono già ben specificate, aggiungendo via via nuove caratteristiche Prototipazione di tipo usa e getta L obiettivo è capire i requisiti del sistema. e quindi sviluppare una definizione migliore dei requisiti. Il prototipo sperimenta le parti del sistema che non sono ancora ben comprese Modello evolutivo Problemi Mancanza di visibilità del processo Sistemi spesso poco strutturati Possono essere richieste particolari capacità (ad esempio in linguaggi per prototyping rapido) Applicabilità Sistemi interattivi di piccola o meda dimensione Per parti di sistemi più grandi (es. interfaccia utente) Per sistemi a vita breve
Modello trasformazionale Basato sulla trasformazione di una specifica matematica in in programma eseguibile, attraverso trasformazioni che permettono di passare da una rappresentazione formale ad un altra. Le trasformazioni devono preservare la correttezza. Questo garantisce che il programma soddisfi la specifica. Modello trasformazionale Formal transformations T1 T2 T3 T4 Formal specification R1 R2 R3 Executable program P1 P2 P3 P4 Proofs of transformation correctness
Valutazione dei Rischi Obiettivo principale = minimizzare i rischi Rischio = misura di incertezza del risultato di un attività Meno informazione si ha, più alti sono i rischi Valutazione dei rischi nei modelli di processo del software Modello a cascata Alto rischio per sistemi nuovi, per problemi di specifica e di progettazione Basso rischio per sviluppo di problemi familiarità già acquisita Modello evolutivo, prototipazione Basso rischio per nuovi sistemi Alto rischio a causa della scarsa visibilità del processo Modello trasformazionale Alto rischio dovuto alla necessità di tecnologia avanzata e di elevate capacità da parte degli sviluppatori
Modello a spirale di Boehm determinazione obiettivi e vincoli valutazione alternative identificazione rischi 1 2 4 pianificazione fase successiva 3 sviluppo e verifica Fasi del modello a spirale Determinazione degli obiettivi e dei vincoli Valutazione e riduzione dei rischi e valutazione delle alternative Progettazione e testing Pianificazione della fase successiva
Modello a spirale Determine objectives alternatives and constraints Plan next p has e REVIEW Requirements plan Life-cycle plan Development plan Integration and test plan Risk analysis Risk analysis Risk analysis Prototype 2 Risk analysis Prototy pe 1 Concept of Operation S/W requirements Requirement valid ation Design V&V Service Acceptance test Evaluate alternatives identify, resolve risks Prototype 3 Operational protoype Simulations, models, bench marks Product design Code Unit test Integr ation test Detailed design Develop, verify next-level product Esempio Obiettivi Migliorare la qualità del software in modo significativo Vincoli In tre anni Senza grandi investimenti senza un cambiamento radicale degli standard dell azienda Alternative Riutilizzare software certificato già esistente Introdurre specifiche e verifiche formali Investire in prodotti di testing e di validazione
Rischi Migliorare la qualità del software può aumentare eccessivamente i costi I nuovi metodi possono indurre il personale a licenziarsi Risoluzione dei rischi Studio della letteratura esistente Avvio di un progetto pilota Analisi delle componenti potenzialmente riutilizzabili Valutazione degli strumenti di supporto già esistenti Addestramento e rimotivazione del personale Risultati I miglioramenti sono difficili da quantificare per la scarsa esperienza nell utilizzo di metodi formali Gli strumenti di supporto disponibili sono insufficienti rispetto allo standard dei sistemi di sviluppo dell azienda Componenti software riusabili, ma scarso contributo degli strumenti di supporto alla riusabilità Pianificazione della fase successiva Finanziare una fase di studio di altri 18 mesi Studiare in maggior dettaglio le opzioni di riuso del software Sviluppare strumenti di supporto al riuso di software Esplorare uno schema di certificazione delle componenti
Vantaggi e limiti del modello a spirale Vantaggi Concentra l attenzione sulle possibilità di riuso Concentra l attenzione sull eliminazione di errori Pone al centro gli obiettivi Integra sviluppo e mantenimento Costituisce un framework di sviluppo hardware/software Limiti Per contratto di solito si specifica a priori il modello di processo e i deliverables Richiede esperienza nella valutazione dei rischi Richiede raffinamenti per un uso generale Visibilità del processo software C è bisogno di documentazione per valutare i progressi nel processo di sviluppo software Problemi La programmazione dei tempi di consegna dei deliverables può non combaciare con i tempi necessari per completare un attività La necessità di produrre documentazione vincola l iterazione del processo Il tempo necessario per approvare i documenti è significativo Il modello a cascata è ancora il modello basato su deliverables più usato
Documentazione del modello a cascata Activity Requirements analysis Requirements definition System specification Architectural design Interface design Detailed design Coding Unit testing Module testing Integration testing System testing Acceptance testing Output documents Feasibility study, Outline requirements Requirements document Functional specification, Acceptance test plan Draft user manual Architectural specification, System test plan Interface specification, Integration test plan Design specification, Unit test plan Program code Unit test report Module test report Integration test report, Final user manual System test report Final system plus documentation Visibilità dei modelli di processo Process model Waterfall model Evolutionary development Formal transformations Reuse-oriented development Spiral model Process visibility Good visibility, each activity produces some deliverable Poor visibility, uneconomic to produce documents during rapid iteration Good visibility, documents must be produced from each phase for the process to continue Moderate visibility, it may be artificial to produce documents describing reuse and reusable components. Good visibility, each segment and each ring of the spiral should produce some document.
Le sfide per l ingegneria del software Legacy systems Sistemi vecchi ma che non possono essere dismessi, ma che devono essere mantenuti e aggiornati Eterogeneità Sistemi distribuiti e dove c è garnde interdipendenza tra hardware e software Delivery Pressione perché la produzione software sia rapida Responsabilità Professionale Non limitarsi agli aspetti tecnici, ma guardare anche ai risvolti etici, sociali e alle responsabilità professionali: essere onesti non è solo rispettare le leggi. Confidenzialità Competenza Diritti di proprietà intellettuale Uso inappropriato dei computer Vedi ACM/IEEE Code of Ethics
Punti chiave L ingegneria del software si occupa di teorie, metodi e strumenti per sviluppare, produrre e mantenere prodotti software Prodotti software consistono in programmi e relativa documentazione. Gli attributi di un prodotto software Il processo software consiste nelle attività necessarie per sviluppare software Punti-chiave Il modello a cascata considera ogni attività del processo separatamente dalle altre Il modello evolutivo considera le attività del processo in modo concorrente Il modello a spirale è guidato dall analisi dei rischi Visibilità = derivables per ogni attività Produrre software implica responsabilità etiche, sociali e professionali