Bedrift

En introduksjon til Inkrementell utvikling - med fordeler og ulemper

Nesten alle agile team bruker inkrementell utvikling når de utvikler en ny programvare.


Det betyr at de deler opp et prosjekt i flere mindre deler, som alle er av betydning for prosessen som en helhet.


I en agil kontekst betyr dette at hver versjon av et produkt er brukbar. Samtidig er hver ny versjon en videreutvikling av den forrige, hvor man legger til brukervennlig funksjonalitet.


Dette får man til ved å dele opp hver syklus i en prosess i flere mindre og enklere sykluser.


Inkrementell utvikling er en måte å forklare en prosess innen programvareutvikling som følger et visst mønster.


Selve meningen med metoden er at man skal lære av de første versjonene av et system eller en programvare, og finne ut hva man kan gjøre bedre i det allerede eksisterende systemet i neste del av utviklingen.


La oss se nærmere på hva inkrementell utvikling egentlig er.


Inkrementell utvikling = Bygg en fungerende programvare flere ganger


I denne modellen for programvareutvikling, vil hver eneste del av programvaren gå gjennom kravene, designet, implementeringen og testing hver for seg.


En fungerende versjon av programvaren vil være klar allerede etter første syklus i prosessen.


Hver eneste del som blir utviklet etter den første, vil legge til funksjoner til den forrige delen. Slik fortsetter man helt til programvaren er ferdig utviklet.


Når man bruker en inkrementell utviklingsstrategi legger man til del for del på et produkt eller en tjeneste, hvor hver enkelt del er fullt utviklet og klar til bruk.


Når en utvikler begynner å bygge en programvare, vil allerede den første versjonen være klar for å testes som en demoversjon av kundene.


Videre vil neste modul være fullstendig utviklet og kan integreres med den første delen.


Del for del vil produktet til slutt ferdigstilles som en fullstendig programvare som er klart til bruk, og som er den beste versjonen av programvaren, fordi hver eneste del som er blitt lagt til er blitt testet og validert av faktiske kunder.

Leter din bedrift etter dyktige folk?
Se gjennom profiler til 700 frilansere og konsulenter i Norge
- som de dyktige folkene under her!
Opprett bedriftsbruker
Tilgjengelig nå
Yngve Skråmm
UX Designer / Interaksjonsdesigner
Heltid eller deltid
Oslo
1100
Kr/t

UX

Interaksjonsdesign

Informasjonsarkitektur

HTML

CSS

JavaScript

Se full profil
Tilgjengelig nå
Hanne Årsnes
Grafisk designer
Heltid eller deltid
Ålesund
1200
Kr/t

Photoshop

Indesign

Illustrator

Se full profil

Hvor kommer idéen om inkrementell utvikling fra?


La oss ta en titt på historien for å forstå hvorfor denne metode for programvareutvikling ble utarbeidet.


1980:


Idéen ble første gang diskutert i IBMs Federal Systems Division i et volum om «Principles of software engineering», hvor det blir anbefalt å organisere «hvert trinn for å maksimere separasjonen av funksjonen(e) fra funksjonen(e) i andre trinn».


I denne perioden var likevel idéen fortsatt bundet til en fastsatt tilnærming for utvikling basert på faser, enn en tilnærming som raskt kan reagere på endringer, slik den agile metoden fungerer.


1984:


Mens kritikk av metoden kalt «waterfall» startet mye tidligere, ble formuleringene av alternative inkrementelle metoder nå mer fremtredende og forklart mer tydelig.


Et godt eksempel er en artikkel om «Knowledge-based communication processes in software engineering» som taler for inkrementell utvikling av den spesifikke grunnen at «komplette og stabile spesifikasjoner ikke er tilgjengelige».


1985:


Det første eksplisitte navngitte, inkrementelle alternativet til «waterfall»-metoden blir utviklet av Tom Gilb, som ble kalt Evolutionary Delivery Model, men gikk under kallenavnet «Evo».


1999:


I en artikkel for rapporten C++ gir Robert C. Martin kanskje den aller første beskrivelsen av den agile meningen med termene «iterativ» og «inkrementell».


Hvordan skiller inkrementell utvikling seg fra «waterfall»-metoden?


Ved bruk av «waterfall»-metoden for utvikling av programvare, vil et produkt bli levert i sin helhet på slutten av prosjektet.


Man ferdigstiller altså hele programvaren før den leveres til kunden og kan valideres med en prototype.


Det er flere måter disse to modellene skiller seg sterkt fra hverandre, blant annet ved:


Brukerdeltagelse


I «waterfall»-metoden blir brukeren kun involvert i et steg av prosessen, nemlig i steget for etterspørsel og behov. Med inkrementell utvikling blir brukeren derimot involvert i hvert eneste steg av utviklingen.


Variabilitet


Programvaren blir levert til kunden først når hele produktet er klart og ferdig utviklet med «waterfall»-modellen. Ved bruk av den inkrementelle metoden blir derimot hvert steg i utviklingen testet av brukere, slik at utvikleren først kan gå videre til neste modul etter å ha fått den forrige modulen godkjent og validert av brukeren.


HR


Det kreves færre ansatte med ved bruk av en inkrementell utviklingsmetode enn ved bruk av «waterfall»-metoden.


Tidsbegrensing


Med «waterfall»-metoden blir et fullt funksjonelt kvalitetsprodukt levert til kunden etter flere måneder, mens det kun tar noen få uker ved bruk av inkrementell utvikling.


Størrelsen på prosjektet


For små prosjekter, vil man ikke kunne benytte seg av «waterfall»-metoden, mens den inkrementelle utviklingsstrategien kan brukes når man skal arbeide med både små og store prosjekter.


Fordeler med å bruke inkrementell utviklingsstrategi


Det er en del fordeler med å bruke denne strategien for utvikling av programvare, blant annet:


·        Genererer fungerende programvarer raskt og tidlig under utviklingsfasen.

·        Det er en svært fleksibel modell, fordi den er mindre kostbar når man skal endre omfang og krav.

·        Det er enklere å gjøre feilsøk og testinger ved mindre feil eller mangler.

·        Lavere kostnader for utvikling.

·        Det er lettere å håndtere risikoer fordi risikable deler blir identifisert og håndtert under utvikling av den enkelte delen.


Ulemper ved bruk av den inkrementelle metoden


Ingen modeller eller metoder er feilfrie, noe som også gjelder for den inkrementelle utviklingsstrategien.


Disse ulempene bør du vurdere før du tar i bruk denne modellen for utvikling av programvare:


·        Krever nøye planlegging og design.

·        Behov for en klar og komplett definisjon av hele systemet før den deles opp i mindre deler og man kan begynne å utvikle inkrementelt.

·        De totale kostnadene kan være høyere enn ved bruk av andre metoder.


Når bør man benytte seg av inkrementell utvikling?


Det vil kanskje ikke alltid være lurt å bruke den inkrementelle metoden fremfor andre ved ethvert prosjekt.


Dette er selvsagt noe man må vurdere for den enkelte situasjonen man står overfor.


Men ved visse typer prosjekter, bør den absolutt brukes, fordi den vil være både nyttig og effektiv.


Ved disse tilfellene bør man benytte seg av inkrementell utvikling:

·        Denne modellen for programvareutvikling bør benyttes når kravene for det komplette systemet er klart definerte og enkle å forstå.

·        Når hovedpunktene i produktet er definerte, men detaljene kan utvikles over tid ettersom prosjektet går fremover.

·        Det er behov for at et produkt skal være på markedet så raskt som mulig.

·        Når man bruker ny teknologi for utviklingen av programvaren.

·        Dersom ressursene med nødvendige ferdigheter ikke er tilgjengelige.

·        Det er høy risiko ved prosjektet og målene.

Relaterte poster

Bli en del
av Flexify

For bedrifter

Registrerer deg for å finne riktig konsulent eller frilanser
Opprett bedriftsbruker

For konsulenter

Bli en del av Flexify, så får du tilgang til spennende oppdrag
Jeg er konsulent
Flexify 2019 ©
Privacy policy