8.6 Systemutvikling og prosessmodeller

Programmeringen er en mindre del av det enn de fleste tror. Å finne ut hva som skal lages, og å holde det i live etterpå, tar til sammen langt mer tid enn å skrive koden.

Alle prosessmodeller består av de samme fire grunnaktivitetene:

1. Spesifikasjon — hva skal systemet gjøre?
2. Utvikling — design og programmering.
3. Validering — gjør det det skal?
4. Evolusjon — hvordan holdes det i live og endres over tid?

Det som skiller modellene, er ikke hvilke aktiviteter de har, men rekkefølgen og hvor mange ganger de gjentas.

Aktiviteten der man finner ut hva systemet skal gjøre, og skriver det ned slik at både kunden og utviklerne forstår det likt.

Arbeidet består i å snakke med dem som skal bruke systemet, forstå arbeidet deres, og oversette det til krav som kan bygges og kontrolleres.

Hvorfor dette er den dyreste å gjøre feil: en misforståelse her forplanter seg gjennom alt annet. Oppdages den først når systemet er ferdig, må design, kode og tester gjøres om. Er den derimot oppdaget i spesifikasjonen, koster den en samtale.

Resultatet av aktiviteten er kravspesifikasjonen, som du møter i løkke 3.

Aktiviteten der systemet faktisk lages: først design — hvordan systemet skal bygges opp — og deretter implementasjon, altså programmeringen.

Designet svarer på spørsmål som: hvilke deler skal systemet ha, hva skal hver del gjøre, hvordan skal delene snakke sammen, hvordan skal dataene lagres?

Å hoppe over designet og begynne å programmere med én gang, virker på et lite program og bryter sammen på et stort. Det er derfor systemarkitekturen — den overordnede oppdelingen — er et eget begrep.

Aktiviteten der man kontrollerer at systemet gjør det det skal, og at det er det kunden faktisk trengte.

Validering er mer enn testing av kode. Den svarer på to ulike spørsmål, og forskjellen er verdt å merke seg:

- Verifisering: bygde vi systemet riktig? Virker koden som spesifisert?
- Validering: bygde vi riktig system? Er det dette kunden trengte?

Et system kan bestå alle tester og likevel være ubrukelig, hvis spesifikasjonen var feil. Det er nettopp derfor akseptansetesting — der kunden selv prøver systemet — er et eget steg.

Aktiviteten som varer lengst: å endre systemet etter at det er tatt i bruk.

Endringene kommer av at verden endrer seg — nye lover, nye behov, nye maskiner å kjøre på — og av feil som først dukker opp i virkelig bruk.

Poenget for eksamen: for et system som lever lenge, koster evolusjonen mer enn den opprinnelige utviklingen. Et system som er i drift i ti år, er under endring i ti år.

Det er også begrunnelsen for mye av det du lærer i kodedelen av boka: lesbar kode, funksjoner som gjenbrukes, navn som forklarer seg selv. Ikke fordi det er penere, men fordi noen skal endre koden om fem år.

Den eldste og enkleste prosessmodellen: fasene utføres sekvensielt, én ferdig før den neste begynner, som vann som renner nedover trappetrinn.

Fasene i den vanlige framstillingen:

1. Kravspesifikasjon
2. Design (systemarkitektur)
3. Implementasjon
4. Testing
5. Drift og vedlikehold

Figur i ord: tegn fem trinn nedover fra venstre mot høyre, hvert trinn en boks, med en pil fra hver boks ned til den neste. Ingen piler går oppover. Det er hele modellen — og hele problemet med den.

Styrken: enkel å planlegge, enkel å følge opp, og hvert trinn gir et dokument som kan godkjennes. Den passer der kravene er kjent og stabile fra starten.

Svakheten: man ser ikke noe kjørende system før langt ut i løpet, og en misforstått kravspesifikasjon oppdages først i testfasen — når alt allerede er bygd på den. Endringer er dyre nettopp fordi modellen ikke er laget for å gå tilbake.

Det ene ordet som spørres om, er «sekvensielle faser».

Systemet bygges i flere små deleveranser — inkrementer — der hver av dem er noe som virker og kan vises fram.

Man begynner med det viktigste, får tilbakemelding, og lar tilbakemeldingen påvirke neste inkrement.

Styrken: kunden ser noe tidlig, misforståelser oppdages mens de er billige å rette, og endrede krav kan tas inn underveis.

Svakheten: helheten kan bli uoversiktlig, og strukturen kan forfalle hvis man aldri stopper opp og rydder. Det er også vanskeligere å si nøyaktig når man er ferdig.

Fellen: å tro at inkrementell er det samme som vannfall bare med flere leveranser. Forskjellen er at inkrementell går tilbake og endrer ut fra det man lærte, mens vannfall gjør hver fase ferdig én gang.

En iterativ og risikodrevet modell, formulert av Barry Boehm. Utviklingen går i runder, og hver runde har fire deler:

1. Sett mål for runden.
2. Vurder risiko og finn alternativer.
3. Utvikle og kontroller.
4. Planlegg neste runde.

Figur i ord: tegn en spiral som starter i midten og går utover i stadig større sirkler. Del sirkelen i fire kvadranter, én for hver av de fire delene. Avstanden fra midten viser hvor mye som er investert; hver omdreining er én runde.

Det som er særegent for spiralmodellen, er risikovurderingen. Andre modeller kan være iterative uten å være risikodrevne. I spiralen er det nettopp risikoen som avgjør hva som gjøres i neste runde — er noe usikkert, tar man det først, mens det ennå er billig å snu.

Det ene ordet som spørres om, er «risiko».

En familie av arbeidsmåter som bygger på inkrementell utvikling, med korte runder — typisk to til fire uker — og tett kontakt med kunden hele veien.

Kjennetegn: fungerende programvare framfor omfattende dokumentasjon, og evne til å ta imot endrede krav framfor å følge en plan som ble lagt for et år siden.

Smidig utvikling er i praksis motstykket til vannfallsmodellen, og de to settes ofte opp mot hverandre i flervalgsalternativer.

Merk: arkivet 2014–2019 spør først og fremst om vannfall, spiral og inkrementell. Smidig er tatt med her fordi ordet ofte står som alternativ i et flervalg, og fordi det er nyttig å vite at det ikke er det samme som spiralmodellen — smidig er drevet av tilbakemelding og korte runder, spiralen av risikovurdering.

Arbeidet med å komme fram til den heter på engelsk requirements engineering, og består av fire ting: samle inn krav fra dem som skal bruke systemet, analysere dem, skrive dem ned, og kontrollere at de er entydige og mulige.

Et godt krav er etterprøvbart. «Systemet skal være raskt» kan ingen kontrollere; «systemet skal svare på et søk innen to sekunder» kan alle kontrollere.

Merk plasseringen: kravspesifikasjonen kommer først. Den er kontrakten alt annet måles mot — og derfor det akseptansetestingen til slutt kontrollerer opp mot.

Kravene deles i to slag:

Arkitekturen bestemmes tidlig, i designfasen, og er den beslutningen som er dyrest å endre senere. Å bytte ut en funksjon er en dags arbeid; å bytte ut oppdelingen av hele systemet er et nytt prosjekt.

Sammenhengen med kodedelen av boka er direkte: å dele et program i funksjoner som hver gjør én ting og gjenbruker hverandre, er arkitektur i det små. Det er samme tanke, på en annen skala.

Testing skjer på flere nivåer, fra det minste til det største:

Den siste testen: kunden prøver systemet med sine egne data og sine egne arbeidsoppgaver, og avgjør om det kan tas i bruk.

Spørsmålet akseptansetesting svarer på, er ikke «virker koden» — det er avklart tidligere. Det er «er dette systemet vi trengte?»

Legg merke til at akseptansetesting måler mot kravspesifikasjonen, altså mot det som ble avtalt i begynnelsen. Det er derfor de to begrepene henger sammen som en bue over hele prosjektet:

- Kravspesifikasjonen står i begynnelsen og sier hva som skal lages.
- Akseptansetestingen står til slutt og kontrollerer at det er det som ble laget.

Fellen er nettopp å bytte om de to. Et alternativ som sier at akseptansetesting er «å skrive ned hva systemet skal gjøre», er den nære distraktoren.