8.0 Gestione del progetto a cascata e ciclica (parte 1)

UN modello a cascata , il modello a sei fasi è un modello a cascata. In altre parole, le fasi si verificano in sequenza. Proprio come è impossibile nuotare contro una cascata controcorrente, la tecnica della cascata pura preclude il ritorno a una fase dopo che è stata terminata.

Non è l’ideale decidere di modificare il design durante la fase di implementazione, interrompendo così l’implementazione. L’approccio a cascata è spesso meno adatto ai progetti di sviluppo software per una serie di motivi.

  • Lo sviluppo del software è uno sforzo artistico; è praticamente difficile anticipare tutte le esigenze (funzionalità).
  • La stima del tempo necessario per sviluppare una funzionalità è molto impegnativa.
  • Durante tutto il ciclo di vita del progetto, gli utenti dovrebbero essere in grado di testare tutti i risultati intermedi.

Lo sviluppo del software è un’impresa artistica #

Per chi non lo sapesse, lo sviluppo del software sembra riguardare più l’ingegneria che l’invenzione. Tuttavia, si riferisce in diversi modi all’invenzione. Nel processo di creazione, non si sa mai esattamente cosa accadrà.

I progettisti e i programmatori responsabili dello sviluppo di nuovo software devono fornire risposte ai problemi che si presentano. Indipendentemente dalle molte tecniche e prescrizioni per il lavoro, la creazione di codice per computer è ancora per lo più sconosciuta e quindi imprevedibile. I programmatori possono scegliere tra milioni di soluzioni scritte in dozzine di linguaggi di programmazione e operanti su migliaia di diverse combinazioni hardware e piattaforme software. Sebbene questa flessibilità abbia molti vantaggi, rende anche il progetto più impegnativo da gestire rispetto a quello più convenzionale gestione del progetto (come progetti di costruzione o costruzione).

Configurazione dell’implementazione #

L’approccio a cascata richiede che i requisiti siano definiti come conseguenza del fase di definizione del progetto . Idealmente, dovrebbe verificarsi una deviazione aggiuntiva minima da questi criteri per il resto del progetto. L’approccio a cascata dello sviluppo del software richiede un impegno iniziale di uno sforzo significativo nell’analisi delle funzionalità richieste (requisiti). Ciò si traduce in un design funzionale (vedi I per ulteriori informazioni sui design funzionali). L’architetto del software crea un progetto tecnico durante tutto il processo di progettazione, utilizzando il progetto funzionale come riferimento. Inoltre, il progetto tecnico fornisce istruzioni su come eseguire la funzionalità richiesta.

Anche se questo può sembrare un problema semplice, considera il seguente scenario. Nell’ambito di un progetto è in fase di sviluppo un nuovo veicolo. In qualità di automobilista attivo, hai il compito di sviluppare le esigenze automobilistiche. Ti connetti con altri automobilisti e compili un elenco esaustivo:

  • L’auto deve ospitare quattro persone;
  • L’automobile deve avere un volante nella parte anteriore sul lato sinistro del guidatore; • L’automobile deve avere un pedale del freno, un pedale dell’acceleratore e un freno a mano.
  • I fari dell’automobile devono essere bianchi e le luci posteriori devono essere rosse. (ovviamente, la vera lista sarebbe enorme)

Progettazione e modellazione #

I designer creano un nuovo design usando la tua lista come guida, che viene poi costruita molti mesi dopo. Mentre scendi per strada, vedi che un veicolo si è fermato. Ti rendi conto di aver omesso le luci dei freni dalla tua lista! Contatti rapidamente l’ingegnere della casa automobilistica, che quasi scoppia in risposta alla tua chiamata. Dici che si tratta di un piccolo aggiustamento. Tuttavia, è una catastrofe per le case automobilistiche. Le automobili già prodotte devono essere completamente smontate, i cavi dai pedali dei freni alla parte posteriore devono essere estesi, la parte posteriore del veicolo deve essere completamente ridisegnata per adattarsi alle luci dei freni e i portelli del bagagliaio già fabbricati devono essere demoliti e l’elenco potrebbe continuare.

Mentre lo scenario di cui sopra sembra ridicolo, rappresenta un evento quasi quotidiano nello sviluppo del software. I programmatori fanno l’erronea supposizione che i clienti, i clienti o gli utenti del prodotto in fase di creazione capiscano esattamente ciò che vogliono. I clienti credono erroneamente che gli sviluppatori di software possano creare (e modificare) qualsiasi cosa nel minor tempo possibile. Questa è la causa principale di contesa tra consumatori e sviluppatori di software.