Menu

Case Study: Come eliminare i difetti dei processi di sviluppo a cascata e Agile utilizzando un modello ibrido

  • Principale
  • Test Agili
  • Case Study: Come eliminare i difetti dei processi di sviluppo a cascata e Agile utilizzando un modello ibrido

case study how eliminate flaws waterfall

Prova Il Nostro Strumento Per Eliminare I Problemi

Modello ibrido a cascata agile

Il modello Waterfall è stata la scelta ideale per lo sviluppo del software. In questo modello, un'idea diventa software utilizzabile in un processo sequenziale che attraversa le fasi di Iniziazione, Analisi, Implementazione, Test e Manutenzione.

Ma il modello Waterfall presenta alcuni svantaggi.

Lo sviluppo agile del software si è evoluto per eliminare i problemi del modello Waterfall. Ha una struttura completamente nuova. Mentre il modello Waterfall ha un design sequenziale, il modello Agile ha seguito un approccio incrementale.

Quando i clienti che seguivano il modello Waterfall sono passati ad Agile, la transizione ha portato con sé molti problemi. Il motivo è l'inadattabilità a un diverso approccio allo sviluppo del software. Il prodotto finale si è rivelato un disastro.

Modello ibrido a cascata agile

Si è così evoluta una nuova metodologia, che può essere definita un 'ibrido', per garantire un prodotto finale robusto selezionando i pro dei modelli Agile e Waterfall.

Per prima cosa conosciamo i modelli di sviluppo Waterfall e Agile e poi passiamo al 'Modello ibrido Agile Waterfall' con pro e contro di ciascuno.

Cosa imparerai:

Modello a cascata

Il modello Waterfall è un approccio per lo sviluppo di software che suddivide un progetto in fasi finite. Si dovrebbe passare alla fase successiva solo quando la fase precedente è stata rivista e verificata.

Nel modello a cascata, le fasi non si sovrappongono.

=> Maggiori informazioni sul modello a cascata qui.

La Figura 1 mostra il modello Waterfall:

domande e risposte dell'intervista php per 2 anni di esperienza

Modello a cascata

Vantaggi del modello a cascata:

  • Semplice e facile da capire e da usare.
  • Modello rigido: ogni fase ha risultati finali e processi di revisione specifici.
  • Documentazione e manufatti meticolosamente mantenuti.
  • Adatto a progetti in cui i requisiti sono ben compresi.

Svantaggi del modello Waterfall:

  • Non adatto a progetti in cui i requisiti rischiano di cambiare.
  • Il costo della riparazione dei difetti è molto elevato se rilevato in una fase successiva.
  • Non è un buon modello per progetti complessi e lunghi.
  • Nessun software funzionante viene prodotto fino a tarda ora durante il ciclo di vita.

Modello agile

Wikipedia definisce il modello Agile come 'un gruppo di metodi di sviluppo software basati sullo sviluppo iterativo e incrementale, in cui i requisiti e le soluzioni si evolvono attraverso la collaborazione tra team interfunzionali auto-organizzati'.

Il modello ha i suoi principi che tendono a portare i processi in secondo piano.

=> Leggi altri articoli sulla metodologia Agile qui.

(Clicca sull'immagine per visualizzarla ingrandita)

Modello agile

Vantaggi del modello Agile:

  • Coinvolgimento del cliente nel processo.
  • ROI elevato poiché il software funzionante viene fornito frequentemente.
  • Anche le modifiche tardive dei requisiti possono essere facilmente adattate.
  • Miglioramento continuo sia del prodotto che del processo.

Svantaggi del modello Agile:

  • Mancanza di enfasi sulla progettazione e sulla documentazione.
  • La squadra dovrebbe essere stabile e qualificata.

Modello collaborativo (ibrido)

Il modello collaborativo mira a combinare entrambi i modelli: Waterfall e Agile. Sfruttare sia l'approccio Waterfall che Agile garantisce il successo del progetto. Elimina gli svantaggi di entrambi i modelli; riunendo i vantaggi di entrambi.

Il modello collaborativo può essere implementato in un progetto eseguendo:

Modello collaborativo (ibrido)

Quindi il modello collaborativo può essere rappresentato schematicamente come di seguito:

Modello collaborativo (ibrido) 2

Vantaggi del modello ibrido

  • Combina i vantaggi dei processi Agile e Waterfall.
  • Il design di alto livello è preparato per applicare i principi della cascata.
  • La codifica e il test vengono eseguiti utilizzando una metodologia agile.

Modello ibrido a cascata Agile - Impara con l'esempio -Un caso di studio

La società di software 'ABC Software Service’s fornisce servizi a un cliente, un'università denominata' XYZ University 'per sviluppare, testare e mantenere il proprio software (supporto per la produzione dal vivo).

Le caratteristiche principali dell'account sono:

  1. ABC Software Services deve aggiornare le applicazioni della XYZ University. Il database deve essere aggiornato e tutte le applicazioni devono essere ri-sviluppate alla più recente tecnologia disponibile sul mercato.
  2. Fino ad ora, tutti i progetti gestiti da ABC Software sono stati eseguiti nel modello Waterfall.
  3. Ora era previsto che due delle applicazioni ad alto traffico e ad alta priorità venissero ri-sviluppate. Il primo è 'Registrazioni online', il secondo è 'Esami online'.
  4. Il cliente XYZ University voleva ora che queste applicazioni venissero utilizzate utilizzando il modello Agile di sviluppo software.

Il primo progetto in un modello Agile per ABC Software è stato Registrazioni online. Dopo l'esecuzione di questo progetto, è stato realizzato in una serie di retrospettive che c'erano molti difetti nei processi seguiti.

Questi difetti sono stati risolti durante l'esecuzione del secondo progetto 'esami online' ed è stato quindi eseguito nel modello ibrido.

Come eliminare i difetti dei processi di sviluppo a cascata e Agile utilizzando un modello ibrido:

Discutiamoli in dettaglio uno per uno.

# 1. Nessuna documentazione:

Uno dei principi dell'agile nel manifesto dell'agile afferma che: Agile dà più valore al 'software funzionante rispetto alla documentazione completa'. La metodologia Agile ritiene che la documentazione debba essere 'appena sufficiente' e viene data maggiore enfasi alla fornitura di un software funzionante. Non viene fatto molto sforzo sulla documentazione, ma per account come la XYZ University, con un team di supporto dedicato per lavorare sui difetti riscontrati nei progetti live, questa abitudine può rivelarsi un ostacolo se la analizziamo a lungo termine.

Nel corso degli anni, quando i progetti sono stati eseguiti nel modello Waterfall, i documenti sono stati mantenuti e aggiornati per consentire al team di supporto di comprendere e lavorare di conseguenza. Progettazione della soluzione, progettazione tecnica, documentazione dettagliata, ecc. Sono stati alcuni dei documenti preparati. Al termine del progetto, lo stesso è stato trasferito al team di supporto.

Ma nel caso del progetto 'registrazioni online', non sono stati preparati documenti di questo tipo e ciò si è rivelato costoso. Quando il progetto è stato avviato, molti ticket sono stati raccolti dagli utenti finali e il team di supporto non aveva la più pallida idea di come lavorarci. Il team non aveva documenti a cui fare riferimento.

Questa è stata un'importante lezione appresa e per il prossimo progetto i documenti 'esami online' sono stati scritti e trasferiti in modo efficace.

conoscenza del dominio sanitario per tester pdf

=> Leggi di più qui perché la documentazione è importante.

#Due. Nessun test UAT / end-to-end:

Nella modalità Agile di sviluppo software, i tester fanno testare le build in incrementi. Queste build continuano a integrarsi fino a quando la build finale non è completamente costruita. I tester testano i requisiti coperti in ogni sprint e continuano a eseguire test di regressione della build che continuano a sommarsi.

Ma dopo che tutti gli sprint sono stati completati e la build finale è pronta e completamente integrata, il tester dovrebbe testare il sistema completo ed eseguire test end-to-end. Questo dovrebbe essere fatto in un ambiente completamente nuovo.

=> Test end to end su un progetto live.

Questo ha i suoi vantaggi:

  • Il sistema completo viene distribuito in un nuovo ambiente e il tester verifica il flusso completo.
  • Crea fiducia perché, in ultima analisi, la build deve essere distribuita nel suo insieme in un ambiente live.

Quando il progetto Registrazioni in linea è stato testato, è stato eseguito nell'ambiente di test. Dopo il test del sistema e il nuovo test di tutti i difetti, è stato dichiarato per l'approvazione. Idealmente, questo non è stato promosso a un altro ambiente per un altro ciclo di test del sistema. (Idealmente, L'UAT si verifica dopo il test del sistema , ma in questo caso, i membri del team UAT sono stati coinvolti nel primo ciclo di test, quindi non è stato programmato un secondo ciclo)

Quando il progetto degli esami online è iniziato, è stato eseguito SIT (System Integration Testing) e il codice è stato promosso in un ambiente UAT in cui è stato eseguito il secondo ciclo di test. Risultato: tutti i difetti ad alta priorità sono stati rilevati e risolti. La build era stabile prima del rilascio del go-live.

# 3. Nessun Scrum Master:

Il Maestro di mischia è responsabile di assicurarsi che un team viva secondo i valori e le pratiche di Scrum. Lo Scrum Master è considerato un coach per il team in quanto aiuta il team a fare il miglior lavoro possibile. Lo Scrum Master può anche essere pensato come un file proprietario del processo per il team.

Il team di registrazione online è stato formato senza uno Scrum Master. L'importanza di avere uno Scrum Master dedicato non era considerata importante. Ciò ha comportato che molti problemi non venissero risolti in tempo e, a sua volta, il tempo per completare il progetto spesso ha superato la scadenza.

Tuttavia, uno Scrum Master dedicato è stato coinvolto nel progetto degli esami online. Le problematiche e le sfide del progetto sono state affrontate dallo Scrum Master. Sono stati preparati i rapporti di progetto / sprint e il team ha potuto vedere i loro progressi.

Inoltre, per ogni sprint si sono svolte riunioni di pianificazione dello sprint adeguate e riunioni retrospettive dello sprint che hanno migliorato le prestazioni del team. Il team si stava concentrando solo sul lavoro e sul completamento dei compiti assegnati per quello sprint. Tutte le pulizie aggiuntive sono state gestite dallo Scrum Master.

# 4. Conversione di documenti di progetto in Product backlog:

I documenti di progetto iniziali che vengono preparati in un modello a cascata sono la specifica dei requisiti aziendali (BRS), il design di alto livello, il design funzionale, ecc. Questi documenti devono essere trasformati in un backlog del prodotto per eseguire le fasi di codifica, test e implementazione in modalità agile. Questo è un passaggio molto importante.

Il product backlog è il punto di partenza di un progetto agile. Il backlog del prodotto è un elenco prioritario di requisiti che viene mantenuto per un prodotto. Consiste di funzionalità, correzioni di bug, requisiti non funzionali, ecc. È un documento in crescita che diventa più grande e migliore in base al feedback dei clienti, ai requisiti in evoluzione, ecc.

Essendo il primo artefatto di qualsiasi progetto, è molto importante elencare i requisiti e assegnare loro le priorità. La conversione dei documenti del progetto a cascata in backlog del prodotto è un compito importante in sé e richiede il brainstorming dell'intero team insieme al cliente / stakeholder.

Una volta che tutti i requisiti sono stati elencati e concordati dal cliente, il compito successivo è stabilire le priorità per raccoglierli negli sprint.

# 5. Matrice di tracciabilità:

Un altro importante artefatto che di solito viene mantenuto nel modello a cascata è la matrice di tracciabilità. Quindi, al fine di garantire che nessun requisito venga perso; dovrebbe inoltre essere progettata e mantenuta una matrice di tracciabilità . Di solito, in Agile non è progettata alcuna matrice di questo tipo.

Questa è una best practice in qualsiasi progetto. Parallelamente al backlog del prodotto dovrebbe essere preparata una matrice di tracciabilità. E dovrebbe essere verificato rispetto ai casi di test eseguiti durante il test di accettazione dell'utente / test end-to-end (questa fase è spiegata nel punto successivo). Anche se qualche requisito viene perso, può essere facilmente incorporato anche nelle ultime fasi di sviluppo poiché agile fornisce quella flessibilità e adattabilità extra.

Dopo che il progetto di registrazione in linea è diventato attivo, gli utenti finali (studenti che volevano registrarsi) hanno avuto accesso all'applicazione. Hanno affrontato molti problemi nell'applicazione. Ciò ha comportato la raccolta di molti ticket per il team di supporto alla produzione. I ticket raccolti possono essere classificati come incidenti, problemi o modifiche. Sono stati risolti molti problemi, anticipando che l'applicazione diventerà stabile. Ma anche allora, più di una dozzina di richieste di modifica / miglioramenti sono state pianificate nelle versioni successive. Questi miglioramenti avevano lo scopo di stabilizzare l'applicazione e migliorare l'esperienza dell'utente finale.

Quindi, alla fine, il costo del progetto è aumentato di molte pieghe. Pertanto, se un progetto non viene correttamente trasferito ad agile, il budget potrebbe superare il limite. Questo è molto necessario per pianificare una transizione completa di un progetto in Agile. Inoltre, la pianificazione dovrebbe essere eseguita nella misura necessaria al progetto per essere eseguito in modalità agile. I modelli ibridi adeguati dovrebbero essere progettati per un particolare progetto.

Prima dell'inizio del progetto Exam Entry, questo aspetto era ben curato. È stato pensato un modello ibrido ed è stato deciso che la fase di analisi dei requisiti e la fase di progettazione di alto livello dovevano essere eseguite in un modello a cascata e le altre fasi in un modello agile.

Il modello ibrido adottato può essere rappresentato pittoricamente come di seguito:

Modello collaborativo (ibrido) 3

Conclusione:

È evidente che sia il modello Waterfall che il modello Agile hanno i propri svantaggi. Quindi, è abbastanza realistico optare per un modello ibrido, che è un approccio a sfruttando il meglio di entrambi i mondi.

L'aspetto più importante dell'inizio di qualsiasi progetto è decidere il modello che il team adotterà. Ciò richiede un'ampia pianificazione. Fattori come budget, tempo, utilizzo delle risorse, complessità dei requisiti, ecc. Dovrebbero essere considerati nell'adozione di un modello software.

Il modello ibrido è ancora in una fase nascente. Man mano che sempre più aziende lo adotteranno, impareremo di più su questo concetto.

Il manifesto Agile ci chiede di valorizzare:

  • Individui e interazioni su processi e strumenti
  • Software funzionante documentazione completa
  • Collaborazione con i clienti sulla negoziazione del contratto
  • Rispondere al cambiamento oltre a seguire un piano

Considerando che, il modello ibrido non aderisce a questo 100%. Suggerisce che tutti gli aspetti hanno la stessa importanza. Spetta ai clienti / project manager decidere quali aspetti valutare di più e quali aspetti senza valore.

Circa l'autore: Questo è un articolo ospite di Harshpal Singh. Ha più di 7 anni di esperienza nel manuale, database, automazione e test delle prestazioni e attualmente lavora come team lead in un'importante MNC. Ha lavorato a molti progetti di QA seguendo i modelli di sviluppo Waterfall, Agile e ibrido.

Hai esperienza lavorando su questo modello ibrido di sviluppo e test? Discutiamo nei commenti.

Lettura consigliata

^