SDLC - Guida rapida
Software Development Life Cycle (SDLC) è un processo utilizzato dall'industria del software per progettare, sviluppare e testare software di alta qualità. L'SDLC mira a produrre un software di alta qualità che soddisfi o superi le aspettative dei clienti, raggiunga il completamento entro tempi e stime dei costi.
SDLC è l'acronimo di Software Development Life Cycle.
È anche chiamato come processo di sviluppo software.
SDLC è un framework che definisce le attività eseguite in ogni fase del processo di sviluppo del software.
ISO / IEC 12207 è uno standard internazionale per i processi del ciclo di vita del software. Vuole essere lo standard che definisce tutte le attività richieste per lo sviluppo e la manutenzione del software.
Cos'è SDLC?
SDLC è un processo seguito per un progetto software, all'interno di un'organizzazione software. Consiste in un piano dettagliato che descrive come sviluppare, mantenere, sostituire e alterare o migliorare software specifico. Il ciclo di vita definisce una metodologia per migliorare la qualità del software e il processo di sviluppo complessivo.
La figura seguente è una rappresentazione grafica delle varie fasi di un tipico SDLC.
Un tipico ciclo di vita dello sviluppo del software è costituito dalle seguenti fasi:
Fase 1: pianificazione e analisi dei requisiti
L'analisi dei requisiti è la fase più importante e fondamentale nell'SDLC. Viene eseguita dai membri senior del team con input dal cliente, dal reparto vendite, indagini di mercato ed esperti di dominio nel settore. Queste informazioni vengono quindi utilizzate per pianificare l'approccio di base del progetto e per condurre uno studio di fattibilità del prodotto nelle aree economiche, operative e tecniche.
Anche la pianificazione per i requisiti di garanzia della qualità e l'identificazione dei rischi associati al progetto viene eseguita in fase di pianificazione. Il risultato dello studio di fattibilità tecnica è quello di definire i vari approcci tecnici che possono essere seguiti per implementare con successo il progetto con rischi minimi.
Fase 2: definizione dei requisiti
Una volta eseguita l'analisi dei requisiti, il passaggio successivo consiste nel definire e documentare chiaramente i requisiti del prodotto e farli approvare dal cliente o dagli analisti di mercato. Questo viene fatto tramite un fileSRS (Software Requirement Specification) documento che consiste in tutti i requisiti del prodotto da progettare e sviluppare durante il ciclo di vita del progetto.
Fase 3: progettazione dell'architettura del prodotto
SRS è il riferimento per gli architetti di prodotto che escogitano la migliore architettura per il prodotto da sviluppare. Sulla base dei requisiti specificati in SRS, di solito più di un approccio di progettazione per l'architettura del prodotto viene proposto e documentato in un DDS - Design Document Specification.
Questo DDS viene esaminato da tutte le parti interessate importanti e sulla base di vari parametri come valutazione del rischio, robustezza del prodotto, modularità del design, budget e vincoli di tempo, viene selezionato il miglior approccio di progettazione per il prodotto.
Un approccio progettuale definisce chiaramente tutti i moduli architettonici del prodotto insieme alla sua comunicazione e rappresentazione del flusso di dati con i moduli esterni e di terze parti (se presenti). Il design interno di tutti i moduli dell'architettura proposta dovrebbe essere chiaramente definito con il più piccolo dei dettagli in DDS.
Fase 4: creazione o sviluppo del prodotto
In questa fase di SDLC inizia lo sviluppo vero e proprio e il prodotto viene costruito. Il codice di programmazione viene generato come da DDS durante questa fase. Se la progettazione viene eseguita in modo dettagliato e organizzato, la generazione del codice può essere eseguita senza troppi problemi.
Gli sviluppatori devono seguire le linee guida di codifica definite dalla loro organizzazione e strumenti di programmazione come compilatori, interpreti, debugger, ecc. Vengono utilizzati per generare il codice. Per la codifica vengono utilizzati diversi linguaggi di programmazione di alto livello come C, C ++, Pascal, Java e PHP. Il linguaggio di programmazione viene scelto in relazione al tipo di software sviluppato.
Fase 5: test del prodotto
Questa fase è solitamente un sottoinsieme di tutte le fasi poiché nei moderni modelli SDLC, le attività di test sono per lo più coinvolte in tutte le fasi dell'SDLC. Tuttavia, questa fase si riferisce all'unica fase di test del prodotto in cui i difetti del prodotto vengono segnalati, tracciati, corretti e testati nuovamente, fino a quando il prodotto non raggiunge gli standard di qualità definiti nell'SRS.
Fase 6: distribuzione nel mercato e manutenzione
Una volta che il prodotto è stato testato e pronto per essere distribuito, viene rilasciato formalmente nel mercato appropriato. A volte la distribuzione del prodotto avviene in fasi secondo la strategia aziendale di tale organizzazione. Il prodotto può essere prima rilasciato in un segmento limitato e testato nell'ambiente di lavoro reale (UAT - Test di accettazione dell'utente).
Quindi, in base al feedback, il prodotto può essere rilasciato così com'è o con miglioramenti suggeriti nel segmento di mercato di destinazione. Dopo che il prodotto è stato immesso sul mercato, la sua manutenzione viene eseguita per la base di clienti esistente.
Modelli SDLC
Esistono vari modelli del ciclo di vita dello sviluppo del software definiti e progettati che vengono seguiti durante il processo di sviluppo del software. Questi modelli sono indicati anche come modelli di processo di sviluppo software ". Ogni modello di processo segue una serie di passaggi unici per il suo tipo per garantire il successo nel processo di sviluppo del software.
Di seguito sono riportati i modelli SDLC più importanti e popolari seguiti nel settore:
- Modello a cascata
- Modello iterativo
- Modello a spirale
- V-Model
- Modello Big Bang
Altre metodologie correlate sono Agile Model, RAD Model, Rapid Application Development e Prototyping Models.
Il modello a cascata è stato il primo modello di processo ad essere introdotto. Viene anche chiamatolinear-sequential life cycle model. È molto semplice da capire e da usare. In un modello a cascata, ogni fase deve essere completata prima che possa iniziare la fase successiva e non vi siano sovrapposizioni nelle fasi.
Il modello Waterfall è il primo approccio SDLC utilizzato per lo sviluppo del software.
Il modello a cascata illustra il processo di sviluppo del software in un flusso sequenziale lineare. Ciò significa che qualsiasi fase del processo di sviluppo inizia solo se la fase precedente è stata completata. In questo modello a cascata, le fasi non si sovrappongono.
Modello a cascata - Design
L'approccio a cascata è stato il primo modello SDLC ad essere ampiamente utilizzato nell'ingegneria del software per garantire il successo del progetto. Nell'approccio "The Waterfall", l'intero processo di sviluppo del software è suddiviso in fasi separate. In questo modello a cascata, in genere, il risultato di una fase funge da input per la fase successiva in modo sequenziale.
La figura seguente è una rappresentazione delle diverse fasi del modello a cascata.
Le fasi sequenziali nel modello Waterfall sono:
Requirement Gathering and analysis - Tutti i possibili requisiti del sistema da sviluppare vengono acquisiti in questa fase e documentati in un documento di specifica dei requisiti.
System Design- In questa fase vengono studiate le specifiche dei requisiti della prima fase e viene preparato il progetto del sistema. Questa progettazione del sistema aiuta a specificare i requisiti hardware e di sistema e aiuta a definire l'architettura complessiva del sistema.
Implementation- Con input dalla progettazione del sistema, il sistema viene prima sviluppato in piccoli programmi chiamati unità, che vengono integrati nella fase successiva. Ogni unità viene sviluppata e testata per la sua funzionalità, denominata Unit Testing.
Integration and Testing- Tutte le unità sviluppate nella fase di implementazione vengono integrate in un sistema dopo il test di ciascuna unità. Dopo l'integrazione, l'intero sistema viene testato per eventuali guasti e guasti.
Deployment of system- Una volta eseguito il test funzionale e non funzionale; il prodotto viene distribuito nell'ambiente del cliente o immesso sul mercato.
Maintenance- Ci sono alcuni problemi che sorgono nell'ambiente client. Per risolvere questi problemi, vengono rilasciate patch. Anche per migliorare il prodotto vengono rilasciate alcune versioni migliori. La manutenzione viene eseguita per fornire questi cambiamenti nell'ambiente del cliente.
Tutte queste fasi sono collegate l'una all'altra in cui il progresso è visto come un flusso costante verso il basso (come una cascata) attraverso le fasi. La fase successiva viene avviata solo dopo che la serie di obiettivi definiti per la fase precedente è stata raggiunta e viene siglata, quindi il nome "Waterfall Model". In questo modello, le fasi non si sovrappongono.
Modello a cascata - Applicazione
Ogni software sviluppato è diverso e richiede un approccio SDLC adeguato da seguire in base ai fattori interni ed esterni. Alcune situazioni in cui l'uso del modello Waterfall è più appropriato sono:
I requisiti sono molto ben documentati, chiari e fissi.
La definizione del prodotto è stabile.
La tecnologia è compresa e non è dinamica.
Non ci sono requisiti ambigui.
Sono disponibili ampie risorse con le competenze richieste per supportare il prodotto.
Il progetto è breve.
Modello a cascata - Vantaggi
I vantaggi dello sviluppo a cascata sono che consente la dipartimentalizzazione e il controllo. È possibile impostare un programma con scadenze per ciascuna fase di sviluppo e un prodotto può procedere attraverso le fasi del modello del processo di sviluppo una per una.
Lo sviluppo passa dal concetto, alla progettazione, all'implementazione, al test, all'installazione, alla risoluzione dei problemi e finisce al funzionamento e alla manutenzione. Ogni fase dello sviluppo procede in rigoroso ordine.
Alcuni dei principali vantaggi del modello a cascata sono i seguenti:
Semplice e facile da capire e da usare
Facile da gestire grazie alla rigidità del modello. Ogni fase ha risultati finali specifici e un processo di revisione.
Le fasi vengono elaborate e completate una alla volta.
Funziona bene per progetti più piccoli in cui i requisiti sono molto ben compresi.
Fasi chiaramente definite.
Pietre miliari ben comprese.
Facile da organizzare le attività.
Processo e risultati sono ben documentati.
Modello a cascata - Svantaggi
Lo svantaggio dello sviluppo a cascata è che non consente molta riflessione o revisione. Una volta che un'applicazione è in fase di test, è molto difficile tornare indietro e modificare qualcosa che non era ben documentato o pensato in fase di concept.
I principali svantaggi del modello a cascata sono i seguenti:
Nessun software funzionante viene prodotto fino a tardi durante il ciclo di vita.
Elevati livelli di rischio e incertezza.
Non è un buon modello per progetti complessi e orientati agli oggetti.
Modello scadente per progetti lunghi e in corso.
Non adatto a progetti in cui i requisiti corrono un rischio di cambiamento da moderato ad alto. Quindi, il rischio e l'incertezza sono elevati con questo modello di processo.
È difficile misurare i progressi nelle fasi.
Non è possibile soddisfare i requisiti in evoluzione
La regolazione dell'ambito durante il ciclo di vita può porre fine a un progetto.
L'integrazione avviene alla fine come un "big bang", il che non consente di identificare in anticipo eventuali colli di bottiglia tecnologici o aziendali o sfide.
Nel modello iterativo, il processo iterativo inizia con una semplice implementazione di un piccolo insieme di requisiti software e migliora iterativamente le versioni in evoluzione fino a quando il sistema completo non è implementato e pronto per essere distribuito.
Un modello iterativo del ciclo di vita non tenta di iniziare con una specifica completa dei requisiti. Invece, lo sviluppo inizia specificando e implementando solo una parte del software, che viene quindi rivista per identificare ulteriori requisiti. Questo processo viene quindi ripetuto, producendo una nuova versione del software alla fine di ogni iterazione del modello.
Modello iterativo - Design
Il processo iterativo inizia con una semplice implementazione di un sottoinsieme dei requisiti software e migliora iterativamente le versioni in evoluzione fino all'implementazione dell'intero sistema. Ad ogni iterazione, vengono apportate modifiche al progetto e vengono aggiunte nuove capacità funzionali. L'idea di base alla base di questo metodo è sviluppare un sistema attraverso cicli ripetuti (iterativi) e in porzioni più piccole alla volta (incrementali).
La figura seguente è una rappresentazione del modello iterativo e incrementale:
Lo sviluppo iterativo e incrementale è una combinazione di progettazione iterativa o metodo iterativo e modello di build incrementale per lo sviluppo. "Durante lo sviluppo del software, potrebbe essere in corso più di un'iterazione del ciclo di sviluppo del software contemporaneamente." Questo processo può essere descritto come un approccio di "acquisizione evolutiva" o "costruzione incrementale". "
In questo modello incrementale, l'intero requisito è suddiviso in varie build. Durante ogni iterazione, il modulo di sviluppo passa attraverso le fasi di requisiti, progettazione, implementazione e test. Ogni versione successiva del modulo aggiunge funzioni alla versione precedente. Il processo continua fino a quando il sistema completo è pronto secondo il requisito.
La chiave per un uso riuscito di un ciclo di vita di sviluppo software iterativo è la convalida rigorosa dei requisiti e la verifica e il test di ciascuna versione del software rispetto a tali requisiti all'interno di ogni ciclo del modello. Man mano che il software si evolve attraverso cicli successivi, i test devono essere ripetuti ed estesi per verificare ogni versione del software.
Modello iterativo - Applicazione
Come altri modelli SDLC, lo sviluppo iterativo e incrementale ha alcune applicazioni specifiche nell'industria del software. Questo modello viene spesso utilizzato nei seguenti scenari:
I requisiti del sistema completo sono chiaramente definiti e compresi.
I requisiti principali devono essere definiti; tuttavia, alcune funzionalità o miglioramenti richiesti potrebbero evolversi nel tempo.
C'è un tempo per il vincolo del mercato.
Una nuova tecnologia è in uso e viene appresa dal team di sviluppo mentre lavora al progetto.
Le risorse con le serie di competenze necessarie non sono disponibili e sono pianificate per essere utilizzate su base contrattuale per iterazioni specifiche.
Ci sono alcune caratteristiche e obiettivi ad alto rischio che potrebbero cambiare in futuro.
Modello iterativo - Pro e contro
Il vantaggio di questo modello è che esiste un modello funzionante del sistema in una fase iniziale di sviluppo, che rende più facile trovare difetti funzionali o di design. L'individuazione dei problemi in una fase iniziale dello sviluppo consente di adottare misure correttive con un budget limitato.
Lo svantaggio di questo modello SDLC è che è applicabile solo a progetti di sviluppo software grandi e voluminosi. Questo perché è difficile suddividere un piccolo sistema software in ulteriori piccoli incrementi / moduli utilizzabili.
I vantaggi del modello SDLC iterativo e incrementale sono i seguenti:
Alcune funzionalità operative possono essere sviluppate rapidamente e nelle prime fasi del ciclo di vita.
I risultati si ottengono precocemente e periodicamente.
È possibile pianificare uno sviluppo parallelo.
Il progresso può essere misurato.
Meno costoso modificare l'ambito / i requisiti.
Il test e il debug durante l'iterazione più piccola è facile.
I rischi vengono identificati e risolti durante l'iterazione; e ogni iterazione è una pietra miliare facilmente gestibile.
Gestione del rischio più semplice: la parte ad alto rischio viene eseguita per prima.
Con ogni incremento, viene fornito un prodotto operativo.
Problemi, sfide e rischi identificati da ogni incremento possono essere utilizzati / applicati all'incremento successivo.
L'analisi dei rischi è migliore.
Supporta il cambiamento dei requisiti.
Il tempo di funzionamento iniziale è inferiore.
Più adatto per progetti di grandi dimensioni e mission-critical.
Durante il ciclo di vita, il software viene prodotto in anticipo, il che facilita la valutazione e il feedback dei clienti.
Gli svantaggi del modello SDLC iterativo e incrementale sono i seguenti:
Potrebbero essere necessarie più risorse.
Sebbene il costo del cambiamento sia inferiore, ma non è molto adatto per cambiare i requisiti.
È necessaria una maggiore attenzione da parte della direzione.
Possono sorgere problemi di architettura o di progettazione del sistema perché non tutti i requisiti vengono raccolti all'inizio dell'intero ciclo di vita.
La definizione degli incrementi può richiedere la definizione del sistema completo.
Non adatto a progetti più piccoli.
La complessità della gestione è più.
La fine del progetto potrebbe non essere nota, il che rappresenta un rischio.
Per l'analisi dei rischi sono necessarie risorse altamente qualificate.
L'avanzamento dei progetti dipende in larga misura dalla fase di analisi del rischio.
Il modello a spirale combina l'idea di sviluppo iterativo con gli aspetti sistematici e controllati del modello a cascata. Questo modello a spirale è una combinazione del modello di processo di sviluppo iterativo e del modello di sviluppo lineare sequenziale, ovvero il modello a cascata con un'enfasi molto elevata sull'analisi del rischio. Consente rilasci incrementali del prodotto o un raffinamento incrementale attraverso ogni iterazione attorno alla spirale.
Modello a spirale - Design
Il modello a spirale ha quattro fasi. Un progetto software passa ripetutamente attraverso queste fasi in iterazioni chiamate Spirali.
Identificazione
Questa fase inizia con la raccolta dei requisiti aziendali nella spirale di base. Nelle successive spirali man mano che il prodotto matura, in questa fase viene effettuata l'identificazione dei requisiti di sistema, dei requisiti del sottosistema e dei requisiti dell'unità.
Questa fase include anche la comprensione dei requisiti di sistema attraverso la comunicazione continua tra il cliente e l'analista di sistema. Alla fine della spirale, il prodotto viene distribuito nel mercato identificato.
Design
La fase di progettazione inizia con la progettazione concettuale nella spirale della linea di base e coinvolge la progettazione architettonica, la progettazione logica dei moduli, la progettazione fisica del prodotto e il progetto finale nelle spirali successive.
Costruisci o costruisci
La fase di costruzione si riferisce alla produzione del prodotto software effettivo ad ogni spirale. Nella spirale di base, quando si pensa al prodotto e si sta sviluppando il design, in questa fase viene sviluppato un POC (Proof of Concept) per ottenere il feedback dei clienti.
Quindi nelle successive spirali con maggiore chiarezza sui requisiti e sui dettagli di progettazione viene prodotto un modello funzionante del software chiamato build con un numero di versione. Queste build vengono inviate al cliente per il feedback.
Valutazione e analisi dei rischi
L'analisi dei rischi include l'identificazione, la stima e il monitoraggio della fattibilità tecnica e dei rischi di gestione, come lo slittamento della pianificazione e il superamento dei costi. Dopo aver testato la build, alla fine della prima iterazione, il cliente valuta il software e fornisce feedback.
L'illustrazione seguente è una rappresentazione del modello a spirale, che elenca le attività in ciascuna fase.
Sulla base della valutazione del cliente, il processo di sviluppo del software entra nell'iterazione successiva e successivamente segue l'approccio lineare per implementare il feedback suggerito dal cliente. Il processo di iterazioni lungo la spirale continua per tutta la vita del software.
Applicazione del modello a spirale
Lo Spiral Model è ampiamente utilizzato nell'industria del software in quanto è in sincronia con il naturale processo di sviluppo di qualsiasi prodotto, ovvero l'apprendimento con maturità che comporta il minimo rischio per il cliente così come per le aziende di sviluppo.
I seguenti suggerimenti spiegano gli usi tipici di un modello a spirale:
Quando c'è un vincolo di bilancio e la valutazione del rischio è importante.
Per progetti a rischio medio-alto.
Impegno del progetto a lungo termine a causa di potenziali cambiamenti alle priorità economiche man mano che i requisiti cambiano nel tempo.
Il cliente non è sicuro delle proprie esigenze, come di solito accade.
I requisiti sono complessi e richiedono una valutazione per ottenere chiarezza.
Nuova linea di prodotti che dovrebbe essere rilasciata in fasi per ottenere un feedback sufficiente dai clienti.
Sono previsti cambiamenti significativi nel prodotto durante il ciclo di sviluppo.
Modello a spirale - Pro e contro
Il vantaggio del modello del ciclo di vita a spirale è che consente di aggiungere elementi del prodotto, quando diventano disponibili o conosciuti. Ciò garantisce che non vi siano conflitti con i requisiti e il design precedenti.
Questo metodo è coerente con gli approcci che hanno più build e rilasci software che consentono di effettuare una transizione ordinata a un'attività di manutenzione. Un altro aspetto positivo di questo metodo è che il modello a spirale impone un coinvolgimento precoce dell'utente nello sforzo di sviluppo del sistema.
D'altro canto, è necessaria una gestione molto rigida per completare tali prodotti e c'è il rischio di eseguire la spirale in un ciclo indefinito. Pertanto, la disciplina del cambiamento e l'entità dell'accettazione delle richieste di cambiamento sono molto importanti per sviluppare e distribuire il prodotto con successo.
I vantaggi del modello Spiral SDLC sono i seguenti:
È possibile soddisfare le esigenze in evoluzione.
Consente un ampio utilizzo di prototipi.
I requisiti possono essere acquisiti in modo più accurato.
Gli utenti vedono il sistema in anticipo.
Lo sviluppo può essere suddiviso in parti più piccole e le parti rischiose possono essere sviluppate prima, il che aiuta a una migliore gestione del rischio.
Gli svantaggi del modello Spiral SDLC sono i seguenti:
La gestione è più complessa.
La fine del progetto potrebbe non essere nota in anticipo.
Non adatto a progetti piccoli oa basso rischio e potrebbe essere costoso per piccoli progetti.
Il processo è complesso
La spirale può andare avanti all'infinito.
Un gran numero di fasi intermedie richiede una documentazione eccessiva.
Il modello a V è un modello SDLC in cui l'esecuzione dei processi avviene in modo sequenziale in una forma a V. È anche conosciuto comeVerification and Validation model.
Il V-Model è un'estensione del modello a cascata e si basa sull'associazione di una fase di test per ciascuna fase di sviluppo corrispondente. Ciò significa che per ogni singola fase del ciclo di sviluppo, esiste una fase di test direttamente associata. Questo è un modello altamente disciplinato e la fase successiva inizia solo dopo il completamento della fase precedente.
Modello V - Design
Nell'ambito del V-Model, la corrispondente fase di test della fase di sviluppo è pianificata in parallelo. Quindi, ci sono fasi di verifica su un lato delle fasi "V" e di convalida sull'altro lato. La fase di codifica unisce i due lati del modello V.
La seguente illustrazione illustra le diverse fasi in un modello V dell'SDLC.
V-Model - Fasi di verifica
Ci sono diverse fasi di verifica nel V-Model, ognuna di queste è spiegata in dettaglio di seguito.
Analisi dei requisiti aziendali
Questa è la prima fase del ciclo di sviluppo in cui i requisiti del prodotto vengono compresi dal punto di vista del cliente. Questa fase prevede una comunicazione dettagliata con il cliente per comprendere le sue aspettative e l'esatta esigenza. Questa è un'attività molto importante e deve essere gestita bene, poiché la maggior parte dei clienti non è sicura di ciò di cui hanno esattamente bisogno. Ilacceptance test design planning viene eseguita in questa fase poiché i requisiti aziendali possono essere utilizzati come input per i test di accettazione.
Sistema di design
Una volta che hai i requisiti del prodotto chiari e dettagliati, è il momento di progettare il sistema completo. Il design del sistema comprenderà e descriverà dettagliatamente la configurazione completa dell'hardware e della comunicazione per il prodotto in fase di sviluppo. Il piano di test del sistema viene sviluppato in base alla progettazione del sistema. Farlo in una fase precedente lascia più tempo per l'effettiva esecuzione del test in un secondo momento.
Progettazione architettonica
Le specifiche architettoniche vengono comprese e progettate in questa fase. Di solito viene proposto più di un approccio tecnico e in base alla fattibilità tecnica e finanziaria viene presa la decisione finale. Il design del sistema è ulteriormente suddiviso in moduli che assumono funzionalità diverse. Questo è anche indicato comeHigh Level Design (HLD).
Il trasferimento dei dati e la comunicazione tra i moduli interni e con il mondo esterno (altri sistemi) è chiaramente compreso e definito in questa fase. Con queste informazioni, i test di integrazione possono essere progettati e documentati durante questa fase.
Progettazione del modulo
In questa fase viene specificato il progetto interno dettagliato di tutti i moduli del sistema, denominato Low Level Design (LLD). È importante che il design sia compatibile con gli altri moduli nell'architettura del sistema e con gli altri sistemi esterni. Gli unit test sono una parte essenziale di qualsiasi processo di sviluppo e aiutano a eliminare i massimi difetti ed errori in una fase molto precoce. Questi test unitari possono essere progettati in questa fase sulla base dei progetti del modulo interno.
Fase di codifica
La codifica vera e propria dei moduli del sistema progettati in fase di progettazione viene ripresa nella fase di Codifica. Il linguaggio di programmazione più adatto viene deciso in base al sistema e ai requisiti architettonici.
La codifica viene eseguita in base alle linee guida e agli standard di codifica. Il codice viene sottoposto a numerose revisioni del codice ed è ottimizzato per le migliori prestazioni prima che la build finale venga archiviata nel repository.
Fasi di convalida
Le diverse fasi di convalida in un modello V sono spiegate in dettaglio di seguito.
Test unitario
Gli unit test progettati nella fase di progettazione del modulo vengono eseguiti sul codice durante questa fase di convalida. Il test unitario è il test a livello di codice e aiuta a eliminare i bug in una fase iniziale, sebbene tutti i difetti non possano essere scoperti dal test unitario.
Test d'integrazione
Il test di integrazione è associato alla fase di progettazione architettonica. I test di integrazione vengono eseguiti per testare la coesistenza e la comunicazione dei moduli interni all'interno del sistema.
Test di sistema
Il test del sistema è direttamente associato alla fase di progettazione del sistema. I test di sistema controllano l'intera funzionalità del sistema e la comunicazione del sistema in fase di sviluppo con i sistemi esterni. La maggior parte dei problemi di compatibilità software e hardware possono essere scoperti durante l'esecuzione di questo test di sistema.
Test di accettazione
Il test di accettazione è associato alla fase di analisi dei requisiti aziendali e implica il test del prodotto nell'ambiente dell'utente. I test di accettazione rivelano i problemi di compatibilità con gli altri sistemi disponibili nell'ambiente utente. Rileva anche i problemi non funzionali come i difetti di carico e di prestazioni nell'ambiente utente effettivo.
Modello V ─ Applicazione
L'applicazione V-Model è pressoché identica al modello a cascata, poiché entrambi i modelli sono di tipo sequenziale. I requisiti devono essere molto chiari prima dell'inizio del progetto, perché di solito è costoso tornare indietro e apportare modifiche. Questo modello è utilizzato nel campo dello sviluppo medico, poiché è un dominio strettamente disciplinato.
I seguenti puntatori sono alcuni degli scenari più adatti per utilizzare l'applicazione V-Model.
I requisiti sono ben definiti, chiaramente documentati e fissi.
La definizione del prodotto è stabile.
La tecnologia non è dinamica ed è ben compresa dal team di progetto.
Non ci sono requisiti ambigui o indefiniti.
Il progetto è breve.
V-Model - Pro e contro
Il vantaggio del metodo V-Model è che è molto facile da capire e da applicare. La semplicità di questo modello lo rende anche più facile da gestire. Lo svantaggio è che il modello non è flessibile ai cambiamenti e nel caso in cui ci sia un cambiamento dei requisiti, che è molto comune nel mondo dinamico di oggi, diventa molto costoso effettuare il cambiamento.
I vantaggi del metodo V-Model sono i seguenti:
Questo è un modello altamente disciplinato e le fasi vengono completate una alla volta.
Funziona bene per progetti più piccoli in cui i requisiti sono molto ben compresi.
Semplice e facile da capire e da usare.
Facile da gestire grazie alla rigidità del modello. Ogni fase ha risultati finali specifici e un processo di revisione.
Gli svantaggi del metodo V-Model sono i seguenti:
Alto rischio e incertezza.
Non è un buon modello per progetti complessi e orientati agli oggetti.
Modello scadente per progetti lunghi e in corso.
Non adatto a progetti in cui i requisiti corrono un rischio di cambiamento da moderato ad alto.
Una volta che un'applicazione è in fase di test, è difficile tornare indietro e modificare una funzionalità.
Nessun software funzionante viene prodotto fino a tardi durante il ciclo di vita.
Il modello Big Bang è un modello SDLC in cui non seguiamo alcun processo specifico. Lo sviluppo inizia con i soldi e gli sforzi richiesti come input e l'output è il software sviluppato che può o meno essere secondo le esigenze del cliente. Questo modello Big Bang non segue un processo / procedura ed è richiesta una pianificazione minima. Anche il cliente non è sicuro di ciò che vuole esattamente e i requisiti vengono implementati al volo senza troppe analisi.
Di solito questo modello viene seguito per piccoli progetti in cui i team di sviluppo sono molto piccoli.
Modello Big Bang ─ Design e applicazione
Il modello Big Bang consiste nel concentrare tutte le risorse possibili nello sviluppo e nella codifica del software, con una pianificazione minima o nulla. I requisiti vengono compresi e implementati non appena vengono. Qualsiasi modifica richiesta potrebbe richiedere o meno il rinnovo dell'intero software.
Questo modello è ideale per piccoli progetti con uno o due sviluppatori che lavorano insieme ed è utile anche per progetti accademici o pratici. È un modello ideale per il prodotto in cui i requisiti non sono ben compresi e non viene fornita la data di rilascio finale.
Modello Big Bang - Pro e contro
Il vantaggio di questo modello Big Bang è che è molto semplice e richiede pochissima o nessuna pianificazione. Facile da gestire e non è richiesta alcuna procedura formale.
Tuttavia, il modello Big Bang è un modello a rischio molto elevato e le modifiche ai requisiti o ai requisiti fraintesi possono persino portare al completo annullamento o alla cancellazione del progetto. È ideale per progetti ripetitivi o piccoli con rischi minimi.
I vantaggi del modello Big Bang sono i seguenti:
Questo è un modello molto semplice
Poca o nessuna pianificazione richiesta
Facile da gestire
Sono necessarie pochissime risorse
Offre flessibilità agli sviluppatori
È un buon aiuto per l'apprendimento per i nuovi arrivati o gli studenti.
Gli svantaggi del modello Big Bang sono i seguenti:
Rischio e incertezza molto elevati.
Non è un buon modello per progetti complessi e orientati agli oggetti.
Modello scadente per progetti lunghi e in corso.
Può rivelarsi molto costoso se i requisiti vengono fraintesi.
Il modello Agile SDLC è una combinazione di modelli di processo iterativi e incrementali con particolare attenzione all'adattabilità del processo e alla soddisfazione del cliente mediante la consegna rapida di prodotti software funzionanti. I metodi agili suddividono il prodotto in piccole build incrementali. Queste build sono fornite in iterazioni. Ogni iterazione dura tipicamente da una a tre settimane circa. Ogni iterazione coinvolge team interfunzionali che lavorano simultaneamente su varie aree come:
- Planning
- Analisi dei requisiti
- Design
- Coding
- Test unitari e
- Test di accettazione.
Alla fine dell'iterazione, un prodotto funzionante viene mostrato al cliente e alle parti interessate importanti.
Cos'è Agile?
Il modello Agile ritiene che ogni progetto debba essere gestito in modo diverso e che i metodi esistenti debbano essere adattati per soddisfare al meglio i requisiti del progetto. In Agile, le attività sono suddivise in time box (piccoli intervalli di tempo) per fornire funzionalità specifiche per un rilascio.
Viene adottato un approccio iterativo e la build del software funzionante viene consegnata dopo ogni iterazione. Ogni build è incrementale in termini di funzionalità; la build finale contiene tutte le caratteristiche richieste dal cliente.
Ecco un'illustrazione grafica del modello Agile:
Il processo di pensiero Agile era iniziato all'inizio dello sviluppo del software e ha iniziato a diventare popolare nel tempo grazie alla sua flessibilità e adattabilità.
I metodi Agile più popolari includono Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development e Dynamic Systems Development Method (DSDM) (1995). Questi sono ora indicati collettivamente comeAgile Methodologies, dopo la pubblicazione del Manifesto Agile nel 2001.
Di seguito sono riportati i principi del Manifesto Agile:
Individuals and interactions - Nello sviluppo Agile, l'auto-organizzazione e la motivazione sono importanti, così come le interazioni come la co-locazione e la programmazione in coppia.
Working software - Il software demo funzionante è considerato il miglior mezzo di comunicazione con i clienti per comprendere le loro esigenze, invece di dipendere solo dalla documentazione.
Customer collaboration - Poiché i requisiti non possono essere raccolti completamente all'inizio del progetto a causa di vari fattori, l'interazione continua con il cliente è molto importante per ottenere i requisiti del prodotto adeguati.
Responding to change - Lo sviluppo agile si concentra su risposte rapide al cambiamento e sviluppo continuo.
Modelli SDLC agili e tradizionali
Agile si basa su adaptive software development methods, mentre i modelli SDLC tradizionali come il modello a cascata si basano su un approccio predittivo. I team predittivi nei modelli SDLC tradizionali di solito lavorano con una pianificazione dettagliata e hanno una previsione completa delle attività e delle funzionalità esatte da fornire nei prossimi mesi o durante il ciclo di vita del prodotto.
I metodi predittivi dipendono interamente da requirement analysis and planningfatto all'inizio del ciclo. Qualsiasi modifica da incorporare passa attraverso una rigorosa gestione del controllo delle modifiche e assegnazione delle priorità.
Agile utilizza un file adaptive approachdove non c'è una pianificazione dettagliata e c'è chiarezza sui compiti futuri solo per quanto riguarda le caratteristiche che devono essere sviluppate. È previsto uno sviluppo basato sulle funzionalità e il team si adatta dinamicamente ai requisiti del prodotto in evoluzione. Il prodotto viene testato molto frequentemente, attraverso le iterazioni di rilascio, riducendo al minimo il rischio di eventuali guasti importanti in futuro.
Customer Interactionè la spina dorsale di questa metodologia Agile e la comunicazione aperta con documentazione minima sono le caratteristiche tipiche dell'ambiente di sviluppo Agile. I team agili lavorano in stretta collaborazione tra loro e si trovano molto spesso nella stessa posizione geografica.
Modello Agile - Pro e contro
I metodi agili sono stati ampiamente accettati nel mondo del software di recente. Tuttavia, questo metodo potrebbe non essere sempre adatto a tutti i prodotti. Ecco alcuni pro e contro del modello Agile.
I vantaggi del modello Agile sono i seguenti:
È un approccio molto realistico allo sviluppo del software.
Promuove il lavoro di squadra e il cross training.
La funzionalità può essere sviluppata rapidamente e dimostrata.
I requisiti di risorse sono minimi.
Adatto per esigenze fisse o mutevoli
Fornisce soluzioni di lavoro parziali iniziali.
Buon modello per ambienti che cambiano costantemente.
Regole minime, documentazione facilmente utilizzabile.
Consente lo sviluppo e la consegna simultanei all'interno di un contesto pianificato globale.
Poca o nessuna pianificazione richiesta.
Facile da gestire.
Offre flessibilità agli sviluppatori.
Gli svantaggi del modello Agile sono i seguenti:
Non adatto per la gestione di dipendenze complesse.
Maggiori rischi di sostenibilità, manutenibilità ed estensibilità.
Un piano generale, un leader agile e una pratica di PM agile è un must senza il quale non funzionerà.
Una rigorosa gestione delle consegne determina l'ambito, la funzionalità da fornire e gli adeguamenti per rispettare le scadenze.
Dipende fortemente dall'interazione del cliente, quindi se il cliente non è chiaro, il team può essere guidato nella direzione sbagliata.
Esiste una dipendenza individuale molto elevata, poiché viene generata una documentazione minima.
Il trasferimento di tecnologia a nuovi membri del team può essere piuttosto impegnativo a causa della mancanza di documentazione.
Il RAD (Rapid Application Development)il modello si basa sulla prototipazione e sullo sviluppo iterativo senza alcuna pianificazione specifica. Il processo di scrittura del software stesso implica la pianificazione necessaria per lo sviluppo del prodotto.
Lo sviluppo rapido delle applicazioni si concentra sulla raccolta dei requisiti del cliente attraverso workshop o focus group, test precoce dei prototipi da parte del cliente utilizzando un concetto iterativo, riutilizzo dei prototipi esistenti (componenti), integrazione continua e consegna rapida.
Cos'è RAD?
Lo sviluppo rapido di applicazioni è una metodologia di sviluppo software che utilizza una pianificazione minima a favore della prototipazione rapida. Un prototipo è un modello funzionante che è funzionalmente equivalente a un componente del prodotto.
Nel modello RAD, i moduli funzionali vengono sviluppati in parallelo come prototipi e vengono integrati per realizzare il prodotto completo per una consegna più rapida del prodotto. Poiché non esiste una pianificazione preliminare dettagliata, è più facile incorporare le modifiche all'interno del processo di sviluppo.
I progetti RAD seguono un modello iterativo e incrementale e hanno piccoli team composti da sviluppatori, esperti di dominio, rappresentanti dei clienti e altre risorse IT che lavorano progressivamente sul loro componente o prototipo.
L'aspetto più importante affinché questo modello abbia successo è assicurarsi che i prototipi sviluppati siano riutilizzabili.
Progettazione del modello RAD
Il modello RAD distribuisce le fasi di analisi, progettazione, costruzione e test in una serie di cicli di sviluppo brevi e iterativi.
Di seguito sono riportate le varie fasi del Modello RAD:
Modellazione aziendale
Il modello di business del prodotto in fase di sviluppo è concepito in termini di flusso di informazioni e di distribuzione delle informazioni tra i vari canali di business. Viene eseguita un'analisi aziendale completa per trovare le informazioni vitali per il business, come ottenerle, come e quando vengono elaborate le informazioni e quali sono i fattori che guidano il flusso di informazioni di successo.
Modellazione dei dati
Le informazioni raccolte nella fase di Business Modeling vengono riviste e analizzate per formare insiemi di oggetti di dati vitali per l'azienda. Gli attributi di tutti i set di dati vengono identificati e definiti. La relazione tra questi oggetti di dati viene stabilita e definita in dettaglio in relazione al modello di business.
Modellazione dei processi
I set di oggetti dati definiti nella fase di modellazione dati vengono convertiti per stabilire il flusso di informazioni aziendali necessario per raggiungere obiettivi aziendali specifici secondo il modello di business. In questa fase viene definito il modello di processo per eventuali modifiche o miglioramenti ai set di oggetti dati. Vengono fornite le descrizioni del processo per l'aggiunta, l'eliminazione, il recupero o la modifica di un oggetto dati.
Generazione di applicazioni
Il sistema effettivo viene costruito e la codifica viene eseguita utilizzando strumenti di automazione per convertire i modelli di processo e di dati in prototipi reali.
Test e fatturato
Il tempo di test complessivo è ridotto nel modello RAD poiché i prototipi vengono testati indipendentemente durante ogni iterazione. Tuttavia, il flusso di dati e le interfacce tra tutti i componenti devono essere accuratamente testati con una copertura di prova completa. Poiché la maggior parte dei componenti di programmazione sono già stati testati, riduce il rischio di eventuali problemi importanti.
La figura seguente descrive in dettaglio il modello RAD.
Modello RAD vs SDLC tradizionale
L'SDLC tradizionale segue modelli di processo rigidi con grande enfasi sull'analisi e la raccolta dei requisiti prima dell'inizio della codifica. Mette pressione sul cliente affinché approvi i requisiti prima dell'inizio del progetto e il cliente non ha la sensazione del prodotto poiché non è disponibile una build funzionante per molto tempo.
Il cliente potrebbe aver bisogno di alcune modifiche dopo aver visto il software. Tuttavia, il processo di modifica è piuttosto rigido e potrebbe non essere fattibile incorporare importanti cambiamenti nel prodotto nell'SDLC tradizionale.
Il modello RAD si concentra sulla consegna iterativa e incrementale di modelli di lavoro al cliente. Ciò si traduce in una rapida consegna al cliente e nel coinvolgimento del cliente durante l'intero ciclo di sviluppo del prodotto riducendo il rischio di non conformità con le effettive esigenze dell'utente.
Modello RAD - Applicazione
Il modello RAD può essere applicato con successo ai progetti in cui è possibile una chiara modularizzazione. Se il progetto non può essere suddiviso in moduli, RAD potrebbe non riuscire.
I seguenti puntatori descrivono gli scenari tipici in cui RAD può essere utilizzato:
RAD dovrebbe essere utilizzato solo quando un sistema può essere modularizzato per essere consegnato in modo incrementale.
Dovrebbe essere usato se c'è un'elevata disponibilità di designer per la modellazione.
Dovrebbe essere utilizzato solo se il budget consente l'uso di strumenti di generazione automatica del codice.
Il modello RAD SDLC deve essere scelto solo se sono disponibili esperti di dominio con conoscenze aziendali pertinenti.
Dovrebbe essere utilizzato laddove i requisiti cambiano durante il progetto e i prototipi funzionanti devono essere presentati al cliente in piccole iterazioni di 2-3 mesi.
Modello RAD - Pro e contro
Il modello RAD consente una consegna rapida in quanto riduce il tempo di sviluppo complessivo grazie alla riutilizzabilità dei componenti e allo sviluppo parallelo. RAD funziona bene solo se sono disponibili ingegneri altamente qualificati e il cliente si impegna anche a realizzare il prototipo mirato nel periodo di tempo stabilito. Se manca l'impegno da entrambe le parti, il modello potrebbe fallire.
I vantaggi del modello RAD sono i seguenti:
È possibile soddisfare le esigenze in evoluzione.
Il progresso può essere misurato.
Il tempo di iterazione può essere breve con l'uso di potenti strumenti RAD.
Produttività con meno persone in breve tempo.
Tempi di sviluppo ridotti.
Aumenta la riutilizzabilità dei componenti.
Si verificano rapide revisioni iniziali.
Incoraggia il feedback dei clienti.
L'integrazione sin dall'inizio risolve molti problemi di integrazione.
Gli svantaggi del modello RAD sono i seguenti:
Dipendenza da membri del team tecnicamente forti per l'identificazione dei requisiti aziendali.
Solo il sistema che può essere modulare può essere costruito utilizzando RAD.
Richiede sviluppatori / designer altamente qualificati.
Elevata dipendenza dalle capacità di modellazione.
Inapplicabile a progetti più economici poiché il costo della modellazione e della generazione di codice automatizzato è molto elevato.
La complessità della gestione è più.
Adatto per sistemi basati su componenti e scalabili.
Richiede il coinvolgimento dell'utente durante tutto il ciclo di vita.
Adatto per progetti che richiedono tempi di sviluppo più brevi.
Il Software Prototyping si riferisce alla creazione di prototipi di applicazioni software che mostrano la funzionalità del prodotto in fase di sviluppo, ma potrebbero non contenere la logica esatta del software originale.
La prototipazione software sta diventando molto popolare come modello di sviluppo software, poiché consente di comprendere i requisiti dei clienti in una fase iniziale di sviluppo. Aiuta a ottenere un feedback prezioso dal cliente e aiuta i progettisti di software e gli sviluppatori a capire cosa ci si aspetta esattamente dal prodotto in fase di sviluppo.
Cos'è la prototipazione software?
Il prototipo è un modello funzionante di software con alcune funzionalità limitate. Il prototipo non contiene sempre la logica esatta utilizzata nell'applicazione software effettiva ed è uno sforzo aggiuntivo da considerare nella stima dello sforzo.
La prototipazione viene utilizzata per consentire agli utenti di valutare le proposte degli sviluppatori e provarle prima dell'implementazione. Aiuta anche a comprendere i requisiti specifici dell'utente e che potrebbero non essere stati considerati dallo sviluppatore durante la progettazione del prodotto.
Di seguito è illustrato un approccio graduale per progettare un prototipo di software.
Identificazione dei requisiti di base
Questo passaggio implica la comprensione dei requisiti di base del prodotto, soprattutto in termini di interfaccia utente. I dettagli più complessi del design interno e gli aspetti esterni come le prestazioni e la sicurezza possono essere ignorati in questa fase.
Sviluppo del prototipo iniziale
Il prototipo iniziale viene sviluppato in questa fase, in cui vengono presentati i requisiti di base e vengono fornite le interfacce utente. Queste funzionalità potrebbero non funzionare esattamente nello stesso modo internamente nel software effettivamente sviluppato. Mentre, le soluzioni alternative vengono utilizzate per dare lo stesso aspetto e sensazione al cliente nel prototipo sviluppato.
Revisione del prototipo
Il prototipo sviluppato viene quindi presentato al cliente e agli altri importanti stakeholder del progetto. Il feedback viene raccolto in modo organizzato e utilizzato per ulteriori miglioramenti nel prodotto in fase di sviluppo.
Rivedi e migliora il prototipo
Il feedback ei commenti di revisione vengono discussi durante questa fase e alcune negoziazioni avvengono con il cliente in base a fattori come: vincoli di tempo e budget e fattibilità tecnica dell'attuazione effettiva. Le modifiche accettate vengono nuovamente incorporate nel nuovo prototipo sviluppato e il ciclo si ripete fino a soddisfare le aspettative del cliente.
I prototipi possono avere dimensioni orizzontali o verticali. Un prototipo orizzontale mostra l'interfaccia utente del prodotto e offre una visione più ampia dell'intero sistema, senza concentrarsi sulle funzioni interne. Un prototipo verticale sull'altro lato è un'elaborazione dettagliata di una funzione specifica o di un sottosistema nel prodotto.
Lo scopo del prototipo orizzontale e verticale è diverso. I prototipi orizzontali vengono utilizzati per ottenere maggiori informazioni sul livello di interfaccia utente e sui requisiti aziendali. Può anche essere presentato nelle demo di vendita per ottenere affari nel mercato. I prototipi verticali sono di natura tecnica e vengono utilizzati per ottenere dettagli sull'esatto funzionamento dei sottosistemi. Ad esempio, i requisiti del database, l'interazione e l'elaborazione dei dati vengono caricati in un determinato sottosistema.
Prototipazione software - Tipi
Esistono diversi tipi di prototipi software utilizzati nel settore. Di seguito sono riportati i principali tipi di prototipazione software ampiamente utilizzati:
Usa e getta / Prototipazione rapida
La prototipazione usa e getta è anche chiamata prototipazione rapida o chiusa. Questo tipo di prototipazione utilizza pochissimi sforzi con un'analisi dei requisiti minimi per costruire un prototipo. Una volta compresi i requisiti effettivi, il prototipo viene scartato e il sistema effettivo viene sviluppato con una comprensione molto chiara dei requisiti dell'utente.
Prototipazione evolutiva
La prototipazione evolutiva, chiamata anche prototipazione breadboard, si basa sulla costruzione di prototipi funzionali effettivi con funzionalità minime all'inizio. Il prototipo sviluppato costituisce il cuore dei futuri prototipi su cui è costruito l'intero sistema. Utilizzando la prototipazione evolutiva, i requisiti ben compresi sono inclusi nel prototipo e i requisiti vengono aggiunti come e quando vengono compresi.
Prototipazione incrementale
La prototipazione incrementale si riferisce alla costruzione di più prototipi funzionali dei vari sottosistemi e quindi all'integrazione di tutti i prototipi disponibili per formare un sistema completo.
Prototipazione estrema
La prototipazione estrema viene utilizzata nel dominio dello sviluppo web. Consiste di tre fasi sequenziali. Innanzitutto, un prototipo di base con tutte le pagine esistenti viene presentato nel formato HTML. Quindi l'elaborazione dei dati viene simulata utilizzando un livello di servizi prototipo. Infine, i servizi vengono implementati e integrati al prototipo finale. Questo processo è chiamato Extreme Prototyping utilizzato per attirare l'attenzione sulla seconda fase del processo, in cui viene sviluppata un'interfaccia utente completamente funzionale con pochissimo riguardo ai servizi effettivi.
Prototipazione software - Applicazione
La prototipazione software è particolarmente utile nello sviluppo di sistemi con un alto livello di interazioni utente come i sistemi online. I sistemi che richiedono agli utenti di compilare moduli o passare attraverso varie schermate prima che i dati vengano elaborati possono utilizzare la prototipazione in modo molto efficace per dare l'aspetto esatto anche prima che il software reale venga sviluppato.
Il software che comporta un'eccessiva elaborazione dei dati e la maggior parte delle funzionalità è interna con un'interfaccia utente molto ridotta di solito non beneficia della prototipazione. Lo sviluppo del prototipo potrebbe essere un sovraccarico aggiuntivo in tali progetti e potrebbe richiedere molti sforzi aggiuntivi.
Prototipazione software - Pro e contro
La prototipazione del software viene utilizzata nei casi tipici e la decisione dovrebbe essere presa con molta attenzione in modo che gli sforzi spesi nella costruzione del prototipo aggiungano un valore considerevole al software finale sviluppato. Il modello ha i suoi pro e contro discussi come segue.
I vantaggi del modello di prototipazione sono i seguenti:
Maggiore coinvolgimento degli utenti nel prodotto anche prima della sua implementazione.
Poiché viene visualizzato un modello funzionante del sistema, gli utenti ottengono una migliore comprensione del sistema in fase di sviluppo.
Riduce tempi e costi in quanto i difetti possono essere rilevati molto prima.
È disponibile un feedback degli utenti più rapido che porta a soluzioni migliori.
Le funzionalità mancanti possono essere identificate facilmente.
Si possono identificare funzioni confuse o difficili.
Gli svantaggi del modello di prototipazione sono i seguenti:
Rischio di un'analisi dei requisiti insufficiente a causa dell'eccessiva dipendenza dal prototipo.
Gli utenti possono confondersi nei prototipi e nei sistemi reali.
In pratica, questa metodologia può aumentare la complessità del sistema poiché la portata del sistema può espandersi oltre i piani originali.
Gli sviluppatori possono provare a riutilizzare i prototipi esistenti per costruire il sistema reale, anche quando non è tecnicamente fattibile.
Lo sforzo investito nella costruzione di prototipi potrebbe essere eccessivo se non viene monitorato adeguatamente.