Spiralmodellhistoria, egenskaper, stadier, exempel

4628
Basil Manning

De spiralmönster det är en arketyp av applikationsutvecklingsprocessen. Det bygger på hypotesen att programutveckling är en iterativ cykel som upprepas tills de fastställda målen uppnås. Den har förmågan att hantera det stora antalet risker som kan uppstå när någon programvara utvecklas.

Det är en av de viktigaste modellerna för att stödja riskhantering. Som namnet antyder visas den här modellen som spiralformad, där de olika stadierna i modellen fördelas i olika cykler. Antalet cykler i modellen är inte fast och kan variera från projekt till projekt.

Analys, utvärdering, planering och utveckling. Spiralkälla för mjukvaruutveckling: Beao [Public domain] commons.wikimedia.org

Artikelindex

  • 1 Historia
    • 1.1 Skapande
    • 1.2 Alternativ till vattenfallsmodellen
  • 2 Egenskaper hos spiralmodellen
    • 2.1 Riskkontroll
    • 2.2 Beskrivning av spiralen
    • 2.3 Generisk
    • 2.4 Flexibel
    • 2,5 Metamodell
  • 3 steg
    • 3.1 Bestäm mål, alternativ och begränsningar
    • 3.2 Riskbedömning
    • 3.3 Utveckling och testning
    • 3.4 Planera nästa cykel
  • 4 Exempel
  • 5 Fördelar
    • 5.1 Cyklisk struktur
    • 5.2 Riskhantering
    • 5.3 Kunddeltagande och feedback
    • 5.4 Perfekt för stora projekt
  • 6 Nackdelar
    • 6.1 Dyrt
    • 6.2 Ganska komplicerat
    • 6.3 Tidshantering
    • 6.4 Många steg
  • 7 Referenser

Berättelse

Skapande

Spiralmodellen definierades av den amerikanska matematikern och professor i programvaruteknik Barry Boehm. Efter att ha presenterat sitt koncept 1986 för utveckling av komplexa applikationer publicerade han sin modell 1988 i ett mer omfattande ramverk i sin artikel ”En spiralmodell för mjukvaruutveckling och förbättring".

En del av denna publikation från 1988 skildrade grafiskt spiralmodellen, som helt visade hur programvaruutvecklingsprocessen ser ut på ett spiralformat och stöds av cykler..

Boehm är känd för sina många bidrag till programvaruteknik, såsom den konstruktiva kostnadsmodellen (COCOMO), spiralmodellen för mjukvaruprocessen, G-Theory (win-win) -metoden för kravbestämning och hantering av programvaran..

Alternativ till vattenfallsmodellen

I sin publikation beskrev Boehm spiralmodellen som ett möjligt alternativ till den tidigare etablerade vattenfallsmodellen, som också fungerade som grund för hans praktik..

Spiralmodellen var inte den första som diskuterade cyklisk utveckling, men den var den första som förklarade varför iteration är viktig. Som ursprungligen tänkt har det riktats in mot stora, komplexa projekt vars iterationer vanligtvis sträcker sig från 6 månader till 2 år..

Denna modell antar inte att mjukvaruutvecklingsuppgifter är utformade linjärt, till skillnad från vattenfallsmodellen, utan ser dem som iterativa uppgifter.

Denna cykliska modell påverkade modellbaserad programvaruteknik (MBASE) och extrem programmering.

Funktioner i spiralmodellen

Riskkontroll

Det som i hög grad skiljer denna modell från andra programvarumodeller är att den uttryckligen känner igen risker. Det minskar alltså avsevärt misslyckandet i stora programvaruprojekt genom att upprepade gånger bedöma risker och verifiera produkten under utveckling varje gång..

Den här datormodellen innehåller komponenter från nästan alla andra modeller av programvarans livscykel, såsom vattenfallsmodellen, prototypmodellen, den iterativa modellen, den evolutionära modellen etc..

På grund av detta kan den hantera nästan alla typer av risker som andra modeller vanligtvis inte hanterar. Men på grund av att ha så många komponenter är den här modellen mycket mer komplex än de andra mjukvaruutvecklingsmodellerna..

Beskrivning av spiralen

Varje spiralvarv representerar en komplett cykel, genom vilken de fyra kvadranten alltid passerar, vilket representerar modellens fyra steg..

När spiralens storlek ökar ökar också framstegen. Därför utförs stegen inte bara en gång utan flera gånger i form av en spiral..

Även om denna cykliska upprepning gör att projektet långsamt närmar sig de fastställda målen minimeras risken att utvecklingsprocessen misslyckas..

Generisk

De fyra stegen implementerar bara de grundläggande målen för en cykel, men de behöver inte manifesteras i varje cykel.

Ordningen på varje cykel bestäms inte heller strikt. Därför kan modellen när som helst kombineras med andra modeller.

Flexibel

Det är ganska flexibelt eftersom processerna för att definiera mål, riskanalys, utveckling och planering utförs separat för varje fas av projektet..

Metamodell

Det anses vara en metamodell eftersom den innehåller de andra modellerna. Om spiralen till exempel var av en enda cykel skulle den representera vattenfallsmodellen, eftersom den innehåller den gradvisa metoden för denna klassiska modell.

Den använder också prototypmodellmetoden, eftersom den i början av varje cykel monterar en prototyp för att hantera risker..

Dessutom är den kompatibel med den evolutionära modellen, eftersom spiralens iterationer kan betraktas som evolutionära nivåer, genom vilka det slutliga systemet byggs..

Stadier

Bestäm mål, alternativ och begränsningar

Systemkrav definieras så mycket detaljerat som möjligt, inklusive prestanda, hårdvaru- / mjukvarugränssnitt, nyckelindikatorer för framgång etc. och överväga vilka mål som ska associeras med den aktuella utvecklingscykeln.

Dessutom undersöks olika alternativ för dess implementering, såsom build vs. köpa, återanvända befintliga komponenter eller lägga ut, etc..

På samma sätt bestäms begränsningar som kostnad, schema och gränssnitt, tidsförbrukning etc..

Riskbedömning

Alla föreslagna alternativ utvärderas. Målen och begränsningarna fungerar som avgörande referenser för att välja den bästa lösningen.

Dessutom identifieras de risker som kan hindra framgången för projektet, såsom brist på erfarenhet, ny teknik, snäva scheman, bristfälliga processer etc., som implementerar de mest lönsamma strategierna med lägsta risk..

Slutligen används metoder som prototyper, simuleringar, analytiska modeller och användarundersökningar..

Utveckling och testning

All nödvändig utveckling genomförs med den valda tekniken och lösningen. För varje iteration skapas en bättre version av applikationen.

Den faktiska koden skrivs och testas flera gånger tills önskat resultat uppnås, som sedan kommer att tjäna som grund för framtida utvecklingssteg.

Planerar nästa cykel

När du har slutfört en cykel börjar planeringen för nästa. Denna planering kan vara att fortsätta normalt med projektet om syftet med cykeln nåddes, med tanke på definitionen av nästa mål.

Det kan också vara att hitta andra lösningar om det tidigare utvecklingsstadiet visade sig vara felaktigt. Den befintliga strategin kan ersättas med ett av de tidigare definierade alternativen eller en ny. Med detta skulle ett nytt försök att nå det givna målet startas..

Exempel

USA: s armé antog spiralmodellen för utveckling och uppdatering av moderniseringsprogrammet Future Fighting Systems (SCF)..

Officiellt lanserades 2003 planerades SCF: er att utrusta trupper med fordon i realtid kopplade till ett extremt snabbt och flexibelt nätverk av slagfält..

Projektet delades in i fyra utvecklingsspiraler på vardera två år. Spiral 1 var planerad att starta 2008 och leverera prototyper för användning och utvärdering..

Efter avslutad Spiral 1 var Spiral 2 planerad att börja 2010. Den slutliga produktutvecklingen var planerad att levereras 2015..

I augusti 2005 tillkännagav Boeing att projektets första stora milstolpe hade slutförts, vilket var systemets funktionella översyn. Boeing och Science Applications International Corporation var medledare för projektet.

Men i oktober 2005 rekommenderade Pentagon att försena projektet på grund av den stora påverkan på kostnaderna från Irak-kriget och hjälp från orkanen Katrina..

Projektet avbröts 2009 efter budgetnedskärningar utan att kunna bevisa fördelarna med spiralmodellen i detta uppdrag.

Fördel

Cyklisk struktur

På grund av denna typ av struktur elimineras stilla problem mellan designen och de tekniska kraven för programvaran tack vare periodiska kontroller..

Riskhantering

Riskerna analyseras i varje steg i produkten innan de fortsätter. Detta hjälper till att övervinna eller mildra potentiella risker.

Alla anställda drar nytta av den stora betydelsen av riskanalys i denna modell, vilket möjligen representerar deras största fördel jämfört med andra processmodeller.

Regelbunden riskbedömning får värde när man använder nya tekniska miljöer, som i allmänhet är förknippade med en viss riskpotential på grund av frånvaron av empiriska värden.

Kunddeltagande och feedback

Kunder deltar i varje steg i projektet tills projektet är klart. Därför kan olika feedback samlas för att förbättra nästa version av projektet..

Dessutom kan feedback erhållas när som helst på grund av spiralförskottet. Således kan kunder och användare integreras från början i utvecklingsprocessen.

Perfekt för stora projekt

Det är särskilt populärt och framträdande för stora och komplexa projekt, där budgetkontroll är en prioritet för kunder och utvecklare. Du har maximal kontroll över programvaruprojektets kostnader, resurser och kvalitet.

Nackdelar

Dyr

Det kan vara ganska dyrt eftersom det kräver hög kompetens för riskanalys. Dessutom tar projekt mycket tid att utveckla, vilket kan öka omkostnaderna.

Ganska komplex

Det krävs en mycket aktiv och komplex förvaltning av projektet där varje cykel kontinuerligt och noggrant kontrolleras och dokumenteras.

Det är jämförelsevis mer komplicerat än andra modeller, eftersom det finns många cykler, som alla går igenom olika steg, vilket ökar ansträngningen för dokumentationsprocessen..

Kunskap om riskanalys och hantering, som ofta inte är tillgänglig, är väsentlig.

Tidsplanering

Tidshantering är svår eftersom antalet cykler är okänt. Dessutom kan utvecklingsprocessen försenas när som helst om viktiga beslut behöver fattas inom en cykel eller genom ytterligare åtgärder när du planerar nästa cykel..

Många steg

Det är inte alltid fördelaktigt att genomföra många steg i mjukvaruutveckling på grund av att trots oavslutade tester kan oavslutade delar av programmet nå det färdiga systemet..

Som en konsekvens finns det alltid risken att eventuella fel eller konceptuella inkonsekvenser påverkar den slutliga produkten..

Referenser

  1. Victor Font Jr (2019). Spiralmodellen. Den ultimata guiden till SDLC. Hämtad från: Ultimatesdlc.com.
  2. Ionos (2019). Spiral model: den riskdrivna programvaruutvecklingsmodellen. Hämtad från: ionos.com.
  3. Techuz (2018). Vad är spiralmodell? En enkel förklaring av Spiral Software Development Life Cycle (SDLC). Hämtad från: techuz.com.
  4. One Stop Testing (2020). Spiralmodell. Hämtad från: onestoptesting.com.
  5. Geeks for Geeks (2020). Programvaruteknik - Spiral Model. Hämtad från: geeksforgeeks.org.
  6. Chandu (2019). Spiral Model in Software Engineering. Hämtad från: medium.com.

Ingen har kommenterat den här artikeln än.