• modelli-processo-prescrittivo

    Modelli di sviluppo a processo prescrittivo

    In questo articolo faremo una panoramica dei modelli di sviluppo a processo prescrittivo nell’ambito dell’ingegneria del software.

    I modelli di processo

    In un precedente articolo dal titolo Il processo di sviluppo del software abbiamo introdotto il processo di sviluppo del software, che consiste di un insieme organizzato di attività finalizzate alla creazione del prodotto da parte del team di sviluppo, utilizzando metodi, tecniche, metodologie e strumenti. Il processo di sviluppo del software è suddiviso in varie fasi secondo uno schema di riferimento (il ciclo di vita del software) e viene descritto da un modello informale, semi-formale o formale.

    I modelli di processo sono uno strumento molto utile per cercare di dare stabilità, controllo, organizzazione ed efficienza alle varie fasi dello sviluppo di un applicativo. La natura mutevole di un software (soggetto a continue modifiche, test e aggiornamenti) e le nuove richieste da parte del cliente, rendono caotica l’attività di sviluppo e imprevedibili le fasi di progettazione e sviluppo. L’esperienza del team di sviluppo e del project manager, insieme all’adozione di modelli specifici, possono consentire la conclusione di un progetto con successo nei tempi previsti.

     

    I modelli di processo prescrittivi

    I modelli di processo prescrittivi prescrivono un insieme di elementi del processo (attività, azioni, compiti, risultati e prodotti) e un flusso di lavoro, e vengono descritti in modo rigido e schematico.

    Il flusso di processi può essere

    • lineare (modello a cascata)
    • incrementale (modello incrementale e modello RAD)
    • evolutivo (modello a prototipi, modello a spirale e modello di sviluppo concorrente)

     

    Il modello a cascata

    Il modello a cascata (waterfall), chiamato anche ciclo di vita classico o modello sequenziale lineare, è il più vecchio (è stato definito nel 1970 da Winston Royce) e il più diffuso tra i paradigmi dell’ingegneria del software. Propone un approccio sistematico e sequenziale allo sviluppo del software. Le fasi previste dal modello a cascata sono:

    • comunicazione: è la fase di avvio del progetto, e prevede la raccolta dei requisiti del cliente;
    • pianificazione: vengono stimati i costi economici e temporali del progetto, viene stilato un piano di azione il più dettagliato possibile, vengono stabilite le modalità per effettuare dei controlli sull’andamento del progetto;
    • modellazione: si analizzano i requisiti e si inizia la progettazione di quello che sarà il software, spesso servendosi di diagrammi UML;
    • costruzione: la fase di programmazione vera e propria, seguita dal collaudo del prodotto;
    • deployment: la consegna del prodotto finito al cliente, l’inizio della fase di supporto eventualmente prevista dal contratto e l’invio di feedback.

    Il modello a cascata è molto semplice, e spesso viene adottato da team poco esperti che necessitano di un punto di partenza per iniziare a pianificare e organizzare il proprio flusso di lavoro. Tuttavia nella moderna ingegneria del software viene considerato come un modello superato e non applicabile ai problemi che presentano i progetti odierni. Infatti il modello si fonda sul presupposto che introdurre cambiamenti sostanziali nel software in fasi avanzate dello sviluppo ha costi troppo elevati: ogni fase deve essere svolta in maniera esaustiva prima di passare alla successiva, in modo da non generare retroazioni. Le problematiche che si incontrano sono le seguenti:

    • Il modello può bloccare completamente una fase se non viene terminata quella precedente: un ritardo in una qualsiasi delle fasi tende quindi ad assumere dimensioni critiche per la buona riuscita del progetto.
    • Un progetto reale raramente è conforme allo schema sequenziale del modello, e ogni modifica è causa di confusione man mano che il progetto avanza.
    • Il modello a cascata prevede che i requisiti siano tutti noti ad inizio delle attività, mentre difficilmente un cliente riuscirà a fornire in modo esaustivo e preciso tutti i requisiti necessari in un breve lasso di tempo, senza poi cambiare idea o senza desiderare modifiche a progetto in corso.
    • Il cliente vedrà una versione del prodotto solo verso la fine del progetto

    Quando il lavoro di sviluppo del software richiede tempi rapidi ed è soggetto a numerose modifiche, il modello a cascata si rivela inappropriato.

    modello-cascata

     

    Il modello a processo incrementale

    Il modello di processo incrementale combina alcuni aspetti del modello a cascata applicati iterativamente. Prevede l’applicazione, scalata nel tempo, di più sequenze complete del modello a cascata. Il modello è stato concepito con l’idea che la prima iterazione porti come risultato la definizione di un prodotto base, una sorta di scheletro che soddisfi solamente i requisiti fondamentali del committente. Questo aiuta il cliente ad enunciare subito le funzionalità principali del software, per poi aggiungere dettagli in seguito (piuttosto che definire subito tutte le caratteristiche del prodotto finito). In quest’ottica, le iterazioni successive servono a raccogliere requisiti sempre più dettagliati e a raffinare maggiormente le funzionalità del prodotto.

    modello-incrementale

    La prima iterazione viene testata dal cliente e si stende un piano per lo stadio successivo, che dovrà occuparsi di:

    • modificare lo stadio rilasciato per soddisfare meglio le esigenze del cliente;
    • aggiungere nuove funzionalità.

    Il processo si ripete iterativamente fino a giungere al prodotto finale.

    sviluppo-modello-incrementale

     

    Il modello RAD

    Il modello RAD (Rapid Application Development, sviluppo rapido di applicazioni) fa parte della categoria dei processi incrementali, ed è un adattamento ad “alta velocità” del modello a cascata. Con dei requisiti chiari, il processo RAD consente tempi di sviluppo molto brevi (indicativamente 60-90 giorni).

    Le fasi di sviluppo previste sono le stesse del modello incrementale, e quindi, quelle del modello a cascata. Rispetto a questi due modelli, quello che cambia è come queste attività sono organizzate nel tempo, e soprattutto come vengono distribuite tra le persone che fanno parte del progetto. Le fasi di comunicazione e pianificazione avvengono come negli altri processi, mentre le differenze sono evidenti con la modellazione e la costruzione. Nella fase di pianificazione vengono identificati i moduli che compongono l’applicazione (quindi l’applicazione deve essere modularizzabile), e il loro sviluppo viene affidato a team indipendenti, che dovranno poi gestire al loro interno la modellazione e la costruzione. Solo la fase di deployment torna ad essere comune, ed è il momento in cui vengono integrati nell’applicativo finale i moduli preparati dai diversi team. Tutto questo comporta una maggiore rapidità di sviluppo, ma per una buona riuscita del prodotto è necessario che gli sviluppatori si muovano su un terreno a loro ben conosciuto e sperimentato, in modo da ridurre i rischi di compatibilità tra i vari moduli e minimizzare gli imprevisti che possono portar via tempo.

    modello-rad

     

    Il modello evolutivo a prototipi

    Il modello evolutivo è un’altro tipo di processo iterativo: propone un ciclo di sviluppo in cui un prototipo iniziale evolve gradualmente verso il prodotto finito attraverso un certo numero di iterazioni dello schema analisi-progettazione-implementazione-validazione. Il vantaggio fondamentale è che ad ogni iterazione è possibile confrontarsi con gli utenti per quanto riguarda le specifiche e le funzionalità (raffinamento dell’analisi) e per rivedere le scelte di progetto (raffinamento del design).

    Nella sua applicazione a prototipi, prevede i cinque passi riconducibili a quelli generali già visti (comunicazione, pianificazione, modellazione, costruzione, deployment), con la peculiarità però di renderli molto rapidi e finalizzati alla creazione di un prototipo funzionante (che non è una versione di base). La sua funzione è quella di poter essere valutato dal cliente in modo da ricavare un feedback necessario per aggiornare i requisiti del prodotto vero che si vuole sviluppare, qualora la stesura di quest’ultimi risulti per vari motivi molto complessa o articolata.

    Il prototipo può essere di due tipi:

    • Throw-away prototype (“usa e getta”): orientato a determinare i requisiti di aspetti meno chiari del software da sviluppare;
    • Evolutionary prototype: orientato a realizzare i requisiti più chiari e stabili.

     

    modello-prototipo

     

    Il modello evolutivo a spirale

    Il modello a spirale è un modello astratto che abbina gli elementi iterativi della prototipazione e gli aspetti formali e organizzativi del modello a cascata, consentendo un rapido sviluppo di versioni via via più complete del software. Il lato iterativo permette di far crescere continuamente il prodotto, mentre il lato prescrittivo aiuta nello stabilire milestone volte a coinvolgere il cliente in più punti prefissati nel corso del progetto.

    Un modello a spirale viene suddiviso in un insieme di attività strutturali decise dal team di sviluppo. Ogni attività rappresenta un segmento del percorso a spirale. Le prime attività consentono di creare prototipi da sottoporre al committente; quelle successive possono permettere di avviare uno sviluppo pianificato in varie milestone intermedie (in cui il cliente può verificare funzionalità e soddisfazione dei requisiti senza dover aspettare una release finale). Le ultime attività infine possono essere eseguite allo scopo di perfezionare un prodotto già finito e consegnato.

     

    modello-spirale

     

    In un articolo successivo vedremo le metodologie di sviluppo Agile, un modello secondo cui la documentazione è inutile e tende a snellire la programmazione.

     

    Giulio Cantali – IT Consultant

    Creatore di Database Master, il primo percorso per diventare esperti di database

Lascia un commento

Se vuoi condividere la tua opinione, lascia un commento

Puoi usare questi tag e attributi: HTML:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">