6.2 Utviklingsmetoder

De fleste forbinder ordet bugg med insekter. I dataverdenen brukes ordet om feil i dataprogrammer. I IT-bransjen er det ofte tidsfrister underveis i et prosjekt. De som jobber på prosjektet, kan for eksempel ha blitt enige om tidspunkt der visse funksjoner skal være ferdige. Og når de har nådd et mål de har satt seg, oppstår det som regel behov for mer arbeid. Det kan være aktuelt å legge til flere funksjoner, ta bort gamle funksjoner, forbedre designet og brukervennligheten, fikse bugger og mye annet. Prosjektet kan sies å leve så lenge noen utvikler det videre. Kanskje deles prosjektet opp i flere prosjekter over tid. Et produkt kan leve i flere tiår etter at det først ble tatt i bruk, slik som Microsoft Windows og Google-søk.

Mappen som inneholder koden man jobber med i et prosjekt, kalles kodebasen.

TEAM

De som utfører et prosjekt, kalles for et team (eller arbeidslag, lag eller gruppe). Et team er med andre ord to eller flere personer som samarbeider om å lage et produkt. I en bedrift er det vanlig å øke antall teammedlemmer hvis man over lang tid har for mye å gjøre. Når det er mindre å gjøre, tar man personer ut av teamet, og da flytter man dem som regel til andre team i bedriften. Et team har sjelden flere enn seks–sju medlemmer. Et team som har flere medlemmer enn det, må ofte bruke så mye tid på å koordinere og kommunisere at vinningen går opp i spinningen.

Som regel er det én eller flere programmerere i teamet. Disse kalles utviklere. Dersom det teamet lager, har et brukergrensesnitt, trengs det interaksjonsdesignere som har spesialkompetanse på brukeropplevelse. Teamet har kanskje også en egen tester som kan spesielt mye om hvordan digitale produkter skal testes.

EKSTRASTOFF

IT-prosjekter med fastsatt sluttresultat og sluttdato

En sjelden gang har IT-prosjekter en bestemt sluttdato og et bestemt sluttresultat. Da vet de som står bak prosjektet, akkurat hva de trenger, slik at de kan sette en tidsfrist.

Når et fysisk produkt som ikke har Internett-tilkobling, forlater fabrikken, er det som regel for sent å oppdatere programvaren. Programvaren må derfor være ferdig og feilfri før produktet skal lanseres. Det er for eksempel ikke mulig å oppdatere programvaren i en datastyrt komfyr etter at den har forlatt fabrikken. Fra 1950- til 1980-årene sparte mange programmerere på lagringsplassen i dataprogrammer ved å sette av bare to sifre til å lagre årstall (de to siste sifrene i stedet for alle fire). Da årsskiftet mellom 1999 og 2000 nærmet seg, måtte mange bedrifter ha ett eller flere såkalte Y2K-prosjekter for å sikre at dataprogrammene deres ikke krasjet fordi de plutselig trodde at de var i år 1900 igjen. I disse prosjektene visste bedriftene hva de trengte (sikring mot krasj), og når de måtte ha det (senest ved inngangen til 1. januar 2000).

I IT-bransjen jobber man med prosjekter i ett eller flere team. Et team kan ha ansvaret for hele eller deler av et prosjekt. Det er vanlig at teammedlemmene veksler litt på oppgavene. Når det for eksempel er få oppgaver som har med interaksjonsdesign å gjøre, kan det være en fordel at interaksjonsdesigneren tar noen kodeoppgaver. Arbeidsdeling gjør teamet mer effektivt, for da kan alle bidra – også når det ikke er noe å gjøre innenfor akkurat deres spesialfelt. Arbeidsdeling forhindrer også at arbeidet med visse deler av koden stopper opp hvis et bestemt medlem skulle bli sykt eller slutte. Og selv om man liker noen oppgaver bedre enn andre, kan det være fint å holde kunnskapen ved like på flere områder.

OPPDRAGSGIVEREN

Oppdragsgiveren er den eller de som har bestemt at produktet skal lages, og som betaler for det.

•Hvis man lager et produkt, for eksempel en nettside eller et dataprogram, på bestilling for en bedrift, er oppdragsgiveren bedriften. • • Hvis produktet lages innad i en bedrift, er oppdragsgiveren én eller flere i ledelsen. Hvis du skal gjennomføre et prosjekt i dette faget, er oppdragsgiveren sannsynligvis læreren din eller deg selv.

I prosjekter som følger en fossefallsmetode, planlegges alle fasene på forhånd. Når en fase er over, er det for sent å gå tilbake.

Sett at en oppdragsgiver har bestilt et produkt av et team. Hvordan skal teamet gå frem for å finne ut hva oppdragsgiveren vil ha, og deretter lage det? Det finnes to overordnede måter å gjennomføre et prosjekt på: fossefallsmetoder og smidige utviklingsmetoder.

FOSSEFALLMETODER

Før i tiden var det vanlig at oppdragsgiveren og teamet analyserte oppdraget og la en fullstendig plan for hvordan produktet skulle produseres, før teamet laget det. Først ble partene enige om hva det ferdige produktet skulle gjøre. Deretter lagde teamet skisser til brukergrensesnitt og kodebase (gjerne med objektorientert modellering). Når planen så var lagt, kodet teamet hver enkelt bit, satte bitene sammen og testet programmet. Alt ble planlagt så detaljert som det var praktisk mulig, inkludert hvor lang tid hver oppgave skulle ta. Partene ble også enige om en tidsfrist for det ferdige produktet og en totalpris.

Tanken var at alt kom til å gå som smurt hvis man bare planla godt og fulgte planen. Slik var det imidlertid ikke i praksis. Når det ferdige produktet ble lansert, manglet det ofte funksjoner som brukerne ønsket seg, og mange ganger var det nesten umulig å bruke. Produktet ble dessuten ofte forsinket, for det viste seg at det ikke var så lett å beregne hvor lang tid det ville ta å utføre de enkelte oppgavene. Og hvis én oppgave ble forsinket, ble også oppgavene som var avhengige av denne, forsinket, og over tid hopet forsinkelsene seg opp.

Analyse Design Programmering Testing