Inleiding tot het watervalmodel
Afkomstig uit de bouw- en productie-industrie, het is een zeer gestructureerde fysieke omgeving bedoeld voor ontwerp- en ontwikkelingsprocessen. Waterfall-model staat ook bekend als het levenscyclusmodel voor softwareontwikkeling. Het was het eerste procesmodel dat werd geïntroduceerd als het lineair-sequentiële levenscyclusmodel. Watervalmodel vertelt eenvoudig het fenomeen om de ene fase volledig te voltooien voordat de nieuwe ontwikkelingsfase wordt gestart, zodat er geen overlappende fasen zijn. Op het gebied van softwareontwikkeling werd het watervalmodel voor het eerst gebruikt als SDLC-aanpak. Om aan het watervalmodel te werken, moeten we de toepassingsbenadering begrijpen op basis van zowel interne als externe factoren, die als volgt kunnen zijn:
- Geen dubbelzinnige vereisten in de toepassing.
- Stabiliteit van productdefinitie
- Het is technologie begrepen
- Het is niet dynamisch
- Er zijn grote middelen met de juiste expertise beschikbaar om het product te ondersteunen
- Vey kort project
- Het goede document, duidelijke en vaste eisen.
Om te beginnen met de geschiedenis van het watervalmodel, zou ik willen zeggen dat de eerste steekproef van het watervalmodel in 1970 in een artikel door Winston w Royce werd geïntroduceerd. Sindsdien staat in het watervalmodel dat men alleen naar een andere fase moet overschakelen wanneer de voorgaande fasen volledig zijn getest, beoordeeld en geverifieerd. Het benadrukt de logische voortgang van fasestappen. De functionaliteit is vergelijkbaar met het water dat over de rand van de klif stroomt. Deze benadering van software-ontwikkeling heeft de naam waterval gekregen omdat het zich systematisch van de ene fase naar de andere ontwikkelt op een neerwaartse manier. Sinds de tijd dat het voor het eerst werd gepubliceerd door Winston W. Royce in 1970, wordt het watervalmodel op grote schaal gebruikt op het gebied van softwareontwikkeling. In de procescyclus van softwareontwikkeling worden programmeermodellen gebruikt om de verschillende fasen van het ontwikkelen van een applicatie te plannen. Een dergelijk model is het watervalmodel.
Fasen van watervalmodel
Laten we het nu hebben over de fasen van het watervalmodel, dat duidelijk kan worden uitgelegd via deze demo-infographic.
Met de bovenstaande infographics kunnen we begrijpen dat het watervalmodel in totaal 7 fasen van ontwerp- en ontwikkelingssoftwarecyclus kent die als volgt zijn:
- Voorwaarden
- Analyse
- Ontwerp
- Codering / implementatie
- testen
- Bediening / inzet
- Onderhoud
We kunnen dus zien dat het watervalmodel van boven naar beneden een hiërarchie uitvoert met een fase voltooid met volledige verificaties en vervolgens overschakelt naar een andere fase, inclusief faseprocessen zoals conceptie, initiatie, analyse, ontwerp, constructie, testen, productie / implementatie en onderhoud. Om een kortere kennis over het watervalmodel te krijgen, moeten we alle processen diepgaand begrijpen met zijn werkmodel. Er is een basisvoorwaarde die moet worden begrepen voordat de diepe fasen van kennis worden gestart. Het gaat om de haalbaarheidsstudie voor het softwareproduct. Het behandelt de financiële en technische aspecten van de projectvereisten. Deze fase behandelt de correctie van de maatregelen op basis van de geanalyseerde voor- en nadelen. Zo wordt de beste oplossing gekozen.
- Vereisten: zo specifiek als woorden, we moeten weten en begrijpen wat we moeten ontwerpen, wat we moeten ontwikkelen, de processen, wat de functionaliteit zal zijn, enz. Het levert inputmateriaal aan het product dat wordt gemaakt en dus het aankomende product wordt bestudeerd, afgerond en gemarkeerd. Het geeft ons ook de extensie om de hardware- of softwarevereisten van het product te bepalen die in alle fasen worden ontworpen, ontwikkeld en vastgelegd.
- Analyse: het resulteert in het ontwerpen van modellen, schema's en bedrijfsregels. Niet alleen deze vereiste bestaat uit twee delen:
- Vereisten verzamelen en analyseren: eerst wordt alle informatie en vereisten voor de productontwikkeling verzameld bij de klant en vervolgens verwerkt voor analyse. De belangrijkste rol van dit onderdeel is het wegnemen van onvolledigheden en inconsistenties met betrekking tot de ontwikkeling van softwareproducten.
- Vereiste specificatie: Vervolgens worden de hierboven geanalyseerde vereisten gedocumenteerd in een SRS-document (specificatie van softwarevereisten). Het dient als een pad tussen de klant en het SRS-ontwikkelingsteam. Eventuele geschillen in de toekomst worden alleen beheerd en beslecht via deze SRS-documentatie.
- Ontwerp: nadat de eerste fase is voltooid en geverifieerd, is dit de volgende belangrijkste fase die moet worden bestudeerd, omdat deze wordt gebruikt voor systeemontwerp. Het helpt bij het specificeren van software- en hardwarevereisten voor het productontwerp. Het helpt ook bij de algehele architectuur voor het systeemontwerp. Daarom wordt de specificatie van de vereisten meestal in deze fase bestudeerd en geverifieerd. Het is ook nuttig bij het omzetten van het SRS-document in functioneel ontwerp en ontwikkeling van het softwareproduct. We kunnen dus zeggen dat in de ontwerpfase de algemene architectuur voor het softwareontwikkelingsproject wordt gemaakt.
- Implementatie: met systeemontwerp volledig geverifieerd, komt de implementatiefase op de rij. In deze fase worden de inputs van het systeemontwerp genomen en het wordt eerst ontwikkeld in kleine programma's die units worden genoemd, die worden getest en geïmplementeerd in de komende fase. Elke eenheid in de implementatiefase ondergaat ontwikkeling en de volledige functionaliteit wordt getest, ook wel unit testing genoemd. Dus in deze fase wordt het systeemontwerp omgezet in broncode met volledig functionele programmamodules. Het omvat de ontwikkeling, het bewijzen en de integratie van de software.
- Integratie en testen: elk unitontwerp en ontwikkeld in de eerdere fasen worden opgenomen uit de implementatiefase die is geïntegreerd in een module of systeem voor een verschillende test, zoals belastingstest, leadtest, enz. Na het testen van elke unit. De testomgeving ondergaat een constante softwarecontrole om na te gaan of het ontwerp of de code stroomt of fouten bevat. Er wordt getest om de stabiliteit en de uitvoerbaarheid van de software te handhaven, zodat de klant tijdens de productie geen storingen of bugs ondervindt. Dus in deze fase na implementatie wordt het hele systeem grondig getest op fouten en storingen. Systeemtests bestaan uit drie verschillende soorten activiteiten die hieronder kunnen worden uitgelegd:
- Alpha (α) Testing: het is de test die wordt uitgevoerd door het ontwikkelingsteam.
- Beta (β) Testen: het is de test die wordt uitgevoerd door het vriendelijke team van klanten en gebruikers.
- Acceptatietest: het gebeurt na zowel de alfatest als de bètatest. Kortom, deze tests worden uitgevoerd na levering door de klanten. Na testen uitgevoerd door de klant wordt besloten of deze software acceptabel is of om deze te weigeren. Dus in deze fase worden in principe fouten opgelost.
- Implementatie van het systeem / bewerkingen: zodra de niet-functionele, functionele, alfa- en bètatests zijn voltooid, wordt het product van software geïmplementeerd bij de gebruiker of het klantensysteem of wordt het vrijgegeven voor de markt. De implementatiefase omvat installatie, migratie en ondersteuning van het volledige systeem naar de gebruikers- of klantomgeving.
- Onderhoud: het is de laatste maar de belangrijkste fase in het waterval-workflowmodel. Deze stap komt net na de installatie en omvat het aanbrengen van de juiste wijziging van het product of systeem, of het verbeteren, wijzigen of wijzigen van attributen gerelateerd aan prestatieproblemen gerelateerd aan het systeem. zijn belangrijkste rol is het verbeteren van de prestaties van het systeem met het maximale nauwkeurigheidsresultaat van de software-output. Deze wijzigingen die zijn opgetreden tijdens de onderhoudsfase, houden voornamelijk verband met wijzigingen die door de klant of gebruikers na de installatie- en testfase zijn aangebracht en die bugs bevatten zoals defecten die zijn ontdekt tijdens live gebruik van het systeem of een verzoek van de klant. De klant krijgt dus tijdig en gepland onderhoud en ondersteuning voor het ontwikkelde product. U zult echt verbaasd zijn om te weten dat de inspanningen in de ontwerp- en ontwikkelingsfase van het softwareproduct slechts 60% zijn in vergelijking met de inspanningen in de onderhoudsfase. Er zijn in principe drie soorten onderhoud die hieronder worden uitgelegd:
- Correctief onderhoud: tijdens de ontwerp- en ontwikkelingsfase worden sommige fouten niet ontdekt, ze houden alleen rekening met wanneer de klant gebruikt. Dit is alleen correctief onderhoud, wat betekent dat problemen of fouten worden gecorrigeerd die niet in de ontwikkelingsfase zijn ontdekt.
- Perfectief onderhoud: dit type onderhoud wordt uitgevoerd op verzoek van de klant om de functionaliteiten van het systeem of de software te verbeteren en te verbeteren.
- Adaptief onderhoud: het is het onderhoud dat nodig is voor het schakelen van de systeemomgeving. Meestal vereist voor het porteren van het bestaande systeem naar een nieuwe omgeving of nieuwe computer of systeem of misschien met een nieuw besturingssysteem. Deze fase is te belangrijk omdat dit leidt tot betere systeemprestaties.
Dus in de bovenstaande discussie hebben we elke fase van het watervalmodel diepgaand leren kennen met volledige specificaties. We kunnen dus zeggen dat het watervalmodel erg belangrijk is op het gebied van software, ook in vergelijking met de mechanische industrie, aangezien elke fase zijn eigen belang heeft, het leidt tot een productievere en stabielere software.
voordelen
Niet alleen dit watervalmodel heeft ook veel meer voordelen in de levenscyclus van softwareontwikkeling, die hieronder kunnen worden besproken:
- Het maakt afdelingen en controle mogelijk.
- Een schema kan worden opgesteld met deadlines voor elke ontwikkelingsfase en een product kan de fasen van het ontwikkelingsprocesmodel één voor één doorlopen.
- Omdat het gemakkelijk te begrijpen en verklaarbare fasen doorloopt, overwint het veel problemen, dus het is heel gemakkelijk te gebruiken.
- Vanwege de starheid van het workflow-model, is het heel gemakkelijk te beheren omdat elke fase in het watervalmodel specifieke review- en deliverables-processen heeft.
- Watervalmodel werkt goed voor kleinere projecten waar de vereisten zeer goed worden begrepen.
- Het schema kan worden ingesteld met deadlines voor elke ontwikkelingsfase en een product kan de fasen van het ontwikkelingsprocesmodel één voor één doorlopen.
- Duidelijk gedefinieerde fasen.
- Goed begrepen mijlpalen.
- Eenvoudig taken regelen.
- Proces en resultaten zijn goed gedocumenteerd.
- Versterkt goede gewoonten: definiëren vóór ontwerp,
- Design-before-code.
- Het model werkt goed voor kleinere projecten en projecten waarbij de eisen goed worden begrepen.
Nadeel
Zoals we weten, heeft elke munt twee gezichten, dus met de grote toegang tot de voordelen van het watervalmodel, heeft het watervalmodel ook enkele nadelen of je kunt nadelen zeggen die hieronder worden besproken:
- Geen goed model voor complexe en objectgerichte projecten.
- Niet geschikt voor projecten waarbij de eisen met een matig tot hoog risico op verandering zijn.
- Het is moeilijk om tijd en kosten in te schatten voor elke fase van het ontwikkelingsproces.
- Geen goed model voor complexe en objectgerichte projecten.
- Er wordt pas laat in de levenscyclus van werkende software geproduceerd.
- Kan niet voldoen aan veranderende vereisten.
- Het is moeilijk om de voortgang binnen fasen te meten.
- Grote hoeveelheden risico en onzekerheid.
- Slecht model voor lange en lopende projecten.
- Het aanpassen van de scope tijdens de levenscyclus kan een project beëindigen.
- Geen feedbackpad
- Geen overlappende fasen
- Moeilijk om wijzigingsverzoeken te verwerken.
- risico en onzekerheid zijn groot met dit procesmodel.
Waar het watervalmodel te gebruiken
Nu we alle scenario's hebben omcirkeld, komen we op een punt waarop we willen weten waar we het watervalmodel kunnen gebruiken.
- Vooral het watervalmodel wordt in een defensieproject gebruikt, omdat de eis duidelijk is omdat ze het voordat ze naar de ontwikkelingsfase gaan goed analyseren.
- Dit kan ook worden gebruikt in migratieprojecten waar de vereisten hetzelfde zijn, alleen platform of talen kunnen variëren / wijzigen.
Conclusie
Dus als een geheel kan ik zeggen dat het watervalmodel het best geschikt is voor een klein softwareontwikkelingsproject in vergelijking met grote projecten omdat ontwerp, ontwikkeling en implementatie gemakkelijker is in het kleine project bij het werken aan een watervalmodel omdat in dit model alle voorgaande fasen nodig zijn in te vullen bij komende fasen. Dus in het grote project komen de problemen en fouten vaak voor omdat het een groot model heeft, dus elke keer dat de testfase wordt voortgezet indien geïmplementeerd via het watervalmodel, wat zal leiden tot minder optimalisatie en nauwkeurigheid van de software.
Aanbevolen artikelen
Dit is een gids voor Waterfall Model geweest. Hier hebben we de fasen, voordelen en de nadelen van Waterfall Model besproken. U kunt ook onze andere voorgestelde artikelen doornemen voor meer informatie -
- Wat is AWS?
- Wat is Bootstrap?
- Wat is een bijenkorf?
- Wat is Unix?
- Scrum vs Waterfall | Vergelijking