1. L Ingegneria del Software

Transcript

1 1. L 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 A.Cortesi Ingegneria del Software Slide 1 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 A.Cortesi Ingegneria del Software Slide 2

2 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? A.Cortesi Ingegneria del Software Slide 3 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? A.Cortesi Ingegneria del Software Slide 4

3 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 intstallarlo Il manuale utente A.Cortesi Ingegneria del Software Slide 5 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). A.Cortesi Ingegneria del Software Slide 6

4 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 A.Cortesi Ingegneria del Software Slide 7 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. A.Cortesi Ingegneria del Software Slide 8

5 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 gli aspetti pratici : come sviluppare software di qualità. Ad un ingegnere del software le conoscenze di base dell informatica srvono quanto la fisica ad un ingegnere elettrico A.Cortesi Ingegneria del Software Slide 9 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. A.Cortesi Ingegneria del Software Slide 10

6 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 A.Cortesi Ingegneria del Software Slide 11 Attività richieste nel processo di sviluppo software Specifica Progettazione Implementazione Validazione Installazione Manutenzione Smaltimento A.Cortesi Ingegneria del Software Slide 12

7 Caratteristiche del processo Comprensibilità Visibilità Supportabilità (CASE ) Accettabilità Robustezza Mantenibilità Rapidità A.Cortesi Ingegneria del Software Slide 13 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 A.Cortesi Ingegneria del Software Slide 14

8 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. A.Cortesi Ingegneria del Software Slide 15 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 A.Cortesi Ingegneria del Software Slide 16

9 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 A.Cortesi Ingegneria del Software Slide 17 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 A.Cortesi Ingegneria del Software Slide 18

10 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 A.Cortesi Ingegneria del Software Slide 19 Modello evolutivo Attività concorrenti Specifica Versione Iniziale Descrizione di massima Sviluppo Versioni Intermedie Validazione Versione Finale A.Cortesi Ingegneria del Software Slide 20

11 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 A.Cortesi Ingegneria del Software Slide 21 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 A.Cortesi Ingegneria del Software Slide 22

12 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. A.Cortesi Ingegneria del Software Slide 23 Modello trasformazionale Formal transformations T1 T2 T3 T4 Formal specification R1 R2 R3 Executable program P1 P2 P3 P4 Proofs of transformation correctness A.Cortesi Ingegneria del Software Slide 24

13 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 A.Cortesi Ingegneria del Software Slide 25 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 A.Cortesi Ingegneria del Software Slide 26

14 Modello a spirale di Boehm determinazione obiettivi e vincoli valutazione alternative identificazione rischi pianificazione fase successiva 3 sviluppo e verifica A.Cortesi Ingegneria del Software Slide 27 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 A.Cortesi Ingegneria del Software Slide 28

15 Modello a spirale D etermine objectives alternatives and constraints Plan next phase REVIEW Requi rements plan Life -cycle plan D evelopment plan I ntegration a nd test plan Risk analysis Risk analysis Risk analysis P rototype 2 Risk analysis Prototype 1 Concept of Operation S/W requirements Requirement validation Design V&V Acceptance Service test Evaluate alterna tives identify, resolve risks Prototype 3 Operational protoype Simulations, models, bench marks Product design Integr ation test Code Unit test Deta iled desi gn Develop, verify next-level product A.Cortesi Ingegneria del Software Slide 29 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 A.Cortesi Ingegneria del Software Slide 30

16 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 A.Cortesi Ingegneria del Software Slide 31 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 A.Cortesi Ingegneria del Software Slide 32

17 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 A.Cortesi Ingegneria del Software Slide 33 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 A.Cortesi Ingegneria del Software Slide 34

18 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 A.Cortesi Ingegneria del Software Slide 35 Visibilità dei modelli di processo Process model Process visibility Waterfall model Good visibility, each activity produces some deliverable Evolutionary Poor visibility, uneconomic to produce development documents during rapid iteration Formal transformations Good visibility, documents must be produced from each phase for the process to continue Reuse-oriented Moderate visibility, it may be artificial to development produce documents describing reuse and reusable components. Spiral model Good visibility, each segment and each ring of the spiral should produce some document. A.Cortesi Ingegneria del Software Slide 36

19 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 A.Cortesi Ingegneria del Software Slide 37 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 A.Cortesi Ingegneria del Software Slide 38

20 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 A.Cortesi Ingegneria del Software Slide 39 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 A.Cortesi Ingegneria del Software Slide 40