Sei sulla pagina 1di 46

Ingegneria del Software II -Introduzione e Richiami -

Ingegneria del Software 2 Introduzione e Richiami

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, 2003. Reperibile allindirizzo: http://www.lips.utexas.edu/ee382c15005/Readings/Readings1/05-Broo87.pdf

Ingegneria del Software 2 Introduzione e Richiami

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

Software ed Ingegneria del Software


Le economie di tutte le nazioni industrializzate dipendono dal software. Sempre pi sistemi sono controllati dal software. Gli investimenti per il software rappresentano una parte significativa del PIL di tutte le nazioni industrializzate. LIngegneria del Software un insieme di teorie , metodi e strumenti per sviluppare software di qualit in maniera professionale .

Ingegneria del Software 2 Introduzione e Richiami

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 dellhardware stesso. pi costoso manutenere il software piuttosto che svilupparlo, soprattutto per sistemi di vecchia data (I cosiddetti sistemi legacy). LIngegneria 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

FAQs relative allingegneria del software


Cos il software? Cos lingegneria del software? Perch lingegneria del software importante? Quale la differenza fra ingegneria del software ed informatica? Cos lingegneria dei sistemi? Cos un processo software? Cos un modello di processo software?

Ingegneria del Software 2 Introduzione e Richiami

FAQs relative allingegneria del software


Quali sono i costi dellingegneria del software? Quali soni I metodi dell ingegneria del software? Cosa sono i CASE (Computer-Aided Software Engineering)? Quali sono le caratteristiche di un buon software? Quali sono le sfide per l ingegneria del software?

Ingegneria del Software 2 Introduzione e Richiami

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 linsieme 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
8

Ingegneria del Software 2 Introduzione e Richiami

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

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 laumento della complessit interna del software

Ingegneria del Software 2 Introduzione e Richiami

11

2. 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

3. Perch lingegneria del software importante?


Il Software deve essere affidabile, sicuro, usabile e manutenibile. Lingegneria 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. Lingegneria 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

13

4. Quale la differenza fra ingegneria del software ed informatica?


Linformatica si occupa delle teorie e dei metodi alla base dei sistemi software ed informatici; lingegneria 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

5. Cos lingegneria dei sistemi?


Lingegneria dei sistemi si occupa di tutti gli aspetti dello sviluppo ed evoluzione di un sistema informatico, dalla progettazione dellhardware a quella dei processi fino allingegneria 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. Lingegneria del software parte di questo processo e si preoccupa di sviluppare linfrastruttura software, il controllo, le applicazioni ed il database.

Ingegneria del Software 2 Introduzione e Richiami

15

6. Che cos un processo software?


Un insieme di attivit aventi per obiettivo lo sviluppo o levoluzione 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 dellutente e del mercato che cambiano.

Ingegneria del Software 2 Introduzione e Richiami

16

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 processo e le relative responsabilit . Waterfall; Iterative development; Component-based software engineering.
17

Generici modelli di processo


Ingegneria del Software 2 Introduzione e Richiami

8. Quali sono i costi dellingegneria del software?


Circa il 60% dei costi speso per le attivit di sviluppo, il 40% per il testing. Per software personalizzato , I costi per levoluzione 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 laffidabilit. La distribuzione dei costi dipende anche dal tipo di modello di sviluppo adottato.

Ingegneria del Software 2 Introduzione e Richiami

18

Distribuzione dei costi di attivit


Water fall model 0 25 50 75 100

Specification

Design

Development

Integration and testing

It erative development 0 25 50 75 100

Specification

Iterative development ineering 50 75

System testing

Component-based software eng 0 25

100

Specification

Development

Integration and testing

Development and evolution costs for long-lifetime syst 0 10 200

ems 30 400

System development

System evolution

Ingegneria del Software 2 Introduzione e Richiami

19

Costi di sviluppo di un prodotto generico

25

50

75

100

Specification

Development

System testing

Ingegneria del Software 2 Introduzione e Richiami

20

10

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

21

10. 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

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 laffidabilit, 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.
23

Ingegneria del Software 2 Introduzione e Richiami

12. Quali sono le sfide fondamentali per lingegneria del software?


Eterogeneit
Definire tecniche in grado di produrre software operativo su piattaforme ed ambienti di esecuzione eterogenei; Proporre tecniche in grado di consentire la consegna del software in tempi pi rapidi, nel rispetto dei requisiti di qualit; Sviluppare tecniche che dimostrino agli utenti laffidabilit del software.
24

Consegna

Fiducia

Ingegneria del Software 2 Introduzione e Richiami

12

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 Siamo in perenne crisi del software necessario imparare ad ingegnerizzareil software

Ingegneria del Software 2 Introduzione e Richiami

25

Curva dei guasti per il software


increased failure rate due to side effects

Frequenza Failure rate di guasto

change actual curve

idealized curve Time


Ingegneria del Software 2 Introduzione e Richiami 26

13

No Silver Bullet in Software Engineering


LIngegneria del Software unattivit che coinvolge
uomini e macchine Lanomalia in questo campo rappresentata non dalla lentezza dellevoluzione del processo software, ma dalla enorme velocit di evoluzione dellhardware, che rende i prodotti software obsoleti prima che essi possano completare la loro naturale evoluzione Le sfide nel campo dellIngegneria del software sono quelle della Produttivit, Affidabilit, e Semplicit.
http://www.lips.utexas.edu/ee382c -15005/Readings/Readings1/05-Broo87.pdf
27

Ingegneria del Software 2 Introduzione e Richiami

No Silver Bullet

Brooks in un articolo storico del 1987 afferma che non esiste (e non potr mai esistere) alcun Silver Bullet (pallottola dargento) che possa risolvere tutti i problemi dellIngegneria 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

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
http://www.lips.utexas.edu/ee382c -15005/Readings/Readings1/05-Broo87.pdf
29

Ingegneria del Software 2 Introduzione e Richiami

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
http://www.lips.utexas.edu/ee382c -15005/Readings/Readings1/05-Broo87.pdf
30

Ingegneria del Software 2 Introduzione e Richiami

15

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
http://www.lips.utexas.edu/ee382c -15005/Readings/Readings1/05-Broo87.pdf
31

Ingegneria del Software 2 Introduzione e Richiami

Soluzioni promettenti attuali (secondo Brooks)


Buy versus build Processi evolutivi e prototipali Attenzione alla progettazione di qualit

http://www.lips.utexas.edu/ee382c -15005/Readings/Readings1/05-Broo87.pdf
32

Ingegneria del Software 2 Introduzione e Richiami

16

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 610.12-1990 Software Life Cycle: The period of time that starts when a 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

Standard IEEE 610.12-1990 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 12207.0-1996

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

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 fornisce una descrizione del processo da una particolare prospettiva.

Ingegneria del Software 2 Introduzione e Richiami

38

19

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. Il sistema viene assemblato a partire da componenti preesistenti.

Ingegneria del Software basata su Componenti

Ci sono molte varianti 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.
39

Ingegneria del Software 2 Introduzione e Richiami

Le Attivit di un Processo Software

Specifica Software Progettazione ed Implementazione Convalida Evoluzione

Ingegneria del Software 2 Introduzione e Richiami

40

20

Specifica del Software


Il processo che stabilisce quali servizi sono richiesti al software ed i vincoli sia per loperativit che per lo sviluppo. Processo di Ingegneria dei Requisiti
Studio di Fattibilit; Raccolta ed Analisi dei requisiti; Specifica dei 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 System models User and system requirements Requir ements document Requir ements validation

Ingegneria del Software 2 Introduzione e Richiami

42

21

Progettazione ed Implementazione
Processo che converte la specifica del sistema in un sistema eseguibile. Progettazione Software
Progettare una struttura software che realizza le specifiche; Tradurre la struttura in un codice eseguibile; Progettazione ed implementazione sono attivit strettamente correlate, non necessariamente sequenziali, ma che possono intrecciarsi.

Implementazione

Ingegneria del Software 2 Introduzione e Richiami

43

Attivit del processo di progettazione

Progetto dellArchitettura Specifica Astratta Progetto dellInterfaccia Progetto dei Componenti Progetto delle strutture dati Progetto degli algoritmi

Ingegneria del Software 2 Introduzione e Richiami

44

22

Il processo di progettazione

Requirements specifica tion Design activities Ar chitectural design Abstract specifica tion Interface design Component design Data structure design Algorithm design

System architecture

Software specifica tion

Interface specifica tion

Component specification

Data structure specifica tion

Algorithm specifica tion

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

Programmazione e debugging
Traduzione del progetto in un programma eseguibile e rimozione degli errori contenuti nel codice. Programmare unattivit personale - non si pu definire nessun processo generico. I Programmatori eseguono anche qualche forma di testing per trovare i difetti nel codice e rimuoverli nellambito 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 lesecuzione del sistema con test cases derivati dai dati reali che saranno elaborati dal sistema.
48

Ingegneria del Software 2 Introduzione e Richiami

24

Il processo di testing
Uni t testing Module testing Sub-system t esting System testing Acceptance testing

Component testing

Integration test ing

User testing
49

Ingegneria del Software 2 Introduzione e Richiami

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 dellintero sistema come un tuttuno. Testing di particolari propriet Acceptance testing Testing effettuato insieme al cliente con dati di questi per verificare che il sistema accettabile
50

Ingegneria del Software 2 Introduzione e Richiami

25

Le fasi del testing

Requir ements specifica tion

System specifica tion

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 dellhardware). 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

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

Il Waterfall model
R equirements definition System and software design Implementa tion and unit testing Integ r ation and system testing Oper a tionand maintenance

Ingegneria del Software 2 Introduzione e Richiami

55

Il Waterfall model
Fasi del Waterfall Model

Analisi e definizione dei Requisiti Progettazione del sistema e 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

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 dallinizio ed difficile che cambino durante lo sviluppo. In realt pochi sistemi presentano 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

Sviluppo Evolutivo
Basato sullidea di produrre una versione iniziale del software, esporla agli utenti e perfezionarla attraverso varie versioni. Due modelli fondamentali: Sviluppo Esplorativo Lobiettivo di lavorare col cliente 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 Lobiettivo 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 Initial version

Specifica tion

Outline description

Development

Inter media te versions

V alida tion

Final version

Ingegneria del Software 2 Introduzione e Richiami

60

30

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) A sistemi interattivi di piccole e medie dimensioni (<500.000 LOC); Per sviluppare alcune parti di sistemi di grandi dimensioni (per es. linterfaccia utente); Per sistemi destinati a vita breve.

Applicabilit

Per grandi sistemi consigliabile un approccio misto.


61

Ingegneria del Software 2 Introduzione e Richiami

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

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 allaccertamento 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

Modello con Prototipo (Usa e Getta)

Ingegneria del Software 2 Introduzione e Richiami

65

Modello Prototipale
2 tipi di prototipazione: mock-ups: produzione completa dellinterfaccia 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

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 allaffermarsi 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

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 .
69

Ingegneria del Software 2 Introduzione e Richiami

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 allinizio del processo, o quando una funzione richiesta da un dato incremento.
Ingegneria del Software 2 Introduzione e Richiami 70

35

Sviluppo e Consegna Incrementale

Define outline requirements

Assign requirements to increments

Design system ar chitectur e

Develop system increment

V alida te incr ement

Integ rate incr ement

V alidate system Final system

System incomplete

Ingegneria del Software 2 Introduzione e Richiami

71

Modello a sviluppo e consegna incrementale

inc rem e nt # n
Co m m un i c a t i o n Pl a n ni ng M o de l i n g anal y s i s des i gn Co n s t c ode t es t ru c ti o n De p l o y m e n t d el i ve r y f e ed b ac k

in cr em en t # 2
C o m m u ni ca t i on Pl a n ni ng M o d el i n g anal y s i s des i gn

de li ve r y o f nt h in cr e m en t

Co n s t r u c t i o n c ode t es t

D e pl o y m e nt d e l i v er y f e e d ba c k

in c rem en t # 1
C om m u ni c a t i o n Pl a n ni n g M o de l i n g a nal ys i s d es i gn

d el ive r y o f 2 nd in cr em e n t

Co n s t r u c t c ode t es t

i o n D ep l o ym en t d e l i ve r y f e e db a c k

d eli ve r y o f 1 st in cre m e n t

p ro je ct c alen d a r t im e

Ingegneria del Software 2 Introduzione e Richiami

72

36

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 riduce il 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 (<=20.000 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

Extreme programming
Extreme Programming
Un esempio di approccio allo sviluppo basato su sviluppo e consegna di piccolissimi incrementi di funzionalit. Si basa su un continuo miglioramento del codice, sul coinvolgimento dellutente 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.
76

Ingegneria del Software 2 Introduzione e Richiami

38

Modello di sviluppo a spirale


Determinazione di alterna tives and constr aints obiettivi, alternative e vincoli
Deter mine objecti ves, Risk analysis Risk anal ysis Risk anal ysis Pr ototype 2 REVIEW Requir ements plan Life-cycle plan Risk anal ysis Pr ototype 1 Simula tions , models , benchmar ks Concept of Oper ation Evalua te alterna tives, identify, r esolv e risks

Valutazione di alternative, identificazione e risoluzione dei rischi


Oper ational pr oto ype

Pr ototype 3

S/W requir ements

Product design

De velopment plan Integ ration and test plan

Requir ement v alidation Design V&V Acceptance test Unit test Integ ra tion test

Detailed design Code

Pianificazione Plan ne xt phase della fase successiva

Service

De velop , verify ne xt-level pr oduct

Ingegneria del Software 2 Introduzione e Richiami

Sviluppo e Verifica del prodotto successivo


77

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

Il RUP (Rational Unified Process)

Ingegneria del Software 2 Introduzione e Richiami

79

Ingegneria del Software 2 Introduzione e Richiami

80

40

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 Avvio

Elaboration

Elaborazione

Construction Costruzione

Transition Transizione

Ingegneria del Software 2 Introduzione e Richiami

82

41

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 lintero sistema delle fasi pu essere ripetuto ciclicamente.

Ingegneria del Software 2 Introduzione e Richiami

84

42

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
85

Ingegneria del Software 2 Introduzione e Richiami

Workflows statici
Workfl ow Business modelling Requi rements Analysis and design Impl ementation Description T he business processes are modelled using bu siness u se cases . Actors who interact with the system are identified and use cases are developed to model the sy stem requirements. A design model is created and do cumented u sing architectural mode ls, componen t models, object models and sequence models. T he components in the sy stem are implemented and structured into implementation sub- sy stems. Automatic code generation from d esign mode ls helps accelerate this process. T esting is an iterative process that is carried ou t in conjunction with implementation. Sy stem testing follows the completion of the implementation. A product release is created, distributed to users and installed in their workp lace. T hi s supporting work f low managed changes to th e sy stem (see Chapt er 29). T hi s supporting work f low manages the system development (s ee Chapt er 5). T hi s workflow is concerned with making appropriate software tools available to the software development team.
86

Test

Deployment Configuration and change management Project management Envi ronment

Ingegneria del Software 2 Introduzione e Richiami

43

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
In ce pt io n El ab or at io n Con st ru ct io n Tr an siti o n Pro d u cti on

Workflows Requirements

Analysis Design

Implementation Test Support Iterations #1 #2 #n-1 #n

Ingegneria del Software 2 Introduzione e Richiami

88

44

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 su componenti: Strutturare larchitettura 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 laderenza a standard di qualit aziendali Controllare le modifiche al software: Gestire I cambiamenti e le configurazioni del software
89

Ingegneria del Software 2 Introduzione e Richiami

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

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 Lutilizzo del processo agevolato dalluso di strumenti (tool) specifici (come quelli della suite Rational) Costi di avvio Adattamento del processo Divulgazione Inquadramento dei processi esistenti 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
91

Ingegneria del Software 2 Introduzione e Richiami

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 dellapplicazione (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