Distribuzione delle attività

Lo sforzo complessivo e la percentuale di ogni attività rispetto al lavoro globale dipendono principalmente da due fattori: dimensione del progetto e strumenti a disposizione.

Al crescere del problema affrontato perde sempre più peso l’attività di programmazione, a vantaggio di documentazione e coordinamento.

Questo fatto è anche abbastanza naturale. Se il problema è piccolo, magari così piccolo da essere portato avanti da una sola persona che copre i ruoli di analista, programmatore e gestore di progetto, il coordinamento è sicuramente ridotto all’osso, perché una persona dovrebbe essere in grado di coordinarsi da sola, la documentazione è ridotta, perché non occorre più produrre tutta quella relativa al coordinamento tra i vari attori.

Quando le dimensioni del progetto aumentano, il team di produzione deve assolutamente diventare più consistente, non è più possibile fare tutto da soli, ma devono esserci uno o più analisti, uno o più programmatori e un gestore del progetto. A questo punto nascono le esigenze di coordinamento tra le varie parti, e di documentazione di ogni lavoro svolto in modo che ogni elemento del team possa capire il prodotto degli altri.

La parte di lavoro svolta al computer diventa percentualmente sempre meno, il lavoro più gravoso si sposta dalla codifica alla documentazione e al coordinamento.

Finora abbiamo evidenziato le percentuali di ogni attività sullo sforzo totale al variare della dimensione del progetto. Consideriamo ora lo sforzo necessario a portare al termine l’applicazione.

Il fattore che più influenza lo sforzo di sviluppo è l’insieme dei tool che si utilizzano. Sfruttando strumenti CASE, l’enfasi viene spostata dalle fasi di codifica, che diventano automatiche, a quelle di analisi e progettazione, con una sensibile diminuzione dello sforzo totale.

Non tutti i tool CASE hanno lo stesso effetto sulla distribuzione dello sforzo: gli strumenti di sola analisi spostano tutto verso questa fase, semplificando le fasi seguenti, gli strumenti integrati portano ad una diminuzione distribuita su tutto il ciclo di vita.

Con metodi tradizionali, il peso maggiore è nelle fasi più a valle. La fase di analisi tende ad essere affrettata, per spostare le verifiche alla codifica e manutenzione: in un certo senso si attua inconsciamente un ciclo di vita a prototipo o ciclico, obbligati dalla mancanza di un formalismo di analisi. Questo porta poi ad un grosso lavoro di implementazione e manutenzione, non tanto per errori introdotti in queste fasi, ma per sopperire alla mancanza di una buona specifica iniziale.

Con strumenti CASE di sola analisi si tende invece a concentrare tutto il lavoro nella definizione degli obiettivi, per ottenere poi una codifica più meccanica possibile. Le fasi a valle risultano estremamente guidate, e quindi semplificate, nell’ipotesi che il buon formalismo iniziale sia riuscito a sviscerare tutti i possibili problemi. Purtroppo questo scenario non tiene conto delle crescite del prodotto in risposta a nuove esigenze.

Ogni fase di nuove implementazioni è un ripetere tutto il ciclo, quindi con picchi di lavoro legati ad ogni nuova richiesta di crescita da parte dell’utente.

Gli strumenti I-CASE, CASE integrato che seguono tutto il ciclo di vita, riescono a ridurre le difficoltà di ogni momento, creando un "passaggio automatico" di tutto il lavoro di ogni fase alla successiva.

In questo modo lo sforzo è notevolmente ridotto e equamente distribuito in ogni fase del ciclo di vita.

E’ interessante notare che, riducendo lo sforzo globale, un progetto che con metodi tradizionali sarebbe stato di medie dimensioni diventa ora piccolo, spostando le percentuali per attività.