Menu

Casestudie: Sådan fjernes fejl i vandfald og smidige udviklingsprocesser ved hjælp af en hybrid model

  • Vigtigste
  • Agil Test
  • Casestudie: Sådan fjernes fejl i vandfald og smidige udviklingsprocesser ved hjælp af en hybrid model

case study how eliminate flaws waterfall

Prøv Vores Instrument Til At Fjerne Problemer

Agile Waterfall Hybrid Model

Vandfaldsmodellen har været det ideelle valg til softwareudvikling. I denne model bliver en idé brugbar software i en sekventiel proces, der kaskader gennem stadierne af initiering, analyse, implementering, test og vedligeholdelse.

Men Waterfall-modellen har nogle ulemper.

Agil softwareudvikling udviklede sig for at eliminere de problemer, som Waterfall-modellen har. Det har en helt ny ramme. Mens vandfaldsmodellen har et sekventielt design, fulgte Agile-modellen en inkrementel tilgang.

Når klienter, der plejede at følge Waterfall-modellen, skiftede til Agile, medførte overgangen mange problemer med det. Årsagen er manglende tilpasning til en anden tilgang til softwareudvikling. Slutproduktet viste sig at være en katastrofe.

Agile Waterfall Hybrid Model

En ny metode har således udviklet sig, der kan kaldes en 'hybrid', for at sikre et robust slutprodukt ved at vælge fordelene ved både Agile og Waterfall-modeller.

Lad os først vide om Waterfall and Agile-udviklingsmodellerne og derefter gå videre til 'Agile Waterfall Hybrid Model' med fordele og ulemper ved hver.

Hvad du lærer:

Vandfaldsmodel

Waterfall-modellen er en tilgang til udvikling af software, der opdeler et projekt i endelige faser. Man skal kun gå til den næste fase, når den foregående fase gennemgås og verificeres.

I vandfaldsmodellen overlapper faser ikke.

=> Læs mere om vandfaldsmodellen her.

Figur 1 viser vandfaldsmodellen:

Vandfaldsmodel

Fordele ved vandfaldsmodellen:

  • Enkel og let at forstå og bruge.
  • Stiv model - Hver fase har specifikke leverancer og gennemgangsprocesser.
  • Dokumentation og artefakter vedligeholdes omhyggeligt.
  • Velegnet til projekter, hvor kravene er godt forstået.

Ulemper ved vandfaldsmodellen:

  • Ikke egnet til projekter, hvor kravene er i fare for at ændre sig.
  • Omkostningerne ved afhjælpning af mangler er meget høje, når de opdages på et senere tidspunkt.
  • Ikke en god model til komplekse og lange projekter.
  • Der produceres ingen fungerende software før sent i livscyklussen.

Adræt model

Wikipedia definerer Agile Model som 'en gruppe af softwareudviklingsmetoder baseret på iterativ og inkrementel udvikling, hvor krav og løsninger udvikler sig gennem samarbejde mellem selvorganiserende, tværfunktionelle teams.'

Modellen har sine egne principper, der har tendens til at bringe processerne til bagsædet.

=> Læs flere artikler om Agile metodologi her.

(Klik på billedet for at se det forstørret)

Adræt model

Fordele ved den agile model:

  • Kundeinddragelse i processen.
  • Høj ROI som arbejdssoftware leveres ofte.
  • Selv sene ændringer i kravene kan let imødekommes.
  • Kontinuerlig forbedring af både produkt og proces.

Ulemper ved den agile model:

  • Manglende vægt på design og dokumentation.
  • Holdet skal være stabilt og dygtigt.

Samarbejdsmodel (hybrid)

Collaborative Model sigter mod at kombinere begge modeller - Waterfall og Agile. Udnyttelse af både vandfalds- og agil-tilgangen sikrer projektets succes. Det fjerner ulemperne ved begge modeller; samtidig samler fordelene ved begge dele.

Den samarbejdsmodel kan implementeres i et projekt ved at udføre:

Samarbejdsmodel (hybrid)

Så den samarbejdsmodel kan repræsenteres diagrammatisk som nedenfor:

Collaborative (Hybrid) Model 2

Fordele ved hybridmodellen

  • Kombinerer fordelene ved både Agile og Waterfall-processer.
  • Design på højt niveau er forberedt på at anvende vandfaldsprincipper.
  • Kodning og test udføres ved hjælp af agil metode.

Agile Waterfall Hybrid Model - Lær ved eksempel -En casestudie

Softwarefirmaet 'ABC Software Service's leverer tjenester til en klient, et universitet ved navn' XYZ University 'til at udvikle, teste og vedligeholde deres software (live produktionssupport).

Hovedfunktionerne på kontoen er:

  1. ABC Software Services skal opgradere applikationerne fra XYZ University. Databasen skal opgraderes, og alle applikationer skal genudvikles til den nyeste tilgængelige teknologi på markedet.
  2. Indtil nu blev alle de projekter, der blev håndteret af ABC Software, udført i Waterfall-modellen.
  3. To af tunge trafikapplikationer og højt prioriterede applikationer var nu planlagt til at blive genudviklet. Den første er 'Online tilmeldinger', den anden er 'Online undersøgelser'.
  4. Client XYZ University ønskede nu, at disse applikationer skulle arbejdes med Agile-modellen til softwareudvikling.

Det første projekt i en Agile-model til ABC Software var Online-registreringer. Efter gennemførelsen af ​​dette projekt blev det i en række retrospektiver indset, at der var mange mangler i de fulgte processer.

Disse fejl blev taget hånd om under udførelsen af ​​det andet projekt 'onlineundersøgelser', og det blev derfor udført i hybridmodel.

hvad er systemtest med eksempel

Sådan fjernes fejl i vandfald og smidige udviklingsprocesser ved hjælp af en hybrid model:

Lad os diskutere disse detaljeret en efter en.

# 1. Ingen dokumentation:

Et af de agile principper i det agile manifest siger, at: Agile giver mere værdi til 'Working Software over Comprehensive Documentation'. Agil metode mener, at dokumentation skal være 'lige næppe god nok', og der lægges mere vægt på at sende en fungerende software. Der gøres ikke meget arbejde med dokumentation, men for konti som XYZ University med et dedikeret supportteam til at arbejde på mangler, der findes på live-projekter, kan denne vane vise sig at være en hindring, hvis vi analyserer det på lang sigt.

I årenes løb, da projekter blev udført i Waterfall-modellen, blev dokumenter vedligeholdt og opdateret, så supportteamet kunne forstå og arbejde i overensstemmelse hermed. Løsningsdesign, teknisk design, gennemgangsdokumenter osv. Var nogle af de dokumenter, der blev udarbejdet. Efter projektets afslutning blev det samme overført til supportteamet.

Men i tilfælde af 'online tilmeldinger'-projektet blev der ikke udarbejdet sådanne dokumenter, og det viste sig at være dyrt. Da projektet gik live, blev mange billetter rejst af slutbrugerne, og supportteamet havde ingen anelse om, hvordan de kunne arbejde med dem. Holdet havde intet dokument at henvise til.

Dette var en stor lektion, og til det næste projekt blev 'online-undersøgelser' dokumenter skrevet og overført effektivt.

=> Læs mere her, hvorfor dokumentation er vigtig.

#to. Ingen UAT / End-to-end test:

I Agile-tilstanden til softwareudvikling får testere builds til at teste i trin. Disse builds fortsætter med at integreres, indtil den endelige build er helt bygget. Testere tester kravene, der er dækket af hver sprint, og fortsætter med at lave regressionstest af det build, der fortsætter med at tilføje.

Men efter at alle sprints er færdige, og den endelige build er klar og integreret, skal testeren teste det komplette system og udføre end-to-end-test. Dette skal ske i et helt nyt miljø.

=> Test til ende til slut på et live projekt.

Dette har sine egne fordele:

  • Det komplette system implementeres i et nyt miljø, og testeren tester det komplette flow.
  • Det bygger tillid, fordi bygningen i sidste ende skal implementeres som en helhed i et levende miljø.

Da projektet Onlineregistreringer blev testet, blev det udført i testmiljøet. Efter systemtest og gentest af alle mangler blev det erklæret til afmelding. Ideelt set blev dette ikke forfremmet til et andet miljø til endnu en cyklus af systemtest. (Ideelt set UAT sker efter systemtest , men i dette tilfælde var UAT-teammedlemmer involveret i den første testcyklus, så ingen anden cyklus var planlagt)

Da onlineundersøgelsesprojektet startede, blev SIT (System Integration Testing) udført, og koden blev forfremmet til et UAT-miljø, hvor den anden testcyklus blev udført. Resultat: Alle højprioritetsfejl blev fanget og løst. Bygningen var stabil før go-live-udgivelsen.

# 3. Ingen Scrum Master:

Det Scrum Master er ansvarlig for at sikre, at et team lever efter Scrums værdier og praksis. Scrum Master betragtes som en træner for holdet ved at hjælpe holdet med at gøre det bedste arbejde, det overhovedet kan. Scrum Master kan også betragtes som en procesindehaver til holdet.

Online tilmeldingsteam blev dannet uden en Scrum Master. Vigtigheden af ​​at have en dedikeret Scrum Master blev ikke anset for vigtig. Det resulterede i, at mange problemer ikke blev løst til tiden, og tid til at afslutte projektet krydsede ofte deadline.

Imidlertid var en dedikeret Scrum Master involveret i projektet Online-eksamen. Projektets problemer og udfordringer blev taget hånd om af Scrum Master. Projekt- / sprintrapporterne blev udarbejdet, og holdet kunne se deres fremskridt.

Der fandt også passende sprintplanlægningsmøder og sprint retrospektive møder sted for hver sprint, der forbedrede holdets ydeevne. Holdet koncentrerede sig kun om deres arbejde og afsluttede deres opgaver til den sprint. Al ekstra husholdning blev håndteret af Scrum Master.

# 4. Konvertering af projektdokumenter til produktforsinkelsen:

De indledende projektdokumenter, der udarbejdes i en vandfaldsmodel, er Business kravspecifikation (BRS), design på højt niveau, funktionelt design osv. Disse dokumenter skal omdannes til et produktforsinkelse for at udføre kodning, test og implementering i smidig tilstand. Dette er et meget vigtigt skridt.

Produktet bagud er udgangspunktet for et smidigt projekt. Produktet bagud er en prioriteret liste over krav, der opretholdes for et produkt. Det består af funktioner, fejlrettelser, ikke-funktionelle krav osv. Det er et voksende dokument, der bliver større og bedre baseret på kundefeedback, skiftende krav osv.

At være den første artefakt af ethvert projekt, er det vigtigst at angive kravene og prioritere dem. Konvertering af vandfaldsprojektdokumenter til produktforsinkelse er en stor opgave i sig selv og kræver brainstorming af hele teamet sammen med kunden / interessenten.

Når alle kravene er opført og aftalt af kunden, er den næste opgave at prioritere dem for at samle dem op i sprints.

# 5. Sporbarhedsmatrix:

En anden vigtig artefakt, der normalt opretholdes i vandfaldsmodellen, er sporbarhedsmatrix. Så for at sikre, at ingen krav går glip af; en sporbarhedsmatrix skal også designes og vedligeholdes . Normalt i agil er ingen sådan matrix designet.

core java interview spørgsmål og svar til nybegynderne

Dette er en bedste praksis i ethvert projekt. En sporbarhedsmatrix skal udarbejdes parallelt med produktets efterslæb. Og det skal kontrolleres mod de testsager, der er udført under test af brugeraccept / test til ende (dette trin forklares i mit næste punkt). Selvom ethvert krav går glip af, kan det let inkorporeres selv i de sene stadier af udviklingen, da agil giver den ekstra fleksibilitet og tilpasningsevne.

Efter at online-tilmeldingsprojektet var gået live, blev slutbrugerne (studerende, der ønskede at tilmelde sig) adgang til applikationen. De stod over for mange problemer i applikationen. Dette resulterede i en masse billetter rejst til produktionsstøtteteamet. Billetter, der er rejst, kan klassificeres som hændelser, problemer eller ændringer. Mange problemer blev løst, idet applikationen forventes at blive stabil. Men selv da var mere end et dusin ændringsanmodninger / forbedringer planlagt i de efterfølgende udgivelser. Disse forbedringer var beregnet til at stabilisere applikationen og forbedre slutbrugeroplevelsen.

Så i sidste ende skød omkostningerne ved projektet op med mange folder. Derfor, hvis et projekt ikke overføres ordentligt til smidigt, kan det medføre, at budgettet overskrides. Dette er meget nødvendigt for at planlægge en grundig overgang af et projekt til Agile. Der skal også planlægges i det omfang projektet har brug for for at blive udført i agil tilstand. Korrekte hybridmodeller skal designes til et bestemt projekt.

Før starten af ​​projektet til eksamensindgang blev dette aspekt passet godt på. Man tænkte på en hybridmodel, og det blev besluttet, at kravanalysefasen og designfasen på højt niveau skulle udføres i vandfaldsmodellen og resten af ​​trinene i en smidig model.

Den vedtagne hybridmodel kan repræsenteres som vist nedenfor:

Collaborative (Hybrid) Model 3

Konklusion:

Det er tydeligt, at både Waterfall-modellen og Agile-modellen har sine egne ulemper. Så det er ret realistisk at vælge en hybridmodel, som er en tilgang til udnytte det bedste fra begge verdener.

Det vigtigste aspekt ved starten af ​​ethvert projekt er at beslutte den model, som holdet skal vedtage. Dette kræver omfattende planlægning. Faktorer som budget, tid, ressourceudnyttelse, kompleksitet af krav osv. Bør overvejes i vedtagelsen af ​​en softwaremodel.

Hybrid-modellen er stadig i en begyndende fase. Da flere og flere virksomheder vil vedtage det, vil vi lære mere om dette koncept.

Agile manifestet beder os om at værdsætte:

  • Enkeltpersoner og interaktioner over processer og værktøjer
  • Arbejdssoftware over omfattende dokumentation
  • Kundesamarbejde over kontraktforhandling
  • Svar på ændringer over at følge en plan

Mens hybridmodellen ikke overholder denne 100%. Det antyder, at alle aspekter er lige vigtige. Det er op til klienter / projektledere at beslutte, hvilke aspekter der skal værdsættes mere og hvilke aspekter, der er værdiløse.

Om forfatteren: Dette er en gæsteartikel af Harshpal Singh. Han har mere end 7 års erfaring med manuel, database, automatisering og performance-test og arbejder i øjeblikket som teamleder i et førende MNC. Han har arbejdet på mange QA-projekter efter modellerne Waterfall, Agile og hybrid.

Har du nogen erfaring med at arbejde med denne hybrid udviklings- og testmodel? Lad os diskutere i kommentarer.

Anbefalet læsning

^