termine si intende l’insieme delle fasi che accompagnano un programma durante

tutta la sua vita, dal momento in cui viene pensato al momento in cui viene can-

cellato perché non più utilizzato.

• la fattibilità del sistema, con cui si verifica se il progetto è realizzabile sia dal punto di vista tecnico, sia dal punto di vista economico;

• i requisiti del sistema, sotto forma di funzionalità richieste e di vincoli che vengono posti;

• l’interfaccia utente;

• l’architettura che dovrà avere il sistema;

• i dati che dovranno essere utilizzati;

• i test da eseguire per verificare l’utilizzabilità del sistema. Progettazione Viene descritto il progetto nei minimi dettagli, prima a livello macro, poi sempre più nei particolari, fino a identificare anche gli aspetti implementativi. Questa fase viene suddivisa in due principali sottofasi:

• l’architettura di progetto, dove vengono organizzate le componenti software;

• il disegno di dettaglio, dove viene descritto come implementare le componenti. Realizzazione Si traduce il progetto in un insieme di programmi scritti in un linguaggio di pro- grammazione, si eseguono dei test e si integrano tra loro le differenti componenti del sistema. Avvio in produzione Una volta completati i test interni, viene consegnato e installato presso il cliente il prodotto software completo e la relativa documentazione. Si provvede al collaudo effettuando test specifici con il personale del cliente e utilizzando dei dati di pro- va reali. Successivamente il sistema entra in produzione, cioè comincia a essere utilizzato concretamente dal cliente. Manutenzione La fase di manutenzione accompagna la vita di un prodotto software da subito dopo il suo rilascio fino alla sua fine, cioè fino al momento in cui non verrà più utilizzato. Vi sono varie tipologie di manutenzione.

• Manutenzione correttiva, quando si evidenziano malfunzionamenti dovuti a casi particolari non sufficientemente testati o non considerati.

• Manutenzione adattativa, quando bisogna effettuare delle modifiche alle fun- zionalità esistenti per adeguarle per esempio alle mutate condizioni fiscali, legi- slative o sociali. • Manutenzione evolutiva, quando vengono inserite nuove funzionalità che soddi- sfino nuove esigenze dell’utenza sorte dopo lo sviluppo del prodotto. puoi farmi un riassunto

Il processo di sviluppo del progetto implica fasi di gestione attraverso le quali pianificare, eseguire e controllare lo stato del progetto. Le attività coinvolgono sia lo sviluppo che la gestione, riconoscendo che la realizzazione di un prodotto complesso richiede un notevole sforzo coordinato tra diverse figure coinvolte.

Le fasi del progetto comprendono avvio, pianificazione, esecuzione, controllo e chiusura. Il Project Management, come disciplina manageriale, fornisce strumenti e tecniche essenziali per gestire attività e risorse. I processi di pianificazione, esecuzione e controllo sono interconnessi, e durante la fase di controllo, potrebbe essere necessario ripianificare con una revisione del piano di progetto.

Il metodo di lavoro principale che devo conoscere come Project Manager include la Work Breakdown Structure (WBS) per la scomposizione gerarchica del progetto e il diagramma di Gantt per la visualizzazione temporale delle attività. Questi strumenti sono fondamentali nel garantire una gestione efficace del progetto e nel raggiungere gli obiettivi prefissati.

di quanto è stato fatto e quanto rimane da fare, a ogni fase di lavoro. Nelle fasi iniziali

del progetto si ha una produzione di documenti di analisi più massiva, dopodi-

ché, oltre a nuovi documenti, si producono anche modifiche ai documenti

esistenti, via via più lievi.

La quantità e la tipologia di documenti da produrre dipendono da

una serie di fattori:

• la dimensione e la complessità del progetto;

• la struttura e la natura organizzativa del cliente;

• la struttura e la natura organizzativa del fornitore del software.

Uno dei documenti più usati al fine di mantenere la storia del pro-

getto ed evitare fraintendimenti tra i vari attori è il Verbale di ri-

unione.

Si tratta di un semplice e utile strumento che ci permette di docu-

mentare e archiviare quanto emerge nelle varie riunioni che si svolgono

durante la vita del progetto. Affinché il documento possa essere utile, dob-

biamo indicare per ogni incontro le seguenti informazioni:

• la data e l’ora della riunione;

• il luogo di svolgimento;

• la durata;

• i nominativi e il ruolo dei partecipanti;

• l’ordine del giorno;

• l’elenco dei punti emersi durante la discussione, in maniera più o meno dettagliata

in funzione del grado di importanza dell’argomento di cui si discute.

strumenti di supporto gestionale; sul mercato ne esistono molti, spesso on-line e gra-

tuiti, almeno per le funzionalità di base o per gestire progetti non troppo complessi.

Tra questi, uno molto diffuso e utilizzato è Trello.

Trello si basa sul concetto di “lavagna condivisa” su cui possiamo creare liste di task

organizzate secondo le indicazioni del gruppo di lavoro.

• Board: la lavagna che rappresenta il progetto;

• List: a seconda della board, vengono rappresentati i macro-step di un progetto (per

esempio “Da fare”, “In lavorazione”, “Fatto”); le idee (per esempio “Idee per rendere

accattivante l’interfaccia”, “Idee per facilitare l’uso dell’interfaccia”), che possono

anche essere relative ai vari componenti del team (per esempio in una board creata

per sviluppare un sistema software le liste serviranno a raccogliere i task degli svi-

luppatori);

• Card: è l’unità di base (scheda) della board e rappresenta il singolo task o un’idea.

Nel corso degli anni, diverse metodologie di progetto sono emerse per soddisfare le esigenze dei progettisti e programmatori. Inizialmente incentrate sulla documentazione del software, si sono poi sviluppate metodologie specifiche per varie fasi del ciclo di vita del software, come l'analisi dei dati e la guida nella fase di analisi funzionale. La scelta di una metodologia dipende dall'applicazione specifica, dall'attività e dal numero di utenti coinvolti. Non esiste una metodologia universale ottimale, ma diverse filosofie si adattano a circostanze specifiche.

Nel modello a cascata (waterfall) il progetto viene organizzato in una sequenza di

fasi, ciascuna delle quali produce un risultato (output) che costituisce l’input per

la fase successiva

Prototipizzazione rapida:

Un prototipo software è un sistema che funziona effettivamente, ha una durata

non generalizzabile e può servire a vari scopi. È parte integrante di un processo

iterativo di sviluppo centrato sull’utente e deve poter essere costruito rapidamen-

te e a basso costo

Modello incrementale:

Nel modello incrementale si adotta una strategia di segmentazione del progetto

in parti al fine di soddisfare più velocemente (per quanto possibile) l’utente e otte-

nere feedback anticipati sull’efficacia del prodotto.

Il sistema viene diviso in parti differenti che possono essere progettate e sviluppate in parallelo.

Modello a spirale o iterativo:

Il modello a spirale estremizza il concetto di sviluppo incrementale e di proto-

tipizzazione rapida. In tale modello il ciclo di vita è un insieme di numerosi pro-

totipi, che si evolvono attraverso successive sperimentazioni e raffinamenti fino a

soddisfare completamente le necessità dell’utente.

Un requisito è la formalizzazione di una funzionalità o di un gruppo di funzionalità, viste come un tutt’uno, che il sistema deve supportare. Ogni requisito corrisponde a uno degli obiettivi che si pone il progetto stesso.

Un’altra classificazione possibile riguarda la tipologia dei requisiti, che possono essere:

• funzionali: esprimono le funzionalità che il sistema deve avere e i vari servizi che

dovrà fornire all’utente;

• non funzionali: esprimono i vincoli non legati alle funzionalità utente, ma dipendenti per esempio dalle necessità prestazionali e/o tecnologiche del sistema stesso.

Metodi per la raccolta dei requisiti:

Prototipi software, Sviluppo cooperativo delle applicazioni, Sviluppo rapido delle applicazionil.

Nel contesto progettuale degli ambienti distribuiti, la strategia adottata per una corretta suddivisione delle attività tra il client e il server riveste un ruolo cruciale. Un approccio comune, basato sull'architettura BCE (Boundary, Control, Entity), introduce un ulteriore livello chiamato middleware. Questo componente rappresenta la logica applicativa che si colloca tra il client (boundary) e il server (entità). Questa architettura a tre livelli, spesso denominata three-tier ("a tre strati"), implica l'esistenza di un nodo di elaborazione dedicato per ciascuno dei tre livelli. Tale struttura, definita anche come architettura a tre strati "pura", contribuisce a una chiara separazione delle funzioni tra client e server in un contesto distribuito.

1. Linee di Codice (LOC): Un approccio iniziale risalente agli anni '60, si basa sul conteggio delle righe di codice sorgente. Maggiore è il numero di righe, maggiore è la complessità e il costo, adatto soprattutto per applicazioni ripetitive e di logica lineare.

2. Complessità Ciclomatica: Applicata a software con logica algoritmica, valuta la complessità attraverso la struttura del codice, analizzando i cammini generati dalle istruzioni condizionali e ripetitive. Il "calcolo ciclomatico" fornisce una misura di complessità, utile se il codice è efficiente e ben scritto.

Le misurazioni storiche delle applicazioni ICT consentono stime più precise nel tempo, fondamentali per il software engineering. Tuttavia, alcuni approcci di misurazione potrebbero non essere più adeguati alle moderne modalità di sviluppo e ai diversi tipi di software.