SPIRAALMODEL: GESCHIEDENIS, KENMERKEN, STADIA, VOORBEELD - TECHNOLOGIE - 2026

Het spiraalmodel is een archetype van het applicatieontwikkelingsproces. Het is gebaseerd op de hypothese dat softwareontwikkeling een iteratieve cyclus is die wordt herhaald totdat de vastgestelde doelstellingen zijn bereikt. Het kan omgaan met het grote aantal risico's dat kan optreden bij het ontwikkelen van software.

Het is een van de belangrijkste modellen ter ondersteuning van risicomanagement. Zoals de naam suggereert, wordt dit model spiraalvormig weergegeven, waarbij de verschillende stadia van het model in verschillende cycli zijn verdeeld. Het aantal cycli in het model staat niet vast en kan van project tot project verschillen.

Analyse, evaluatie, planning en ontwikkeling. Software Development Spiral Bron: Beao commons.wikimedia.org

Geschiedenis

Creatie

Het spiraalmodel is gedefinieerd door de Amerikaanse wiskundige en hoogleraar software engineering Barry Boehm. Nadat hij in 1986 zijn concept voor de ontwikkeling van complexe applicaties had gepresenteerd, publiceerde hij zijn model in 1988 in een uitgebreider kader in zijn artikel "A Spiral Model of Software Development and Improvement".

Een deel van deze publicatie uit 1988 gaf een grafische weergave van het spiraalmodel, waarbij op een alomvattende manier werd getoond hoe het softwareontwikkelingsproces er spiraalsgewijs uitziet en wordt ondersteund door cycli.

Boehm staat bekend om zijn talrijke bijdragen aan software engineering, zoals het constructieve kostenmodel (COCOMO), het spiraalmodel van het softwareproces, de G-Theorie (win-win) benadering van het bepalen en beheren van vereisten. van de software.

Alternatief voor het watervalmodel

In zijn publicatie beschreef Boehm het spiraalmodel als een mogelijk alternatief voor het eerder opgezette watervalmodel, dat tevens als basis diende voor zijn praktijk.

Het spiraalmodel was niet het eerste dat over cyclische ontwikkeling sprak, maar het was het eerste model dat uitlegde waarom iteratie belangrijk is. Zoals oorspronkelijk gepland, was het gericht op grote, complexe projecten waarvan de iteraties doorgaans variëren van 6 maanden tot 2 jaar.

Dit model gaat er niet van uit dat softwareontwikkelingstaken lineair worden ontworpen, in tegenstelling tot het watervalmodel, maar beschouwt ze eerder als iteratieve taken.

Dit cyclische model beïnvloedde Model Based Software Engineering Architecture (MBASE) en extreme programmering.

Kenmerken van het spiraalmodel

Risico controle

Wat dit model sterk onderscheidt van andere softwareprocesmodellen, is dat het risico's expliciet herkent. Het vermindert dus het falen van grote softwareprojecten aanzienlijk door herhaaldelijk risico's te beoordelen en het product dat in ontwikkeling is, elke keer te verifiëren.

Dit computermodel bevat componenten uit bijna elk ander model van de softwarelevenscyclus, zoals het watervalmodel, het prototyping-model, het iteratieve model, het evolutionaire model, enz.

Hierdoor kan het bijna elk type risico aan dat andere modellen over het algemeen niet aankunnen. Vanwege het feit dat er zoveel componenten zijn, is dit model echter veel complexer dan de andere softwareontwikkelingsmodellen.

Beschrijving van de spiraal

Elke omwenteling van de spiraal vertegenwoordigt een volledige cyclus, waar altijd de vier kwadranten doorheen gaan, die de vier fasen van het model vertegenwoordigen.

Naarmate de omvang van de spiraal toeneemt, neemt ook de geboekte vooruitgang toe. Daarom worden de fasen niet één keer, maar meerdere keren spiraalvormig uitgevoerd.

Hoewel deze cyclische herhaling ervoor zorgt dat het project langzaamaan de gestelde doelen nadert, wordt het risico dat het ontwikkelproces mislukt sterk geminimaliseerd.

Algemeen

De vier fasen implementeren alleen de basisdoelen van een cyclus, maar ze hoeven zich niet in elke cyclus te manifesteren.

De volgorde van elke cyclus is ook niet strikt bepaald. Daarom kan het model op elk moment worden gecombineerd met andere modellen.

Flexibel

Het is vrij flexibel, aangezien het de doelstellingen, risicoanalyse, ontwikkelings- en planningsprocessen afzonderlijk voor elke fase van het project uitvoert.

Metamodel

Het wordt als een metamodel beschouwd omdat het de andere modellen omvat. Als de spiraal bijvoorbeeld een enkele cyclus zou zijn, zou het het watervalmodel vertegenwoordigen, aangezien het de geleidelijke benadering van dit klassieke model omvat.

Hij gebruikt ook de benadering van prototyping-modellen, aangezien hij aan het begin van elke cyclus een prototype samenstelt om risico's te beheersen.

Bovendien is het compatibel met het evolutionaire model, omdat de iteraties van de spiraal kunnen worden beschouwd als evolutionaire niveaus, waardoor het uiteindelijke systeem wordt gebouwd.

Stadia

Bepaal doelstellingen, alternatieven en beperkingen

Systeemvereisten worden zo gedetailleerd mogelijk gedefinieerd, inclusief prestaties, hardware / software-interfaces, sleutelindicatoren voor succes, enz. en welke doelen moeten worden geassocieerd met de huidige ontwikkelingscyclus worden overwogen.

Daarnaast worden verschillende alternatieven voor de implementatie onderzocht, zoals build vs. bestaande componenten kopen, hergebruiken of uitbesteden, etc.

Evenzo worden beperkingen zoals kosten, planning en interfaces, tijdverbruik, enz. Bepaald.

Risico's evalueren

Alle voorgestelde alternatieven worden geëvalueerd. De doelstellingen en beperkingen dienen als bepalende referenties om de beste oplossing te selecteren.

Bovendien worden de risico's geïdentificeerd die het succes van het project kunnen belemmeren, zoals gebrek aan ervaring, nieuwe technologieën, strakke planningen, slechte processen, enz., Het implementeren van de meest winstgevende strategieën met het laagste risico.

Ten slotte worden methoden zoals prototyping, simulaties, analytische modellen en gebruikersonderzoeken gebruikt.

Ontwikkeling en testen

Alle noodzakelijke ontwikkeling wordt uitgevoerd met behulp van de technologie en de geselecteerde oplossing. Met elke iteratie wordt een betere versie van de applicatie gemaakt.

De eigenlijke code wordt meerdere keren geschreven en getest totdat het gewenste resultaat is bereikt, dat vervolgens zal dienen als basis voor toekomstige ontwikkelingsstappen.

Planning van de volgende cyclus

Na voltooiing van de ene cyclus begint de planning voor de volgende. Deze planning zou kunnen zijn om het project normaal voort te zetten als de doelstelling van de cyclus is bereikt, rekening houdend met de definitie van de volgende doelstelling.

Het kan ook zijn om andere oplossingen te vinden, als de vorige ontwikkelingsfase niet klopte. De bestaande strategie zou kunnen worden vervangen door een van de eerder gedefinieerde alternatieven of een nieuwe. Hiermee zou een nieuwe poging om het gegeven doel te bereiken worden gestart.

Voorbeeld

Het Amerikaanse leger heeft het spiraalvormige model aangenomen voor de ontwikkeling en upgrade van het moderniseringsprogramma Future Fighting Systems (SCF).

Officieel gelanceerd in 2003, waren de SCF's bedoeld om troepen uit te rusten met voertuigen die in realtime waren verbonden met een buitengewoon snel en flexibel netwerk van slagvelden.

Het project was opgedeeld in vier ontwikkelingsspiralen van elk ongeveer twee jaar. Spiral 1 zou in 2008 van start gaan en prototypes opleveren voor gebruik en evaluatie.

Na voltooiing van spiraal 1 zou spiraal 2 in 2010 beginnen. De eindproductontwikkeling zou in 2015 worden opgeleverd.

In augustus 2005 kondigde Boeing de voltooiing aan van de eerste grote mijlpaal van het project, namelijk de functionele revisie van de systemen. Boeing en Science Applications International Corporation waren de co-leiders van het project.

Echter, voor oktober 2005 adviseerde het Pentagon om het project uit te stellen vanwege de hoge impact op de kosten van de oorlog in Irak en de hulp van de orkaan Katrina.

Het project werd in 2009 geannuleerd nadat er bezuinigingen waren doorgevoerd, zonder de voordelen van het spiraalmodel in deze missie te kunnen bewijzen

Voordeel

Cyclische structuur

Door dit soort structuur worden problemen tussen ontwerp en technische eisen van de software stilzwijgend geëlimineerd dankzij periodieke controles.

Risicomanagement

Risico's worden in elke fase van het product geanalyseerd voordat verder wordt gegaan. Dit helpt potentiële risico's te overwinnen of te verkleinen.

Alle medewerkers profiteren van het grote belang van risicoanalyse in dit model en vertegenwoordigen mogelijk hun grootste voordeel ten opzichte van andere procesmodellen.

Regelmatige risicobeoordeling is waardevol bij het gebruik van nieuwe technische omgevingen, die doorgaans worden geassocieerd met een bepaald risicopotentieel vanwege het ontbreken van empirische waarden.

Klantparticipatie en feedback

Klanten worden bij elke fase van het project betrokken, totdat het project is voltooid. Daarom kunnen verschillende feedbacks worden verzameld om de volgende versie van het project te verbeteren.

Ook kan op elk moment feedback worden verkregen dankzij de spiraalvormige vervroeging. Zo kunnen klanten en gebruikers vanaf het begin in het ontwikkelingsproces worden geïntegreerd.

Ideaal voor grote projecten

Het is vooral populair en prominent voor grote en complexe projecten, waar budgetbewaking een prioriteit is voor klanten en ontwikkelaars. U heeft maximale controle over de kosten, middelen en kwaliteit van het softwareproject.

Nadelen

Duur

Het kan behoorlijk duur zijn, omdat het een hoog niveau van expertise vereist voor risicoanalyse. Bovendien kosten projecten veel tijd om zich te ontwikkelen, wat de overhead kan verhogen.

Best complex

Een zeer actief en complex voorafgaand beheer van het project is vereist, waarbij elke cyclus continu en zorgvuldig wordt gecontroleerd en gedocumenteerd.

Het is relatief complexer dan andere modellen, omdat er veel cycli zijn die elk verschillende fasen doorlopen, waardoor de inspanning van het documentatieproces toeneemt.

Kennis van risicoanalyse en -beheer, die vaak niet aanwezig is, is essentieel.

Tijdsbeheer

Tijd is moeilijk te beheren omdat het aantal cycli onbekend is. Bovendien kan het ontwikkelingsproces op elk moment worden vertraagd als er belangrijke beslissingen moeten worden genomen binnen een cyclus of door aanvullende acties bij het plannen van de volgende cyclus.

Veel stappen

Veel stappen zetten in softwareontwikkeling is niet altijd gunstig omdat, ondanks de veelzijdigheid van testen, onvoltooide delen van het programma het voltooide systeem kunnen bereiken.

Bijgevolg bestaat altijd het gevaar dat een conceptuele fout of inconsistentie het eindproduct beïnvloedt.

Referenties

1. Victor Font Jr (2019). Het spiraalmodel. De ultieme gids voor de SDLC. Genomen van: ultimatesdlc.com.
2. Ionos (2019). Spiraalmodel: het risicogestuurde procesmodel voor softwareontwikkeling. Genomen van: ionos.com.
3. Techuz (2018). Wat is een spiraalmodel? Een eenvoudige uitleg van Spiral Software Development Life Cycle (SDLC). Genomen van: techuz.com.
4. One Stop Testing (2020). Spiraalvormig model. Genomen van: onestoptesting.com.
5. Geeks for Geeks (2020). Software Engineering - Spiraalmodel. Ontleend aan: geeksforgeeks.org.
6. Chandu (2019). Spiraalmodel in software-engineering. Genomen van: medium.com.