Progettazione del software

Rivediamo limitatamente al processo Waterfall qual è la parte di progettazione: 

La progettazione, che viene svolta prima della realizzazione vera e propria del software, è un insieme di fasi che hanno l’obiettivo di:

– verificare se un progetto è fattibile, quanto tempo richiede e che risorse sono necessarie (analisi di fattibilità);

– fornire al committente una indicazione rigorosa e non ambigua di cosa verrà effettivamente sviluppato (analisi funzionale) ;

– a fornire ai team di sviluppo e ai tecnici un progetto che definisca come il prodotto dovrà essere realizzato (ovvero l’analisi tecnica).

Nello schema seguente possiamo vedere le tre fasi, i principali attori e come sono collegate tra loro.

L’analisi di fattibilità

L’analisi di fattibilità ha lo scopo non solo di verificare se un progetto è fattibile, ma anche di individuare a grandi linee le soluzioni tecnologiche proposte (vedi sotto) ed il loro costo (espresso in termini sia di risorse materiali che di lavoro e competenze richieste), al fine di permettere al reparto commerciale (o al marketing) di calcolare il costo e dare un prezzo finale al committente del progetto/prodotto da realizzare. Questa attività viene chiamata stima ed è un elemento chiave per un progetto software, in quanto deve essere il più possibile corretta. Una sovrastima dei costi infatti può comportare un prezzo troppo alto per il committente, mentre una sottostima invece può portare a costi eccessivi per chi realizza il software (in generale una società di software/di consulenza informatica).

Effettuare una stima corretta richiede molta esperienza ed in genere è svolta dal programmatore più esperto e nelle aziende più grandi da una figura dedicata ovvero il software architect, ovvero la figura che progetterà il software. Nei progetti di grandi dimensioni ed in particolar modo quando sono previste delle gare di appalto (ad esempio nell’amministrazione pubblica) è necessario giustificare la stima con modelli di calcolo della stima di tipo ingegneristico. Tra questi il più diffuso è il COCOMO, un modello matematico particolarmente adatto ai processi Waterfall classici fino alle 500 mila righe di codice, dove ogni funzionalità richiesta viene stimata in righe di codice, e vengono poi adottati dei moltiplicatori in base alle dimensioni dei team di sviluppo/test, la loro seniority e la difficoltà di progetto ed i rischi.

Analisi funzionale

L’analisi funzionale ha lo scopo di definire, con un linguaggio non tecnico, cosa dovrà fare l’applicazione. Il documento di analisi funzionale è organizzato mediante la definizione di funzionalità che vengono descritte tramite il concetto di caso d’uso. Un caso d’uso va ad identificare una specifica funzione concreta, per la quale è previsto un attore (un utente che ha un ruolo preciso nel sistema informativo collegato al software), delle azioni che esso svolge, degli eventi che si aspetta, l’elaborazione di dati e la loro presentazione all’utente. L’obiettivo è quello di fornire un approccio rigoroso e non ambiguo, rispetto a tutti gli altri stakeholder.

Una metodologia innovativa di analisi funzionale è quella che lega il caso d’uso al concetto di Personas, ovvero un archetipo di utente-tipo in modo da raccontare l’utilizzo dell’applicazione dal punto di vista dell’esperienza dell’utente. Ad esempio nel descrivere un registro elettronico le possibili Personas potrebbero essere:

• prof. Maria Bianchi, docente di filosofia di 60 anni, poco esperta nell’uso del pc;
• prof. Bruno Rossi, docente di matematica di 30 anni, “smanettone” che usa il tablet;
• studente Filippo Verdi, studente di chimica di 16 anni, ha solo uno smartphone e sa usare solo i social.

Nella descrizione dei casi d’uso come si vede le Personas hanno un nome e cognome, un profilo di competenze, una età, ed anche una attitudine verso l’esperienza digitale. Questo aiuta a descrivere meglio il funzionamento del software, tenendo conto in primo luogo del fatto che questo non sarà usato da un generico utente, ma da persone con mentalità, esperienza e cultura differenti.

E’ importante quindi capire che definire cosa fa il software non è semplicemente un elenco astratto di specifiche, ma cerca di rappresentarle in un contesto reale con persone verosimili.

La specifica funzionale viene quindi sottoposta a revisione da parte del committente, e va a definire quindi effettivamente cosa sarà poi sviluppato.

L’architettura dell’informazione

La progettazione, una volta pronte le specifiche, prevede una fase successiva, detta analisi tecnica, che prevede di norma 3 attività principali:

• la definizione del modello dati
• la definizione dell’interfaccia utente
• il progetto tecnico vera e proprio.

Il punto di partenza è dato dall’architettura dell’informazione.

L’architettura dell’informazione è un modello che cerca di rappresentare sia le risorse di conoscenza e di informazione sia il modo in cui queste comunicano tra loro, tramite azioni dell’utente, elaborazioni, memorizzazione dei dati, flussi verso altri sistemi (ad esempio su Internet).

Ad esempio se vogliamo sviluppare un sito di eCommerce, l’architettura dell’informazione dovrà comprendere la struttura dei prodotti, le categorie, i prezzi, oltre a tutti i flussi permettono di gestire ordini, magazzino, utenti e acquisti. Se si vuole creare un registro elettronico, questa sarà costituita dalle classi, dagli studenti, dai docenti, dalle materie, dal registro presenze e da quello dei voti.

Qui un esempio di architettura di informazione che definisce le entità principali di conoscenza del progetto di un albergo che gestisce prenotazioni. Per ciascun blocco sono poi previsti dati e flussi di azioni per gestirli.

L’architettura dell’informazione è il punto di partenza nel definire la struttura dei dati, il modo in cui questi interagiscono con l’utente, e il design del software in termini di componenti e flussi. Essi sono quindi rispettivamente lo schema di database, l’interfaccia utente e la specifica software.

Il primo è la definizione della struttura dei dati, che può essere realizzata con schemi Entità Relazione, modelli gerarchici, grafi o altre strutture dati. Essa andrà a costituire il database dell’applicazione, ma anche i formati dati utilizzati per lo scambio di informazione (JSON, XML, ecc.).

Il secondo è l’interfaccia utente, che organizza il modo in cui l’utente interagisce con l’informazione. Per questo tipo di attività è utile una descrizione visuale tramite Wireframe e storyboard, ovviamente per quelle sole applicazioni che prevedono un frontend. In alternativa per le applicazioni di backend (ad esempio web service) è comunque necessario definire l’interfaccia di programmazione che offrono verso gli utenti dell’applicazione (API).

Il terzo è la vera e propria specifica tecnica , che va a definire il modo in cui sarà realizzato il software. Nella realizzazione della specifica il software architect disegna una soluzione che prevede:

• una specifica architettura del software,
• le tecnologie da utilizzare (linguaggi, database e frameworks);
• l’infrastruttura hardware-software che consisterà nell’ambiente di esecuzione, le reti dati, ecc.

Affronteremo questo tema in dettaglio in una lezione successiva.

Requisiti non funzionali

Il progettista deve inoltre soddisfare, per garantire degli standard di qualità in grado di dare valore al prodotto software, oltre alle specifiche funzionali, anche un insieme di altri requisiti detti “non funzionali” ma ugualmente importanti. I principali sono:

– la scalabilità: il prodotto deve poter gestire quantità e qualità di dati differenti continuando a funzionare. Ad esempio se si tratta di una applicazione che deve gestire flussi di traffico (utenti) che variano nel tempo deve essere in grado di modificare le proprie prestazioni se vengono modificate le risorse hardware/software messe a disposizione;

– la sicurezza: deve evitare sia perdite di dati per malfunzionamenti sia accessi non autorizzati (security), sia evitare rischi per la salute o per incidenti (safety);

– l‘estensibilità: deve essere possibile aggiungere funzionalità col minor costo possibile e senza ridisegnare tutto il progetto;

– la manutenibilità: deve essere facile sistemare eventuali bug senza ridisegnare il progetto. Possono essere anche previsti adeguamenti tecnici (ad esempio il rispetto di normative, aggiornamenti dei sistemi operativi, compatibilità con nuovi hardware, ecc.) che devono essere realizzabili con il minor sforzo possibile.