Questa prima fase (analisi e specifica dei requisiti) cerca di capire quali siano i requisiti del cliente e i vincoli progettuali che potremmo avere. Questo viene effettuato attraverso un requirement engineering process:
Non mi devo limitare a chiedere che cosa vuole il cliente, ma devo dirgli come ho interpretato le cose che mi ha detto e poi avere il feedback finale del cliente per la validazione (devo essere sicuro che alla fine di tutto sia stato correttamente soddisfatto). C’è una grande produzione di artifacts per ciascuna di queste fasi. Tendenzialmente sono dei documenti che servono da input alla attività o fase successiva per riuscire ad andare avanti all’interno del progetto. E’ tutto molto a blocchi e a fasi. Se lavoro bene qua evito errori grossi a monte. Solitamente si fanno errori di progettazione a monte che vanno a compromettere tutta quanta la realizzazione del progetto.
La fase di progetto definisce quali sono i componenti e come si relazionano tra di loro, praticamente l’architettura e la struttura del nostro sistema software. In inglese sarebbe design, ma in italiano è chiamata a volte disegno, ma la cosa migliore sarebbe progetto. Project sarebbe lo specifico progetto, mentre design sarebbe la fase di progettazione. Una volta definita la nostra architettura e come si relazionano tra di loro le varie componenti/funzionalità possiamo tradurre il tutto in codice eseguibile con la fase di implementazione.
In teoria le due fasi dovrebbe essere abbastanza separate per fare un progetto che non sia troppo legato al linguaggio di programmazione al fine di poter scegliere il linguaggio solamente in fase di implementazione. Questo è molto comodo in termini di modularità così che se un domani cambiamo alcune cose non dobbiamo andare ad impazzire a cambiare tutto quanto il progetto. Non è tutto quanto astraibile in maniera disassociata dal linguaggio di programmazione, perché ci sono dei requisiti che magari vengono implementati forte del fatto che un linguaggio abbia determinate caratteristiche. I documenti prodotti in questa fase possono essere usati in fase di implementazione e dati in parto agli sviluppatori. Spesso la parte di Design e quella di Implementation si combinano fra di loro. E’ molto normale perché spesso mentre pensiamo al design siamo già rivolti verso l’implementazione.
Ho diversi strumenti per andare a specificare le parti del nostro progetto:
Devo andare a trasformare la parte di design in un programma effettivo e poi devo andare a testare il mio programma e cercare di progettare la riparazione dell’errore. Capire se ho problemi di codice oppure problemi che sono progettuali e mi vengono dai requisiti. Una volta aggiustato l’errore mi devo ricordare di andare testare ancora il programma. Bisogna stare attenti ai requisiti perché questi potrebbero darti problemi progettuali il più delle volte; se progetto male un requisito ho un problema intrinseco che faccio molta più fatica a risolvere e notare. Molto importante la questione della verifica e della validazione, perché devo stare attento che il sistema faccia quello per cui è stato pensato, ricordandosi di fare vedere anche il software al cliente.
La fase di test mostra la presenza di errori, non l’assenza. Anche fare molti test non garantisce che non ci siano errori. Faremo test ovviamente su casi più comuni e funzionalità più usate, ma potrà sempre sfuggirci qualcosa. Alcune statistiche ci dicono comunque che errori ci sono sempre, ma col test cerchiamo di ridurre questo soprattutto i casi d’uso più grandi. Abbiamo due tipologie di test: