Ingegneria del Software Ingegneria del Software

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