Progetto del Software

UNIMORE-FIM INFORMATICA

Progetto del Software

Appunti delle lezioni

Lorenzo Balugani (@EvilBalu)

Sesto Semestre

INTRODUZIONE

Nell’ambito dell’ingegneria del software, la progettazione è una fase del ciclo di vita del software che, sulla base dei requisiti, definisce come tali requisiti saranno soddisfatti, entrando nell’ambito della struttura del software. Nello specifico, si parlerà della modellazione e metodologia necessaria per la specifica, l’analisi dei requisiti e la progettazione di sistemi software complessi, con riferimento alla UML e Essence.

1 – ING. DEL SOFTWARE

Il software ha un particolare ciclo di vita, che designa le varie fasi della vita di un software, e lo sviluppo è una parte di questo ciclo: questo processo ha inizio con il concepimento dell’idea, e si conclude con il rilascio finale, ed è

strettamente legato all’ingegneria del software.

Definizione: Ingegneria

Applicazione creativa di scienza e metodi matematici agli ambiti di progettazione, costruzione, innovazione, eccetera.

L’obiettivo di un’attività ingegneristica (ambito software) è portare a termine un prodotto (decidere cosa/come sviluppare), e include la gestione dei clienti/colleghi ed eseguire la manutenzione. La programmazione ha come obiettivo il portare a termine un programma (capire il compito, ideare un algoritmo, trasporlo in codice, ottimizzare).

Entrambe le cose son difficili e complicate, ma l’ingegneria è anche lunga.

L’ingegneria del software adotta un approccio organizzato e sistematico alla produzione del software, usando tecniche e mezzi che tengano conto di vincoli e risorse disponibili: offre soluzione sostenibili a problemi informatici pratici applicando conoscenze allo sviluppo del software. L’ingegneria del software ha come obiettivo quello di essere d’aiuto,quindi , alla produzione di software utile (anche se è complicato, dato che l’informatica è recente come scienza).

2 – PROSPETTIVA STORICA

L’ingegneria è antica, e possiamo considerare come inizio l’era romana: poca teoria, nessuna applicazione della matematica e completamente empirica. Nonostante questo, le opere di quel periodo ancora si mantengono. Con il rinascimento, l’ingegneria si appoggia alla scienza, e questo comporta un cambiamento nelle strutture e in come queste vengono costruiti. L’ingegneria del software è una disciplina giovane, ma molto importante dovuta all’ubiquità del software e alla sua continua crescita (anche economica, il costo del software è superiore a quello dell’hw). Negli anni 60, dopo insuccessi, nasce il ciclo di vita a cascata, preso in prestito dall’ingegneria civile, che ha diversi problemi (software in ritardo, costi elevati…) in quanto presa troppo alla lettera. L’approccio moderno è il ciclo di vita iterativo, in cui non tutti i requisiti non sono noti a priori e viene costruito man mano, con ogni iterazione che vengono presi in considerazione per l’iterazione successiva. I modelli per la rappresentazione dati sono passati da un modello che vede separati dati e funzioni a uno che li unisce (Metodo a componenti, UML), per poi arrivare alle metodologie Agili.

Le metodologie Agili portano un nuovo approccio mentale, con innovative pratiche e impostando iterazioni brevi nel modello iterativo. Fattore chiave nella progettazione software è l’esperienza, dato che non esistono in questo campo risposte definitive e immutabili.

3 – SVILUPPO E ORGANIZZAZIONE

I sistemi che si vanno a costruire devono essere affidabili e sicuri, ed esistono parecchi modelli di processi software che sono adatti a un certo ambito.

Legge di Conway

Le organizzazioni che progettano sistemi sono indotte a generare design che sono copie dei legami nelle

organizzazioni stesse. Ad esempio, se ci sono 4 team che fanno un compilatore, la struttura finale sarà su 4 processi in pipeline.

Le persone che lavorano in un team/organizzazione devono comunicare senza ostacoli e vicine dal punto di vista organizzativo al fine di evitare bias: nel caso in cui non ci siano relazioni chiare o non corrette, ci saranno problemi.

Il software moderno è, a tutti gli effetti, un processo sociale, e molte delle sue qualità si possono giudicare solo in termini sociali.

SOFTWARE

1 – QUALITÀ DEL SOFTWARE

Le qualità su cui si valuta un software possono essere interne o esterne, e sono fortemente legate (non si hanno qualità esterne se non ci sono qualità interne). Le qualità possono essere valutate relativamente al prodotto (caratteristiche del sistema) o al processo (processo che si è seguito per sviluppare il sistema). Alcune caratteristiche del prodotto sono:

• Correttezza, un sistema è corretto se rispetta le specifiche (committenti, specifiche)

• Affidabilità, l’utente può dipendere da esso (specifiche)

• Robustezza, il sistema si comporta in modo ragionevole in caso di emergenza (ciò che non è specifica, sviluppatori)

• Prestazioni, soddisfa requisiti quantitativi dell’utente (è efficiente se usa bene risorse di calcolo, è una qualità interna valutata dagli sviluppatori)

• Facilità d’uso, il sistema ha un interfaccia che permette all’utente di usarlo in modo naturale

• Verificabilità, le caratteristiche del sistema sono verificabili

• Facilità di manutenzione, se facilita la ricerca di errori, si possono aggiungere funzionalità di sistema e si può adattarlo a cambiamenti di dominio applicativo

• Riusabilità, se può essere “riciclato” in nuovi sistemi (in parte o completamente)

• Portabilità, se è multipiattaforma

• Comprensibilità, se è facile da comprendere

• Interoperabilità, funziona bene con altri programmi

Parallelamente alla valutazione del prodotto, si valuta anche il processo:

• Produttività, tempo di consegna

• Tempestività, valutazione e rispetto dei tempi di consegna

• [LOST]

Alcuni campi di applicazione (sistemi embedded, sistemi informativi, …) possono dare più peso a certe qualità che altri. Riassumendo, alcune qualità sono soggettive, e non esistono metriche standard: per questo motivo, è importante definire in fare di sviluppo degli indicatori di qualità.

2 – PRINCIPI IDS Definizione: Metodo

Un metodo è una procedura per ottenere qualcosa, in modo sistematico o già associato.

Definizione: Pratiche o tecniche Applicazione della teoria legati [LOST]

I principi sono:

• Rigore/formalità

o Anche se è un’attività creativa deve essere mandata avanti in modo preciso e rigoroso, il che implica Affidabilità, Controllo, e Fiducia nello sviluppo. La formalità richiede il supporto di leggi

matematiche, e implica il rigore, e insieme migliorano la manutenibilità, la riusabilità, la portabilità, la comprensività e l’intetroperabilità.

• Separation of Concern

o Divide diversi aspetti del problema che si affronteranno separatamente (divide et impera, si divide per ciclo di vita, per tipo d’interfaccia…), e non è sempre possibile da attuare.

• Modularità

o Un sistema complesso può venire diviso in moduli. E’applicazione della Separation of Concern, in due modi: nella top-down si parte da un problema generale, per poi scomporlo in sottoproblemi, mentre nella bottom-up si fa il contrario. In un modulo è preferibile avere alta coesione e basso accoppiamento, che facilita la manutenzione del codice.

• Astrazione

o Identifica gli aspetti fondamentali di un fenomeno, è un tipo particolare della Separation of Concern:

si va a creare un modello matematico del sistema, che svolgerà i compiti in modo ‘opaco’ al programmatore che sta lavorando su altro.

• Anticipazione del cambiamento

o Pianificare l’evoluzione del software, legata alla riusabilità, con cambiamenti confinati entro specifiche porzioni (refactoring). Rendono necessari dei compromessi.

• Generalità

o Quando si deve risolvere il problema A, è importante capire se A è un caso specifico di un altro problema (di cui magari esiste già una soluzione ben documentata), anche se la soluzione generale potrebbe essere meno ottimizzata. Non si usa nell’Agile.

• Incrementalità

o Lo sviluppo procede per passi successivi, mediante una seria di approssimazioni successivi e usando feedback per digerire gli incrementi. E’ pensato per le modalità Agile.

Definizione: Coesione

Misura il grado di legame tra le componenti del modulo.

Definizione: Accoppiamento Misura l’interdipendenza tra moduli.

Tutti questi principi forniscono linee guida, ma… nient’altro. Esistono alcuni programmi che offrono aiuto, i CASE (Trello, Mave, JUnit, Git).

Le sfide attuali sono la gestione di sistemi legacy (tecnologia obsoleta), e gestire la complessità (i sistemi sono sempre distribuiti e sono eterogenei dal punto di vista sw/hw). Ci si aggiungono la riduzione dei tempi di consegna e la scalabilità a complicare tutto quanto.

I costi del software sono una grossa fetta nei costi di un sistema, e superano di diversi OdG il costo dell’hardware, e il costo sta nel mantenimento più che nell’effettivo sviluppo.

I costi diretti sono quelli del personale (programmatori e supporto), del materiale (server) e i materiali di consumo (carta, corrente, rete…). I costi indiretti sono quelli della struttura (affitti), capacità/motivazione/coordinamento del personale (formazione), stabilità dei requisiti, costo di manutenzione.

E’ necessario che il software evolva, in quanto possono esserci bug oppure non ha del tutto raggiunto i requisiti:

l’evoluzione è ineliminabile. La maggior parte degli errori potrebbe essere trovata con tecniche di revisione di progetto, e i moduli con maggior complessità hanno più possibilità di contenere errori (i costi di rimozione dei bug è proporzionale alla maturità del software).

Al progettista sono affidate responsabilità che entrano nel campo professionale e etiche:

• Riservatezza, rispettare la riservatezza indipendentemente da NDA

• Competenza, non falsare il proprio livello di competenza o non accettare incarichi al di fuori delle proprie competenze

• Conoscere le leggi sulla proprietà intellettuale

• Non sfruttare le proprie competenze tecniche per usi non istituzionali 3 – PROJECT MANAGEMENT

Definizione: Project Management

Attività coinvolte nel garantire la realizzazione di un prodotto rispettando scadenze e vincoli (tempo e costo).

Per gestire i progetti, bisogna:

1. Proporre un progetto (o farsi proporre un progetto) a. Pianificare attività e costi

2. Selezionare il personale

3. Controllo dello stato di avanzamento 4. Produzione di report periodici

Le attività di un progetto vanno organizzate per produrre un risultato concreto e giudicare lo stato del progetto, con le milestone che sono la conclusione delle singole attività e i deliverable che sono i risultati del progetto rilasciati al committente (ogni azione visibile al committente). La progettazione si occupa anche dello scheduling, ovvero la stima delle risorse temporali per ogni attività e organizzarle in modo da usare ottimamente le risorse (individuazione di percorsi critici, minima dipendenza tra attività). Lo scheduling viene fatto:

1. Identificando le attività 2. Identificando le dipendenze 3. Stima delle risorse

4. Allocazione del personale

5. Creazione dei diagrammi di scheduling (GANT, PERT) MODELLI DI PROCESSO TRADIZIONALI

1 – COSTRUIRE SOFTWARE

Il processo di sviluppo definisce chi fa cosa, quando e in che modo, al fine di raggiungere un certo risultato. Lo sviluppo software è un’entità che digerisce i requisiti e produce il sistema e la sua documentazione, e ha alcune attività tipiche:

• Specifica, comprensione dello scopo del sistema e dei vincoli

• Progetto, definizione astratta del sistema

• Realizzazione, produzione di detto sistema

• Validazione, controllo che il sistema faccia quello che deve

• Manutenzione/Evoluzione

La metodologia di produzione è la rappresentazione semplificata e astratta di un processo di sviluppo, e si basa su un modello del processo di sviluppo (Cascata, Evolutivo…), e prevede:

• Artefatti, elementi che bisogna produrre

• Flusso di produzione degli artefatti, mostra le dipendenze

• Notazioni, usare per produrre gli artefatti

• Regole, vincoli da rispettare per la produzione di artefatti

• Suggerimenti/Aiuti/Buone pratiche

2 – LAVORARE IN TEAM

Fare parte di un team è qualcosa di necessario, in quanto è impossibile realizzare software complesso da soli, e all’interno del team sono presenti persone con più ruoli ed esperienze diverse:

• Come progettare il prodotto software (architetti)

• Come costruire il prodotto (programmatori)

• A cosa serve il sw (esperti del dominio di cui si occuperà il software)

• Come va fatta l’UI (progettisti d’interfaccia)

• Controllo di qualità di prodotto (tester)

• Uso delle risorse (project manager)

• Come riusare software esistente (gestori delle configurazioni)

La presenza di un team genera overhead di comunicazione, e ci sono diversi approcci alla programmazione:

programming in the small (un programmatore = un modulo), programming in the large (software su più moduli, versioni e configurazioni su cui lavorano diverse persone (mai stessa persona su stesso modulo)) e programming in the many (software grandi, richiede cooperazione e coordinamento tra diversi programmatori).

Il processo di produzione più semplice è il “programma e prova”, generalmente valido in un ottica di programmazione personale (e singola), in cui scrive una funzionalità e la si prova (anche noto come cowboy programming): questo è veloce e ha feedback rapido, ma va bene solo per progetti piccoli e non incoraggia la documentazione, pessimo per la manutenzione e scala male.

Nella programming in the large, le cose possono essere più complicate.

Definizione: Configurazione

Una configurazione è formata da configuration items, e sono un elemento atomico [LOST]

Definizione: Baseline / Milestone

Versione particolare che è stata rivista e approvata dall’amministrazione, che può essere usata come base per ulteriori sviluppi, e può venire modificata solo da procedure controllate

Definizione: Release

Milestone che viene resa visibile al di fuori del team 3 – MODELLI DI PROCESSO

Definizione: Processo SW

Attività necessarie per sviluppare un software (ruoli, attività e documenti da produrre) Definizione: Modelli di processo SW

Famiglia di processi

Il modello di processo è analogo alla relazione esistente tra classe e oggetto in OOP (un processo waterfall è un istanza del metodo waterfall). Per descrivere un processo bisogna definire attività, strumenti, ruoli, eventi, documenti e criteri di qualità. Descrivere un processo di sviluppo serve a creare una guida, che permetta di mantenere la rotta e

coordinare il team: se si migliora il processo, si migliora il progetto.

I modelli generici possono essere divisi in 4 categorie:

• Modelli lineari (waterfall): specifica e sviluppo sono separati, hanno una sequenzialità marcata

• Modello iterativo (UP): specifica e sviluppo sono siclici e sovrapposti (linearità circolare)

• Modello agile (XP): è pianificato diversamente in quanto guidato dall’utente e dai test

• Modello formale (B method): il modello matematico diventa modello di processo

WATERFALL

Caratterizzato da rigide fasi sequenziali, fortemente pianificato e document-driven (tutto quanto viene documentato, la documentazione è fondamentale), ha grande importanza storica. E’composto da diverse fasi:

• Analisi dei requisiti, porta alla creazione dell’SRS (dice cosa deve fare il sistema).

• Progetto

o I progettisti usano i requisiti per determinare l’architettura del sistema. Procude l’SDD, documento di progetto che indentifica tutti i moduli e le loro interfacce.

• Codifica

o I vari moduli sono implementati e testati.

• Integrazione

o I moduli sono integrati tra loro, e si testano le integrazioni. Il risultato di questa fase è l’STD, che è il documento di test d’integrazione.

• Test del sistema

o Il sistema viene provato nella sua totalità e nel suo ambiente, e si producono il documento di verifica e la documentazione utente (oltre che il sistema deployato)

Aspetti positivi Aspetti negativi

Pianificato Molto rigido

Molto dettagliato Adatto a organizzazioni gerarchizzate

Orientato alla documentazione e agli standard Coinvolge il cliente solo alla fine

Il modello è molto adatto per progetti con requisiti stabili e ben definiti, ma ha problemi strutturali (il cliente deve sapere definire i requisiti, il software funziona solo alla fine ed è difficile fare modifiche durante).

V-MODEL

Modello fatto a V, che permette di tornare indietro (in un certo senso):

tutte le fasi (a parte quella di coding) hanno una fase che le conferma. E’

un modello lineare.

MODELLO SHARKTOOTH

Modello che permette di avere conferme per ogni fase, mediante feedback da parte del cliente.

MODELLO ITERATIVO

Il problema dei processi lineari è che, superata la fase di progetto e arrivati in fase di codifica, non si può tornare indietro senza dover buttare via tutto il lavoro.

Se nel waterfall si parla di tempo lineare, nel tempo ciclico si hanno cicli di durata temporale differente. L’uso di un modello iterativo consente di segmentare lo sforzo in modo migliore (il testing nel metodo a cascata assorbe molto più sforzo delle altre attività).

MODELLO A FASI SOVRAPPOSTE

Basato su apprendimento e adattamento, usa un processo iterativo e sovrappone più fasi una sopra l’altra.

MODELLO A SPIRALE

Modello iterativo composto da 4 fasi:

• Definizione dell’obiettivo

• Valutazione dei rischi di non riuscita

• Sviluppo e validazione

• Pianificazione (revisione + futuro)

Il modello a spirale è adatto se i requisiti sono instabili.

Aspetti positivi Aspetti negativi

Flessibile, Pianificato Difficile valutare i rischi

Valuta il rischio di ogni iterazione Costoso Può supportare diversi modelli di processo

Richiede il coinvolgimento del cliente PROCESSI ITERATIVI

• RUP

o Modello di processo iterativo diviso in 4 fasi: fattibilità, progettazione, codifica/test, deployment. Il modello venne proposto negli anni 90, e a lui si sono ispirati diversi processi, che prendono il nome di UP.

o Il processo RUP integra la prospettiva tecnica (aspetti qualitativi/ingegneristici e di progettazione) e una prospettiva gestionale (aspetti finanziari e commerciali), rispettivamente estese su 6 (Business modeling, requisiti, analisi, test, implementazione, ilascio) e 3 (gestione progetto, gestione configurazione, ambiente) core workflow (discipline)

• Open UP

o OpenUp usa dei micro-incrementi che, in tot tempo, generano una nuova iterazione (produce una demo) che fa avanzare il progetto.

• Varianti di RUP e MSF

• Synch and Stabilize

QUALITÀ DEI PROCESSI SOFTWARE

La qualità di un processo viene stabilita osservando 4 indicatori:

1. Precisione: il processo descrive ruoli e artefatti in modo chiaro

2. Ripetibilità: il processo può essere eseguito da persone diverse, che otterranno lo stesso risultato 3. Visibilità: il processo è noto alle parti interessate

4. Misurabilità: il processo può essere valutato mediante alcuni indicatori PROCESSI AGILI

I progetti, nel 2014, che rientrano nei requisiti iniziali e arrivano a conclusione sono solo 16%, che non rispettano i vincoli economici/temporali il 53% e i falliti il 31%. La percentuale è così elevata è dovuta al fatto che… certe cose non vengono pianificati: alcuni problemi sono complessi, la situazione non è chiara, i requisiti cambiano (ogni sei mesi la metà dei requisiti perdono di importanza, soppiantati da nuovi). L’idea è quella di mantenere valida l’idea dei processi iterativi, cercando di concentrarsi sul produrre valore senza sprechi.

La fisolofia Agile ha lo scopo di ridurre gli sprechi, e i metodi agili sono molteplici, anche se ci concentreremo su Scrum. Mettono al centro individui e interazioni, software che funziona (al posto di una documentazione completa), collaborazione con il cliente (al posto di una negoziazione contrattuale) e il reagire ai cambiamenti (al posto di seguire un piano). Gli aspetti comuni a tutti i metodi agili sono:

• Rilasci frequenti del prodotto (versioni nightly)

• Collaborazione continua del team con il cliente

• Documentazione ridotta

• Valutazione continua di rischi

Si sposta l’attenzione dal progetto al prodotto.

Definizione: MVP

Nello sviluppo di un prodotto, l’MVP è il prodotto con il più alto ritorno sugli investimenti rispetto al rischio.

La strategia dell’MVP è mirata a evitare di creare cose che i clienti non vogliono, massimizzando le informazioni apprese sul cliente. Nell’Agile, se nell’incrementale dal deploy torniamo al build, nell’iterativo torniamo al planning, torniamo daccapo allo scoping per capire se stiamo facendo qualcosa di utile (o meno) per l’utente.

La discriplina agile XP (extreme programming), basata sulla semplicità, coraggio, comunicazione e feedback, porta lo sviluppo ad essere condotto da un team di persone composto da pochi individui, nello stesso locale, e in presenza di un rappresentante di un cliente. E’ composta dalla fase esplorativa, dalla fase di pianificazione, dalla fase di iterazione e di produzione (che si ripetono). La XP prevede diverse tecniche, presenti in altre discipline agili, come la Continuous Integration. I requisiti sono:

• User Stories: usate al posto dei documenti per i requisiti, scritte dai clienti con linguaggio non tecnico (gli utenti possono fare x)

• Planning Game: i requisiti vengono organizzati, e le risorse sono valutati dagli sviluppatori: le storie vengono ordinate per priorità, e la posizione è fluida (la priorità può aumentare/calare). Il mazzo prende il nome di Product Backlog

• Presenza del cliente: evita che il progetto perda la mira (i programmatori immaginano quello che il cliente vuole): gli sviluppatori non devono fare ipotesi!

• Test driven developement: scegliere una user story e definire i test prima del codice, e i test dovranno essere prima automatizzati. I test sono guidati dalle user stories, scritti dal cliente e servono come contratto e come indicatore di progresso.

• Piccoli rilasci: di durata breve (quello che c’è allo scadere del tempo c’è, se qualcosa non va la si lascia indietro), minimali ma utili e immediatamente condivisi (integrazione continua)

• Metafora: non sempre usata, metafora tra funzionalità e altro

• Progettare in modo semplice: si pianifica poco e si realizza quello che si vuole nel modo più semplice possibile, includendo la documentazione.

• Refactoring: migliorare il codice senza cambiare la funzionalità, atto a semplificare il codice e migliorarlo.

Vengono usati test per assicurare che le modifiche non rompano qualcosa.

• Pair programming: due programmatori lavorano allo stesso codice, uno scrive e l’altro osserva e partecipa, con i ruoli che vengono scambiati periodicamente. Il pair programming migliora la qualità.

• Integrazione continua: la coppia scrive i test ed il codice, fa il test, integra il nuovo codice, verifica l’integrazione, e passa alla task successiva.

• Proprietà collettiva del codice: il codice appartiene al progetto, tutti possono osservarlo e modificarlo, e per ottenere questo serve l’integrazione continua

• Passo sostenibile: non lavorare fino a tardi, se il progetto danneggia la vita privata dei partecipanti il progetto ne risente.

• Codifica: occorre essere necessario stabilire delle convenzioni di codifica (per il Pair Programming), e non dovrebbe essere necessario commentare il codice (se il codice richiede un commento, va riscritto) I rischi del processo XP sono:

• Codice non testato interamente

• Il team produce pochi test utili per il cliente, il quale non aiuta a testare il sistema

• I test non vanno prima dell’integrazione e sono lenti

• Le storie sono complicate

• Il sistema è troppo difettoso

• Il controllo qualità vuole documenti

• Il manager vuole la documentaizone

• Il team è sovraccarico e deve affrontare scelte rischiose

• Alcuni nel team fanno i cowboy

Il metodo, dati alla mano, sembra funzionare (le coppie producono codice di qualità, le coppie completano i loro compiti con minor sforzo individuale).

Come fare a scegliere tra agile o pianificato? Se il team è piccolo, ci sono requisiti instabili, è richiesto refactoring allora è meglio andare di Agile, che piace a chi vuole libertà di fare e necessita di esperti di metodi agili (al posto di esperti analisti per la pianificazione).

ESSENCE

Linguaggio grafico nato per porre fine alla guerra di religione tra metodi di sviluppo. Prevede un nucleo comune a tutte le pratiche, poi aggiunge un linguaggio grafico. Il sistema prevede gli alpha (entità del processo che vogliamo controllare), ognuno dei quali avrà uno stato diverso, i prodotti (artefatti) e le competenze. Essence vuole diventare un metodo generale per descrivere/monitorare/controllare/predirre tutti gli aspetti dei processi.

5 – SPECIFICA DEI REQUISITI

FASI E TECNICHE DEL PROGRESSO DI SVILUPPO (RECAP)

Esistono vari modi di sviluppare software, ma le fasi (specifica, progettazione, implementazione, verifica/validazione, manutenzione&evoluzione) sono sempre le medesime: cambiano solo tempi, importanza e sequenza di queste fasi.

Specifica

Attività che stabilisce quali siano i requisiti e i vincoli, e si procede per un processo di ingegneria dei requisiti (studio di fattibilità, specifica dei requisiti, analisi dei requisiti e validazione).

Progettazione

Attività che permette la progettazione della struttura che va a realizzare la specifica. Le metodologie di progettazione sono varie, e il progetto è documentato con un insieme di modelli (data-flow diagram, entity-relation diagram).

Implementazione

Converte l’architettura in qualcosa di codificato.

Verifica e validazione

Attività che servono per mostrare che rispetta le specifiche (verifica) e soddisfa i requisiti (validazione), e

comprendono la revisione e testing del sistema (il testing viene fatto su casi di test derivanti da specifiche). Il testing serve per verificare il comportamento di un sistema su un numero di casi sufficientemente (non c’è modo migliore di definirlo) ampio da poter assumere che il sistema si comporti correttamente nelle restanti situazioni. Il testing non è debugging (il testing può essere automatizzato e non solo da programmatori, il debugging manualmente e da programmatori, lo scopo nel testing è trovare l’errore mentre del debugging trovarne le cause). Il testing fatto bene può evitare sessioni di debugging evitabili.

Il testing può essere fatto a diversi livelli:

• Test funzionali sul componente

o Unit testing: testing di ogni singolo componente o Module testing: test di ogni modulo

• Test d’integrazione

o Sub-system testing: test dell’integrazione tra sotto sistemi o System testing: test del Sistema nel suo complesso o Acceptance testing: testing con utenti

o Regression test, Performance test

Esistono tre tipologie di test: Black box testing (dettagli interni al programma non noti, si concentrano sui risultati osservabili), White box testing (usano la conoscenza della struttura del programma interna per guidare i test), Grey box testing (misto dei due precedenti), Monkey testing (grande quantità di dati a caso per vedere se qualcosa si rompe) e Exploratory testing (apprendimento+test design+esecuzione e strategia scacchistica: il tester costruisce nuovi test, man mano che scopre il codice). In ambito professionale si usano tool automatici per il testing. Le

operazioni di testing si dividono in testing in the small (moduli singoli) e testing in the large (sistema nella sua totalità)

TESTING IN THE SMALL

Valuta il funzionamento di una porzione di codice, osservando l’output in base all’input. Verifica la copertura dei programmi e delle istruzioni, possibile solo tramite white-box testing

• Branch test: per ogni condizione si usa un test che produce risultato vero o falso, e per ogni diramazione devono essere testate tutte le possibilità (applicabile solo a piccole porzioni)

• Verifica di copertura delle condizioni e delle decisioni

TESTING IN THE LARGE

Il white-box testing è inapplicabile, si usa principalmente il black-box testing e si fa grande affidamento alle specifiche (si costruiscono test conoscendo le specifiche).

ISPEZIONE DEL CODICE

Analisi del codice per capirne le caratteristiche e le funzionalit.

Definizione: Code walk-through

Analisi informale fatta da un team che simulano su carta il comportamento del programma, basandosi sulla documentazione.

Definizione: Code inspection

Processo che coinvolge una persona o un software che ispeziona il codice e segnala possibili problemi (variabili non usate, loop infiniti, rilascio memoria improprio).

REQUISITI E DESIDERI

Requisiti, desideri e bisogni sono cose diverse, e il compito del progettista è mettere insieme requisiti tenendo conto delle altre due cose. Ogni sistema da costruire deve avere dei requisiti (idealmente quantificabili). Nel progetto del software, la specifica è un accordo tra il produttore e il committente (consolidato nell’SRS, backlog nel mondo Agile). A seguire la specifica dei requisiti, il progettista e i programmatori si accordano sulle caratteristiche del software in termini di organizzazione, e si prendono accordi a livello di moduli.

La specifica dice cosa il sistema deve fare ma non il come, a cui penserà l’implementazione. Un requisito è una descrizione delle caratteristiche del sistema, e si dividono in tre tipi: funzionali (come il sistema deve

reagire/comportarsi), non funzionali (caratteristiche dei servizi, come affidabilità, reattività, resistenza…) e di dominio (legati all’ambito del progetto). Il confine tra funzionale e non funzionale è labile e legato al contesto.

REQUISITI NON FUNZIONALI

• Requisiti di prodotto o Affidabilità o Portabilità o Usabilità o Efficienza

 Spazio

 Performance

• Requisiti organizzativi o Requisiti di consegna o Requisiti di implementazione o Requisiti su standard

• Requisiti esterni

o Interoperabilità tra sistemi o Requisiti etici

o Requisiti legislativi

USO DELLE SPECIFICHE

Le specifiche descrivono quello che vuole l’utente, e sono un aspetto critico e prono ad errore: il programmatore può non comprendere alcune esigenze, o il committente può non aver chiare le proprie esigenze. Le specifiche definiscono il modo in cui l’utente interagisce con il sistema, e anche specifiche di tipo interno. Sono utili anche per attivare la manutenzione del software, che può essere correttiva (cambia l’implementazione), adattiva (requisiti modificati), perfettiva (i requisiti funzionali non cambiano). Le specifiche dovrebbero essere chiare (non ambigue, comprensibili), consistenti (non ci devono essere contraddizioni), complete (completezza interna, la specifica deve definire tutti i termini di cui fa uso, completezza esterna, tutti i requisiti funzionali devono essere specificati), incrementali (le specifiche vanno raffinate in modo incrementale): difficilmente lo sono, e più il documento è lungo più è facile che ci siano incoerenze. Le specifiche possono essere verificate o osservando il comportamento del sistema oppure le sue proprietà.

Per mostrare le specifiche operazionali, si usano diagrammi di flusso di dati, diagrammi UML, macchine a stati finiti o reti di Petri, mentre quelle descrittive (vicine al cliente) sono i diagrammi E/R, le User Story e le card classe-

responsabilità. Tutte queste notazioni possono essere completate in modo abbastanza libero.

ESTRAZIONE DI REQUISITI

La fase di specifica richiede la scrittura di requisiti, ed è necessario ‘sollecitare’ il cliente a fornire tutti i requisiti necessari. Per farlo è necessario:

1. Raccogliere informazioni

a. Stakeholder analysis: intervistare i clienti. Ha il vantaggio di considerare tutti i punti di vista e dare priorità alle opinioni, ma produce troppi dati e richiede troppo tempo.

b. Brainstorming: permette di raccogliere molte idee da un gruppo di persone, permette a tutti di dare un contributo. E’ breve, ma non è sempre produttivo

c. Intervista

I requisiti sono qualcosa di fondamentale, che accompagnano il progetto per tutto il suo ciclo di vita. Vengono rilevati identificando gli stakeholder e parlando con loro. L’uso delle carte permette di capire se stiamo andando nella giusta direzione.

6 – SRS

L’SRS è uno standard (IEEE 830-1998) che riporta in modo corretto [LOST]. Viene usato generalmente per i modelli classici.

Termine: Contratto, documento legale stilato tra committente e fornitore Termine: Committente, colui che paga per il prodotto

Termine: Fornitore, colui che fornisce il prodotto Termine: Utente, colui che usa il software

L’SRS deve essere:

• Corretto: i requisiti descritti al suo interno devono rappresentare qualcosa che è stato richiesto nel prodotto finale.

• Non ambiguo: l’SRS è composto da un dizionario (definisce con esattezza ogni voce), usa linguaggio di specifica (ogni caratteristica deve essere descritta con lo stesso termini, bisogna prevedere dei glossari) e una notazione basata sui concetti di oggetto, processo e comportamento.

• Completo: se comprende tutti i requisiti e definisce la risposta per tutti gli ingressi. Se ci sono frasi contenenti il “da definire”, l’SRS non è completo.

• Consistente: nessun requisito deve essere in conflitto con altri requisiti.

• Ordinato: ogni requisito ha un identificatore che indica la sua importanza, attribuita per la sua stabilità (il requisito è più o meno vago) o necessità (quanto ci serve). Per quest’ultimo, si segue il metodo MoSCoW:

o Must-haves (fondamentali)

o Should (migliorano il software, ma si può usare senza) o Could (valore aggiunto)

o Would (sarebbe carino, ma può essere tralasciato)

• Verificabile: la verificabilità di un SRS dipende dalla verificabilità dei suoi requisiti (che vanno quantificati).

• Modificabile: l’SRS deve rendere possibile l’eseguire cambiamenti in modo facile, completo e consistente, mediante una struttura rigida.

a. Introduzione

i. Campo d’applicazione ii. Obiettivi

iii. Definizione iv. Fonti

v. Struttura documento (panoramica)

• Tracciabile: ogni requisito è tracciabile.

L’SRS è il risultato della scrittura congiunta tra committente e fornitore, che vanno a definire i requisiti: il committente è un esperto del dominio di applicazione, il fornitore è esperto dello sviluppo software.