Menu

Casestudy: hoe fouten in waterval en Agile ontwikkelingsprocessen te elimineren met behulp van een hybride model

  • Hoofd
  • Agile Testen
  • Casestudy: hoe fouten in waterval en Agile ontwikkelingsprocessen te elimineren met behulp van een hybride model

case study how eliminate flaws waterfall

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Agile waterval hybride model

Het Waterfall-model was de ideale keuze voor softwareontwikkeling. In dit model wordt een idee bruikbare software in een sequentieel proces dat door de fasen van initiatie, analyse, implementatie, testen en onderhoud loopt.

Maar het Waterfall-model heeft enkele nadelen.

Agile softwareontwikkeling is geëvolueerd om de problemen van het Waterfall-model te elimineren. Het heeft een volledig nieuw kader. Terwijl het Waterfall-model een sequentieel ontwerp heeft, volgde het Agile-model een incrementele benadering.

Toen klanten die voorheen het Waterfall-model volgden, overstapten naar Agile, bracht de transitie veel problemen met zich mee. De reden hiervoor is onaangepastheid aan een andere benadering van softwareontwikkeling. Het eindproduct bleek een ramp te zijn.

Agile waterval hybride model

Er is dus een nieuwe methodologie ontwikkeld, die een ‘Hybride’ kan worden genoemd, om een ​​robuust eindproduct te garanderen door de voordelen van zowel Agile- als Waterfall-modellen te kiezen.

oracle database interviewvragen en antwoorden

Laten we eerst de Waterfall- en Agile-ontwikkelingsmodellen leren kennen en dan verder gaan met het 'Agile Waterfall Hybrid Model' met voor- en nadelen van elk.

Wat je leert:

Waterval model

Het Watervalmodel is een benadering voor het ontwikkelen van software die een project opsplitst in eindige fasen. Men moet alleen naar de volgende fase gaan als de voorgaande fase is herzien en geverifieerd.

In het watervalmodel overlappen fasen elkaar niet.

​ Lees hier meer over het Watervalmodel.

Figuur 1 toont het Watervalmodel:

Waterval model

Voordelen van het Watervalmodel:

  • Eenvoudig en gemakkelijk te begrijpen en te gebruiken.
  • Rigide model - Elke fase heeft specifieke resultaten en beoordelingsprocessen.
  • Documentatie en artefacten worden zorgvuldig onderhouden.
  • Geschikt voor projecten waar de eisen goed worden begrepen.

Nadelen van het Watervalmodel:

  • Niet geschikt voor projecten waar eisen dreigen te veranderen.
  • De kosten voor het herstellen van defecten zijn erg hoog wanneer ze in een later stadium worden ontdekt.
  • Geen goed model voor complexe en lange projecten.
  • Pas laat in de levenscyclus wordt er werkende software geproduceerd.

Agile model

Wikipedia definieert het Agile-model als 'een groep softwareontwikkelingsmethoden gebaseerd op iteratieve en incrementele ontwikkeling, waarbij vereisten en oplossingen evolueren door samenwerking tussen zelforganiserende, multifunctionele teams.'

Het model heeft zijn eigen principes die de neiging hebben om de processen naar de achterbank te brengen.

​ Lees hier meer artikelen over Agile-methodologie.

(Klik op afbeelding om vergroot te bekijken)

Agile model

Voordelen van het Agile-model:

  • Betrokkenheid van de klant bij het proces.
  • Hoge ROI omdat er regelmatig werkende software wordt geleverd.
  • Zelfs late wijzigingen in vereisten kunnen gemakkelijk worden opgevangen.
  • Voortdurende verbetering van zowel product als proces.

Nadelen van het Agile-model:

  • Gebrek aan nadruk op ontwerp en documentatie.
  • Het team moet stabiel en bekwaam zijn.

Collaboratief (hybride) model

Het Collaborative Model heeft tot doel om beide modellen te combineren: Waterfall en Agile. Door gebruik te maken van zowel de Waterval- als de Agile-aanpak, wordt het succes van het project gegarandeerd. Het verwijdert de nadelen van beide modellen; terwijl de voordelen van beide samenkomen.

Het Collaborative Model kan in een project worden geïmplementeerd door het volgende uit te voeren:

Collaboratief (hybride) model

Dus het Collaborative-model kan schematisch worden weergegeven zoals hieronder:

Collaboratief (hybride) model 2

Voordelen van het hybride model

  • Combineert de voordelen van zowel Agile- als Waterfall-processen.
  • High-level design is voorbereid om watervalprincipes toe te passen.
  • Codering en testen worden gedaan met behulp van agile methodologie.

Agile Waterfall Hybrid Model - Leer door het voorbeeld -Een casestudy

Softwarebedrijf ‘ABC Software Service’ levert diensten aan een klant, een universiteit genaamd‘ XYZ University ’om hun software te ontwikkelen, testen en onderhouden (ondersteuning voor live productie).

De belangrijkste kenmerken van het account zijn:

  1. ABC Software Services moet de applicaties van XYZ University upgraden. De database moet worden geüpgraded en alle applicaties moeten opnieuw worden ontwikkeld volgens de nieuwste technologie die op de markt beschikbaar is.
  2. Tot nu toe werden alle projecten van ABC Software uitgevoerd in het Waterval-model.
  3. Twee van de toepassingen met veel verkeer en hoge prioriteit zouden nu opnieuw worden ontwikkeld. De eerste is ‘Online inschrijvingen’, de tweede is ‘Online examens’.
  4. Opdrachtgever XYZ University wilde nu dat aan deze applicaties gewerkt zou worden met behulp van het Agile-model van Softwareontwikkeling.

Het eerste project in een Agile-model voor ABC Software was online registraties. Na de uitvoering van dit project werd in een reeks retrospectieven geconstateerd dat er veel tekortkomingen waren in de gevolgde processen.

Deze gebreken werden opgevangen tijdens de uitvoering van het tweede project ‘online examens’ en het werd daarom uitgevoerd in een hybride model.

Hoe gebreken in waterval en Agile ontwikkelingsprocessen te elimineren met behulp van een hybride model:

Laten we deze een voor een in detail bespreken.

# 1. Geen documentatie:

Een van de agile principes in het agile manifest stelt het volgende: Agile geeft meer waarde aan ‘Working Software boven Comprehensive Documentation’. Agile-methodologie is van mening dat documentatie ‘maar net goed genoeg’ zou moeten zijn, en er wordt meer nadruk gelegd op het verzenden van werkende software. Er wordt niet veel moeite gedaan met documentatie, maar voor accounts zoals XYZ University, met een toegewijd ondersteuningsteam om te werken aan defecten die in live projecten zijn gevonden, kan deze gewoonte een belemmering blijken te zijn als we het op lange termijn analyseren.

Door de jaren heen, toen projecten werden uitgevoerd in het Watervalmodel, werden documenten bijgehouden en bijgewerkt zodat het ondersteuningsteam het kon begrijpen en dienovereenkomstig kon werken. Oplossingsontwerp, technisch ontwerp, walkthrough-documenten, enz. Waren enkele van de documenten die werden voorbereid. Nadat het project voorbij was, werd hetzelfde overgedragen aan het ondersteuningsteam.

Maar in het geval van het project ‘online registraties’ werden dergelijke documenten niet opgesteld en dat bleek kostbaar. Toen het project live ging, werden veel tickets opgehaald door eindgebruikers en had het ondersteuningsteam geen idee hoe ze eraan moesten werken. Het team had geen document om naar te verwijzen.

Dit was een belangrijke les die werd geleerd en voor het volgende project werden ‘online examens’ documenten geschreven en effectief overgezet.

​ Lees hier meer waarom documentatie belangrijk is.

#twee. Geen UAT / end-to-end-testen:

welke etl-tool is het beste op de markt

In de Agile-modus van softwareontwikkeling laten testers de builds stapsgewijs testen. Deze builds blijven integreren totdat de laatste build volledig is gebouwd. Testers testen de vereisten die in elke sprint worden gedekt en blijven regressietests uitvoeren van de build die steeds weer kloppen.

Maar nadat alle sprints zijn voltooid en de laatste build klaar en allemaal geïntegreerd is, moet de tester het complete systeem testen en end-to-end testen uitvoeren. Dit moet in een geheel nieuwe omgeving gebeuren.

​ End-to-end testen op een live project.

Dit heeft zo zijn voordelen:

  • Het complete systeem wordt ingezet in een nieuwe omgeving en de tester test de complete flow.
  • Het wekt vertrouwen omdat de build uiteindelijk als geheel in een live omgeving moet worden geïmplementeerd.

Toen het project Online Registraties werd getest, gebeurde dit in de testomgeving. Na het testen van het systeem en het opnieuw testen van alle defecten, werd het voor aftekening verklaard. Idealiter werd dit niet gepromoot naar een andere omgeving voor een volgende cyclus van systeemtesten. (Ideaal, UAT vindt plaats na het testen van het systeem , maar in dit geval waren de UAT-teamleden betrokken bij de eerste testcyclus, dus er was geen tweede cyclus gepland)

Toen het online examenproject van start ging, werd SIT (System Integration Testing) gedaan en werd de code gepromoveerd naar een UAT-omgeving waar de tweede testcyclus werd uitgevoerd. Resultaat: alle defecten met hoge prioriteit werden vastgelegd en opgelost. De build was stabiel vóór de go-live-release.

# 3. Geen Scrum Master:

De Scrum Master is ervoor verantwoordelijk dat een team leeft volgens de waarden en praktijken van Scrum. De Scrum Master wordt beschouwd als een coach voor het team door het team te helpen het beste uit zichzelf te halen. De Scrum Master kan ook worden gezien als een proces eigenaar voor het team.

Het online registratieteam is gevormd zonder Scrum Master. Het belang van een toegewijde Scrum Master werd niet belangrijk geacht. Dat had tot gevolg dat veel problemen niet op tijd werden opgelost en dat de tijd om het project af te ronden vaak de deadline overschreed.

Er was echter een toegewijde Scrum Master betrokken bij het project Online Examinations. De projectproblemen en uitdagingen werden door de Scrum Master afgehandeld. De project- / sprintrapporten werden opgesteld en het team kon de voortgang zien.

Ook vonden er voor elke sprint goede sprintplanningsvergaderingen en sprint-retrospectieve vergaderingen plaats die de prestaties van het team verbeterden. Het team concentreerde zich alleen op hun werk en voltooide de taken die waren toegewezen voor die sprint. Alle extra huishouding werd afgehandeld door de Scrum Master.

# 4. Projectdocumenten converteren naar de Product backlog:

De initiële projectdocumenten die worden opgesteld in een watervalmodel zijn Business Requirements Specificatie (BRS), High-level design, Functioneel ontwerp, etc. Deze documenten moeten worden getransformeerd naar een product backlog om de codering, test en implementatiefase uit te voeren. in behendige modus. Dit is een heel belangrijke stap.

De product backlog is het startpunt van een agile project. De product backlog is een geprioriteerde lijst met vereisten die voor een product wordt bijgehouden. Het bestaat uit functies, bugfixes, niet-functionele vereisten, enz. Het is een groeiend document dat groter en beter wordt op basis van feedback van klanten, veranderende vereisten, enz.

Omdat het het eerste artefact van een project is, is het belangrijk om de vereisten op te sommen en prioriteiten toe te wijzen. Het omzetten van watervalprojectdocumenten naar product backlog is een grote taak op zich en vereist brainstorming van het hele team samen met de klant / stakeholder.

Zodra alle vereisten zijn opgesomd en overeengekomen door de klant, is de volgende taak om ze te prioriteren om ze in sprints op te halen.

# 5. Traceerbaarheid Matrix:

Een ander belangrijk artefact dat meestal in het watervalmodel wordt gehandhaafd, is de traceerbaarheidsmatrix. Dus om er voor te zorgen dat er geen eisen worden gemist; er moet ook een traceerbaarheidsmatrix worden ontworpen en onderhouden ​Gewoonlijk wordt in agile zo'n matrix niet ontworpen.

Dit is een best practice in elk project. Parallel aan de productachterstand moet een traceerbaarheidsmatrix worden opgesteld. En het moet worden vergeleken met de testgevallen die zijn uitgevoerd tijdens het testen van gebruikersacceptatie / end-to-end-tests (deze fase wordt uitgelegd in mijn volgende punt). Zelfs als een vereiste wordt gemist, kan het gemakkelijk worden opgenomen, zelfs in de late ontwikkelingsstadia, aangezien agile die extra flexibiliteit en aanpassingsvermogen biedt.

Nadat het project Online inschrijvingen live was gegaan, werd de applicatie benaderd door de eindgebruikers (studenten die zich wilden registreren). Ze hadden veel problemen met de applicatie. Dit resulteerde in veel tickets voor het productie-ondersteuningsteam. Opgehaalde tickets kunnen worden geclassificeerd als incidenten, problemen of wijzigingen. Veel problemen zijn opgelost, in de verwachting dat de applicatie stabiel zal worden. Maar zelfs toen waren er meer dan een dozijn wijzigingsverzoeken / verbeteringen gepland in de volgende releases. Deze verbeteringen waren bedoeld om de applicatie te stabiliseren en de ervaring van de eindgebruiker te verbeteren.

Dus uiteindelijk schoten de kosten van het project met vele plooien omhoog. Als een project niet op de juiste manier wordt omgezet naar agile, kan het budget daardoor te hoog worden opgeschoten. Dit is zeer noodzakelijk om een ​​gedegen transitie van een project naar Agile te plannen. Ook moet er worden gepland voor zover het project nodig heeft om in agile-modus te worden uitgevoerd. Voor een bepaald project moeten de juiste hybride modellen worden ontworpen.

Voor de start van het Exam Entry-project werd dit aspect goed verzorgd. Er werd een hybride model bedacht en er werd besloten dat de vereistenanalysefase en de ontwerpfase op hoog niveau zouden worden uitgevoerd in een watervalmodel en de rest van de fasen in een agile model.

Het hybride model dat is aangenomen, kan als volgt worden weergegeven:

Collaboratief (hybride) model 3

Gevolgtrekking:

Het is duidelijk dat zowel het Waterfall-model als het Agile-model zo zijn eigen nadelen hebben. Het is dus best realistisch om voor een hybride model te kiezen, dat is een benadering van gebruik maken van het beste van twee werelden.

Het belangrijkste aspect van de start van een project is om te beslissen welk model het team gaat gebruiken. Dit vereist een uitgebreide planning. Factoren zoals budget, tijd, gebruik van middelen, de complexiteit van vereisten, enz. Moeten in overweging worden genomen bij het adopteren van een softwaremodel.

gratis download van de tijdkloksoftware voor werknemers

Het hybride model bevindt zich nog in de kinderschoenen. Naarmate meer en meer bedrijven het zullen adopteren, zullen we meer over dit concept leren.

Het Agile-manifest vraagt ​​ons om te waarderen:

  • Individuen en interacties over processen en tools
  • Werkende software over uitgebreide documentatie
  • Klantensamenwerking over contractonderhandelingen
  • Reageren op verandering over het volgen van een plan

Terwijl het hybride model zich hier niet 100% aan houdt. Het suggereert dat alle aspecten even belangrijk zijn. Het is aan de klanten / projectmanagers om te beslissen welke aspecten ze meer waarderen en welke aspecten waardeloos.

Over de auteur: Dit is een gastartikel van Harshpal Singh. Hij heeft meer dan 7 jaar ervaring in handmatige, database-, automatisering- en prestatietests en werkt momenteel als een teamleider in een toonaangevende MNC. Hij heeft aan veel QA-projecten gewerkt volgens de ontwikkelingsmodellen Waterfall, Agile en hybride.

Heb je ervaring met het werken aan dit hybride ontwikkel- en testmodel? Laten we het in opmerkingen bespreken.

Aanbevolen literatuur

^