Ecco un elenco dei modelli di sviluppo produttivo più usati e che andremo a vedere. Nel tempo si è visto che possa andare a mescolare un pochino questo ingredienti e lo andremo a vedere attraverso diversi modelli, soprattutto quelli usati in passato:

• Waterfall (tutto in cascata)
• Component-Based (bottom-up)
• Evolutionary (iterativo, fasi si ripetono ciclicamente più volte e sono interessanti perché alla base di agile)
• Incremental (iterativo, fasi si ripetono ciclicamente più volte e sono interessanti perché alla base di agile)
• Transformational (trasformazioni formali per poi arrivare al prodotto)

Nella realtà i modelli più usati sono quelli iterativi (evolutivo ed incrementale) e poi quello waterfall.

Code and Fix

Partiamo in realtà da un non modello: code and fix. In questo ci sono solamente due fasi: scrivi il codice e lo fixi (aggiusti). Purtroppo ancora molto diffuso anche se non è un vero modello. Sembra che all’inizio si risparmi, ma alla fine spendi tutto quanto nel fix che il tempo risparmiato nell’evitare analisi e progetto. Praticamente tu inizi a scrivere subito direttamente il codice, ma saltando tutta la parte di progettazione risulta innanzitutto difficile riuscire ad ottenere una forma che sia ottimale del progetto e anche in termini di manutenzione diventa sicuramente più complesso andare a fare fix. Manca una visione di insieme e si fanno sicuramente le cose all’acqua di rose. Anche modifiche piccole rischiano di impegnare davvero moltissimo lavoro. Potrebbe funzionare davvero per modelli minuscoli, altrimenti no. Questo modello è molto diverso dalla metodologia agile anche se sembra simile, ma questo ha molta progettazione e scheduling (che il code and fix non ha).

Waterfall

Nel metodo waterfall facciamo una specifica totale di tutti i requisiti e passiamo il tutto a chi progetta software, infinte implementiamo. Ecco le fasi:

1. Requirementes Analysis and Specification

2. System and Software Design

3. Implementation and Unit Testing

4. Integration and System Testing (testing large)

5. Deployment and Maintenance

   

Si chiama a cascata perché ogni processo praticamente cade sulla fase successiva, tutto quanto in maniera sequenziale e per step. Non abbiamo ritorni indietro se qualcosa non funziona. Io vado comunque avanti e solamente alla fine, in fase di maintenance torno a rifare alcune parti. Non ho loop all’interno del processo. Si arriva in fondo e torna indietro solamente alla fine. Soprattutto dagli svantaggi capiamo la nascita delle metodologie agili.

Potrei andare a fare un leggero fix con il metodo waterfall model with feedback, ma sicuramente non è comodissimo andare indietro totalmente.

Component Base