2 IntroduzioneERichiami

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

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.
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
19
Costi di sviluppo di un prodotto generico
25
50
75
100
Specification
Development
System testing
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
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.
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
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
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
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

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
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
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
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
30
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
31
Soluzioni promettenti attuali (secondo Brooks)

Buy versus build Processi evolutivi e prototipali Attenzione alla progettazione di qualit
32
16
Parte 2: Il Ciclo di Vita del Software
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.
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
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
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
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.
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
Le Attivit di un Processo Software
Specifica Software Progettazione ed Implementazione Convalida Evoluzione
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.
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
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

43
Attivit del processo di progettazione
Progetto dellArchitettura Specifica Astratta Progetto dellInterfaccia Progetto dei Componenti Progetto delle strutture dati Progetto degli algoritmi
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
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.
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.
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
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
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
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
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.
52
26
Evoluzione del Sistema
Define system requirements
Assess existing systems
Propose system changes
Modify systems
Existing systems
New system
53
Parte 3: I Modelli di Processo Software
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
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
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)
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.
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.
Sviluppo evolutivo- Esplorativo

Concurr ent acti vities Initial version
Specifica tion
Outline description
Development
Inter media te versions
V alida tion
Final version
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
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.
31
Due tipi di Approccio Prototipale: Modelli con Sistema Pilota (fattibilit) Modelli con Prototipazione (requisiti)
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
64
32
Modello con Prototipo (Usa e Getta)
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).
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.
Sviluppo basato su Componenti
Requirements specification
Component analysis
Requirements modification
System design with reuse
Development and integ ration
System validation
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
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.
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
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
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.
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.
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.
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
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
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.
78
39
Il RUP (Rational Unified Process)
79
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.
81
Prospettiva dinamica: Le fasi del RUP

Phase iteration
Inception Avvio
Elaboration
Elaborazione
Construction Costruzione
Transition Transizione
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.
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.
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
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
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.
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
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
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
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
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
46

2 IntroduzioneERichiami

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2 IntroduzioneERichiami

Uploaded by

Copyright:

Available Formats

Ingegneria del Software II -Introduzione e Richiami -

Ingegneria del Software 2 Introduzione e Richiami

Ingegneria del Software 2 Introduzione e Richiami

Ingegneria del Software 2 Introduzione e Richiami

Software ed Ingegneria del Software

Ingegneria del Software 2 Introduzione e Richiami

Costi del Software

Ingegneria del Software 2 Introduzione e Richiami

FAQs relative allingegneria del software

Ingegneria del Software 2 Introduzione e Richiami

FAQs relative allingegneria del software

Ingegneria del Software 2 Introduzione e Richiami

1. Che cos il software?

La definizione IEEE (Institute of Electrical and Electronic Engineers)

Ingegneria del Software 2 Introduzione e Richiami

Varie Classificazioni per il Software

La Natura del Software...

Il Software facile da riprodurre

La produzione del software richiede un grosso impegno intellettivo

Ingegneria del Software 2 Introduzione e Richiami

La Natura del Software...

Ingegneria del Software 2 Introduzione e Richiami

2. Che cos l ingegneria del software?

Ingegneria del Software 2 Introduzione e Richiami

3. Perch lingegneria del software importante?

Ingegneria del Software 2 Introduzione e Richiami

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

Ingegneria del Software 2 Introduzione e Richiami

5. Cos lingegneria dei sistemi?

Ingegneria del Software 2 Introduzione e Richiami

6. Che cos un processo software?

Ingegneria del Software 2 Introduzione e Richiami

7. Che cos un modello di processo software ?

Generici modelli di processo

Ingegneria del Software 2 Introduzione e Richiami

8. Quali sono i costi dellingegneria del software?

Ingegneria del Software 2 Introduzione e Richiami

Distribuzione dei costi di attivit

Integration and testing

It erative development 0 25 50 75 100

Iterative development ineering 50 75

Component-based software eng 0 25

Integration and testing

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

Ingegneria del Software 2 Introduzione e Richiami

Costi di sviluppo di un prodotto generico

Ingegneria del Software 2 Introduzione e Richiami

9. Cosa sono i metodi di ingegneria del software?

Ingegneria del Software 2 Introduzione e Richiami

10. Cosa sono i CASE (Computer-Aided Software Engineering)?

Ingegneria del Software 2 Introduzione e Richiami

11. Quali sono le caratteristiche di un buon software?

Ingegneria del Software 2 Introduzione e Richiami

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

Ingegneria del Software 2 Introduzione e Richiami

La Natura del Software

Ingegneria del Software 2 Introduzione e Richiami

Curva dei guasti per il software

Frequenza Failure rate di guasto

change actual curve

idealized curve Time

No Silver Bullet in Software Engineering

Ingegneria del Software 2 Introduzione e Richiami