SPIRALMODELL: HISTORIE, EGENSKAPER, STADIER, EKSEMPEL - TEKNOLOGI - 2026

Den spiral modellen er en arketype påføringsprosessen. Det er basert på hypotesen om at programvareutvikling er en iterativ syklus som gjentas inntil de etablerte målene er nådd. Den har muligheten til å håndtere det store antallet risikoer som kan oppstå når du utvikler programvare.

Det er en av de viktigste modellene for å støtte risikostyring. Som navnet antyder, er denne modellen vist som spiralformet, der de forskjellige stadiene av modellen er fordelt i forskjellige sykluser. Antall sykluser i modellen er ikke faste og kan variere fra prosjekt til prosjekt.

Analyse, evaluering, planlegging og utvikling. Programvareutvikling Spiralkilde: Beao commons.wikimedia.org

Historie

Opprettelse

Spiralmodellen ble definert av den amerikanske matematikeren og programvareingeniørprofessoren Barry Boehm. Etter å ha presentert sitt konsept i 1986 for utvikling av komplekse applikasjoner, publiserte han modellen sin i 1988 i en mer omfattende ramme i sin artikkel "A Spiral Model of Software Development and Improvement".

En del av denne publikasjonen fra 1988 avbildet spiralmodellen grafisk, og viser fullstendig hvordan programvareutviklingsprosessen ser ut på en spiralformet måte og støttet av sykluser.

Boehm er kjent for sine mange bidrag til programvareteknikk, for eksempel den konstruktive kostnadsmodellen (COCOMO), spiralmodellen for programvareprosessen, G-teorien (vinn-vinn) tilnærming til kravbestemmelse og styring. av programvaren.

Alternativ til fossemodellen

I sin publikasjon beskrev Boehm spiralmodellen som et mulig alternativ til den tidligere etablerte fossefallmodellen, som også fungerte som grunnlag for hans praksis.

Spiralmodellen var ikke den første som diskuterte syklisk utvikling, men den var den første modellen som forklarte hvorfor iterasjon er viktig. Som opprinnelig planlagt, har det vært målrettet mot store, komplekse prosjekter hvis iterasjoner vanligvis varierer fra 6 måneder til 2 år.

Denne modellen forutsetter ikke at programvareutviklingsoppgaver er utformet lineært, i motsetning til fossefallmodellen, men ser dem heller som iterative oppgaver.

Denne sykliske modellen påvirket Model Based Software Engineering Architecture (MBASE) og ekstrem programmering.

Funksjoner i spiralmodellen

Risikokontroll

Det som i stor grad skiller denne modellen fra andre programvareprosessmodeller er at den eksplisitt anerkjenner risikoer. Dermed reduserer det svikt i store programvareprosjekter ved gjentatte ganger å vurdere risiko og verifisere produktet under utvikling hver gang.

Denne datamodellen inneholder komponenter fra nesten alle andre modeller av programvarens livssyklus, for eksempel fossefallmodellen, prototypingsmodellen, den iterative modellen, den evolusjonsmodellen og så videre.

På grunn av dette er den i stand til å håndtere nesten alle typer risikoer som andre modeller generelt ikke håndterer. På grunn av å ha så mange komponenter, er denne modellen imidlertid mye mer kompleks enn de andre programvareutviklingsmodellene.

Beskrivelse av spiralen

Hver sving i spiralen representerer en komplett syklus, gjennom hvilken de fire kvadrantene alltid passerer, og representerer de fire trinnene i modellen.

Når spiralstørrelsen øker, gjør også fremskrittene. Derfor blir scenene ikke utført bare en gang, men flere ganger, i spiralform.

Selv om denne konjunkturrepetisjonen gjør at prosjektet sakte nærmer seg de etablerte målene, minimeres risikoen for at utviklingsprosessen mislykkes.

Generisk

De fire trinnene implementerer bare de grunnleggende målene for en syklus, men de trenger ikke å bli manifestert i hver syklus.

Rekkefølgen på hver syklus er heller ikke strengt bestemt. Derfor kan modellen når som helst kombineres med andre modeller.

fleksibel

Den er ganske fleksibel, ettersom den utfører måldefinisjonen, risikoanalysen, utviklings- og planleggingsprosessene hver for seg i hver fase av prosjektet.

meta

Det regnes som en metamodel fordi den inkluderer de andre modellene. For eksempel, hvis spiralen var en enkel syklus, ville den representere fossemodellen, siden den inkluderer den gradvise tilnærmingen til denne klassiske modellen.

Han bruker også prototyping-modelltilnærmingen, da han i begynnelsen av hver syklus setter sammen en prototype for å styre risiko.

I tillegg er den kompatibel med den evolusjonære modellen, fordi spiralens iterasjoner kan betraktes som evolusjonsnivåer, gjennom hvilke det endelige systemet bygges.

Stages

Bestem mål, alternativer og begrensninger

Systemkrav er definert i så mye detalj som mulig, inkludert ytelse, maskinvare / programvare-grensesnitt, viktige indikatorer for suksess, etc. og hvilke mål som bør knyttes til den nåværende utviklingssyklusen vurderes.

I tillegg undersøkes forskjellige alternativer for implementering, for eksempel build vs. kjøp, gjenbruk eksisterende komponenter eller outsource osv.

På samme måte bestemmes begrensninger som kostnad, tidsplan og grensesnitt, tidsforbruk osv.

Evaluering av risiko

Alle foreslåtte alternativer evalueres. Målene og begrensningene fungerer som bestemmende referanser for å velge den beste løsningen.

I tillegg identifiseres risikoer som kan hindre suksessen til prosjektet, som mangel på erfaring, nye teknologier, stramme tidsplaner, mangelfulle prosesser, etc., implementere de mest lønnsomme strategiene med lavest risiko.

Til slutt brukes metoder som prototyping, simuleringer, analytiske modeller og brukerundersøkelser.

Utvikling og testing

All nødvendig utvikling blir utført ved bruk av teknologien og valgt løsning. Med hver iterasjon opprettes en bedre versjon av applikasjonen.

Den faktiske koden skrives og testes flere ganger til ønsket resultat er nådd, som da vil tjene som grunnlag for fremtidige utviklingstrinn.

Planlegger neste syklus

Etter fullført en syklus begynner planleggingen for den neste. Denne planleggingen kan være å fortsette med prosjektet normalt hvis syklusens mål ble nådd, med tanke på definisjonen av neste mål.

Det kan også være å finne andre løsninger, hvis det forrige utviklingsstadiet viste seg å være feil. Den eksisterende strategien kan erstattes av et av de tidligere definerte alternativene eller en ny. Med dette ville et nytt forsøk på å nå det gitte målet bli startet.

Eksempel

Det amerikanske militæret vedtok spiralmodellen for utvikling og oppgradering av Future Fighting Systems (SCF) moderniseringsprogram.

Offisielt lansert i 2003, ble SCFs tenkt å utstyre tropper med kjøretøyer koblet i sanntid til et ekstraordinært raskt og fleksibelt nettverk av slagmarker.

Prosjektet ble delt inn i fire utviklingsspiraler på omtrent to år hver. Spiral 1 skulle etter planen begynne i 2008 og levere prototyper for bruk og evaluering.

Etter fullføring av spiral 1 var planlagt spiral 2 å begynne i 2010. Endelig produktutvikling skulle etter planen leveres i 2015.

I august 2005 kunngjorde Boeing ferdigstillelse av prosjektets første store milepæl, som var den funksjonelle overhalingen av systemene. Boeing og Science Applications International Corporation var lederne for prosjektet.

For oktober 2005 anbefalte Pentagon imidlertid å utsette prosjektet på grunn av den store innvirkningen på kostnadene fra Irak-krigen og bistanden fra orkanen Katrina.

Prosjektet ble avlyst i 2009 etter at budsjettkutt kom frem, uten å kunne bevise fordelene med spiralmodellen i dette oppdraget

Fordel

Syklisk struktur

På grunn av denne typen struktur elimineres problemene mellom design og tekniske krav til programvaren stilltiende, takket være periodiske kontroller.

Risikostyring

Risikoen blir analysert i hvert trinn av produktet før du fortsetter videre. Dette bidrar til å overvinne eller avbøte potensielle risikoer.

Alle ansatte drar fordel av den store viktigheten av risikoanalyse i denne modellen, og representerer muligens deres største fordel i forhold til andre prosessmodeller.

Regelmessig risikovurdering er verdifull når man bruker nye tekniske miljøer, som generelt er forbundet med et spesielt risikopotensial på grunn av fravær av empiriske verdier.

Kundedeltakelse og tilbakemelding

Kunder er involvert i hvert trinn i prosjektet, helt til prosjektet er fullført. Derfor kan forskjellige tilbakemeldinger samles for å forbedre den neste versjonen av prosjektet.

Tilbakemelding kan også oppnås når som helst på grunn av spiralformet fremskritt. Dermed kan kunder og brukere integreres fra begynnelsen av i utviklingsprosessen.

Ideell for store prosjekter

Det er spesielt populært og fremtredende for store og komplekse prosjekter, der budsjettkontroll er en prioritet for klienter og utviklere. Du har maksimal kontroll over kostnadene, ressursene og kvaliteten til programvareprosjektet.

ulemper

Dyrt

Det kan være ganske dyrt, da det krever høy kompetanse for risikoanalyse. I tillegg tar prosjekter mye tid å utvikle seg, noe som kan øke overhead.

Ganske kompleks

Det kreves en veldig aktiv og kompleks tidligere styring av prosjektet, der hver syklus kontinuerlig og nøye kontrolleres og dokumenteres.

Det er relativt mer sammensatt enn andre modeller, fordi det er mange sykluser som hver går gjennom forskjellige stadier, og dermed øker innsatsen i dokumentasjonsprosessen.

Kunnskap om risikoanalyse og styring, som ofte ikke er tilgjengelig, er essensiell.

Tidsfordriv

Tid er vanskelig å styre ettersom antallet sykluser er ukjent. I tillegg kan utviklingsprosessen til enhver tid bli forsinket hvis viktige beslutninger må tas innen en syklus eller ved ytterligere tiltak når du planlegger neste syklus.

Mange trinn

Å ta mange trinn i programvareutvikling er ikke alltid gunstig på grunn av det faktum at til tross for allsidigheten i testing, kan uferdige deler av programmet nå det ferdige systemet.

Som en konsekvens er det alltid faren for at enhver konseptuell feil eller inkonsekvens vil påvirke sluttproduktet.

referanser

1. Victor Font Jr (2019). Spiralmodellen. Den ultimate guiden til SDLC. Hentet fra: ultimatesdlc.com.
2. Ionos (2019). Spiralmodell: den risikodrevne prosessmodellen for programvareutvikling. Hentet fra: ionos.com.
3. Techuz (2018). Hva er spiralmodell? En enkel forklaring av Spiral Software Development Life Cycle (SDLC). Hentet fra: techuz.com.
4. One Stop Testing (2020). Spiralmodell. Hentet fra: onestoptesting.com.
5. Geeks for Geeks (2020). Programvareteknikk - spiralmodell. Hentet fra: geeksforgeeks.org.
6. Chandu (2019). Spiralmodell i programvareteknikk. Hentet fra: medium.com.