Ingegneria del Software II -Introduzione e Richiami -

Transcript

1 Ingegneria del Software II -Introduzione e Richiami - Ingegneria del Software 2 Introduzione e Richiami 1 Riferimenti bibliografici I. Sommerville Ingegneria del Software 8a edizione Cap.1 R. Pressman- Principi di Ingegneria del Software- 4 edizione- Cap. 1, 2, 3 F.P. Brooks, No Silver Bullet: Essence and Accidents of Software Engineering, Reperibile all indirizzo: /Readings/Readings1/05-Broo87.pdf Ingegneria del Software 2 Introduzione e Richiami 2 1

2 Sommario 1. Concetti di base sul Software ed Ingegneria del Software 2. Il Ciclo di Vita del Software e le sue attività fondamentali 3. Panoramica sui Modelli di Processo Software fondamentali Ingegneria del Software 2 Introduzione e Richiami 3 Software ed Ingegneria del Software Le economie di tutte le nazioni industrializzate dipendono dalsoftware. Sempre piùsistemi sono controllati dal software. Gli investimenti per il software rappresentano una parte significativa del PIL di tutte le nazioni industrializzate. L Ingegneria del Software è un insieme di teorie, metodi e strumenti per sviluppare software di qualità in maniera professionale. Ingegneria del Software 2 Introduzione e Richiami 4 2

3 Costi del Software I costi del Software spesso dominano i costi complessivi dei sistemi informatici. Addirittura, nel caso di PC, I costi del software sono spesso maggiori dei costi dell hardware stesso. É più costoso manutenere ilsoftware piuttosto che svilupparlo, soprattutto per sistemi di vecchia data (I cosiddetti sistemi legacy). L Ingegneria del software ha come obiettivo riuscire a sviluppare software in maniera efficace e con costi contenuti (cost-effective). Ingegneria del Software 2 Introduzione e Richiami 5 FAQs relative all ingegneria del software Cos è il software? Cos è l ingegneria del software? Perchè l ingegneria del software è importante? Quale è la differenza fra ingegneria del software ed informatica? Cos è l ingegneria dei sistemi? Cos è un processo software? Cos è un modello di processo software? Ingegneria del Software 2 Introduzione e Richiami 6 3

4 FAQs relative all ingegneria del software Quali sono i costi dell ingegneria del software? Quali soni I metodi dell ingegneria del software? Cosa sono i CASE (Computer-Aided Software Engineering)? Quali sono le caratteristiche di un buonsoftware? Quali sono le sfide per l ingegneria del software? Ingegneria del Software 2 Introduzione e Richiami 7 1. Che cos è il software? Programmi per computer con la relativa documentazione, quale ad esempio requisiti, modelli di progetto, e manuali utente. non solo programmi, ma l insieme degli artifatti che lo compongono, prodotti durante il suo sviluppo un programma verrà usato dal suo autore, che lo ha sviluppato senza preoccuparsi di altri utenti, di portabilità, affidabilità, un sistema software, essendo rivolto ad altri utenti, dovrà essere usabile, portabile, affidabile, etc... La definizione IEEE (Institute of Electrical and Electronic Engineers) insieme di programmi, procedure, regole, e ogni altra documentazione relativa al funzionamento di un sistema di elaborazione dati Ingegneria del Software 2 Introduzione e Richiami 8 4

5 Varie Classificazioni per il Software I prodotti software possono essere sviluppati o per un particolare cliente o per il mercato. Il Software può essere: Generico sviluppato per essere venduto a diversi clienti (es. Software per PC come Excel or Word). Personalizzato sviluppato per particolari clienti, secondo le loro richieste. Il software può ossere ottenuto sviluppandolo exnovo, configurando sistemi software generici (es. ERP), o riusando software pre-esistente. Ingegneria del Software 2 Introduzione e Richiami 9 La Natura del Software... Il Software è intangibile Difficile comprenderne la complessità, la qualità, lo sforzo necessario per lo sviluppo Il Software è facile da riprodurre I Costi maggiori sono nel processo di progettazione e sviluppo, diversamente da altri prodotti industriali La produzione del software richiede un grosso impegno intellettivo É difficile da automatizzare Ingegneria del Software 2 Introduzione e Richiami 10 5

6 La Natura del Software... Problemi di qualità: qualunque sviluppatore (anche privo di adeguata preparazione) è in grado di scrivere codice che funzionerà (ma fino a che punto?) I problemi di qualità del software sono difficili da rilevare Il Software è facilmente modificabile Anche senza conoscerlo a fondo pericolo di nuovi bugs Il Software non si consuma Si deteriora nel progetto a causa di modifiche fatte male, o per modifiche che non erano state previste in anticipo La conseguenza è l aumento della complessità interna del software Ingegneria del Software 2 Introduzione e Richiami Che cos è l ingegneria del software? L ingegneria del software è una disciplina ingegneristica che si occupa di tutti gli aspetti relativi allo sviluppo del sofware. Gli ingegneri del software dovrebbero adottare: un approccio sistematico e organizzato per il loro lavoro usando strumenti e tecniche appropriate variabili a seconda del problema da risolvere, dei vincoli di sviluppo, e delle risorse disponibili. Ingegneria del Software 2 Introduzione e Richiami 12 6

7 3. Perchè l ingegneria del software è importante? Il Software deve essere affidabile, sicuro, usabile e manutenibile. L ingegneria del software punta a produrre software con queste caratteristiche e, diversamente dalla programmazione, non si preoccupa solo della funzionalità o di particolari caratteristiche del sistema. L ingegneria del software è particolarmente importante per sistemi da cui dipendono persone e processi di business, e che vengono usati per molti anni. Ingegneria del Software 2 Introduzione e Richiami Quale è la differenza fra ingegneria del software ed informatica? L informatica si occupa delle teorie e dei metodi alla base dei sistemi software ed informatici; l ingegneria del software si occupa degli aspetti pratici relativi alla produzione del software. Anche se le teorie ed i principi informatici sono fondamentali, spesso vengono trascurati dagli ingegneri del software per questioni di praticità (diversamente da quanto accade in altre branche ingegneristiche). Ingegneria del Software 2 Introduzione e Richiami 14 7

8 5. Cos è l ingegneria dei sistemi? L ingegneria dei sistemi si occupa di tutti gli aspetti dello sviluppo ed evoluzione di un sistema informatico, dalla progettazione dell hardware a quella dei processi fino all ingegneria del software stessa. Gli ingegneri dei sistemi si occupano di definire le specifiche del sistema, la sua architettura generale, e di integrarne le varie parti. L ingegneria del software è parte di questo processo e si preoccupa di sviluppare l infrastruttura software, il controllo, le applicazioni ed il database. Ingegneria del Software 2 Introduzione e Richiami Che cos è un processo software? Un insieme di attività aventi per obiettivo lo sviluppo o l evoluzione di un sistema software. Ogni processo software deve includere le seguenti attività fondamentali: Specifica definizione di ciò che il sistema dovrà fare e dei vincoli di progettazione Sviluppo progettazione e programmazione Convalida si verifica che il software sia esattamente ciò che il cliente richiede Evoluzione si modifica il software per adeguarlo a requisiti dell utente e del mercato che cambiano. Ingegneria del Software 2 Introduzione e Richiami 16 8

9 7. Che cos è un modello di processo software? Una descrizione semplificata del processo software, osservato da un determinato punto di vista. Diverse possibili descrizioni: Workflow model descrive la sequenza di attività; Data-flow model evidenzia le trasformazioni dei dati operate dalle attività del processo; Role/action model I ruoli delle persone coinvolte nel processoe le relative responsabilità. Generici modelli di processo Waterfall; Iterative development; Component-based software engineering. Ingegneria del Software 2 Introduzione e Richiami Quali sono i costi dell ingegneria del software? Circa il 60% dei costi è speso per le attività di sviluppo, il 40% per iltesting. Per software personalizzato, I costi per l evoluzione spesso superano quelli di sviluppo. I costi variano in base al tipo di sistema sviluppato e ai requisiti di qualità richiesti quali le prestazioni o l affidabilità. La distribuzione dei costi dipende anche dal tipo di modello di sviluppo adottato. Ingegneria del Software 2 Introduzione e Richiami 18 9

10 Distribuzione dei costi di attività Water fall model Specification Design Development Integration and testing It erative development Specification Iterative development System testing Component-based software eng ineering Specification Development Integration and testing Development and evolution costs for long-lifetime syst ems System development System evolution Ingegneria del Software 2 Introduzione e Richiami 19 Costi di sviluppo di un prodotto generico Specification Development System testing Ingegneria del Software 2 Introduzione e Richiami 20 10

11 9. Cosa sono i metodi di ingegneria del software? Approcci strutturati per sviluppare software di qualità, a costi contenuti. (Es. SADT, JSD, OOA, OOD, etc..) I metodi forniscono indicazioni relativamente a: Modelli di sistema Descrizioni dei modelli grafici da sviluppare; Regole Vincoli che i modelli devono rispettare; Raccomandazioni Consigli che determinano la corretta procedura di progettazione; Guida ai Processi Descrizione delle attività di processo e della relativa organizzazione Ingegneria del Software 2 Introduzione e Richiami Cosa sono i CASE (Computer-Aided Software Engineering)? Sistemi software usati per aiutare le attività di processi software (es.analisi, modellazione, debugging, testing). I sistemi CASE sono spesso usati a supporto di specifici metodi. Upper-CASE Supportano le attività alte del processo, quali la specifica dei requisiti e la progettazione; Lower-CASE Supportano le attività successive, quali la programmazione, il debugging e il testing. Ingegneria del Software 2 Introduzione e Richiami 22 11

12 11. Quali sono le caratteristiche di un buon software? Un software di qualità dovrebbe fornire le funzionalità e le prestazioni richieste essendo contemporaneamente manutenibile, fidato ed accettabile. Manutenibilità Il Software deve essere in grado di evolvere per soddisfare le nuove richieste dei clienti; Fidatezza (Dependability) La fidatezza include l affidabilità, la protezione e la sicurezza; Efficienza Il software non dovrebbe sprecare le risorse del sistema (memoria, CPU); Accettabilità Il Software deve essere accettato dai suoi utenti e pertanto deve essere comprensibile, usabile e compatibile con altri sistemi. Ingegneria del Software 2 Introduzione e Richiami Quali sono le sfide fondamentali per l ingegneria del software? Eterogeneità Definire tecniche in grado di produrre software operativo su piattaforme ed ambienti di esecuzione eterogenei; Consegna Proporre tecniche in grado di consentire la consegna del software in tempi più rapidi, nel rispetto dei requisiti di qualità; Fiducia Sviluppare tecniche che dimostrino agli utenti l affidabilità del software. Ingegneria del Software 2 Introduzione e Richiami 24 12

13 La Natura del Software Conclusioni Senza adeguati sforzi, metodologie e conoscenze il software risultante risulta di qualità scadente, destinata a peggiorare durante il suo ciclo di vita La richiesta di software è elevata e sempre crescente Siamoin perenne crisidel software É necessario imparare ad ingegnerizzare il software Ingegneria del Software 2 Introduzione e Richiami 25 Curva dei guasti per il software Frequenza Failure di guasto rate increased failure rate due to side effects change actual curve idealized curve Time Ingegneria del Software 2 Introduzione e Richiami 26 13

14 No Silver Bullet in Software Engineering L Ingegneria del Software è un attività che coinvolge uomini e macchine L anomalia in questo campo è rappresentata non dalla lentezza dell evoluzione del processo software, ma dalla enorme velocità di evoluzione dell hardware, che rende i prodotti software obsoleti prima che essi possano completare la loro naturale evoluzione Le sfide nel campo dell Ingegneria del software sono quelle della Produttività, Affidabilità, e Semplicità. Ingegneria del Software 2 Introduzione e Richiami 27 No Silver Bullet Brooks in un articolo storico del 1987 afferma che non esiste (e non potrà mai esistere) alcun Silver Bullet (pallottola d argento) che possa risolvere tutti i problemi dell Ingegneria del Software. I problemi derivano da quelle che Brooks definisce Difficoltà Essenziali ed Accidentali nel software Ingegneria del Software 2 Introduzione e Richiami 28 14

15 Essential and Accidental Difficulties Accidental difficulties: sono legate ad aspetti della produzione del software che generano la possibilità di commettere errori: uso di linguaggi macchina complessi, lenti tempi di risposta di alcuni sistemi (es. Batch), etc.. Alcuni miglioramenti nel processo e negli strumenti di sviluppo del software possono però abbattere sensibilmente gli sforzi legati a tali difficoltà: Linguaggi di Alto Livello Time Sharing Ambienti di sviluppo unificati Le Essential difficulties, invece, sono ben più difficili da affrontare Ingegneria del Software 2 Introduzione e Richiami 29 Essential difficulties Complexity: il software deve modellare e controllare problemi complessi Conformity: la complessità del software deriva dalla sua necessità di sottostare ad un insieme di regole/ interfacce poco chiare, perchè dettate da persone diverse (piuttosto che da un elegante modello fisico e matematico). Changeability: i requisiti del software variano molto velocemente, già al tempo stesso di sviluppo Invisibility: il software è invisibile e non visualizzabile: ciò rende difficile mantenerne una vista complessiva Ingegneria del Software 2 Introduzione e Richiami 30 15

16 Speranze passate Linguaggi di programmazione di moderna concezione (es. Ada) Programmazione object oriented Intelligenza artificiale e sistemi esperti Generatori di codice Programmazione grafica Tecniche di testing Ambienti di sviluppo integrati Ingegneria del Software 2 Introduzione e Richiami 31 Buy versus build Soluzioni promettenti attuali (secondo Brooks) Processi evolutivi e prototipali Attenzione alla progettazione di qualità Ingegneria del Software 2 Introduzione e Richiami 32 16

17 Parte 2: Il Ciclo di Vita del Software Ingegneria del Software 2 Introduzione e Richiami 33 Il Ciclo di Vita del Software (CVS) Standard IEEE Software Life Cycle: The period of time that starts whena software product is conceived and ends when the product is no longer available for use. The software life cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation and checkout phase, operation and maintenance phase, and sometimes, retirement phase. Note: These phases may overlap or be performed iteratively. Contrast with Software Development Cycle. Ingegneria del Software 2 Introduzione e Richiami 34 17

18 Standard IEEE Software Development Cycle : (1) The period of time that begins with the decision to develop a software product and ends when the product is delivered. This cycle typically includes a requirements phase, design phase, implementation phase, test phase, and sometimes, installation and checkout phase. Contrast with Software Life Cycle. Notes: The phases listed above may overlap or be performed iteratively, depending upon the software development approach used. (2) This term is sometimes used to mean a longer period of time, either the period that ends when the software is no longer being enhanced by the developer, or the entire software life cycle Ingegneria del Software 2 Introduzione e Richiami 35 Standard IEEE Software Life Cycle: a framework containing the processes, activities,and tasks in the development, operation and maintenance of a software product, spanning the life of the system from the definition of its requirements to the termination of its use Ingegneria del Software 2 Introduzione e Richiami 36 18

19 Relazione fra Ciclo di Vita del Software e Processo Software Processo: un insieme di attività concentrate nel tempo finalizzate alla realizzazione di un particolare output. Processo Software: Un insieme strutturato di attività necessarie per lo sviluppo di un sistema software. Specifica; Progettazione (o Design); Validazione; Evoluzione Ingegneria del Software 2 Introduzione e Richiami 37 Ciclo di Vita e Modelli di Processi Software Un processo software può essere organizzato usando i Cicli di Vita del Software: I CVS definiscono la struttura di massima di un processo software, indicando le fasi in cui si articola e i criteri di successione. Si parla anche di Modello di Processo Software. Un Modello di processo software è una rappresentazione astratta di un processo. Esso fornisceuna descrizione del processoda una particolare prospettiva. Ingegneria del Software 2 Introduzione e Richiami 38 19

20 Generici modelli di processo software Modello a cascata (waterfall model) Prevede fasi ben distinte per la specifica dei requisiti e per lo sviluppo. Sviluppo Evolutivo Specifica, sviluppo e validazione si accavallano. Ingegneria del Software basata su Componenti Il sistema viene assemblato a partire da componenti preesistenti. Ci sono moltevarianti di questi modelli: e.g. sviluppo formale usando il modello a cascata, dove però la specifica è una specifica formale che viene rifinita attraverso varie iterazioni, fino ad arrivare ad un progetto implementabile. Ingegneria del Software 2 Introduzione e Richiami 39 Le Attività di un Processo Software Specifica Software Progettazione ed Implementazione Convalida Evoluzione Ingegneria del Software 2 Introduzione e Richiami 40 20

21 Specifica del Software Il processo che stabilisce quali servizi sono richiesti al software ed i vincoli sia per l operatività che per lo sviluppo. Processo di Ingegneria dei Requisiti Studio di Fattibilità; Raccolta ed Analisi dei requisiti; Specificadei requisiti; Convalida dei requisiti. Ingegneria del Software 2 Introduzione e Richiami 41 Il processo di ingegneria dei requisiti Feasibility stud y Requir ements elicitation and anal ysis Requir ements specification Feasibility repor t Requir ements validation System models User and system requirements Requir ements document Ingegneria del Software 2 Introduzione e Richiami 42 21

22 Progettazione ed Implementazione Processo che converte la specifica del sistema in un sistema eseguibile. Progettazione Software Progettare una struttura software che realizza le specifiche; Implementazione Tradurre la struttura in un codiceeseguibile; Progettazione ed implementazione sono attività strettamente correlate, non necessariamente sequenziali, ma che possono intrecciarsi. Ingegneria del Software 2 Introduzione e Richiami 43 Attività del processo di progettazione Progetto dell Architettura Specifica Astratta Progetto dell Interfaccia Progetto deicomponenti Progetto delle strutture dati Progetto degli algoritmi Ingegneria del Software 2 Introduzione e Richiami 44 22

23 Il processo di progettazione Requirements specification Design activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Design products Ingegneria del Software 2 Introduzione e Richiami 45 Metodi Strutturati Approcci sistematici per produrre il progetto del software. Il progetto è in genere documentato da un insieme di modelli grafici. Possibili modelli Object model; Sequence model; State transition model; Structural model; Data-flow model. Ingegneria del Software 2 Introduzione e Richiami 46 23

24 Programmazione e debugging Traduzione del progetto in un programma eseguibile e rimozione degli errori contenuti nel codice. Programmare è un attività personale- non si può definire nessun processo generico. I Programmatori eseguono anche qualche forma di testing per trovare i difetti nelcodice e rimuoverli nell ambito del processo di debugging. Ingegneria del Software 2 Introduzione e Richiami 47 Convalida del Software La Verifica e Validazione (V & V) punta a mostrare che il software è conforme alle sue specifiche e soddisfa le aspettative del cliente. Verifica: Are we making the right product? Validazione: Are we making the product right? Comprende i processi di controllo, come le ispezioni e le revisioni (ad ogni stadio del processo), ed il testing. Il testing di sistema richiede l esecuzione del sistema con test cases derivati dai dati reali che saranno elaborati dal sistema. Ingegneria del Software 2 Introduzione e Richiami 48 24

25 Il processo di testing Uni t testing Module testing Sub-system t esting System testing Acceptance testing Component testing Integration test ing User testing Ingegneria del Software 2 Introduzione e Richiami 49 Le attività del processo Unit testing Ciascun singolo componente è testato separatamente Module testing Sono testati insiemi di componenti tra loro correlati e dipendenti Sub-system testing I moduli sono integrati in sotto-sistemi e testati. Focus sul testing delle interfacce System testing Testing dell intero sistema come un tutt uno. Testing di particolari proprietà Acceptance testing Testing effettuato insieme al cliente con dati di questi per verificare che il sistema è accettabile Ingegneria del Software 2 Introduzione e Richiami 50 25

26 Le fasi del testing Requir ements specification System specification System design Detailed design Acceptance test plan System integ ration test plan Sub-system integ ration test plan Module and unit code and test Service Acceptance test System integ ration test Sub-system integ ration test Ingegneria del Software 2 Introduzione e Richiami 51 Evoluzione del Software Il software è flessibile per sua natura e può cambiare (più facilmente dell hardware). Man mano che i requisiti cambiano, al cambiare delle esigenze di business, il software che supporta tale business deve evolvere e cambiare. Sebbene ci sia sempre stata una divisione fra processo di sviluppo e quello di manutenzione, tale divisione sta diventando sempre più irrilevante, giacchè si sviluppano sempre meno sistemi completamente ex novo. É più giusto considerare il processo di ingegneria del software come un processo evoluzionistico, in cui il software è continuamente modificato. Ingegneria del Software 2 Introduzione e Richiami 52 26

27 Evoluzione del Sistema Define system requirements Assess existing systems Propose system changes Modify systems Existing systems New system Ingegneria del Software 2 Introduzione e Richiami 53 Parte 3: I Modelli di Processo Software Ingegneria del Software 2 Introduzione e Richiami 54 27

28 Il Waterfall model Requirements definition System and software design Implementa tion and unit testing Integration and system testing Oper ation and maintenance Ingegneria del Software 2 Introduzione e Richiami 55 Il Waterfall model Fasi del Waterfall Model Analisi e definizione dei Requisiti Progettazione del sistemae del software Implementazione e Testing di unità Integrazione e testing di sistema Operatività e manutenzione Vantaggi del modello la fasi da seguire sono ben definite gli output di ciascuna fase precisamente individuati Ingegneria del Software 2 Introduzione e Richiami 56 28

29 Limitazioni del Waterfall model Il modello assume che i requisiti possano essere congelati alla fine della fase di specifica, ma ciò è impensabile per un sistema i cui requisiti non siano ben chiari neanche al committente Di conseguenza questo modello è adatto solo se i requisiti sono ben chiari fin dall inizio ed è difficile che cambino durante lo sviluppo. In realtà pochi sistemipresentano requisiti stabili. Il nuovo sistema software diventa installabile solo quando è totalmente completato In alcuni casi è invece auspicabile sviluppare prima una parte del sistema e poi completarlo (utente finale= mercato) Ingegneria del Software 2 Introduzione e Richiami 57 Applicabilità del Waterfall model Il modello a cascata si usa per lo più quando fa parte di un progetto più vasto di ingegneria dei sistemi. Ingegneria del Software 2 Introduzione e Richiami 58 29

30 Sviluppo Evolutivo Basato sull idea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraverso varie versioni. Due modelli fondamentali: Sviluppo Esplorativo L obiettivo è di lavorare colcliente per esaminare i requisiti iniziali e farli evolvere fino al sistema finale. Dovrebbe partire da pochi requisiti ben compresi e aggiungere nuove caratteristiche proposte dal cliente. Prototipo Usa e Getta L obiettivo è di comprendere i requisiti del sistema. Si parte da requisiti poco chiari e si realizzano prototipi per esplorare i requisiti e chiarirli. Ingegneria del Software 2 Introduzione e Richiami 59 Sviluppo evolutivo- Esplorativo Concurr ent acti vities Specifica tion Initial version Outline description Development Inter media te versions Valida tion Final version Ingegneria del Software 2 Introduzione e Richiami 60 30

31 Sviluppo evolutivo Problemi Mancanza di visibilità del processo (è anti-economico documentare ogni versione del sistema); I sistemi diventano spesso mal strutturati (per i continui cambiamenti); Richiedono particolari skills (es. Uso di linguaggi di prototipazione rapida) Applicabilità A sistemi interattivi di piccole e medie dimensioni (< LOC); Per sviluppare alcune parti di sistemi di grandi dimensioni (per es. l interfaccia utente); Per sistemi destinati a vita breve. Per grandi sistemi è consigliabile un approccio misto. Ingegneria del Software 2 Introduzione e Richiami 61 Sviluppo Evolutivo- Basato su Prototipo Usato per superare i problemi relativi alla valutazione della fattibilità ed alla comprensione dei requisiti del committente Realizzazione di una prima implementazione (prototipo), più o meno incompleta da considerare come una prova, con lo scopo di: accertare la Fattibilità del prodotto validare i Requisiti Dopo la fase di utilizzo del prototipo si passa alla produzione della versione definitiva del Sistema Sw mediante un modello che, in generale, è di tipo waterfall. Ingegneria del Software 2 Introduzione e Richiami 62 31

32 Due tipi di Approccio Prototipale: Modelli con Sistema Pilota (fattibilità) Modelli con Prototipazione (requisiti) Ingegneria del Software 2 Introduzione e Richiami 63 Modelli con Sistema Pilota Orientati all accertamento della fattibilità Costruzione di un PILOT per stabilire se il problema sia risolubile attraverso una sua implementazione. Il pilota è: Esplorativo (è una versione completa ma rozza del sistema) non orientato alla produzione (non ci si preoccupa di come poi si andrà a produrre il Sistema finale) fornisce feedbacks ed indicazioni per la definizione di un prodotto finale migliore e più utile Ingegneria del Software 2 Introduzione e Richiami 64 32

33 Modello con Prototipo (Usa e Getta) Ingegneria del Software 2 Introduzione e Richiami 65 Modello Prototipale 2 tipi di prototipazione: mock-ups: produzione completa dell interfaccia utente. Consente di definire con completezza e senza ambiguità i requisiti (si può, già in questa fase, definire il manuale di utente) breadboards: implementazione di sottoinsiemi di funzionalità critiche del SS, non nel senso della fattibilità ma in quello dei vincoli pesanti che sono posti nel funzionamento del SS (carichi elevati, tempo di risposta,...), senza le interfacce utente. Produce feedbacks su come implementare la funzionalità (in pratica si cerca di conoscere prima di garantire). Ingegneria del Software 2 Introduzione e Richiami 66 33

34 Ingegneria del software basata su componenti (CBSE) Sviluppo basato sul riuso sistematico, integrando componenti esistenti o interi sistemi COTS (Commercial-offthe-shelf) Fasi del Processo Specifica dei requisiti; Analisi dei componenti; Modifica dei Requisiti (specificando i componenti disponibili); Progettazione con riuso; Sviluppo e Integrazione. Questo approccio viene sempre più usato grazie all affermarsi di appositi standard per la specifica di componenti. Ingegneria del Software 2 Introduzione e Richiami 67 Sviluppo basato su Componenti Requirements specification Component analysis Requirements modification System design with reuse Development and integ ration System validation Ingegneria del Software 2 Introduzione e Richiami 68 34

35 Processi di sviluppo Iterativi I requisiti di un sistema cambiano SEMPRE nel corso di un progetto, e sono pertanto inevitabili nuovi cicli di processo in cui si ritorna sulle fasi già condotte, soprattutto per grandi sistemi. I cicli di processo possono essere applicati ad ogni generico modello di processo. Due possibili approcci: Sviluppo e Consegna Incrementale; Sviluppo a Spirale. Ingegneria del Software 2 Introduzione e Richiami 69 Sviluppo e Consegna Incrementale Piuttosto che consegnare il sistema tutto in una volta, lo sviluppo e la consegna sono eseguiti per incrementi,dove ogni incremento rilascia parte delle funzionalità richieste. Ai requisiti Utente vengono associati livelli di priorità e quelli a priorità maggiore vengono rilasciati con I primi incrementi. Una volta partito lo sviluppo di un incremento, I relativi requisiti devono essere congelati, mentre I requisiti coinvolti in incrementi successivi possono continuare ad evolvere. I servizi comuni possono essere implementati all inizio del processo, o quando una funzione è richiesta da un dato incremento. Ingegneria del Software 2 Introduzione e Richiami 70 35

36 C om m u ni c a t i o n Pl a n ni n g C o m m u ni ca t i on M o de l i n g a nalys is Co n st ru ct i o n d esign c ode t est Pl a n ni ng D ep l o ym en t d e l i ve ry f e e db a ck M o d el i n g anal ysis desi gn Co n s t ru c t i o n code t est D e pl o y m e nt d e l i v ery f Co m m un i c at i o n ee d ba c k Pl a n ni ng M o de l i n g anal ysi s desi gn Co n st code t est ru c t i o n De p l o ym e n t d el i ve ry f e ed b ac k Sviluppo e Consegna Incrementale Define outline requirements Assign requirements to increments Design system ar chitectur e Develop system increment Validate increment Integrate increment Validate system Final system System incomplete Ingegneria del Software 2 Introduzione e Richiami 71 Modello a sviluppo e consegna incrementale inc rem e nt # n in cr em en t # 2 de li ve r y o f nt h in cr e m en t in c rem en t # 1 d el ive r y o f 2 nd in cr em e n t d eli ve r y o f 1 st in cre m e n t project calendar time Ingegneria del Software 2 Introduzione e Richiami 72 36

37 Vantaggi dello sviluppo incrementale I clienti non devono aspettare il sistema completo per la consegna, ma possono disporre al più presto dei requisiti più critici, attraverso I primi incrementi. I primi incrementi possono essere usati come prototipo per aiutare a definire I requisiti degli incrementi successivi. Si riduceil rischio di un fallimento totale del progetto. I servizi a più alta priorità saranno anche testati più intensamente degli altri. Ingegneria del Software 2 Introduzione e Richiami 73 Problemi dello sviluppo Incrementale Alcuni Problemi Gli incrementi devono essere relativamente piccoli (<= LOC) ma può essere difficile predisporre i requisiti in incrementi della dimensione giusta. Le funzionalità comuni (richieste da più requisiti) potrebbero non essere identificate abbastanza presto, giacchè bisogna prima attendere che gli incrementi siano completati per avere ben chiari tutti i requisiti. Ingegneria del Software 2 Introduzione e Richiami 74 37

38 Extreme programming Extreme Programming Un esempio di approccio allo sviluppo basato su sviluppo e consegna di piccolissimiincrementi di funzionalità. Si basasuun continuo miglioramento del codice, sul coinvolgimento dell utente nel processo di sviluppo, e sulla programmazione a coppie. Ingegneria del Software 2 Introduzione e Richiami 75 Sviluppo a Spirale (di Boehm) Il processo è rappresentato come una spirale, piuttosto che una sequenza di attività con retroazioni. Ogni giro nella spirale rappresenta una fase del processo. Non prevede fasi prefissate a priori (come la specifica o il design) ma i cicli sono definiti in base al caso specifico. C è una esplicita gestione dei rischi che vengono valutati e risolti durante tutto il processo. Metamodello perché comporta la selezione di un modello di CVS da adottare nello sviluppo. Ingegneria del Software 2 Introduzione e Richiami 76 38

39 Modello di sviluppo a spirale Deter mine objecti ves, alterna tives and constr aints Determinazione di obiettivi, alternative e vincoli Pianificazione della fase successiva Plan ne xt phase REVIEW Requir ements plan Life-cycle plan De velopment plan Integ ration and test plan Risk anal ysis Risk anal ysis Risk analysis Pr ototype 2 Risk anal ysis Pr ototype 1 Concept of Oper ation S/W requir ements Requir ement v alidation Design V&V Acceptance Service test Pr ototype 3 Oper a- tional pr oto ype Simula tions, models, benchmar ks Product design Integ ra tion test Valutazione di alternative, identificazione e risoluzione dei rischi Evalua te alterna tives, identify, resolv e risks Unit test Detailed design Ingegneria del Software 2 Introduzione e Richiami 77 Code De velop, verify ne xt-level pr oduct Sviluppo e Verifica del prodotto successivo Settori del modello a spirale Determinazione degli obiettivi Definizione di obiettivi, vincoli e piano di gestione della fase. Valutazione e riduzione del rischio Si analizzano I rischi della fase e si scelgono le attività necessarie a gestire I rischi. Sviluppo e Convalida Si sceglie un modello di sviluppo per il sistema tra I modelli generici. Pianificazione Il progetto viene revisionato e si decide se continuare con un nuovo giro della spirale. Si pianifica tale giro. Ingegneria del Software 2 Introduzione e Richiami 78 39

40 Il RUP (Rational Unified Process) Ingegneria del Software 2 Introduzione e Richiami 79 Ingegneria del Software 2 Introduzione e Richiami 80 40

41 Rational Unified Process (RUP) Un moderno modello di processo software derivato da UML e dal relativo processo. Include tutte le caratteristiche dei modelli generici (sviluppo iterativo ed incrementale) Individua 3 prospettive sul processo: Una prospettiva dinamica che mostra le fasi del modello al fluire del tempo; Una prospettiva statica che mostra le attività (workflow) coinvolte; Una prospettiva pratica che suggerisce le buone regole da seguire. Ingegneria del Software 2 Introduzione e Richiami 81 Prospettiva dinamica: Le fasi del RUP Phase iteration Inception Elaboration Construction Transition Avvio Elaborazione Costruzione Transizione Ingegneria del Software 2 Introduzione e Richiami 82 41

42 Le fasi del RUP Avvio Stabilire gli obiettivi di business (e relativi limiti, fattibilità e giustificazioni economiche) per il sistema. Elaborazione Ottenere una comprensione del dominio del problema (e specificare i requisiti), stabilire una struttura architetturale ed il piano di progetto. Costruzione Progettare, programmare e testare il sistema incrementalmente. Transizione Trasferire il sistema nel suo ambiente operativo. Ingegneria del Software 2 Introduzione e Richiami 83 Fasi, Iterazioni ed Incrementi Ogni fase può essere eseguita in modo ciclico, con risultati sviluppati in modo incrementale. Anche l intero sistema delle fasi può essere ripetuto ciclicamente. Ingegneria del Software 2 Introduzione e Richiami 84 42

43 Prospettiva Statica: I Workflow Il RUP prevede vari workflow (6 attività principali e 3 di supporto): Modellazione Processi di business Requisiti Analisi e Progettazione Implementazione Test Rilascio Gestione della configurazione e delle modifiche Gestione del Progetto Ambiente Ingegneria del Software 2 Introduzione e Richiami 85 Workflows statici Workflow Business modelling Requirements Analysis and design Implementation Test Deployment Configuration and change management Project management Environment Description The business processes are modelled using business u se cases. Actors who interact with the system are identified and use cases are developed to model the system requirements. A design model is created and documented u sing architectural mode ls, componen t models, object models and sequence models. The components in the system are implemented and structured into implementation sub- systems. Automatic code generation from d esign mode ls helps accelerate this process. Testing is an iterative process that is carried out in conjunction with implementation. System testing follows the completion of the implementation. A product release is created, distributed to users and installed in their workp lace. Thi s supporting workf low managed changes to th e system (see Chapt er 29). Thi s supporting workf low manages the system development (see Chapt er 5). Thi s workflow is concerned with making appropriate software tools available to the software development team. Ingegneria del Software 2 Introduzione e Richiami 86 43

44 Workflow e Fasi Tutti i workflow del RUP possono essere eseguiti in qualunque iterazione del processo. Ovviamente nelle prime iterazioni gli sforzi si concentreranno sui workflow di modellazione e dei requisiti, nelle successive sulla implementazione e sul test. Ingegneria del Software 2 Introduzione e Richiami 87 Distribuzione dei workflow per fasi UP Phases Workflows Incept ion Elabor at ion Const ruct ion Tr ansition Production Requirements Analysis Design Implementation Test Support Iterations #1 #2 #n-1 #n Ingegneria del Software 2 Introduzione e Richiami 88 44

45 Le pratiche fondamentali del RUP Sviluppare il software iterativamente: Pianificare gli incrementi in base alle priorità del cliente Gestire i requisiti: Documentare esplicitamente I requisiti ed I cambiamenti effettuati Usare architetture basate sucomponenti: Strutturare l architettura con un approccio a componenti Creare modelli visuali del software: Usare modelli grafici UML per rappresentare viste statiche e dinamiche del sistema Verificare la qualità del software: Verificare l aderenza a standard di qualità aziendali Controllare le modifiche al software: Gestire I cambiamenti e le configurazioni del software Ingegneria del Software 2 Introduzione e Richiami 89 Configurazione del RUP Il RUP è un processo generico di sviluppo software: deve essere istanziato per ciascuna organizzazione e per ciascun progetto specifico, aggiungendo: standard, modelli di documento standard, strumenti, Punti di forza: Separazione di fasi e workflow Le fasi sono dinamiche e vanno pianificate, i workflow sono statici e sono attività tecniche condotte nelle varie fasi Comprende un vasto insieme di linee guida e template per operare con approccio OO e basato su componenti Definisce in modo accurato: Ruoli, Attività, Input Output delle varie attività Ingegneria del Software 2 Introduzione e Richiami 90 45

46 Costi del RUP Impatto organizzativo Può portare ad una riorganizzazione completa del lavoro Impatto culturale Può comportare una ridefinizione del modo di lavorare Costi tecnologici L utilizzo del processo é agevolato dall uso di strumenti (tool) specifici (come quelli della suite Rational) Costi di avvio Adattamento del processo Divulgazione Inquadramento dei processiesistenti Spesso si rinuncia ad adottare il RUP proprio perchè esso comporta un drastico cambiamento nel modo di lavorare delle persone, che potrebbero reagire (sul breve termine) diminuendo la loro produttività Ingegneria del Software 2 Introduzione e Richiami 91 Selezione di un Modello di Processo: qualche linea guida tolleranza del modello ai rischi che si potranno incontrare facilità di comunicazione tra sviluppatori e utilizzatori stabilità dei requisiti noti; probabilità di esistenza di requisiti (ancora) non noti importanza di rilasci early di (parziali) funzionalità Intrinseca complessità del problema e delle probabili soluzioni (anticipata) conoscenza di frequenza e dimensione di richieste di cambiamento maturità dell applicazione (o del dominio applicativo) disponibilità e priorità di fondi flessibilità dello scheduling e budget (scadenze per il ricevimento e spesa dei fondi; possibilità di modificare gli incrementi per ottimizzare costi e minimizzare rischi) criticità del rispetto di scheduling e budget adeguatezza del processo istituzionale e tool di sviluppo dello sviluppatore corrispondenza tra organizzazione del management e il modello da adottare Ingegneria del Software 2 Introduzione e Richiami 92 46