Ingegneria del software – modelli di sviluppo, UML, project e system design

CAPITOLO 1: Introduzione

1.1 Cos’è il Software

Il software è l’insieme delle componenti immateriali (in contrapposizione con l’hardware, che è

fisico) di un sistema di elaborazione. In particolare comprende non solo il codice, ma anche

documentazione, test, specifiche di progetto e manuali utente. Questo svolge un doppio ruolo:

 Prodotto: consente di sfruttare il potenziale dell’hardware.

 Veicolo di altri prodotti: agisce come base per il controllo di un elaboratore (Sistema

Operativo), la comunicazione di informazioni (reti informatiche), la produzione e controllo di

altri programmi (ambienti di sviluppo).

1.2 Programma vs Prodotto Software (Sommerville)

Bisogna distinguere in due terminologie fondamentali nello sviluppo software:

 Programma: qui l’autore è anche l’utente, non si hanno delle documentazioni, non viene

testato e non viene progettato. Ad esempio, uno script fatto da uno studente per risolvere un

esercizio.

 Prodotto Software: qui l’utente non è lo sviluppatore, si ha una documentazione essenziale,

richiede dei testing formali e richiede una progettazione formale. Questo rappresenta il software

industriale il cui costo è di circa dieci volte il costo del programma. Ad esempio, un app mobile,

un gestionale per aziende o qualsiasi app prodotta per essere usata da altri. Può essere di due

tipologie:

Generici: prodotti stand-alone venduti ad un mercato di massa. Qui le specifiche

o vengono controllate da chi sviluppa il software.

Specifici: prodotti su commissione per un singolo cliente. Qui le specifiche vengono

o controllate dall’acquirente.

1.3 Costi e Produttività

Il software ha costi elevati legati alle risorse umane, in particolare al rapporto mesi/uomo

(manpower) di lavoro. Il testing, invece, impiega fino al 40% dei costi, la manutenzione all’incirca il

90%. La produttività media si aggira in torno alle 300/1000 linee di codice per mese/uomo.

1.4 Problemi Tipici

Alcuni dei problemi tipici che si possono incontrare durante lo sviluppo software sono, ad esempio, gli

sforamenti di budget e tempi di consegna (ad esempio come accaduto per l’US Air Force o l’azienda

GDO). Un altro problema tipico è l’abbandono del progetto magari a causa di spese non più sostenibili

legate anche al ritardo dei tempi di consegna. Un ultimo problema tipico è la scarsa a idabilità del

software, in quanto oltre il 70% dei malfunzionamenti in sistemi complessi vengono rilevati durante

l’operatività del sistema (es. Ariane 5, Mariner).

1.5 Ingegneria del Software

Proprio a causa di tutti i problemi riscontrati nello sviluppo software nasce la necessità di applicare i

principi ingegneristici per sviluppare software complessi (Ingegneria del Software), su larga scala

e in squadra. In particolare, per realizzare un software che deve essere: il giusto prodotto, al giusto

costo, nel tempo giusto e con la giusta qualità.

Questa si basa sui seguenti principi:

 Rigore: concetto primitivo basato su precisione e accuratezza.

 Formalità: oltre il rigore, si inizia a parlare di fondamento matematico.

 Separazione degli aspetti: a rontare separatamente i problemi.

 Modularità: suddividere un sistema complesso in parti più semplici.

 Astrazione: identificazione degli aspetti cruciali ignorando gli altri.

 Anticipazione del cambiamento: la progettazione deve favorire l’evoluzione del software

 Generalità: tentare di risolvere il problema nella sua accezione più generale.

 Incrementalità: lavorare per passi successivi.

1.6 Metodi e Metodologie e Strumenti

Altre terminologie di cui bisogna tenere conto sono le seguenti:

 Metodo: tecnica per risolvere classi di problemi.

 Metodologia: insieme di metodi e principi per garantire la correttezza e l’e icacia del proprio

procedere.

 Strumenti: tool pratici per fare qualcosa in modo migliore.

 Procedura: combinazione di metodi e strumenti.

 Paradigma: approccio generale per fare qualcosa (es. Agile, waterfall, ecc.)

1.7 Processo Software

Un processo è una sequenza di passi che, nella tecnica, definisce le singole operazioni

fondamentali di attività, vincoli e risorse. Un processo software, invece, è l’insieme di attività

strutturate che sono utili per lo sviluppo (ad esempio testing e manutenzione) ed è suddiviso in varie

fasi che prendono il nome di ciclo di vita del software. Viene descritto da un modello (informale,

semi-formale o formale):

 Waterfall Model

 Spiral Model

 Rapid Prototyping

 Incremental Development

Il processo di sviluppo del software, alla fine, è il processo con cui le richieste dell’utente vengono

tradotte in un prodotto software, implementandone il codice, testandolo e, qualche volta, installando

e controllando il software per operazioni di utilizzo.

1.8 CASE Tools

I case tools sono degli strumenti per automatizzare lo sviluppo. Sono di due tipi principali:

 Upper-CASE: supportano le fasi iniziali come analisi e progettazione.

 Lower-CASE: supportano le fasi finali come programmazione, testing, debugging.

CAPITOLO 2: Modelli del CVS

2.1 Cos’è il ciclo di vita del software

Il ciclo di vita del software è l’intero arco di esistenza di un prodotto software: dalla concezione fino

allo sviluppo per poi passare all’uso e infine alla dismissione. Include fasi come: concettualizzazione,

requisiti, progettazione, implementazione, test, installazione, esercizio, manutenzione e ritiro.

Attenzione però, non va confuso con il solo ciclo di sviluppo che, al contrario, è il periodo che inizia

con la decisione di sviluppare un prodotto software e termina con il rilascio di quest’ultimo. Infatti,

inizia con la fase di analisi dei requisiti, la fase di sviluppo, la fase di implementazione, la fase di test e

la fase di installazione e prova. Le fasi principali del ciclo di vita del software si dividono in fasi alte

(ovvero quelle di definizione e progettazione dove agiscono anche gli Upper Case) e in fasi basse

(ovvero quelle di realizzazione e rilascio dove agiscono i Lower Case):

 Fasi Alte:

Studio di fattibilità: costi/benefici, alternative, risorse.

o Analisi dei requisiti: bisogni del committente, criteri di accettazione.

o Progettazione: che può essere architetturale quando ha una struttura generale,

o oppure di dettaglio quando si ha l’implementazione dei singoli moduli.

 Fasi Basse:

Implementazione (coding): scrittura del codice.

o Test di unità: verifica dei singoli moduli.

o Integrazione e test di sistema: verifica del sistema completo.

o Installazione: rilascio e avvio.

o Manutenzione: correzioni, aggiornamenti, miglioramenti.

o

2.2 Modelli del ciclo di vita del software

Un modello del ciclo di vita del software è una caratterizzazione descrittiva o prescrittiva di come

un sistema software viene o dovrebbe essere sviluppato che comprendono le descrizioni di dettaglio

delle attività, degli oggetti, delle trasformazioni e degli eventi. I principali modelli del ciclo di vita del

software sono i seguenti:

MODELLO A CASCATA (o WATERFALL): è un modello sequenziale lineare dove, prima di passare alla

fase successiva, bisogna concludere la fase precedente. Questo segue diverse fasi suddivise in fasi

alte del processo:

 Studio di fattibilità quando viene e ettuata una valutazione dei costi e delle risorse

 Analisi dei requisiti quando viene e ettuata una definizione delle funzionalità

 Progettazione quando viene e ettuata una definizione della struttura software delle

componenti

Oppure in fasi basse del processo:

 Sviluppo e test di unità quando viene e ettuata la codifica e la verifica dei singoli moduli

 Integrazione e test di sistema quando viene e ettuata la verifica del sistema completo

 Deployment quando viene e ettuata la distribuzione del software

 Manutenzione quando viene e ettuata la gestione delle evoluzioni del software.

Nonostante sia un modello chiaro, documentato e controllabile, l’iterazione con il committente

avviene solo all’inizio e alla fine e i requisiti vengono congelati presto.

MODELLO A V: è una variante del waterfall che enfatizza verifica e validazione (V&V). Qui le attività di

sinistra sono collegate a quelle di destra. Se si trova un errore in una fase di destra si ri-esegue il pezzo

della V collegato a sinistra.

MODELLI BASATI SU PROTOTIPO: viene creato un prototipo iniziale (anche grezzo) per accertarsi che

le funzionalità richieste siano ben comprese per ottenere un feedback dal committente. Questo

prototipo può essere di varie tipologie: Mock-Ups, modelli dell’interfaccia utente per chiarire i

requisiti; Breadboards, prototipi che testano funzionalità critiche senza interfaccia utente;

Throw-Away, prototipi usa e getta per chiarire i requisiti inizialmente poco chiari; Prototipazione

Esplorativa, partenza dai requisiti meglio compresi e lavoro a stretto contatto con il committente.

MODELLO INCREMENTALE: con questo modello il sistema è rilasciato in più versioni parziali

(incrementi) dove ogni versione aggiunge nuove funzionalità. Questo modello o re un feedback

continuo, una riduzione del rischio di fallimento e un testing più e icace rispetto agli altri modelli

precedenti.

SVILUPPO EVOLUTIVO: a di erenza del modello incrementale qui il sistema è completo sin dall’inizio

ma grezzo, tuttavia le funzionalità vengono migliorate progressivamente.

MODELLO A SPIRALE (BARRY BOEHM): è un meta-modello che consente di utilizzare più modelli

diversi in un approccio iterativo, con una forte attenzione alla gestione dei rischi. Ogni ciclo della

spirale è diviso in quattro fasi:

 Definizione obiettivi

 Identificazione dei rischi

 Prototipazione e sviluppo

 Verifica e feedback

Questo modello o re una maggiore flessibilità e la possibilità di avere una gestione controllata del

rischio.

EXTREME PROGRAMMING (XP): è un metodo agile, che si concentra su iterazioni veloci, piccoli

incrementi di funzionalità e costante miglioramento del codice. Coinvolge attivamente il

committente nel team di sviluppo e si adatta rapidamente ai cambiamenti.

MODELLO A COMPONENTI: si basa sullo sviluppo tramite componenti esistenti riusabili o di sistemi

COTS (o Commercial O -The-Shelf).

2.3 Scelta del modello giusto

Quando dobbiamo scegliere il modello giusto dobbiamo seguire determinate regole:

 Tipo di progetto

 Stabilità dei requisiti

 Disponibilità del cliente

 Dimensioni e criticità

 Risorse disponibili

CAPITOLO 3: Project Management

3.1 Cos’è un progetto

Un progetto è uno sforzo temporaneo intrapreso per creare un prodotto o un servizio unico, con un

inizio e una fine ben definiti. Secondo il Project Management Institute (o PMI) un progetto ha

obiettivi precisi, non è ripetitivo, e richiede risorse coordinate come tempo, persone, denaro,

materiali e competenze. Ha un ciclo di vita con fasi distinte, a partire da un’ideazione, per poi passare

con l’esecuzione e infine all’avviamento. Un progetto è complesso, non seriale e soggetto ad

imprevisti. Il costo di accelerazione cresce esponenzialmente nelle fasi finali a causa delle decisioni

prese all’inizio che hanno il maggior impatto su tempi e costi. Il project management (o PM) è

responsabile di rispettare le scadenze (tempo), di restare entro il budget (costo) e di soddisfare il

cliente (performance). La curva dei costi cumulati ra igura la crescita significativa nella fase di

esecuzione con una particolare attenzione agli imprevisti in ritardo.

3.2 Le quattro fasi del ciclo di vita del progetto

Il ciclo di vita del progetto si compone di quattro fasi che sono le seguenti:

 Ideazione: viene e ettuata l’analisi dei bisogni, opportunità, definizione obiettivi.

 Fattibilità: viene e ettuata la valutazione tecnico-economica, stima risorse, decisione se

procedere.

 Progettazione e organizzazione: viene e ettuata la pianificazione dettagliata, allocazione

risorse, contatti con stakeholder.

 Esecuzione: viene e ettuata la realizzazione vera e propria del progetto.

 Avviamento (chiusura): viene e ettuato il collaudo finale, messa in servizio, consegna,

smantellamento risorse.

3.3 Ruolo del project manager

Il project manager è il responsabile unico della riuscita del progetto e svolge attività come:

 Pianificazione e stima dei costi

 Monitoraggio e revisione

 Selezione e gestione del team

 Comunicazione con stakeholder

 Produzione di documentazione, report, presentazioni

Questa figura ha diverse competenze fondamentali sia tecniche (con l’uso di strumenti, teorie e

normative), sia di esperienza pratica, sia capacità relazionali e decisionali e sia sulla gestione dei

rischi.

3.4 Modelli di project management

Il primo modello di project management che viene creato dal project management institute nel 1996

è il PMBOCK (o Project Management Body of Knowledge) che e ettua una suddivisione del progetto

in fasi segnate da una consegna. Questo si occupa di raggiungere degli obiettivi attraverso processi

(simultanei e sequenziali) gestionali interrelati. Il PMBOCK segue diverse aree di conoscenza del

project management:

 Integration Management

 Scope Management

 Time Management

 Cost Management

 Quality Management

 Human Resources Management

 Communications Management

 Risk Management

 Procurement Management

 Stakeholders Management

3.5 Gruppi di processo (5 fasi operative)

Il PMBOCK segue la sovrapposizione dei gruppi di processo in una fase, questi si organizzano in

cinque fasi operative che sono: inizio, quando viene e ettuato lo studio approfondito dell’opera da

realizzare e del processo produttivo finalizzato; pianificazione, consiste nella programmazione

dettagliata della realizzazione dell’opera sviluppando le operazioni necessarie per la realizzazione e

i costi associati; esecuzione e controllo, quando si verifica la realizzazione

dell’opera/prodotto/servizio ed il controllo del processo produttivo; chiusura, quando vengono

e ettuate le analisi ex-post dell’opera in particolare di eventuali problemi insorti e degli errori

commessi puntando a ridurre la probabilità di commettere errori nelle successive realizzazioni.

3.6 Strumenti e tecniche del PM

Gli strumenti e le tecniche maggiormente utilizzate dal project manager sono le seguenti:

 WBS (Work Breakdown Structure): scomposizione del lavoro in task e work package.

 Milestone: punti chiave di controllo.

 Deliverable: risultati forniti al committente.

 Gantt Chart: pianificazione temporale visiva.

 PERT/CPM: analisi del percorso critico.

3.7 Gestione dei rischi

Il risk management consiste nell’identificare, analizzare e monitorare i rischi che possono essere di tre

tipologie principali:

 Project risks (tempi, risorse)

 Product risks (qualità, funzionalità).

 Business risks (mercato, concorrenza).

Per gestirli possiamo seguire diverse azioni:

 Avoidance: prevenire.

 Minimisation: ridurre impatto.

 Contingency: piani B se accade.

3.8 Tipi di team

Esistono diverse tipologie di team di lavoro così suddivisi:

 Democratico decentralizzato: nessun leader fisso, consenso condiviso.

 Controllato decentralizzato: leader che assegna compiti, decisioni condivise.

 Controllato centralizzato: leadership forte e diretta, comunicazione verticale.

CAPITOLO 4: Software Project Management

4.1 Cos’è il software project management

L’obiettivo del software project management è quello di gestire un progetto software per garantire:

 Consegna nei tempi stabiliti

 Rispetto degli standard qualitativi

 Controllo su costi e risorse

 Soddisfazione del committente

In questa operazione sono coinvolti vari ruoli con diverse funzioni, ad esempio avremo i business

managers che definiscono i vincoli economici, poi ci sono i project managers che organizzano e

controllano il progetto, poi ci sono i practitioners che realizzano tecnicamente il sistema, poi ci sono i

customers che definiscono i requisiti e, infine, ci sono gli end users che usano il software prodotto. Il

project manager software è quel ruolo che si occupa della stesura proposta e della stima dei costi

del progetto, della pianificazione (ovvero il planning e lo scheduling), della selezione del team e della

gestione delle risorse, del monitoraggio e controllo e del report e della documentazione.

4.2 Struttura del piano di progetto (un esempio)

Il piano di progetto si suddivide in varie sezioni:

 Introduzione: qui vengono definiti gli obiettivi e i deliverable del progetto (ovvero tutti gli items

che saranno consegnati con data e luogo di consegna), inoltre vengono definiti anche i piani di

evoluzione e i materiali di riferimento.

 Organizzazione: qui viene definito il modello del processo (ovvero le relazioni tra le varie fasi

del progetto), la struttura organizzativa (ovvero la gestione interna) e le responsabilità (ovvero

le principali funzionalità e attività).

 Processi Gestionali: qui vengono definiti gli obiettivi, vincoli e gestione dei rischi tramite un

monitoraggio e reporting e la pianificazione dello sta (ovvero skill necessari).

 Processi Tecnici: qui vengono definiti i metodi, gli strumenti e le tecnologie del progetto,

inoltre viene definita la documentazione software