Riassunti esame Ingegneria del Software

Presentazione

L'ingegneria del software è una attività creativa, quindi ad alta intensità umana e si differenzia dai tipi tradizionali, come navale, perché è:

• Intangibile, quindi difficile da descrivere e valutare
• Malleabile, quindi si può modificare continuamente
• Umano-intensivo, ma non coinvolge solo triviali processi manifatturieri.

La disciplina dell'ingegneria del software nasce nel 1968 per rispondere al cronico fallimento di grandi progetti software nel raggiungere gli obbiettivi rispettando tempi e costi.

Concetti generali

Il software: la sua natura

L'ingegneria del software è una attività creativa, quindi ad alta intensità umana. Il software è costruito e mantenuto per soddisfare dei predefiniti requisiti funzionali e delle predefinite qualità. Per ingegneria del software si intende l'applicazione di metodi ingegneristici al software ed è quella disciplina informatica che tratta i sistemi software, quindi sistemi grandi e complessi costituiti da gruppi di lavoro, che esistono in molte versioni, che durano molti anni e che subiscono continui cambiamenti. Si tratta infatti dell'applicazione di un approccio sistematico, disciplinato e quantificabile alla produzione, esercizio e manutenzione del software.

Le risorse utilizzate dall'ingegnere del software

• Modelli per la caratterizzazione dei prodotti, dei processi e delle risorse.
• Modelli per la stima dell'impiego delle risorse nei progetti di sviluppo software.
• Modelli per la valutazione ed il monitoraggio della qualità dei prodotti e dei processi.

L'ingegnere del software non deve solo programmare in piccolo, egli infatti è coinvolto nella programmazione in grande. Infatti un programmatore piccolo deve essere un buon programmatore, esperto in strutture dati e algoritmi e conoscitore di uno o più linguaggi di programmazione, mentre un programmatore in grande deve essere in grado di:

• Sviluppare modelli necessari nelle varie fasi dei processi di sviluppo per effettuare, grazie a questi, i compromessi necessari.
• Esprimere i concetti inerenti il software con diversi livelli di astrazione, dipendentemente dal destinatario del manufatto che produce.
• Trovare le risorse utili per accelerare ed economizzare il processo di sviluppo.
• Lavorare in gruppo.
• Gestire progetti e coordinare il lavoro degli altri.

Fasi per la produzione del software

• Analisi e specifiche dei requisiti: Definisce in modo preciso e formale quali sono le capacità e le caratteristiche del Sistema Software e produce anche i manuali utenti e i test di accettazione.
• Progettazione e specifiche: Organizza le componenti che comporranno il sistema e le loro relazioni, attraverso l'Architettura. Le componenti vengono decomposte, a basso livello, in moduli. In questa fase si produce anche il manuale di sistema, il test di integrazione e il test di sistema.
• Codifica e test dei moduli: Produce i moduli e ne fa il test per la correttezza.
• Integrazione e test: Integra tutti i moduli prodotti secondo quanto previsto dal progetto e ne fa il test di integrazione e, terminata quest'ultima, effettua il test di sistema.
• Rilascio: Si ha quando il sistema supera anche il test di accettazione e viene consegnato al committente.
• Manutenzione: Consiste nella manutenzione dello stesso durante il suo esercizio per eliminare malfunzionamenti e per adeguarlo a nuove esigenze.

Il valore centrale dell'ingegneria del software è la qualità, nella quale si sta assistendo nell'ultimo decennio ad un processo di convergenza virtuoso e progressivo tra qualità di processo e qualità di prodotto. Infatti negli ultimi anni sono state sviluppate linee guida a supporto dello sviluppo del software che consentono oggi di approcciare la qualità del software da prospettive diverse. Le prospettive di qualità sono tre:

• Qualità in uso: Esprime l'efficacia ed efficienza con cui il software serve le esigenze dell'utente, ed è correlata alla percezione diretta dell'utente.
• Qualità interna: Esprime la misura in cui il codice software possiede una serie di attributi statici, indipendentemente dall'ambiente di utilizzo e dall'utente.
• Qualità esterna: Esprime il comportamento dinamico del software, nell'ambito d'uso. L'assunto è che i tre punti di vista si influenzano a vicenda e che non può esservi qualità percepita positivamente dall'utente senza che vi sia una buona qualità intrinseca al codice e buone prestazioni.

Le caratteristiche principali di qualità sono:

• Correttezza: Un sistema software deve soddisfare tutti i suoi requisiti funzionali e di prestazione.
• Affidabilità: Deve garantire che il sistema software si comporti secondo le attese in un intervallo di tempo.
• Robustezza: Un sistema software si deve comportare in modo accettabile anche in circostanze non previste nelle sue specifiche.
• Usabilità: Il sistema software deve essere reputato di facile uso dai suoi utilizzatori.
• Manutenibilità: Implica la facilità con cui si identifica la causa di un malfunzionamento e di eliminazione dello stesso e la facilità di aggiunta, rimozione o modifica di capacità e funzioni del sistema.
• Riusabilità: Consiste nella possibilità di riusare delle componenti del software o artefatti di processo software. Essa può essere applicata, pertanto, a vari livelli di granularità. La programmazione OO ha lo scopo di raggiungere sia una migliore riusabilità che una migliore evolvibilità.
• Prestazioni: Tempo di risposta, reattività, latenza, throughput, carico, sensibilità al carico, efficienza, capacità o max throughput, scalabilità.

Tipi di prodotti software

• Un programma: È un insieme di istruzioni autoconsistenti rispetto ad uno o più obiettivi ed è spesso usato dallo stesso autore. Inoltre è difficile farlo utilizzare da altri a causa della scarsa documentazione o di difficile comprensione. I suoi difetti sono rilevati sul campo perché è scarsa la validazione durante la sua produzione ed ha vita breve perché la manutenzione fa decadere la sua qualità e diventa sempre più difficile e costoso farlo evolvere.
• Un'applicazione: È un insieme di programmi interagenti tra loro. Spesso viene venduto come un pacchetto usabile da persone che non hanno dimestichezza con l'informatica perché sono forniti, almeno, di un'interfaccia e di un documento d'uso. I loro difetti sono scoperti essenzialmente dagli utilizzatori ma durante la produzione una parte sono scoperti attraverso la validazione. Spesso hanno bassi livelli di qualità in quanto sono poco attrezzati per il trasferimento a nuovi sviluppatori e la loro qualità decade molto velocemente.
• Un sistema software: È un insieme di programmi interagenti che coprono un dominio applicativo con un alto livello di qualità, completo di tutta la documentazione (requisiti, manuali d'uso ecc.). Per far rientrare gli alti costi di produzione, essi sono destinati ad un esteso bacino di utenza anche con piattaforme diverse grazie anche all'usabilità e la portabilità.
• Applicazioni per l'impresa: Sono sistemi software caratterizzati da dati persistenti necessari per passare le informazioni tra differenti applicazioni e tra differenti esecuzioni della stessa applicazione. Inoltre è presente un rilevante volume di dati, un sistema di medie dimensioni avente diversi GB di dati organizzati in decine di tipi di record. Questi sistemi software devono permettere l'accesso concorrente ai dati da diversi utilizzatori dell'applicazione, devono avere un rilevante numero di schermate componenti l'interfaccia e devono offrire l'integrazione tra applicazioni che supportano domini differenti della stessa impresa molto spesso costituite da approcci eterogenei.
• Sistemi in tempo reale: Caratterizzati principalmente da una alta velocità di risposta a particolari condizioni esterne. Sono orientati al controllo, cioè gestiscono pochi dati ma molte funzioni e possono essere basati su eventi oppure basati sul tempo. Spesso sono usati per operazioni critiche quindi devono avere caratteristiche di affidabilità e di salvaguardia/protezione in condizioni di rischio.
• Sistemi embedded: Sistemi che generalmente non hanno interfaccia verso gli utenti esterni ma che hanno interfacce verso dispositivi dello stesso sistema di cui sono componenti ed anche essi in genera hanno pochi dati e poche capacità funzionali.

Dissonanze concettuali

Molti concetti del dominio applicativo sono interpretati in modo diverso da utenti e da applicazioni diverse. I concetti utilizzati in una applicazione devono essere definiti con rigore facendo riferimento a conoscenza esplicita oppure dichiarano la sua definizione in un glossario.

Frontiera dell'ingegneria del software

Uno degli obiettivi dell'ingegneria del software è quello di potenziare lo sviluppatore permettendogli di sviluppare per configurazione invece che per scrittura codice, cioè nello sviluppare dei framework, linee di prodotti e sviluppo per componenti. L'ingegneria del software mira anche a definire la distribuzione della produzione del software (global software development, sviluppo open source, web-service).

Un framework è un componente di grande scala che generalizza le applicazioni di uno stesso dominio per sviluppare applicazioni non scrivendo codice o scrivendone poco. La specificabilità del comportamento del framework per un particolare utente viene fatto tramite parametrizzazione, plug-in cioè procedure esterne usate dai framework e scripting cioè un frammento eseguibile di codice che è agganciato dinamicamente al sistema. I problemi del framework sono principalmente la grande mole di parametri che causano difficoltà di comprensione e uso, i linguaggi di scripting che sono generalmente proprietari e l'aumento del numero di plug-in diminuisce la manutenibilità del sistema software.

La linea di prodotti consiste nell'utilizzare le somiglianze tra sistemi software differenti per migliorare lo sviluppo e la manutenzione delle applicazioni. Questo ha effetto di aumentare i tempi e i costi di sviluppo e la qualità. Le linee di prodotti promuovono il riuso.

Lo sviluppo per componenti consiste nell'utilizzare software già scritto per costruire nuove applicazioni. Esse possono essere commerciali, legacy o open source. I problemi che si creano sono la selezione e la certificazione delle componenti con caratteristiche di qualità e funzionali adeguate alle richieste dell'applicazione, la modalità di integrazione delle componenti non omogenee rendendo quindi la manutenzione molto costosa.

I contesti applicativi oggi si caratterizzano per rapidi e crescenti evoluzioni a causa di molta diversità nei requisiti per la numerosità degli utilizzatori, per il crescente ritmo di variazione dei requisiti per la volatilità dei mercati e per un crescente ritmo dei cambiamenti tecnologici per la pressione competitiva dei produttori. La conseguenza che emerge è l'inadeguatezza dei processi ad approccio sequenziale tipo il classico Waterfall.

Tecniche di produzione del software

Le tecniche di produzione per il rapido adeguamento dei processi si possono dividere in due casi:

• Tecniche basate sull'architettura che si focalizzano sulle sorgenti di cambiamento più probabili o i requisiti più instabili e usano l'information hiding e la modularità per nascondere le sorgenti di cambiamento nei moduli di architettura.
• Tecniche basate sul refactoring che si focalizzano sul mantenere il prodotto il più semplice possibile e adeguarlo incrementalmente con successivi insiemi di cambiamenti dei requisiti.

Se l'evoluzione dei requisiti si può conoscere per tempo e i contenuti restano stabili per un tempo sufficiente le tecniche basate sull'architettura sono adeguate, mentre se i cambiamenti sono frequenti e difficilmente prevedibili o del tutto imprevedibili, le soluzioni pre-architettate saranno continuamente infrante con relativi enormi costi di riprogettazione, quindi sono più adeguate le tecniche basate sul refactoring.

Le tecniche basate sull'architettura sono realizzate meglio con i processi guidati da piani: Rational Unified Process, Spirale, Waterfall ecc., mentre le tecniche basate sul refactoring sono realizzate meglio con i processi agili: SCRUM, Agile, Adaptive Software Development, Extreme Programming ecc. È possibile combinare modelli di processo guidati dai piani con quelli agili.

La documentazione è considerata il manufatto centrale dello sviluppo di un'applicazione e deve essere tracciabile tra manufatti di differenti fasi del ciclo di vita del software ed all'interno di uno stesso manufatto. La tracciabilità è assicurata se il codice non è documentato a posteriori ma è ricavato dalla documentazione.

Principi dell'ingegneria del software

I principi formano le basi dei metodi, tecniche, metodologie e strumenti. I principi descrivono proprietà desiderabili dei prodotti e dei processi in termini generali ed astratti e sono applicabili in tutti i processi di sviluppo del software, indipendentemente dal contesto di sviluppo, il tipo di sistema da sviluppare, l'ambiente di sviluppo e dall'ambiente target del sistema software. I principi si trasformano in pratiche attraverso metodi e tecniche confezionate in metodologie supportate dagli strumenti che potenziano gli sviluppatori.

I principi sono sette:

• Rigore e formalità: L'ingegneria del software è un'attività creativa che deve essere praticata sistematicamente e per questo il rigore è il giusto complemento per aumentare la confidenza in tutto ciò che si sviluppa. Esso è la coerenza con le precondizioni e con lo scopo del manufatto che si sta producendo, oltre che con il metodo e le tecniche che si intendono utilizzare nella produzione. Il livello più alto di rigore è la formalità, che prevede l'uso di formalismi matematici per guidare lo sviluppo del software. Essa consente di derivare rigorosamente e sistematicamente i dati per la verifica dinamica. La descrizione rigorosa delle attività e delle relazioni tra loro da eseguire durante lo sviluppo del software aiutano a gestire il progetto ed ad accertare tempi e costi dello stesso. Inoltre, consente di sviluppare software con buoni livelli di qualità grazie alla scrittura rigorosa della documentazione resa comprensibile e tracciabile. Mantenere sistematicamente lo stesso livello di rigore è molto difficile per uno sviluppatore che spesso si comporta in maniera non conforme, infatti il formalismo richiede molto impegno.
• Separazione degli interessi: Consiste nel separare le decisioni necessarie per risolvere aspetti diversi dello stesso problema. Esistono diverse modalità di separazione: separazione per tempo, cioè aspetti che si rilevano in tempi diversi; separazione per caratteristiche in cui ogni aspetto rilevante corrisponde ad una caratteristica, ognuna è analizzata separatamente dall'altra; separazione per prospettive in cui ogni aspetto attiene alla prospettiva di un portatore di interessi e separazione per parti in cui ogni capacità del sistema deve riguardare una parte di esso. Questo principio consente di analizzare, uno per volta, i differenti aspetti/interessi di un grande problema, diminuendo così il numero di decisioni da assumere contemporaneamente. D'altro canto, separare gli aspetti potrebbe far perdere l'ottimizzazione perché si assumono decisioni riguardanti aspetti differenti che potrebbero trascurare la relazione esistente tra alcune di esse, e per questo due o più aspetti con caratteristiche comuni non conviene separarli.
• Modularità: I moduli sono parti del sistema software in quanto ognuno realizza una parte delle sue funzioni e tutti cooperano tra loro per realizzare gli scopi del sistema software. I moduli ad alta coesione interna devono avere basso accoppiamento tra loro. La coesistenza logica degli elementi interni di un modulo misura la densità ed il tipo di interdipendenza tra i moduli. I moduli consentono di applicare la separazione degli interessi, cioè prima sono trattati gli scopi di ogni modulo e le relazioni tra loro in modo dettagliato, poi si analizzano i dettagli di ogni modulo e infine si verifica la coerenza della loro integrazione attraverso le relazioni e la correttezza del sistema integrato rispetto agli scopi complessivi del sistema. I moduli possono essere componenti già scritte che sono catalogate in una libreria e quindi riusate, agevolando la manutenzione. Tuttavia, l'eccessiva divisione in moduli può diminuire la comprensibilità del sistema software, in particolare quando le funzioni sono state divise tra molti moduli per rispettare la separazione degli interessi.
• Anticipazione del cambiamento: È la capacità di una applicazione di accogliere i cambiamenti generati da una qualsiasi causa, con poco impegno, in poco tempo e con un limitato rischio. I cambiamenti sono generati da miglioramenti del dominio applicativo, dei modelli, da cambiamenti del dominio applicativo o delle tecnologie a supporto del dominio. Questo permette di ridurre i tempi ed i costi per la manutenzione e aumenta la riusabilità delle componenti. Tuttavia, l'analisi e la progettazione devono essere tanto accurate da prevedere, quanto più possibile, i cambiamenti futuri portando alla necessità degli analisti della conoscenza approfondita del dominio applicativo.
• Astrazione: Consiste nell'estrarre ed analizzare gli aspetti più significativi di un progetto, riducendo la complessità e focalizzandosi sugli elementi fondamentali per la risoluzione dei problemi.