Meny

Casestudie: Hvordan eliminere feil ved fossefall og smidige utviklingsprosesser ved hjelp av en hybrid modell

  • Hoved
  • Agile Testing
  • Casestudie: Hvordan eliminere feil ved fossefall og smidige utviklingsprosesser ved hjelp av en hybrid modell

case study how eliminate flaws waterfall

Prøv Instrumentet Vårt For Å Eliminere Problemer

applikasjoner av java i den virkelige verden

Agile Waterfall Hybrid Model

Waterfall Model har vært det ideelle valget for programvareutvikling. I denne modellen blir en idé brukbar programvare i en sekvensiell prosess som faller gjennom stadiene av initiering, analyse, implementering, testing og vedlikehold.

Men Waterfall-modellen har noen ulemper.

Agil programvareutvikling utviklet seg for å eliminere problemene Waterfall-modellen har. Den har et helt nytt rammeverk. Mens Waterfall-modellen har en sekvensiell design, fulgte Agile-modellen en trinnvis tilnærming.

Når kunder som pleide å følge Waterfall-modellen byttet til Agile, førte overgangen til mange problemer. Årsaken er utilpassbarhet til en annen tilnærming til programvareutvikling. Sluttproduktet viste seg å være en katastrofe.

Agile Waterfall Hybrid Model

En ny metodikk har dermed utviklet seg, som kan kalles en ‘Hybrid’, for å sikre et robust sluttprodukt ved å velge proffene til både Agile og Waterfall-modeller.

La oss først vite om fossefall og smidig utviklingsmodeller, og deretter gå videre til 'Agile Waterfall Hybrid Model' med fordeler og ulemper med hver.

Hva du vil lære:

Fossmodell

Waterfall-modellen er en tilnærming for utvikling av programvare som deler et prosjekt i endelige faser. Man bør bare gå til neste fase når den forrige fasen blir gjennomgått og verifisert.

I fossemodellen overlapper ikke faser.

=> Les mer om fossemodellen her.

Figur 1 viser fossefallmodellen:

Fossmodell

Fordeler med fossemodellen:

  • Enkelt og lett å forstå og bruke.
  • Stiv modell - Hver fase har spesifikke leveranser og gjennomgangsprosesser.
  • Dokumentasjon og gjenstander vedlikeholdes nøye.
  • Egnet for prosjekter der kravene er godt forstått.

Ulemper med fossefallmodellen:

  • Ikke egnet for prosjekter der kravene er i fare for endring.
  • Kostnadene ved å fikse feil er veldig høye når de oppdages på et senere tidspunkt.
  • Ikke en god modell for komplekse og lange prosjekter.
  • Ingen fungerende programvare produseres før sent i løpet av livssyklusen.

Agil modell

Wikipedia definerer Agile Model som 'en gruppe programvareutviklingsmetoder basert på iterativ og inkrementell utvikling, der krav og løsninger utvikler seg gjennom samarbeid mellom selvorganiserende, tverrfunksjonelle team.'

Modellen har sine egne prinsipper som har en tendens til å bringe prosessene til baksetet.

=> Les flere artikler om Agile metodikk her.

(Klikk på bildet for å se forstørret)

Agil modell

Fordeler med Agile-modellen:

  • Kundens involvering i prosessen.
  • Høy avkastning som arbeidsprogramvare leveres ofte.
  • Selv sene endringer i kravene kan lett imøtekommes.
  • Kontinuerlig forbedring av både produkt og prosess.

Ulemper med den smidige modellen:

  • Mangel på vekt på design og dokumentasjon.
  • Teamet skal være stabilt og dyktig.

Samarbeidsmodell (hybrid)

Collaborative Model har som mål å kombinere begge modellene - Waterfall og Agile. Utnyttelse av både fossefall og smidig tilnærming sikrer prosjektets suksess. Det fjerner ulempene med begge modellene; mens du samler fordelene med begge deler.

Samarbeidsmodellen kan implementeres i et prosjekt ved å utføre:

Samarbeidsmodell (hybrid)

Så samarbeidsmodellen kan presenteres diagrammatisk som nedenfor:

Samarbeidsmodell (hybrid) 2

Fordeler med Hybrid-modellen

  • Kombinerer fordelene med både Agile og Waterfall-prosesser.
  • Design på høyt nivå er forberedt på å anvende fossefallprinsipper.
  • Koding og testing gjøres ved hjelp av smidig metodikk.

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

Programvarefirmaet ‘ABC Software Service’s leverer tjenester til en klient, et universitet som heter‘ XYZ University ’for å utvikle, teste og vedlikeholde programvaren (live produksjonssupport).

Hovedtrekkene i kontoen er:

  1. ABC Software Services må oppgradere applikasjonene til XYZ University. Databasen må oppgraderes, og alle applikasjoner må utvikles på nytt til den nyeste teknologien som er tilgjengelig i markedet.
  2. Inntil nå ble alle prosjektene håndtert av ABC Software utført i Waterfall-modellen.
  3. To av applikasjonene med tung trafikk og høy prioritet var nå planlagt å bli reutviklet. Den første er ‘Online registreringer’, den andre er ‘Online undersøkelser’.
  4. Klient XYZ University ønsket nå at disse applikasjonene skulle jobbes med Agile-modellen for programvareutvikling.

Det første prosjektet i en smidig modell for ABC Software var Online-registreringer. Etter gjennomføringen av dette prosjektet ble det innsett i en serie med tilbakeblikk at det var mange feil i prosessene som fulgte.

Disse feilene ble ivaretatt under utførelsen av det andre prosjektet ‘online undersøkelser’, og det ble derfor utført i hybridmodell.

Hvordan eliminere feil ved fossefall og smidige utviklingsprosesser ved hjelp av en hybridmodell:

La oss diskutere disse i detalj en etter en.

#1. Ingen dokumentasjon:

Et av de smidige prinsippene i det smidige manifestet sier at: Agile gir mer verdi til ‘Working Software over Comprehensive Documentation’. Agile metodikk mener at dokumentasjon burde være 'bare knapt god nok', og det legges mer vekt på å sende ut en fungerende programvare. Det gjøres ikke mye innsats for dokumentasjon, men for kontoer som XYZ University, med et dedikert supportteam for å jobbe med mangler som finnes på live-prosjekter, kan denne vanen vise seg å være en hindring hvis vi analyserer det på lang sikt.

I løpet av årene, da prosjekter ble utført i Waterfall-modellen, ble dokumenter vedlikeholdt og oppdatert for at supportteamet skal forstå og jobbe deretter. Løsningsdesign, teknisk design, gjennomgangsdokumenter osv. Var noen av dokumentene som ble utarbeidet. Etter at prosjektet var over ble det samme overført til supportteamet.

Men i tilfelle prosjektet ‘online registrations’ ble ingen slike dokumenter utarbeidet, og det viste seg å være kostbart. Da prosjektet gikk i live, ble mange billetter samlet inn av sluttbrukere, og supportteamet hadde ingen anelse om hvordan de skulle jobbe med dem. Teamet hadde ikke noe dokument å referere til.

Dette var en stor lærdom og for det neste prosjektet ble dokumentene på nettet undersøkt og skrevet effektivt.

=> Les mer her hvorfor dokumentasjon er viktig.

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

I den smidige modusen for programvareutvikling får testere byggingen til å teste i trinn. Disse byggene fortsetter å integreres til den endelige bygningen er fullstendig bygget. Testere tester kravene som dekkes i hver sprint og fortsetter å gjøre regresjonstesting av bygningen som fortsetter å legge seg.

Men etter at alle sprintene er fullført og den endelige bygningen er klar og integrert, bør testeren teste hele systemet og utføre end-to-end-testing. Dette bør gjøres i et helt nytt miljø.

=> Test til slutt til slutt på et live-prosjekt.

Dette har sine egne fordeler:

  • Hele systemet distribueres til et nytt miljø, og testeren tester hele flyten.
  • Det bygger selvtillit fordi til slutt må bygningen distribueres som en helhet i et levende miljø.

Da Online Registrations-prosjektet ble testet, ble det gjort i testmiljøet. Etter systemtesting og omprøving av alle mangler ble den erklært for avlogging. Ideelt sett ble dette ikke promotert til et annet miljø for en ny syklus med systemtesting. (Ideelt sett, UAT skjer etter systemtesting , men i dette tilfellet var UAT-teammedlemmer involvert i den første testsyklusen, så ingen andre syklus var planlagt)

Da online-undersøkelsesprosjektet startet, ble SIT (System Integration Testing) gjort og koden ble promotert til et UAT-miljø der den andre testsyklusen ble gjort. Resultat: Alle mangler med høy prioritet ble fanget opp og løst. Bygget var stabilt før go-live-utgivelsen.

# 3. Ingen Scrum Master:

De Scrum Master er ansvarlig for at teamet lever etter Scrums verdier og praksis. Scrum Master regnes som en trener for laget ved å hjelpe teamet til å gjøre det beste arbeidet det muligens kan. Scrum Master kan også betraktes som en prosessinnehaver for laget.

Registreringsteamet på nettet ble dannet uten en Scrum Master. Viktigheten av å ha en dedikert Scrum Master ble ikke ansett som viktig. Det resulterte i at mange problemer ikke ble løst i tide, og i sin tur krysset tiden for å fullføre prosjektet ofte fristen.

Imidlertid var en dedikert Scrum Master involvert i Online Examinations-prosjektet. Prosjektets spørsmål og utfordringer ble ivaretatt av Scrum Master. Prosjekt- / sprintrapportene ble utarbeidet og teamet kunne se fremdriften deres.

Det fantes også skikkelige sprintplanleggingsmøter og sprint retrospektive møter for hver sprint som forbedret teamets ytelse. Teamet konsentrerte seg bare om arbeidet sitt og fullførte oppgavene som ble tildelt den sprinten. All ekstra rengjøring ble håndtert av Scrum Master.

# 4. Konvertering av prosjektdokumenter til produktets etterspørsel:

De første prosjektdokumentene som er utarbeidet i en fossemodell er spesifikasjoner for forretningskrav (BRS), høyt nivå design, funksjonell design osv. Disse dokumentene må transformeres til et produktetterslep for å kunne utføre kodings-, test- og implementeringsstadiene i smidig modus. Dette er et veldig viktig skritt.

Produktet etterslep er utgangspunktet for et smidig prosjekt. Produktet etterslep er en prioritert liste over krav som opprettholdes for et produkt. Den består av funksjoner, feilrettinger, ikke-funksjonelle krav osv. Det er et voksende dokument som blir større og bedre basert på tilbakemeldinger fra kunder, endrede krav osv.

Som den første gjenstanden for ethvert prosjekt, er det viktigst å liste opp kravene og tildele dem prioriteringer. Konvertering av fosseprosjektdokumenter til produktetterslep er en stor oppgave i seg selv og krever idédugnad av hele teamet sammen med kunden / interessenten.

Når alle kravene er oppført og avtalt av kunden, er neste oppgave å prioritere dem for å plukke dem opp i sprints.

# 5. Sporbarhetsmatrise:

En annen viktig gjenstand som vanligvis opprettholdes i fossemodellen er sporbarhetsmatrise. Så for å sikre at ingen krav blir savnet; en sporbarhetsmatrise bør også utformes og vedlikeholdes . Vanligvis, i smidig, er ingen slik matrise designet.

Dette er en god praksis i ethvert prosjekt. En sporbarhetsmatrise bør utarbeides parallelt med produktetterslepet. Og det bør sjekkes mot testtilfellene som er utført under testing av brukeraksept / end-to-end-testing (dette trinnet blir forklart i mitt neste punkt). Selv om noen krav blir savnet, kan det enkelt innarbeides selv i de sene stadiene av utviklingen, ettersom smidig gir ekstra fleksibilitet og tilpasningsevne.

Etter at online registreringsprosjekt gikk live, ble sluttbrukerne (studenter som ønsket å registrere seg) tilgang til applikasjonen. De møtte mange problemer i applikasjonen. Dette resulterte i mange billetter hentet til produksjonstøtteteamet. Billetter som samles inn kan klassifiseres som hendelser, problemer eller endringer. Mange problemer ble løst, i påvente av at applikasjonen blir stabil. Men selv da var mer enn et dusin endringsforespørsler / forbedringer planlagt i de påfølgende utgivelsene. Disse forbedringene var ment å stabilisere applikasjonen og forbedre sluttbrukeropplevelsen.

Så til slutt, kostnadene for prosjektet skutt opp av mange folder. Derfor, hvis et prosjekt ikke overføres ordentlig til smidig, kan det føre til at budsjettet overskytes. Dette er veldig nødvendig for å planlegge en grundig overgang av et prosjekt til Agile. Også planlegging bør gjøres i den grad prosjektet trenger for å kunne gjennomføres i smidig modus. Riktige hybridmodeller bør utformes for et bestemt prosjekt.

Før starten av eksamensoppføringsprosjektet var dette aspektet godt ivaretatt. Det ble tenkt på en hybridmodell, og det ble besluttet at faseanalysefasen og designfasen på høyt nivå skulle utføres i fossemodellen og resten av trinnene i en smidig modell.

hva er metadata i datalagring

Hybridmodellen som er tatt i bruk, kan vises som vist nedenfor:

Samarbeidsmodell (hybrid) 3

Konklusjon:

Det er tydelig at både Waterfall-modellen og Agile-modellen har sine egne ulemper. Så det er ganske realistisk å velge en hybridmodell, som er en tilnærming til utnytte det beste fra begge verdener.

Det viktigste ved starten av ethvert prosjekt er å bestemme hvilken modell teamet skal vedta. Dette krever omfattende planlegging. Faktorer som budsjett, tid, ressursutnyttelse, kompleksitet i krav osv. Bør vurderes ved å ta i bruk en programvaremodell.

Hybrid-modellen er fremdeles i en begynnende fase. Etter hvert som flere og flere selskaper vil vedta det, vil vi lære mer om dette konseptet.

Agile-manifestet ber oss verdsette:

  • Enkeltpersoner og interaksjoner over prosesser og verktøy
  • Arbeidsprogramvare over omfattende dokumentasjon
  • Kundesamarbeid over kontraktsforhandlinger
  • Svar på endring over å følge en plan

Mens hybridmodellen ikke følger denne 100%. Det antyder at alle aspekter er like viktige. Det er opp til klientene / prosjektledere å bestemme hvilke aspekter som skal verdsettes mer og hvilke aspekter som er verdiløse.

Om forfatteren: Dette er en gjesteartikkel av Harshpal Singh. Han har 7+ års erfaring med manuell, database, automatisering og ytelsestesting og jobber for tiden som teamleder i et ledende MNC. Han har jobbet med mange QA-prosjekter etter modellene Waterfall, Agile og hybrid.

Har du noen erfaring med å jobbe med denne hybrid utviklings- og testmodellen? La oss diskutere i kommentarer.

Anbefalt lesing

^