Appunti di Ingegneria del software

Matilde Simonini Ingegneria informatica anno 2022/2023

Ingegneria del software

dell’Informatica che si occupa di sistemi sw:

È un settore

 di dimensioni e complessità elevate (intese come complessità dei problemi che vengono risolti e come struttura

interna dell’applicazione).

 realizzati da squadre

 disponibili in più versioni, dove ogni versione è generalmente orientata ad una diversa categoria di utenti.

Le versioni devono evolvere nel tempo.

 di lunga durata

 destinati a sottostare a cambiamenti ↓

Implica una programmazione in grande ma 

ingegneria del sw programmazione

→ una parte dell’ingegneria dei sistemi.

Consiste di molte altre attività in aggiunta alla programmazione è

La programmazione è una delle basi dell’ingegneria del sw.

Fase pionieristica (anni ’40)

I primi albori risalgono agli anni ’40 del secolo scorso, quando sono nati i primi calcolatori, che erano dedicati ad un

dedicati all’esecuzione di un singolo programma.

singolo problema. Possono essere intesi come

Successivamente nasce l’esigenza di programmare il calcolatore.

→ calcolatore = strumento per l’esecuzione di

Le prime applicazioni = automazione di procedimenti di calcolo

operazioni numeriche che difficilmente potrebbero essere eseguite manualmente con la precisione richiesta.

CURIOSITA’: al giorno d’oggi utilizziamo ancora il termine computer perché quando ancora non esistevano i

computer come li intendiamo oggi, i calcoli complessi venivano fatti da persone, denominate computer che

avevano quello specifico compito / lavoro.

I primi programmatori (erano in realtà degli scienziati) che usavano il calcolatore scrivevano in linguaggi /

strumenti di basso livello (di astrazione).

Si pensi che fino alla metà degli anni ’80 si utilizzavano le schede perforate: sulla tastiera, collegata alla macchina

perforatrice, veniva scritto tutto ciò che si doveva dare in ingresso al calcolatore.

Nei primi anni dopo la guerra, spesso, gli sviluppatori del sw coincidevano con utente del sw stesso.

Le applicazioni avevano vita breve.

Dal calcolo alla elaborazione dati →

❖ Avvento di applicazioni di natura gestionale calcolatore = macchina per creare, mantenere, modificare,

distribuire informazione

❖ Distinzione tra sviluppatori e utenti →

❖ Esigenza di una professionalità specifica nascono EDP (Electronic Data Processing) e sw house

Dall’arte (lavoro individuale creativo) all’artigianato (lavoro di piccoli gruppi specializzati)

❖

❖ Aumento della criticità e della complessità delle applicazioni

❖ Automazione di settori non tradizionali

Già negli anni ’50 si inizia a intuire la capacità del calcolatore che smette di essere visto come una macchina in

grado di fare esclusivamente calcoli → si comprende che il calcolatore è in grado di archiviare informazioni e di

trattare dei dati, non necessariamente numerici.

Data la nuova visione del calcolatore diventa indispensabile una nuova figura specifica, ossia quella dello

sviluppatore di software.

Aumentano anche i settori lavorativi in cui viene richiesto l’uso di applicazioni software.

l’avvento dei linguaggi di alto livello alla fine degli anni ’50.

Si ha 1

Matilde Simonini Ingegneria informatica anno 2022/2023

(seconda metà anni ’60)

Fase industriale

L’attività di sviluppo e manutenzione del sw coinvolge gruppi di lavoro, anche di grosse dimensioni, il cui lavoro

→ nascono esigenze di natura manageriale.

deve essere pianificato e coordinato

L’attività di progettazione del sw deve essere sempre meno sviluppata manualmente e informalmente e deve

essere sempre più supportata da strumenti automatici.

Negli anni ’60 si inizia a concepire il sw come un prodotto industriale.

Lo sviluppo deve seguire metodologie efficaci e deve aderire a standard di produzione che rendano la stessa

insensibile al ricambio di personale. →

Nuove applicazioni devono potere essere ottenute anche assemblando componenti standardizzati già sviluppati

l’assemblaggio / catena di montaggio è un fattore tipico del settore industriale, per i quali si compone un prodotto

nuovo mettendo insieme elementi già esistenti.

Per poter competere sul mercato sono necessari:

 → nell’ambito

Produttività della produzione del software è complicato definire la produttività.

 Qualità (deve essere certificata)

La crisi del sw

I grandi progetti sw sono affetti da una incapacità cronica di rispettare i vincoli relativi a scadenze e budget.

Negli anni ’60 non venivano mai rispettate le scadenze perché non si era in grado di prevedere con precisione i

tempi di lavorazione, e neanche i budget.

La domanda di sw, in questo periodo, è largamente insoddisfatta: vi sono ritardi fra il momento in cui sorge la

di un’applicazione e il momento in cui la richiesta inizia a essere soddisfatta.

richiesta

Le cause sono:

• Immaturità rispetto alle altre discipline ingegneristiche.

Es. ingegneria civile: metodologie assestate che consentono una descrizione precisa e rigorosa dell’artefatto

da progettare, modelli a diverso livello di astrazione, produzione di disegni dettagliati in base ai quali il sistema

sarà realizzato, collaudo finale allo scopo di fornire una certificazione

• Carenza numerica di personale specializzato

• Grande quantità di addetti impiegati nella manutenzione

→ →

Gorgo del sw: carenza di personale specializzato uso di personale impreparato/inesperto produzione di sw di

→ → →

cattiva qualità grande sforzo di manutenzione richiesto impiego di una grande quantità di personale

carenza di personale.

costo sw

Il rapporto: è crescente e le cause sono date da:

costo hw

֎ La produzione di sw è scarsamente automatizzabile (attività brain-intensive = richiede un largo apporto

intellettuale individuale), a differenza della produzione di hw, che è largamente automatizzata (calo dei costi

per hw).

֎ Complessità delle applicazioni richieste

Si parla spesso di quella che viene definita ‘crisi del sw’, che però è solo apparentemente una crisi. Si tratta invece

del fatto ben noto che numerosi prodotti sw in uso, che non sono stati progettati da ingegneri qualificati,

siano di qualità più o meno scadente. Certo, questo sw è difficile da modificare ed è tecnicamente mal

documentato. La dipendenza del funzionamento del sw dalla presenza di chi lo ha sviluppato è talmente grande

che in molti casi lo si può considerare come il prodotto di un’attività amatoriale, certamente non come un lavoro

professionale e tanto meno come esempio di tecnica e capacità ingegneristica.

(W. Zuser, S. Biffl, T. Grechenig, M. Köhle, 2001).

Quando un programma sw ha successo, ovvero quando risponde alle esigenze delle persone che lo usano, si

comporta senza problemi in un lungo arco di tempo, è facile da modificare e ancora più facile da utilizzare, cambia

in meglio la nostra vita. Quando il sw fallisce gli obiettivi, ovvero quando gli utenti sono insoddisfatti, quando il sw è

soggetto a errori, quando è difficile da modificare e ancora più difficile da utilizzare, si verificano varie situazioni

negative. Tutti noi vogliamo realizzare del sw che cambi in meglio il mondo, evitando tutto ciò che accade quando

non si riesce a ottenere un buon risultato. Per ottenere ciò è necessario introdurre disciplina nella progettazione e

2

Matilde Simonini Ingegneria informatica anno 2022/2023

nella realizzazione del sw. Questo è il motivo per cui è necessario un approccio ingegneristico.

(Pressman, 2004) per diversi decenni oltre gli anni ’60.

In realtà si è parlato di crisi del software

Nasce una nuova disciplina

In una conferenza NATO tenuta a Garmisch nel 1968 viene coniato il termine “Ingegneria del Software” a

testimoniare l’esigenza di una disciplina ingegneristica, basata su solide basi teoriche e metodologiche che

permettano la progettazione, produzione e manutenzione di applicazioni che forniscano caratteristiche di qualità

prefissate mediante l’uso delle risorse previste.

L’oggetto non è la computazione e la teoria sottostante ma piuttosto l’uso dell’informatica per risolvere dei problemi

(chimico vs. ing. chimico).

Programmi sw = prodotti industriali di supporto ad altri settori produttivi. all’Ingegneria del sw.

Ciclo del software = parabola vitale del sw. Tutte le fasi del ciclo vengono disciplinate grazie

IEEE Standard 610.12-1990 - Definizione di Ingegneria del Software

a) Applicazione di un approccio sistematico, disciplinato e misurabile allo sviluppo, esercizio e manutenzione del

software; cioè applicazione dell’ingegneria al sw;

b) Studio di strategie di supporto al punto precedente

–

Parnas 1978 - Definizione di Ingegneria del Software

Costruzione da parte di più persone di software disponibile in più versioni.

Relazione tra Software Engineering e Computer Science

Relazioni tra: Software Engineering e altre discipline

Software Engineering e Computer Science 

 Ingegneria gestionale

Linguaggi di programmazione 

 Ingegneria dei sistemi

Sistemi operativi

 Basi di dati

 Intelligenza artificiale Informatica teorica

Caratteristiche esclusive del sw non si logora con l’uso.

Innanzi tutto, non obbedisce alle leggi della natura: è immateriale, intangibile, non pesa,

֎ Malleabilità apparente (sembra facile modificare il sw ma non è facile operare modifiche al fine di ottenere un

certo comportamento desiderato)



֎ Immaterialità solo progettazione

֎ Intangibilità (difficoltà di descrizione e valutazione)

֎ Assenza del processo di assemblaggio 3

Matilde Simonini Ingegneria informatica anno 2022/2023

֎ Evoluzione tecnologica rapidissima

Processo produttivo del sw (= ciclo di vita): dove termina lo sviluppo di una applicazione e dove inizia la sua

evoluzione?

Approccio ingegneristico alla produzione del sw

Mira a garantire alti livelli di controllo sulla qualità grazie a un processo formale che descrive le varie fasi che vanno

seguite nello sviluppo del sw. è importante (vedi progetti dell’ingegneria

Molte persone lavorano allo stesso progetto; quindi, la documentazione

“disegno” di alto livello e di dettaglio.

civile):

La fase iniziale di raccolta dei requisiti del cliente prevede che siano esibiti diagrammi, prototipi e documenti tali

da garantire che ciò che si svilupperà è effettivamente ciò che vuole il cliente.

L’approccio ingegneristico è caratterizzato dalla centralità della progettazione e risulta fondamentale la

componente intellettuale creativa.

Il testing del prodotto segue un processo ben formalizzato, in cui i requisiti iniziali del cliente sono riesaminati per

verificarne la corretta implementazione.

L’ingegnere del sw

Alle diverse fasi corrispondono figure professionali diverse (suddivisione di competenze e ruoli); nei piccoli progetti

2 o 3 persone coprono tutti i ruoli:

⍟ analista

⍟ progettista

⍟ programmatore

⍟ ingegnere del testing

⍟ istruttore (mostra agli utenti come usare il sistema)

⍟ (include analisti, progettisti, …)

gruppo manutenzione

⍟ gruppo controllo qualità

⍟ librarian (redattore di documenti usati durante la vita del sistema, ad es. specifiche dei requisiti, descrizioni

di progetto, documentazione di programma, manuali di addestramento, ecc.)

⍟ squadra di gestione delle configurazioni (documenta le corrispondenze fra requisiti, progetto,

implementazione e test, ad es. per poter dire ai manutentori quale funzione modificare se è richiesto un

cambiamento nei requisiti, ecc.; inoltre coordina le diverse versioni di un sistema)

Configurazione software = insieme di documenti che descrive una versione del sistema sw e le relazioni di

tracciabilità fra i file stessi. Mantenere tutte queste relazioni è fondamentale nel momento in cui si deve modificare

il sw.

Nel momento in cui si effettua la modifica vengono modificate le relazioni di tracciabilità tra i file che descrivono il

sw e che sono mantenuti da un tool di configurazione sw.

Ogni versione ha una configurazione e le descrizioni relative a ciascuna versione si intersecano: diverse versioni

possono avere in comune molti file. La qualità è relativa:

parlare in termini assoluti di qualità → dipende dall’osservatore che la giudica.

Non si può 4

Matilde Simonini Ingegneria informatica anno 2022/2023

Qualità del sw: una duplice classificazione

Il nocciolo dell’ingegneria del software è l’attenzione alla qualità

(Pressman, 2004)

Primo criterio:

⎔ Qualità di prodotto

⎔ Qualità di processo (influenza quella di prodotto)

Secondo criterio:

⎔ Qualità esterne: percepibili da un osservatore esterno che esamina una black-box (sono quelle di interesse

→ prospettiva utente

per SE)

⎔ Qualità interne: percepibili esaminando la struttura interna di una white-box (sono quelle che permettono di

→ prospettiva

realizzare le qualità esterne) del ricercatore

Fattori di qualità (16)

Di prodotto Sia di prodotto sia di processo

⎊ Correttezza ⎔ Verificabilità

⎊ ⎔

Affidabilità Manutenibilità

⎊ ⎔ Riusabilità

Robustezza ⎔

⎊ Comprensibilità

Sicurezza

⎊ Innocuità

⎊ Di processo

Prestazioni

⎊ Usabilità o Produttività

⎊ Portabilità o Visibilità

⎊ Interoperabilità o Tempestività

Il sw è corretto se soddisfa le specifiche dei requisiti funzionali (caratteristica oggettiva). A priori, prima di iniziare lo

sviluppo, devono essere stabiliti i requisiti funzionali, che non sono gli unici da rispettare.

È sufficiente anche un solo episodio in cui non vengono rispettati alcuni requisiti affinché si possa dire che

l’applicazione non sia corretta.

Se tali specifiche sono formali, la correttezza può essere provata formalmente (mediante una dimostrazione di

teorema) dal momento che i programmi sono oggetti formali, oppure smentita mediante controesempi (attività di

testing).

A ogni forma sintattica si ha una forma semantica, ossia l’effetto.

Generalmente i requisiti vengono espressi in maniera informale.

La correttezza viene verificata attraverso l’attività di si sottopone l’applicazione a prove di esecuzione.

testing:

Limiti:

(sì/no), non esiste alcun concetto di “grado di correttezza” né di gravità dell’infrazione

È una qualità assoluta e se

le specifiche fossero sbagliate (magari a causa di requisiti inattendibili o di errori nella conoscenza di dominio).

Questa proprietà non consente di esprimere un rigoroso giudizio con un elevato grado di sicurezza.

→

Ci si chiede quanto è importante la correttezza dell’applicazione è importante dal momento in cui i requisiti

rispecchino effettivamente le richieste/aspettative/esigenze degli utenti.

Spesso i requisiti non rappresentano le vere esigenze dell’utente. Colui che si occupa di raccogliere le richieste è

l’analista, il quale può fraintendere.

È fondamentale esprimere e descrivere bene i requisiti fondamentali: se tale lavoro non viene svolto

correttamente si può giungere al fallimento del progetto.

Informalmente significa che l’utente si può fidare del prodotto sw in questione.

Si tratta di una caratteristica valutata dagli utenti.

I risultati delle elaborazioni (le uscite) sono quelli voluti o presentano disturbi tollerabili (concetto soggettivo e

variabile da sistema a sistema).

Tale giudizio dipende da chi lo esprime e dal dominio nel quale viene espresso.

5

Matilde Simonini Ingegneria informatica anno 2022/2023

Poiché si vuole oggettivare anche questo giudizio, come tutti gli altri, è stata formulato in maniera matematica.

Matematicamente è definibile come la “probabilità di assenza di malfunzionamenti nell’unità di tempo”.

Un esempio di malfunzionamento grave è la corruzione di un file.

⇒

Correttezza affidabilità

Il viceversa non è sempre vero. circostanze non previste dai requisiti (valori d’ingresso

Il prodotto sw si comporta in modo ragionevole anche in

non validi, malfunzionamenti hw, ecc.).

Come si deve comportare se riceve degli ingressi che non appartengono al dominio di ingresso? A seconda del

dominio è possibile affermare il comportamento desiderato in corrispondenza di certi ingressi.

Capacità del sistema sw in esecuzione di impedire l’accesso a informazioni private.

→ Assenza di pericolosità (o tollerabilità della pericolosità) dell’elaborazione.

→ Capacità di operare senza malfunzionamenti catastrofici.

Tempi di elaborazione, occupazione di memoria, traffico in rete.

Dipendono da un uso efficiente delle risorse (memoria, tempo di elaborazione, canali di comunicazione).

Influenzano l’usabilità e la “scalabilità” di un’applicazione (una soluzione che funziona su una LAN magari non

funziona su una WAN).

Possono essere verificate mediante:

Analisi di complessità (insegnamento di “Algoritmi e Strutture Dati”)

⧉

⧉ Misure durante esecuzioni-campione

⧉ Simulazione di un modello

⧉ Analisi di un modello (es. analisi probabilistica secondo la teoria delle code)

naturalezza ed ergonomicità dell’interazione col sistema sw dal punto di vista delle diverse categorie di

Intuitività,

utenti dello stesso (espressione vecchia