Meny

Fallstudie: Hur man kan eliminera brister i vattenfall och smidiga utvecklingsprocesser med hjälp av en hybridmodell

  • Huvud
  • Agile Testing
  • Fallstudie: Hur man kan eliminera brister i vattenfall och smidiga utvecklingsprocesser med hjälp av en hybridmodell

case study how eliminate flaws waterfall

Prova Vårt Instrument För Att Eliminera Problem

Agile Waterfall Hybrid Model

Vattenfallsmodellen har varit det perfekta valet för mjukvaruutveckling. I den här modellen blir en idé användbar programvara i en sekventiell process som går igenom stadierna av initiering, analys, implementering, testning och underhåll.

Men vattenfallsmodellen har vissa nackdelar.

Agil mjukvaruutveckling utvecklades för att eliminera de problem som Waterfall-modellen har. Den har en helt ny ram. Medan Waterfall-modellen har en sekventiell design, följde Agile-modellen ett stegvis tillvägagångssätt.

När kunder som brukade följa Waterfall-modellen bytte till Agile, medförde övergången många problem med den. Anledningen var otillgänglighet till ett annat tillvägagångssätt för programutveckling. Slutprodukten visade sig vara en katastrof.

Agile Waterfall Hybrid Model

gratis programvara för att rippa DVD till MP4

En ny metodik har således utvecklats, som kan kallas en ”hybrid”, för att säkerställa en robust slutprodukt genom att välja fördelarna med både Agile- och Waterfall-modeller.

Låt oss först veta om utvecklingsmodellerna Waterfall och Agile och gå sedan vidare till 'Agile Waterfall Hybrid Model' med fördelar och nackdelar med var och en.

Vad du kommer att lära dig:

Vattenfallsmodell

Vattenfallsmodellen är ett tillvägagångssätt för att utveckla programvara som delar upp ett projekt i slutliga faser. Man bör bara gå till nästa fas när föregående fas granskas och verifieras.

I vattenfallsmodellen överlappar inte faserna.

=> Läs mer om vattenfallsmodellen här.

Figur 1 visar vattenfallsmodellen:

Vattenfall modell

Fördelar med vattenfallsmodellen:

  • Enkelt och lätt att förstå och använda.
  • Styv modell - Varje fas har specifika leveranser och granskningsprocesser.
  • Dokumentation och artefakter underhålls noggrant.
  • Lämplig för projekt där kraven är väl insatta.

Nackdelar med vattenfallsmodellen:

  • Inte lämpligt för projekt där kraven riskerar att förändras.
  • Kostnaden för att åtgärda defekter är mycket hög när den upptäcks i ett senare skede.
  • Inte en bra modell för komplexa och långa projekt.
  • Ingen fungerande programvara produceras förrän sent under livscykeln.

Agil modell

Wikipedia definierar den agila modellen som 'en grupp av programvaruutvecklingsmetoder baserade på iterativ och inkrementell utveckling, där krav och lösningar utvecklas genom samarbete mellan självorganiserande, tvärfunktionella team.'

Modellen har sina egna principer som tenderar att föra processerna till baksätet.

=> Läs fler artiklar om Agile-metodik här.

(Klicka på bilden för att se förstorad)

Smidig modell

Fördelar med Agile-modellen:

  • Kundengagemang i processen.
  • Hög avkastning som arbetsprogram levereras ofta.
  • Även sena ändringar av kraven kan lätt tillgodoses.
  • Ständig förbättring av både produkt och process.

Nackdelar med den smidiga modellen:

  • Brist på betoning på design och dokumentation.
  • Teamet ska vara stabilt och skickligt.

Samarbetsmodell (hybrid)

Collaborative Model syftar till att kombinera båda modellerna - Waterfall och Agile. Genom att utnyttja både vattenfallet och den agila metoden säkerställs projektets framgång. Det tar bort nackdelarna med båda modellerna; samtidigt som man samlar fördelarna med båda.

Samarbetsmodellen kan implementeras i ett projekt genom att utföra:

Samarbetsmodell (hybrid)

Så samarbetsmodellen kan representeras diagrammatiskt enligt nedan:

Collaborative (Hybrid) Model 2

Fördelar med hybridmodellen

  • Kombinerar fördelarna med både Agile och Waterfall-processer.
  • Högnivådesign är beredd att tillämpa vattenfallsprinciper.
  • Kodning och testning görs med hjälp av smidig metodik.

Agile Waterfall Hybrid Model - Lär dig genom exempel -En fallstudie

Mjukvaruföretaget ABC Software Service tillhandahåller tjänster till en klient, ett universitet som heter 'XYZ University' för att utveckla, testa och underhålla sin programvara (live produktionssupport).

Huvudfunktionerna i kontot är:

  1. ABC Software Services måste uppgradera applikationerna från XYZ University. Databasen måste uppgraderas och alla applikationer måste utvecklas till den senaste tekniken som finns på marknaden.
  2. Hittills har alla projekt som hanterats av ABC Software utförts i Waterfall-modellen.
  3. Två av de tunga trafikapplikationerna och högprioriterade applikationerna planerades nu att utvecklas om. Den första är ”Online-registreringar”, den andra är ”Online-undersökningar”.
  4. Klient XYZ University ville nu att dessa applikationer skulle arbetas med Agile-modellen för mjukvaruutveckling.

Det första projektet i en Agile-modell för ABC Software var online-registreringar. Efter genomförandet av detta projekt insåg man i en serie retrospektiv att det fanns många brister i de processer som följde.

Dessa brister sköts under genomförandet av det andra projektet ”online-undersökningar” och det genomfördes därför i hybridmodell.

Hur man eliminerar brister i vattenfall och smidiga utvecklingsprocesser med hjälp av en hybridmodell:

Låt oss diskutera dessa i detalj en efter en.

# 1. Ingen dokumentation:

En av de smidiga principerna i det agila manifestet säger att: Agile ger mer värde till ”Working Software over Comprehensive Documentation”. Agil metodik anser att dokumentation bör vara ”bara knappt tillräckligt bra”, och mer tonvikt läggs på att skicka ut en fungerande programvara. Inte mycket ansträngningar görs för dokumentation, men för konton som XYZ University, med ett dedikerat supportteam för att arbeta med defekter som finns i live-projekt, kan denna vana visa sig vara ett hinder om vi analyserar det på lång sikt.

Under årens lopp, när projekt genomfördes i Waterfall-modellen, underhålls och uppdateras dokument så att supportteamet förstår och arbetar därefter. Lösningsdesign, teknisk design, genomgångsdokument etc. var några av de dokument som utarbetades. När projektet var över övergick detsamma till supportteamet.

Men när det gäller projektet ”online-registreringar” utarbetades inga sådana dokument och det visade sig vara kostsamt. När projektet gick i live samlades många biljetter av slutanvändare och supportteamet hade ingen aning om hur man skulle arbeta med dem. Teamet hade inget dokument att referera till.

Detta var en stor lärdom och för nästa projekt skrivs och överfördes dokument online-undersökningar effektivt.

=> Läs mer här varför dokumentation är viktig.

#två. Ingen UAT / End-to-end-testning:

I det smidiga läget för mjukvaruutveckling får testare byggnaderna för att testa i steg. Dessa byggnader fortsätter att integreras tills den slutliga byggnaden är helt byggd. Testare testar kraven som täcks i varje sprint och fortsätter att göra regressionstest av byggnaden som fortsätter att lägga upp.

Men efter att alla sprintarna är klara och den slutliga byggnaden är klar och allt integrerat, bör testaren testa hela systemet och bör utföra test från slut till slut. Detta bör göras i en helt ny miljö.

=> Testa slutet på slutet på ett live-projekt.

Detta har sina egna fördelar:

  • Hela systemet distribueras till en ny miljö och testaren testar hela flödet.
  • Det bygger förtroende för att i slutändan måste byggnaden distribueras som en helhet i en levande miljö.

När onlineregistreringsprojektet testades gjordes det i testmiljön. Efter systemtestning och omprövning av alla defekter förklarades det för avloggning. Helst befordrades inte detta till en annan miljö för en ny cykeltest av systemtestning. (Helst, UAT händer efter systemtestning , men i det här fallet var UAT-teammedlemmar inblandade i den första testcykeln så ingen andra cykel var planerad)

När online-undersökningsprojektet startade genomfördes SIT (System Integration Testing) och koden befordrades till en UAT-miljö där den andra testcykeln gjordes. Resultat: Alla högprioriterade fel upptäcktes och löstes. Bygget var stabilt före lanseringen.

# 3. Ingen Scrum Master:

De Scrum Master är ansvarig för att ett team lever efter Scrums värderingar och praxis. Scrum Master betraktas som en tränare för laget genom att hjälpa laget att göra det bästa arbete som möjligt. Scrum Master kan också betraktas som en processägare för laget.

Online-registreringsteamet bildades utan Scrum Master. Vikten av att ha en dedikerad Scrum Master ansågs inte vara viktig. Det resulterade i att många frågor inte löstes i tid och i sin tur korsade tiden för att avsluta projektet ofta deadline.

En dedikerad Scrum Master var dock involverad i projektet Online Examinations. Projektfrågorna och utmaningarna sköts av Scrum Master. Projekt- / sprintrapporterna utarbetades och teamet kunde se deras framsteg.

Korrekt sprintplaneringsmöten och sprint retrospektiva möten ägde också rum för varje sprint som förbättrade teamets prestationer. Teamet koncentrerade sig bara på sitt arbete och slutförde sina uppgifter för den sprinten. All ytterligare städning hanterades av Scrum Master.

# 4. Konvertera projektdokument till produktstocken:

De ursprungliga projektdokumenten som är beredda i en vattenfallsmodell är Business kravspecifikation (BRS), högnivådesign, funktionell design etc. Dessa dokument behöver omvandlas till en produktstock för att kunna utföra kodnings-, test- och implementeringsstadierna i smidigt läge. Detta är ett mycket viktigt steg.

Produktstocken är utgångspunkten för ett smidigt projekt. Produktstocken är en prioriterad lista över krav som upprätthålls för en produkt. Den består av funktioner, buggfixar, icke-funktionella krav etc. Det är ett växande dokument som blir större och bättre baserat på kundfeedback, förändrade krav etc.

Eftersom det är den första artefakten i något projekt är det viktigast att lista upp kraven och prioritera dem. Omvandlingen av vattenfallsprojektdokument till produktbacklogg är en stor uppgift i sig och kräver brainstorming av hela teamet tillsammans med kunden / intressenten.

När alla krav listats och godkänts av kunden är nästa uppgift att prioritera dem för att plocka upp dem i sprints.

# 5. Spårbarhetsmatris:

En annan viktig artefakt som vanligtvis upprätthålls i vattenfallsmodellen är spårbarhetsmatris. Så för att säkerställa att inga krav missas; en spårbarhetsmatris bör också utformas och underhållas . I smidig design är vanligtvis ingen sådan matris utformad.

Detta är en bästa praxis i alla projekt. En spårbarhetsmatris bör framställas parallellt med produktens eftersläpning. Och det bör kontrolleras mot testfall som utförs under testning av användaraccept / slut-till-slut-test (detta steg förklaras i min nästa punkt). Även om något krav missas kan det enkelt införlivas även i de sena utvecklingsstadierna, eftersom smidig ger extra flexibilitet och anpassningsförmåga.

Efter att onlineregistreringsprojektet gick live, fick applikationen tillgång till slutanvändarna (studenter som ville registrera sig). De stod inför många problem i applikationen. Detta resulterade i att många biljetter togs upp till produktionsstödteamet. Biljetter som samlas in kan klassificeras som incidenter, problem eller förändringar. Många problem löstes och förväntade sig att applikationen skulle bli stabil. Men även då planerades mer än ett dussin ändringsförfrågningar / förbättringar i de efterföljande utgåvorna. Dessa förbättringar var avsedda att stabilisera applikationen och förbättra upplevelsen för slutanvändaren.

Så i slutändan sköt projektets kostnad upp många gånger. Därför, om ett projekt inte övergår ordentligt till smidigt, kan det få budgeten att överskridas. Detta är mycket nödvändigt för att planera en grundlig övergång av ett projekt till Agile. Dessutom bör planering göras i den utsträckning projektet behöver för att kunna genomföras i smidigt läge. Korrekt hybridmodell bör utformas för ett visst projekt.

Innan projektet för examensinträde startade var denna aspekt väl omhändertagen. Man tänkte på en hybridmodell och det beslutades att kravanalysfasen och designnivån på hög nivå skulle genomföras i vattenfallsmodellen och resten av stegen i en smidig modell.

Den hybridmodell som antagits kan visas i bild enligt nedan:

Collaborative (Hybrid) Model 3

Slutsats:

Det är uppenbart att både vattenfallsmodellen och Agile-modellen har sina egna nackdelar. Så det är ganska realistiskt att välja en hybridmodell, vilket är ett tillvägagångssätt för utnyttja det bästa från två världar.

Den viktigaste aspekten av varje projekts start är att bestämma vilken modell teamet ska anta. Detta kräver omfattande planering. Faktorer som budget, tid, resursutnyttjande, kraven på komplexitet etc. bör beaktas vid antagandet av en programvarumodell.

Hybridmodellen är fortfarande i ett växande skede. Eftersom fler och fler företag kommer att anta det kommer vi att lära oss mer om detta koncept.

Agile-manifestet ber oss värdera:

vilken musiknedladdare är bäst
  • Individer och interaktioner över processer och verktyg
  • Arbetsprogramvara över omfattande dokumentation
  • Kundsamarbete över kontraktsförhandlingar
  • Svarar på förändring över att följa en plan

Medan hybridmodellen inte följer detta 100%. Det antyder att alla aspekter är lika viktiga. Det är upp till kunderna / projektledarna att bestämma vilka aspekter som ska värderas mer och vilka aspekter som är värdelösa.

Om författaren: Detta är en gästartikel av Harshpal Singh. Han har 7+ års erfarenhet av manuell, databas, automatisering och prestandatestning och arbetar för närvarande som teamledare i ett ledande MNC. Han har arbetat med många QA-projekt efter modellerna Waterfall, Agile och hybrid.

Har du någon erfarenhet av att arbeta med denna hybridutvecklings- och testmodell? Låt oss diskutera i kommentarer.

Rekommenderad läsning

^