Ingegneria del software - Informatica per il management

Ingegneria del software: appunti e slide

Università di Bologna 2023/24

Introduzione

Il problema fondamentale dell'ingegneria software è che i progetti software hanno come artefatto ultimo un sistema software che molto spesso risulta fallimentare. La causa è dovuta alla complessità della progettazione stessa; infatti, ci sono parti di prodotti software dinamici e in evoluzione. L'ingegneria del software si occupa della costruzione da parte di più persone di software che verrà rilasciato in più versioni. Il fatto che ci siano più persone che devono collaborare in modo proficuo è una problematica che deve essere analizzata. È comune che il software abbia un ciclo di vita che non termina con il primo rilascio, ma venga spesso modificato.

Un sistema software che funziona bene come gli altri può essere mal strutturato internamente: quindi, lo scopo non è scrivere programmi che funzionano e che siano solo intelligenti/furbi, ma che abbiano un elevato livello qualitativo. Non stiamo sviluppando abilità di programmare e usare bene un linguaggio ostico. Non dobbiamo fare algoritmi furbi, ma è più importante che sia facile da leggere e mantenere perché è probabile che un software un domani debba essere aggiornato/modificato, e se è un algoritmo furbo probabilmente nel futuro chi dovrà modificarlo non lo comprende e rischia di fare danni. Fare in modo che la soluzione finale sembri facile è difficile ed è questo che dobbiamo imparare a fare.

Poniamo il problema di ingegneria del software perché i progetti software tendono ad avere una percentuale di fallimento molto più alta rispetto ad altri progetti. Teoria: il progetto ci metterà sempre più tempo e risorse rispetto a quelle pianificate anche se sono state pianificate tenendo conto di questa teoria.

Si parlò per la prima volta dell'ingegneria software come una disciplina in una conferenza della NATO nel 1969 dove si cercò di stabilire una disciplina capace di abbassare la percentuale di fallimento dei progetti e che soprattutto facesse in modo da farli realizzare on Time e on budget. La NATO si interessò dell’ingegneria del software perché aveva a disposizione molti sistemi complessi composti da tante componenti complesse, tra cui il software. Problema: si davano dei tempi per realizzare dei progetti, e in quei tempi tutti gli altri elementi complessi erano pronti nei tempi giusti, ma il progetto non si concludeva perché il software non funzionava o non era pronto. Dato che il software era molto importante, si cominciò a cercare dei programmatori, ma non basta che sappiano programmare. Occorre che sappiano ciò che insegna l’ingegneria del software.

Quindi l’ingegneria del software non viene considerata più solo una disciplina prettamente matematica, ma disciplina in cui usare anche pratiche usate in altre discipline che è stato visto che funzionano; quindi, non basta saper programmare e conoscere algoritmi, ma servono pratiche che riprendono pratiche ingegneristiche.

Ha funzionato questa cosa? Ha aiutato ma non risolto, quindi guardare come si gestiscono progetti in altre ingegnerie può essere un aiuto, ma non ha risolto tutti i problemi che emergono con progetti software perché c’è qualcosa che li rende diversi dagli altri progetti.

Pensiamo agli oggetti fisici: essi rispondono alle leggi della fisica, mentre il software non è una cosa fisica, quindi non lo si può paragonare ad un oggetto fisico che viene analizzato nelle altre ingegnerie. Per esempio, per far stare su un ponte, ci sono regole fisse, calcoli precisi, invece nel caso dei software si fanno scelte in continuazione; un progetto software può essere fatto in mille modi diversi in base alle scelte fatte, seppur ottenendo lo stesso risultato finale.

L'ingegneria del software ha caratteristiche diverse dalle altre discipline ingegneristiche, sia per la natura intangibile del software che per la natura discreta del suo funzionamento; quindi, pratiche imparate da altre ingegnerie, solo in parte possiamo estenderle per quella del software. Cerca di integrare i principi della matematica e dell'informatica con le pratiche ingegneristiche sviluppate per produrre artefatti fisici tangibili.

Definizione: L’ingegneria del software riguarda la creazione di software di alta qualità (modificabilità) in modo sistematico, controllato ed efficiente. Di conseguenza, viene posta un'enfasi importante sull'analisi e sulla valutazione, sulle specifiche, sulla progettazione e sull'evoluzione del software. Inoltre, ci sono questioni legate alla gestione e alla qualità, alla novità e alla creatività, agli standard, alle competenze individuali, al lavoro di squadra e alla pratica professionale che svolgono un ruolo vitale nell'ingegneria del software.

SWEBOK = insieme delle competenze che rientrano nell’ingegneria del software.

Strumenti per affrontare la complessità

Data la necessità di affrontare una complessità superiore, è più facile utilizzare alcuni strumenti per semplificare. Quindi, il problema di partenza è che i sistemi che progettiamo sono complessi, ma gli strumenti che ci aiutano in questa complessità sono:

• Astratti: Processo di astrazione che definisce/formula idee o concetti generalizzati estraendo qualità comuni da esempi specifici. L'intera storia dell'ingegneria del software è caratterizzata da livelli crescenti di astrazione perché l'astrazione è il modo principale in cui noi, come esseri umani, affrontiamo la complessità [G. Booch]. Il processo di astrazione è innato e non scontato: filtriamo tutta la realtà sensibile a cui siamo esposti e classifichiamo la realtà per ragionare sulle astrazioni che sono più semplici degli oggetti di partenza a cui sono derivate.
• Modelli: Rappresentazione di un sistema (per rappresentare l’astrazione) che risponde a cosa fa il sistema per un dato insieme di domande. Bisogna pensare al modello come ad un oracolo: risponde, come risponderebbe a quelle domande, l’oggetto reale che vuole rappresentare. Il modello è un’astrazione (semplificazione della realtà), non esiste, ma nonostante la loro intrinseca falsità, sono comunque estremamente utili perché sono meccanismi per rappresentare.

Modello di analisi (Analysis Model)

Il processo software può essere visto come sequenza di attività che abbassano il livello/grado di astrazione man mano che andiamo avanti nel processo. Il nostro lavoro consiste nel far abbassare il livello di astrazione. Sequenza di attività (dalla più astratta alla più concreta):

• Analisi
• Progettazione
• Costruzione

Il processo software può essere visto come un perfezionamento dei modelli:

• Modello di analisi (o modello dei requisiti ma gli piace di meno)
• Modello di progettazione
• Modello di costruzione

A questi modelli precede il modello mentale, cioè il software comincia dall'idea di qualcuno. Tutto il processo che costruiamo cerca, a partire dal modello mentale (più astratto), di costruire un sistema che realizza le idee di chi lo aveva immaginato. Quindi, il processo software può essere visto come un perfezionamento dei modelli:

• Modello mentale, spazio del problema
• Modello di analisi
• Modello di progettazione, spazio della soluzione
• Modello di costruzione

Tra questi modelli possiamo tracciare una linea netta: i primi due operano sullo spazio del problema, mentre gli altri due sullo spazio della soluzione. Modelli nello spazio del problema servono per rispondere a: cosa deve fare il sistema? Modelli nello spazio della soluzione servono per rispondere a: come deve essere fatto il sistema?

Raffinazione = Meccanismo per arricchire di dettagli il modello astratto per farlo diventare più concreto.

Obiettivi del modello di analisi

• Comprensione corretta e completa di quello che è richiesto dal software (cioè cosa deve fare una volta realizzato).
• Questa comprensione deve essere rappresentata in modo che sia facile da spiegare e far comprendere agli altri membri del team.
• Definire una serie di requisiti che possono essere convalidati una volta creato il software, quindi avere meccanismi per controllare e dimostrare che è stato fatto il requisito richiesto, cioè se il software soddisfa il requisito.

Artefatti del modello di analisi

• Documento sui requisiti
• Casi d'uso
• Modello di dominio
• Specifica supplementare (acquisisce e identifica altri tipi di requisiti, come report, documentazione, packaging, sopportabilità, licenza, ...)
• Glossario
• Regole aziendali (o regole di dominio)

Requisiti software

I requisiti software sono le necessità e i vincoli di un prodotto software. Il committente vuole che il software faccia una determinata cosa e occorre operare in certi vincoli. La ingegneria dei requisiti (Requirements engineering – RE) è la sistematica gestione dei requisiti. Aree di conoscenza dei requisiti software (Software Requirements knowledge areas): Modello di analisi composto da processo di:

• Elicitazione: Meccanismo attraverso il quale facciamo passaggio da modello mentale a modello di analisi; rappresentiamo quello che sta nella mente, in maniera non ambigua, completa, facilmente leggibile, ecc. Modo per condividere una rappresentazione del modello mentale degli stakeholder riguardo al sistema. Come si fa?
  • Tramite interviste/questionari: chiedendo direttamente agli stakeholder, nelle interviste puoi dirgli se stanno dicendo cose contraddittorie a quello che hanno detto prima.
  • Osservazione dell'ambiente o dei modelli di lavoro
  • Revisione della documentazione tecnica, ecc.
• Analisi: Comprende attività che servono ad organizzare, verificare i requisiti, vedere che non siano contraddittori tra di loro, ecc. requisiti nella loro interezza. Lo scopo del processo di analisi dei requisiti è trasformare la visione dei servizi desiderati, orientata ai requisiti, da parte degli stakeholder, in una visione tecnica del prodotto richiesto che potrebbe fornire tali servizi. Sollecitare i requisiti degli stakeholder
  • Identificare i singoli stakeholder o classi di stakeholder che hanno un legittimo interesse nel sistema durante tutto il suo ciclo di vita.
  • Sollecitare i requisiti degli stakeholder da stakeholder identificati.
• Specifica: Meccanismo attraverso il quale rappresentare la conoscenza in modo che sia comprensibile, ecc.
• Validazione: Verifica di quelli che sono i requisiti che abbiamo raccolto…dei requisiti software. Comprende attività per analizzare i requisiti nella loro interezza, verificare che non siano contradditori tra loro, che siano corretti e completi. Raccolgo requisiti e voglio definire meccanismi di validazione per confermare che il software che realizzo rispetta i requisiti.

Standard di rappresentazione dei requisiti

Per rappresentare/formalizzare i requisiti ci sono degli standard che definiscono come devono essere rappresentati i requisiti e quali sono i documenti che li definiscono, questi documenti sono:

• Stakeholder Requirements Specification Document (StRS): Quindi, requisiti per un sistema, che vengono espressi dagli stakeholder ovvero da chi deve usare il software. Definisce le funzionalità che servono agli stakeholder per raggiungere i loro obiettivi. Esprime l'interazione prevista che il sistema avrà con il suo ambiente operativo e costituiscono il riferimento rispetto al quale viene convalidato ogni servizio operativo risultante.
• System Requirements Specification Document (SyRS): Definisce quali funzionalità deve offrire il sistema in modo tale che vengano soddisfatte le attese degli stakeholder espresse nello Stakeholder requirements. È una specificazione, dal punto di vista del fornitore, di quali caratteristiche, attributi e requisiti funzionali e prestazionali il sistema deve possedere, al fine di soddisfare i requisiti espressi dagli stakeholder.
• Software Requirements Specification Document (SRS): Ha senso solo quando il sistema non è solo software.

Esprimere un requisito

Un requisito dovrebbe essere il più inequivocabile possibile (linguaggio controllato), quindi occorre minimizzare l’ambiguità. Il requisito dovrebbe essere formulato come una o più frasi modali (una è meglio, se possibile) contenente una combinazione di: soggetto/i, azione/i, oggetto/i, valore/i, condizione/i, vincolo/i.

Esempio: Quando viene ricevuto il segnale x [Condizione], il sistema [Soggetto] imposterà [Azione] il segnale x ricevuto bit [Oggetto] entro 2 secondi [Vincolo].

Esempio: Nello stato del mare 1 [Condizione], il sistema radar rileverà i bersagli a una distanza massima di [Azione o vincolo] 100 miglia nautiche [Valore].

Esempio: Il sistema di fatturazione [Soggetto], visualizzerà le fatture cliente in sospeso [Azione] in ordine crescente [Valore] in cui le fatture devono essere pagate.

Per comprendere davvero un requisito scritto in questo modo può servire un glossario; inoltre, determinati template sono più comodi e migliori per descrivere alcuni requisiti rispetto ad altri.

Caratteristiche di un buon requisito

Per un singolo requisito:

• Inequivocabile, non ambiguo
• Coerente
• Completo
• Singolare
• Fattibile, realizzabile
• Tracciabile: cioè che passiamo attraverso passi di raffinazione per definire i requisiti, quindi è bene tener traccia da come vengono fuori questi requisiti, da chi sono stati richiesti.
• Verificabile

Per un insieme di requisiti:

• Completo
• Coerente
• Conveniente: ragionevolmente realizzabili nel contesto delle risorse affidate al progetto
• Limitato: che abbiano limiti definiti

Metadati dei requisiti (Requirements metadata)

• Identificazione
• Priorità degli stakeholder
• Dipendenza
• Rischi che posso correre quando cerco di soddisfare un requisito
• Sorgente
• Motivazione
• Difficoltà
• Tipo

Tipi di requisiti

I requisiti vengono classificati in maniera diversa:

Funzionale

Descrive le interazioni tra il sistema e il suo ambiente, indipendentemente dall'implementazione; descrive il comportamento atteso indipendentemente da come internamente la funzionalità viene implementata. Determina il funzionamento analizzando il sistema come una scatola nera dall'esterno, spiega come il sistema reagisce ad alcune sollecitazioni esterne. Esempio: Realizzo il sistema della calcolatrice e ho il requisito della funzionalità somma: se metto numero + numero vuole che si faccia somma. Requisiti funzionali hanno impatto sulla progettazione del sistema, cioè varie scelte che dobbiamo fare e scelte con livello di astrazione più basso.

I requisiti funzionali sono affrontati dalla progettazione del sistema cosa fa il sistema (Esempio: calcolatrice fa la somma). Requisiti funzionali si rappresentano in 3 modi:

• Documento strutturato (visto alla lezione prima) non ne parliamo tanto ma possono esserci domande all’esame e non facciamo pratica.
• Casi d’uso
• User story

Non funzionale

Ha a che fare con proprietà dei sistemi non direttamente legate agli aspetti funzionali. Esempio: Nella calcolatrice voglio che il risultato appaia all’utente velocemente. Requisiti non funzionali sono affrontati dall’architettura del sistema, scelte che caratterizzano il sistema, cioè spesso requisiti non funzionali vanno indirizzati attraverso scelte che dobbiamo fare che sono più critiche; se si sbagliano le scelte, è peggio in questo caso. Esempio: È più difficile modificare un sistema lento per farlo andare veloce. Quindi i requisiti non funzionali sono quelli più critici perché esprimono necessità più difficili da realizzare.

Esprimono come dovrebbe essere il sistema (o come dovrebbe fare quello che fa) (Es: lo fa in modo veloce) ed ha a che fare con proprietà generali che caratterizzano il sistema. Il committente spesso comunica quello che vuole ma non comunica le sue aspettative e questo crea problema, perché ad esempio se faccio una calcolatrice e fa la somma come richiesto da lui, poi glielo consegniamo ma si lamenta perché è troppo lento, lui non ha specificato anche il requisito non funzionale, cioè la velocità. Normalmente requisiti non funzionali spesso vengono validati man mano.

Confronto tra requisiti funzionali e non funzionali

FURPS+

• Funzionale (Functional): caratteristiche, capacità, sicurezza.
• Usabilità (Usability): fattori umani, aiuto, documentazione.
• Affidabilità (Reliability): frequenza di guasto, recuperabilità, prevedibilità.
• Prestazioni (Performance): tempi di risposta, produttività, precisione, disponibilità, utilizzo delle risorse.
• Sopportabilità (Supportability): adattabilità, manutenibilità, internazionalizzazione, configurabilità.
• +: implementazione, interfaccia, operazioni, packaging, legale.

Problema di vincoli

Spesso il sistema deve rispettare requisiti ma con dei vincoli che possono essere esterni o interni all’organizzazione (esempio fare un software che usa un database già presente).