Menu

Wat is een STLC V-model?

what is stlc v model

Probeer Ons Instrument Voor Het Oplossen Van Problemen

Wat is een STLC V-model?

Een van de grootste handicaps van waterval STLC-model was dat defecten werden gevonden in een zeer later stadium van het ontwikkelingsproces, aangezien er aan het einde van de ontwikkelingscyclus werd getest. Het werd een grote uitdaging en kostbaar om de defecten te herstellen, aangezien deze in een zeer later stadium werd gevonden. Om dit probleem op te lossen, werd een nieuw ontwikkelingsmodel geïntroduceerd, het 'V-model' genaamd

V-model is nu een van de meest gebruikte softwareontwikkelingsprocessen. De introductie van het V-model heeft de implementatie van testen al vanaf de vereistenfase bewezen. V-model wordt ook wel een verificatie- en validatiemodel genoemd.

STLC V-model

Wat je leert:

Verificatie en validatie

Om het V-model te begrijpen, moeten we eerst begrijpen wat verificatie en validatie in software is.

Verificatie ​ Verificatie is een statische analysetechniek. Bij deze techniek wordt getest zonder de code uit te voeren. Voorbeelden zijn onder meer - Recensies, inspectie en walkthrough.

Validatie ​ Validatie is een dynamische analysetechniek waarbij wordt getest door de code uit te voeren. Voorbeelden zijn onder meer functionele en niet-functionele testtechnieken.

V-model

In het V-model worden de ontwikkelings- en QA-activiteiten gelijktijdig uitgevoerd. Er is geen afzonderlijke fase genaamd Testen, maar het testen begint direct vanaf de vereiste fase. De verificatie- en validatieactiviteiten gaan hand in hand.

Laten we de onderstaande afbeelding bekijken om het V-model te begrijpen:

STLC V-model

retourneert een array van een methode in java

In een typisch ontwikkelproces toont de linkerkant de ontwikkelingsactiviteiten en de rechterkant de testactiviteiten. Ik zou het niet mis hebben als ik zeg dat in de ontwikkelingsfase zowel verificatie als validatie worden uitgevoerd samen met de daadwerkelijke ontwikkelingsactiviteiten.

Laten we nu eens kijken naar de figuur:

Linkerzijde

Zoals eerder gezegd, zijn activiteiten aan de linkerkant ontwikkelingsactiviteiten. Normaal gesproken voelen we, wat kunnen we testen in de ontwikkelingsfase, maar dit is het mooie van dit model dat aantoont dat testen ook in alle fasen van ontwikkelingsactiviteiten kan worden uitgevoerd.

Vereiste analyse : In deze fase worden de requirements verzameld, geanalyseerd en bestudeerd. Hier is niet hoe het systeem wordt geïmplementeerd, maar wat het systeem moet doen, is belangrijk. Hersenstormsessies / walkthrough, interviews worden afgenomen om de doelstellingen duidelijk te maken.

  • Verificatieactiviteiten : Vereistenbeoordelingen.
  • Validatie-activiteiten : Creatie van UAT ( Gebruikers acceptatie test ) testgevallen
  • Artefacten geproduceerd : Vereisten die het document begrijpen, UAT-testgevallen.

Systeemvereisten / hoogstaand ontwerp : In deze fase wordt het ontwerp van de software op hoog niveau gebouwd. Het team bestudeert en onderzoekt hoe de eisen kunnen worden geïmplementeerd. Ook wordt de technische haalbaarheid van de eisen onderzocht. Het team bedenkt ook de modules die zouden worden gemaakt / afhankelijkheden, hardware / software-behoeften

  • Verificatieactiviteiten : Ontwerprecensies
  • Validatie-activiteiten : Creatie van Systeemtestplan en cases, Creëren van traceerbaarheidsstatistieken
  • Artefacten geproduceerd : Systeemtestcases, Haalbaarheidsrapporten, Systeemtestplan, Hardware-softwarevereisten en aan te maken modules, etc.

Architectueel ontwerp: In deze fase gebaseerd op het high-level design ​ softwarearchitectuur wordt gemaakt. De modules, hun relaties en afhankelijkheden, architecturale diagrammen, databasetabellen, technologiedetails worden allemaal in deze fase afgerond.

  • Verificatieactiviteiten : Ontwerprecensies
  • Validatie-activiteiten : Integratietestplan en testcases.
  • Artefacten geproduceerd : Ontwerpdocumenten, Integratietestplan en testcases, Database-tafelontwerpen etc.

Moduleontwerp / laag ontwerp: In deze fase wordt elke module van de softwarecomponenten afzonderlijk ontworpen. Methoden, klassen, interfaces, datatypes enz. Worden allemaal in deze fase afgerond.

  • Verificatieactiviteiten : Ontwerprecensies
  • Validatie-activiteiten : Aanmaken en beoordelen van unit test cases.
  • Artefacten geproduceerd : Unit test cases,

Implementatie / Code : In deze fase wordt de daadwerkelijke codering gedaan.

  • Verificatieactiviteiten : Codebeoordeling, beoordeling van testcases
  • Validatie-activiteiten : Opstellen van functionele testcases.
  • Artefacten geproduceerd : testcases, controlelijst.

Rechterzijde

Rechterzijde toont de testactiviteiten of de Validatiefase. We beginnen van onderaf.

Testen van een eenheid: In deze fase worden alle unit-testgevallen, gecreëerd in de Low-level ontwerpfase, uitgevoerd.

* Unit testing is een white box-testtechniek, waarbij een stuk code wordt geschreven dat een methode (of een ander stuk code) aanroept om te testen of het codefragment de verwachte output geeft of niet. Dit testen wordt in principe uitgevoerd door het ontwikkelteam. In het geval van een afwijking worden defecten geregistreerd en bijgehouden.

Artefacten geproduceerd : Resultaten van de uitvoering van een eenheidstest

Integratietesten : In deze fase worden de integratietestgevallen uitgevoerd die in de Bouwkundig ontwerpfase tot stand zijn gekomen. In geval van afwijkingen worden defecten gelogd en bijgehouden.

* Integratietesten: Integratietesten is een techniek waarbij de unit-geteste modules worden geïntegreerd en getest of de geïntegreerde modules de verwachte resultaten opleveren. In eenvoudigere woorden, het valideert of de componenten van de applicatie samenwerken zoals verwacht.

Artefacten geproduceerd : Resultaten van de integratietest.

Systemen testen : In deze fase worden alle systeemtestgevallen, functionele testgevallen en niet-functionele testgevallen uitgevoerd. Met andere woorden, hier vindt het daadwerkelijke en volledige testen van de applicatie plaats. Defecten worden geregistreerd en gevolgd voor de sluiting. Voortgangsrapportage is ook een belangrijk onderdeel van deze fase. De traceerbaarheidsstatistieken worden bijgewerkt om de dekking te controleren en de risico's te beperken.

Artefacten geproduceerd : Testresultaten, testlogboeken, defectrapport, testoverzichtsrapport en bijgewerkte traceerbaarheidsmatrices.

Testen van gebruikersacceptatie : Acceptatietesten hebben in feite betrekking op het testen van zakelijke vereisten. Hier wordt getest om te valideren dat aan de zakelijke vereisten wordt voldaan in de gebruikersomgeving. Compatibiliteitstesten en soms niet-functionele testen ( Belasting, stress en volume ) testen worden ook in deze fase gedaan.

Artefacten geproduceerd : GAT-resultaten, bijgewerkte bedrijfsdekkingsmatrices.

Wanneer gebruik je het V-model?

V-model is van toepassing wanneer:

  • De eis is goed gedefinieerd en niet dubbelzinnig
  • De acceptatiecriteria zijn goed gedefinieerd.
  • Project is van korte tot middelgrote omvang.
  • De gebruikte technologie en tools zijn niet dynamisch.

Voors en tegens van het gebruik van het V-model

PROSNadelen
- Ontwikkeling en vooruitgang is zeer georganiseerd en systematisch-Niet geschikt voor grotere en complexe projecten
- Werkt goed voor kleinere tot middelgrote projecten.- Niet geschikt als de eisen niet consistent zijn.
- Het testen begint vanaf het begin, dus dubbelzinnigheden worden vanaf het begin geïdentificeerd.- In de tussenfase wordt geen werkende software geproduceerd.
- Gemakkelijk te beheren aangezien elke fase duidelijk omschreven doelstellingen en doelen heeft.- Geen voorziening voor het doen van risicoanalyses, dus onzekerheid en risico's zijn er.

Aanbevolen literatuur

^