Ecco spiegate le tre fasi principali dello sviluppo di una base di dati, per rendere più semplici gli studi ai prossimi programmatori web o semplicemente fare una chiarezza in più a chi, per passione, vuole migliorare la forma del proprio sviluppo web / applicazioni.

Progettazione Concettuale

È il livello più alto della progettazione di un database, quello più vicino all’essere umano e più lontano dal computer. Durante la fase della progettazione concettuale della base di dati, il progettista ha il compito di estrapolare nei dettagli, con parole e linguaggi chiari e comuni, comprensibili a tutti, tutti i dati dell’applicativo da sviluppare. Deve quindi essere realizzata con strumenti indipendenti dall’ambiente e dal sistema di dati che si andrà ad utilizzare durante lo sviluppo.

Il metodo più semplice per riuscire in questa fase consiste nello scrivere una descrizione breve ed essenziale del problema come se doveste fare un compito di italiano e successivamente evidenziare tutti i sostantivi e le forme verbali presenti nel testo creato (senza produrre duplicati): i sostantivi saranno nella base di dati gli oggetti, mentre i verbi rappresenteranno le relazioni.

Il prodotto dell’analisi è uno schema concettuale, schema che mette in relazione entità (gli oggetti) con le relazioni: è il diagramma E/R (Entità Relazioni) o DEA (Diagramma Entità Relazione).

Progettazione Logica

Durante la fase della progettazione logica si traduce lo schema concettuale prodotto nella fase di progettazione concettuale, nel modello di rappresentazione dei dati adottato dall’ambiente database scelto per la programmazione.

La traduzione, per essere formalmente corretta con i software in uso (per utilizzare così il minor numero di spazio e aumentare le velocità di recupero dei dati), porta ad utilizzare la tecnica della normalizzazione che si divide in tre (3) ulteriori livelli: 1ª, 2ª e 3ª forma normale.

Il prodotto di questa fase è chiamato schema logico.

Progettazione Fisica

La terza ed ultima fase di progettazione di una base di dati è quella fisica, progettazione che, forse, solo i sistemisti e i DBA (DataBase Administrator, Amministratori delle Basi di dati) conoscono: dico forse perchè, con l’avvento delle tante piattaforme di sviluppo database, conoscere nei dettagli i parametri fisici di memorizzazione dei dati (impacchettamento dei records, clusterizzazione, indicizzazione, …) è veramente cosa per pochi.

Ogni forma di memorizzazione dipende soprattutto dall’ambiente che si è scelto di utilizzare e i software di gestione dei database si preoccupano di convertire lo schema logico prodotto nella fase di progettazione logica in puntamenti a vettori e “riserva” dello spazio su disco.

Aspetti metodologici (metodologia)

La metodologia di progettazione di una base di dati può vedersi quindi come un insieme di attività tra di loro collegate, atte a produrre un insieme di prodotti intermedi e finali utilizzando criteri di verifica (normalizzazione) di qualità delle fasi e dei risultati ottenuti, volti a realizzare un database corretto e funzionale a partire da un insieme di specifiche legate al progetto di partenza.

Darò una spiegazione generale di ogni modello, elencandone, se possibile, pregi e difetti, per porre tutti coloro che hanno poco chiaro l’argomento in grado di comprendere meglio l’evoluzione di questi modelli.

Modello a cascata (o document based)

Questo modello, nato negli anni 50, diventa famoso solamente intorno agli anni 70, anni in cui un numero sempre crescente di persone si pone di fronte ad un computer per produrre software. Prevede anche due varianti (retroazione singola e a fontana).

Prende nome dal flusso preciso delle fasi che lo compongono, partendo dalla raccolta dei requisiti e cadendo (come l’acqua dalla montagna) attraverso tutte le altre fasi, fino ad arrivare al cliente. Una volta che il progetto è consegnato al cliente, questo modello non prevede nemmeno la fase di manutenzione.
È anche chiamato “document based” perchè presuppone una fortissima rigidità nella compilazione di documenti di specifiche: i reparti che si occupano di gestire le fasi non comunicano tra loro e la documentazione deve essere per questo motivo il più chiara possibile.

Pregi: si possono fissare nei dettagli le scadenze delle singole fasi.

Difetti: rigidità (impossibile fare modifiche), congelamento dei sotto prodotti, stima dei costi solo iniziale, monoliticità. Anche per il cliente che cambia idea in un secondo momento non c’è possibilità di modifica.

Variante: retroazione singola

La variante a retroazione singola prevede che ogni fase può intervenire al livello precedente per effettuarne modifiche e/o correzioni. Diventa però un modello troppo libero e non mi permette di seguire un percorso chiaro e preciso.

Variante: modello a fontana

Questo modello prevede l’aggiunta delle fasi di manutenzione e evoluzione: come in una fontana l’acqua viene spinta verso l’alto per poi ricadere nella vasca, questo modello prevede il passaggio attraverso tutte le fasi della produzione e, giunto alla fase di manutenzione (o alla fase di evoluzione), ritorna all’inizio. Per ogni modifica che si vorrà effettuare al progetto si riaffronteranno così tutte le fasi, una per una.

Modello a V (o dente di pescecane)

Modello particolare che prevede che, ad ogni passo avanti effettuato lungo la sequenza delle fasi, vengano effettuati due differenti test. Il primo è il test di verifica rispetto alla fase precedente, il confronto con le specifiche fornite dal livello superiore, il secondo è il test di validazione che viene effettuato con l’utente.

Ogni volta che mostrerò il sistema all’utente, l’utente avrà un’idea più completa di quello che vuole e potrà fornirmi informazioni di specifica più precise e complete.

Modello Evolutivo e Incrementale

Tra questi due modelli c’è una sostanziale differenza, anche se sono molto simili tra loro.

Nel modello evolutivo, consegnerò il sistema completo all’utente ogni volta che si presenterà una modifica sensibile (che crea un aggiunta di valore) per lo stesso.

Il modello incrementale, invece, prevede un continuo balzare dalla fase di coding (di scrittura del codice dell’applicativo) alla fase di analisi dei requisiti, fino a quando sarò certo di aver creato il programma definitivo: solo a questo punto lo consegnerò all’utente.

Difetti: in entrambi i modelli non posso determinare quanti cicli effettuerò e la pianificazione diventa così difficile da gestire.

Modello Prototipale

Modello discutibile, prevede in sostanza di effettuare il lavoro almeno due volte.
Il primo lavoro sarà il prototipo del sistema e servirà al programmatore, quanto al cliente, per avere un’idea precisa di cosa fare, delle problematiche che si possono incontrare lungo il cammino e avere un feedback completo.
Si potrà così buttare via tutto per affrontare il lavoro in maniera completa.

Pregi: ottimo per le interfacce utente, che verranno mostrate senza alcun codice correlato.

Modello Flipper

Poco da dire: il ciclo di vita è quasi puramente casuale. Il sistema è come una pallina che rimbalza a caso tra le fasi. Non ci sono vincoli temporali e nulla è misurabile.

Meta-modello a spirale (risk based)

Questo meta modello è una sorta di framework attraverso cui posso inquadrare tanti altri modelli. Prevede di analizzare ciclicamente (allontanandomi dal centro e aumentando i costi) tutte le fasi dello sviluppo, permettendomi, per esempio, di terminare ad ogni momento la produzione.

Le fasi di analisi cicliche, ideate da Boehm, sono

• determinazione degli obiettivi, delle alternative e dei vincoli
• valutazione di eventuali alternative e identificazione dei rischi
• fase di sviluppo e di verifica
• pianificazione nei dettagli della fase successiva

Sempre Boehm, in seguito, creò a questo la variante Win Win, attraverso la quale si ottimizzano le specifiche tramite una contrattazione tra programmatore e utente: entrambi avranno l’illusione finale di aver vinto (win) circa le proprie idee.

Modello COTS (component of the shelf)

Perchè sono obbligato a ripartire sempre dal principio e riscrivere sempre le stesse cose partendo da zero? Ecco che, finalmente, il riutilizzo del codice diventa importante. Nascono le librerie, che raccolgono le funzioni base più utilizzate.

Una volta che avrò raccolto le specifiche del sistema, dovrò guardarmi in giro per cercare qualcosa di già pronto e il più simile a quanto mi è necessario: potrò anche andare a variare le specifiche, semplificandole, per adattarmi a quanto trovato.

Difetti: se così possono essere definiti le difficoltà di archiviazione dei moduli e la capacità di ricerca degli stessi.

Modello Agile Programming

Il modello Agile Programming (che comprende anche il modello dell’eXtreme Programming) è un modello che prevede un continuo contatto con il cliente/utente, in modo da facilitare la richiesta di requisiti e la soluzione ad alcuni dubbi o problemi sollevati dallo sviluppo. Non esiste una vera documentazione scritta come nella maggior parte dei modelli analizzati: il codice è scritto secondo convenzioni e standard tali da permetterne in maniera molto rapida (agile) l’analisi.

Introduce quattro variabili: portata (il numero di funzionalità del sistema), tempistiche (deadline – scadenze), qualità (quanto deve essere buono e bello il prodotto finale) e costo. Attraverso il dialogo, si porta l’utente/cliente a scegliere 3 di queste quattro variabili in modo da permettere di calcolare l’ultima anche se un cliente vorrà sempre tutto, in poco tempo, con la massima qualità e un costo pari a zero!!!

Il cliente ha il diritto di cambiare idea quando e come vuole, facendomi buttare quanto già fatto se di poca utilità o evitandomi del lavoro inutile. Grazie all’uso delle priorità, però, i lavori iniziali saranno sicuramente quelli più sicuri e assodati, che delineeranno il prodotto finale e permetteranno al cliente di aggiungere/modificare/eliminare tutte quelle funzionalità con bassa priorità.

Il tentativo di questi modelli è quello di ridurre al minimo i fallimenti, rilasciano piccoli “aggiornamenti” sensibili in finestre temporali di piccole dimensioni (qualche settimana circa), diminuire i costi di produzione e godere della piena soddisfazione del cliente.

L’ingegneria del software, a differenza di tutte le altre differenti branche dell’ingegneria, soffre di un grosso male, ma gode nello stesso tempo di alcuni benefici. Se il cliente potrà, in ogni momento dello sviluppo, modificare le proprie richieste (spesso stravolgendole), è anche vero che l’ingegneria del software è l’unica che permette di “uscire” con un prodotto non completo o non completamente funzionale: nessuno di voi comprerà mai un auto di cui non si assicura il funzionamento, come non si assicura il funzionamento completo di un prodotto software che, anche ora, state utilizzando sul vostro PC.

Anche se veramente poco utilizzate nella normale programmazione all’interno di team o poco numerosi o inesperti, le fasi studiate dall’ingegneria del software potrebbero migliorare notevolmente lo sviluppo di ogni applicativo o sistema web based. Si parla più comunemente di ciclo di vita del software.

Analisi dei requisiti

Di fronte alla richiesta di un cliente, è sempre opportuno verificare nei dettagli cosa l’utente vuole dall’applicativo, quali risultati vorrebbe ottenere dall’utilizzo dello stesso e quali caratteristiche e qualità si aspetta di trovare una volta che l’applicativo sarà completato. Per poter generare una lista di requisiti completa, è importante consultare anche gli stakeholders, gli utenti finali del sistema.

Al termine dell’analisi dei requisiti, i consigli dati dall’ingegneria del software sono quelli di produrre in output un documento di specifiche, un manuale utente di base (si, un manuale utente ancor prima di aver creato l’applicativo) e un piano di test di sistema sulle specifiche raccolte. Raccogliendo tutte le informazioni in documenti, eviterete di perdere dettagli importanti durante lo svolgimento delle fasi successive.

Progettazione (design)

Se la fase di Analisi dei requisiti potrebbe rispondere alla domanda “cosa deve/devo fare?“, la fase di design dell’applicativo si può specchiare nel quesito “come posso fare?“, come l’applicativo o progetto dovrà soddisfare tutti i requisiti raccolti.

Durante la fase di progettazione si delineano solamente gli aspetti di alto livello, generali e piuttosto astratti della programmazione: la fase si sviluppo (coding – trasformazione in codice) sarà successiva e inizierà al completamento della fase di progettazione.

Coding (sviluppo)

La fase di coding è, come accennato in precedenza, quella in cui si cominciano a scrivere le righe di codice che daranno vita all’applicativo. La fase di codifica del progetto si può spesso visualizzare, soprattutto quando il progetto ha una certa complessità e il team di sviluppo si divide i compiti, come unione di due sottofasi:

• fase di creazione di moduli base
• fase di integrazione dei moduli creati

La fase di creazione di moduli distinti permette di avere una migliore verificabilità delle singole porzioni di codice ottenendo così un applicativo più corretto e funzionale.
Nella fase di integrazione, invece, i blocchi (detti stub) che sono stati creati utilizzando richieste o generando output fittizi, devono essere uniti l’un l’altro per dar vita al progetto completo.

Test (o collaudo)

È in questa fase che vengono eseguiti i test di conformità del progetto e la verifica del rispetto delle specifiche iniziali. Il documento prodotto già durante la raccolta dei requisiti si rivela così molto utile per permettere allo sviluppatore di controllare nei dettagli che sia correttamente possibile fare quanto richiesto inizialmente dal cliente.

Anche la fase di test si può scomporre in due diverse sottofasi:

• test di sistema (o test funzionali)
• test di accettazione

I test di sistema sono i test generali, ovvero tutti quei test che possono confermare la correttezza del sistema software creato.

I test di accettazione, invece, sono tutti quei test che vengono fatti per verificare che tutto sia conforme alle specifiche fornite dal cliente.
Ma spesso il cliente non è un singolo individuo, ma il progetto è fonte di un’idea della software-house stessa. In questo la fase di accettazione vedrà due distinte sottofasi di test: Alfa Test e Beta Test.

Gli Alfa Test vengono effettuati solitamente all’interno dell’azienda produttrice e vengono fatti utilizzare da persone che rispecchiano l’utente finale del sistema; la versione beta di un’applicativo, viene invece rilasciata ad un gruppo più esteso di utenti,  solitamente in versione gratuita, ma con l’obbligo di riportare alla casa produttrice l’elenco degli errori trovati durante il normale utilizzo.

Manutenzione

L’ultima fase di cui l’ingegneria del software si occupa è la fase di manutenzione. Questo momento del ciclo di vita di un prodotto è solitamente il momento più lungo. Durante questa fase vengono rilasciati tutti gli aggiornamenti per migliorare la stabilità del sistema, correggendone errori o adattandolo per permettere il supporto di nuove piattaforme operative, così come possono essere aggiunte funzionalità non previste nella prima versione di uscita.

La lunga durata di questa fase incide sui costi totali del progetto per quasi il 60%: ogni modifica, aggiunta o miglioramento prevede che venga rieseguita l’intera fase di testing.