Typer av programvare prosessmodeller

Designe, bygge og vedlikeholde programvare tar tid, penger og fremfor alt en metode, en linje for angrep. Ellers tusener på tusener av beslektede oppgaver software engineering krever ville raskt gå galt. Som programvare og bruken har utviklet seg og mangedoblet, så også har de prosessene som brukes til å produsere den.

typer

I dag faktisk er det hundrevis av utviklingsmodeller, men i praksis mange er varianter på et dusin eller så grunnleggende modeller. Den mest brukte er: foss, spiral, kode-and-fix, rapid prototyping, hyllevare (COTS) tweaking, kast prototyping, ekstrem programmering (XP), enhetlig prosess (UP), og den smidige prosess. Bestemme å ansette avhenger i stor grad på fremtidige sluttbrukerkrav og forventninger, prosjektets kompleksitet og påfølgende drift vedlikehold og tidspress overfor programvareingeniører.

Betydning

Skrive, montering og testing av koden er en veldig krevende, veldig forseggjort foretak. Funksjonen blir datastyrt må brytes ned i sine atskilte deler, oppgaver og drift av hver del oversatt til linjer med kode, og deretter disse blokkene med kode integrert med sine omkringliggende blokker og programmet som helhet. Når den er oppe og går, uforutsette glitches alltid overflaten krever patcher og feilrettinger. Et program med en lang levetid-span må også jevnlig oppdatert.

Expert Insight

Enkelte modeller passe noen organisasjoner bedre enn andre. Uforanderlige miljøer, Frank Kand av London School of Economics observert, har svært spesifikke standard operasjonsprosedyrer. Modeller stole på streng dokumentasjon og nitidig utvikling som fossen og spiral fungerer best her. Men hvis konstant forandring er normen, er en organisasjon bedre tjent med rapid prototyping. Noen ganger, skjønt, lærer organisasjonen når den beveger seg fremover, og programvareutviklere må forholde seg til ukjente. Her kast prototyping, utforskende utvikling og smidige programvare prosesser fungerer bedre.

strukturerte prosesser

Grundig og tidkrevende, fossen Process "definerer før det design" og "design før det koder." Brukernes behov er dokumentert og programvarekrav identifisert, deretter systemets arkitektur er utformet; koding og testing følger. Men det er ikke en iterativ prosess, en hvor design ideer og kode er gjentatte ganger revisited og raffinert. Ofte vage brukerkrav komme tilbake å hjemsøke utviklere. Tar en mer gradvis tilnærming, forvalter spiral prosessen denne og andre farer. Hver fase leverer en del av den ferdige programvare. Risiko og begrensninger blir analysert og nye tilnærminger utforsket på forhånd. Utviklere derfor ofte kombinere begge prosesser.

ustrukturerte Prosesser

Sluttbrukere ofte tilstede utviklere med i beste fall en overfladisk sett med innledende kravene. Så designere bygge en prototype med klienten, teste den, raffinere den og teste den på nytt før kunden er fornøyd. Noen ganger utviklerne mangler selv de mest elementære sett sluttbruker krav på et prosjekt start, og dermed stole på en on-the-fly, kode og-fikse utforskende prosess. COTS brukes når tid og finansiering begrensninger veie tungt. Selv om hensiktsmessig, tweaking off-the-sokkel programvaren har en ulempe: funksjonelle kompromisser ofte må gjøres og interoperabilitet problemer vinne.