Softwareudviklingsprocessen: sådan foregår et projekt fra idé til drift

En softwareudviklingsproces går typisk gennem seks faser: afklaring, design, udvikling i korte sprints, test, lancering og drift. Herunder kan du se hvordan et projekt forløber når jeg bygger en webapp eller platform, hvad der sker i hver fase, og hvad du som kunde skal bidrage med for at det lykkes.

Rækkefølgen er stort set den samme for en kundeportal, et internt system og en SaaS. Det der ændrer sig, er hvor lang tid hver fase tager, og hvor meget der står på spil hvis en af dem bliver sprunget over.

Den korte version: seks faser fra idé til drift

Varighederne er et groft skøn for en mellemstor webapp, fx en kundeportal eller et internt system med et par integrationer. Et lille værktøj kan bygges på få uger. En stor platform tager længere. I praksis overlapper faserne også: der bliver designet videre mens de første funktioner bygges, og der bliver testet hele vejen.

Guiden her er overblikket. Hver fase rejser sine egne spørgsmål, og undervejs linker jeg til artikler der går i dybden med dem. Støder du på et fagord du ikke kender, kan du slå det op i min ordbog over it- og udviklingsbegreber.

Før koden: afklaring, forprojekt og design

De to første faser er dem mange helst vil springe over fordi der ikke kommer kode ud af dem. Det er også dem der i højest grad afgør om resten af projektet holder tidsplan og budget. En misforståelse der bliver opdaget på en skitse, koster en samtale. Den samme misforståelse opdaget efter lancering kan koste uger.

Trin 1: Afklaring og forprojekt

Afklaringen, som også kaldes discovery, handler om at forstå problemet før nogen foreslår en løsning. Hvem skal bruge systemet, og hvilke opgaver skal de løse? Hvad bruger I i dag, fx regneark, mails eller et ældre system, og hvad er det der ikke virker? Og hvilke andre systemer skal løsningen tale med?

Før større projekter foreslår jeg altid et betalt forprojekt med fast pris. Det er et afgrænset forløb hvor du og jeg sammen gør idéen konkret nok til at den kan prissættes og planlægges. Et forprojekt giver typisk:

• En kravspecifikation der beskriver hvad systemet skal kunne. Har du aldrig lavet en, kan du se hvordan en god kravspecifikation er bygget op.
• User stories, altså korte beskrivelser af hvad en bestemt bruger skal kunne gøre, og hvorfor.
• En prioriteret liste over opgaver, en såkaldt backlog, delt op i det der skal med i første version, og det der kan vente.
• De store tekniske valg, fx om løsningen skal være en webapp, en app til telefonen eller en PWA. Jeg har sammenlignet webapp, app og PWA i en separat artikel.
• Et estimat og en plan for første version, så du ved præcis hvad du siger ja til.

Hvorfor betalt? Fordi alternativet er et tilbud bygget på gæt. Uden en afklaring skal en udvikler enten lægge en stor buffer i prisen eller tage chancen, og begge dele ender som regel på din regning. Et godt forprojekt giver dig samtidig dokumenter du kan bruge, også hvis du vælger en anden til at bygge systemet.

Trin 2: Design og prototype

Når kravene er på plads, bliver de til noget du kan se. Designfasen starter typisk med enkle skitser (wireframes) af de vigtigste skærmbilleder og brugerflows, fx hvordan en kunde logger ind, finder sin ordre og kontakter support. Skitserne er bevidst grå og enkle, så snakken handler om indhold og rækkefølge og ikke om farver.

Næste skridt er ofte en klikbar prototype i et værktøj som Figma. Den kan du vise til et par rigtige brugere før der bliver skrevet kode. Har du en designer eller et bureau der står for det visuelle, er det her de kommer ind.

Sideløbende bliver de tekniske fundamenter lagt:

• Datamodellen: hvilke data systemet skal gemme, og hvordan de hænger sammen.
• Brugerroller og rettigheder: hvem må se og ændre hvad.
• Arkitekturen. Til langt de fleste webapps i den størrelse jeg arbejder med, anbefaler jeg én samlet applikation frem for mange små tjenester. Argumenterne finder du i monolit eller microservices.
• Teknologien. Jeg bygger typisk med Laravel og React eller Next.js, og forskellene har jeg beskrevet i Laravel vs. Next.js. Er begrebet nyt for dig, så start med hvad en tech stack er.

To krav hører hjemme i designfasen og ikke bagefter. Det ene er tilgængelighed: skal systemet bruges af forbrugere, kan der være lovkrav, og det er langt billigere at designe det ind end at rette det til senere. Se kravene til webtilgængelighed. Det andet er persondata: hvilke oplysninger gemmer systemet, hvor står serverne, og hvem har adgang? Behandler en leverandør persondata på dine vegne, skal der være en databehandleraftale, jf. GDPR artikel 28.

Selve udviklingen: sprints, demoer og test

Når forprojekt og design er på plads, begynder byggeriet. Det er den længste fase før lancering, og det er her du for alvor mærker forskel på en god og en dårlig proces.

Trin 3: Udvikling i sprints

Selve udviklingen foregår i sprints: korte forløb med fast længde hvor en afgrænset mængde opgaver bliver bygget, testet og vist frem. Scrum-guiden sætter grænsen ved højst en måned. Jeg anbefaler en til to uger fordi du så ser fremskridt ofte nok til at rette kursen i tide.

En sprint følger det samme mønster hver gang:

1. Planlægning: Du og jeg vælger de vigtigste opgaver fra backloggen og bliver enige om hvad der skal være færdigt.
2. Udvikling: Jeg bygger og tester funktionerne og lægger dem løbende på et testmiljø (staging), hvor du kan følge med.
3. Demo: Når sprinten slutter, viser jeg det der er bygget, i rigtig software og ikke i en præsentation.
4. Justering: Din feedback og dine nye idéer kommer ind i backloggen og bliver prioriteret til næste sprint.

Det er helt normalt at få nye idéer undervejs. Det afgørende er at de bliver prioriteret mod det der allerede er planlagt, i stedet for at blive lagt oveni. Er første version aftalt til fast pris, erstatter en ny funktion enten noget andet eller bliver prissat for sig. Hvorfor den måde at arbejde på normalt slår en plan der er låst fra start, kan du læse i agil udvikling vs. vandfald.

Undervejs taler du direkte med mig, den udvikler der skriver koden. Der er ingen projektleder imellem, og jeg svarer inden for én arbejdsdag. Koden er din fra første dag, og den bør ligge i et repository (kodearkiv) som du selv har adgang til.

Mange projekter skal også tale med andre systemer, fx økonomisystem, betalingsløsning eller CRM. Det sker via et API, og hvad et API er har jeg forklaret uden fagsprog. Integrationer er ofte der hvor estimater skrider fordi den anden parts system sjældent opfører sig præcis som dokumentationen lover. Skal du koble på et dansk økonomisystem, så se min guide til integration med e-conomic og Dinero.

Trin 4: Test og accepttest

Test er ikke en fase der starter når udviklingen er færdig. Den foregår i tre lag hele vejen:

• Automatiske tests bliver skrevet sammen med koden og kører hver gang noget ændres. De fanger når en ny funktion ødelægger en gammel. Hvorfor det betaler sig, har jeg skrevet om i automatiserede tests.
• Sikkerhed og hastighed bliver tjekket løbende: login, rettigheder, validering af input og hvordan systemet klarer sig med realistiske datamængder. OWASP Top 10 er et godt udgangspunkt for de mest almindelige sårbarheder, og min tjekliste til websikkerhed gør den konkret.
• Accepttesten er din. Her gennemfører du og et par rigtige brugere de opgaver systemet er bygget til, med rigtige data, og godkender at det virker.

En accepttest er ikke at klikke rundt og se om noget ser forkert ud. Den virker bedst når kriterierne er skrevet på forhånd, typisk direkte ud fra de user stories der blev lavet i forprojektet: "Som medarbejder i kundeservice kan jeg finde en ordre ud fra kundens telefonnummer." Enten kan du det, eller også kan du ikke.

Lancering og drift

De sidste to faser handler om at få systemet sikkert i hænderne på brugerne og holde det kørende bagefter.

Trin 5: Lancering

En god lancering er kedelig. Den er planlagt så grundigt at der ikke sker noget dramatisk. Typisk ser forløbet sådan ud:

1. Lav en lanceringsplan med dato, ansvarsfordeling og en plan for hvad der sker hvis noget går galt, herunder hvordan der rulles tilbage til den gamle løsning.
2. Flyt data fra det gamle system eller regnearkene. Kør flytningen som prøve først, og tjek resultatet sammen med en der kender dataene.
3. Sæt produktionsmiljøet op: hosting, domæne, SSL-certifikat, afsendelse af mails, backup og overvågning. Alt bliver testet før lanceringsdagen.
4. Start gerne blødt med en mindre gruppe brugere før alle får adgang.
5. Overdrag adgange og dokumentation, så du ikke er afhængig af én persons hukommelse. Hvad der bør være skrevet ned, kan du se i tjeklisten til dokumentation af et softwareprojekt.

Min tommelfingerregel er at lancere tidligt på ugen og aldrig fredag eftermiddag. De første dage efter lanceringen bør der være afsat tid til at rette småfejl og svare på spørgsmål fra brugerne.

Trin 6: Drift og videreudvikling

Når systemet er live, begynder den længste fase. Software står ikke stille: framework og pakker får sikkerhedsopdateringer, browsere ændrer sig, og de systemer du er integreret med, bliver opdateret af andre end dig. Drift dækker typisk opdateringer, overvågning, backup der faktisk bliver testet, og hurtig hjælp når noget går galt. Hvad det indebærer i praksis, kan du læse i drift og vedligehold af webapps.

Videreudvikling er den anden halvdel. De første måneder med rigtige brugere lærer dig typisk mere end hele forprojektet, og backloggen bliver suppleret med ønsker fra virkeligheden. Her er det vigtigt at holde koden sund, så hver ny funktion ikke bliver dyrere end den forrige. Det er det teknisk gæld handler om, og du kan selv holde øje med tegnene på en sund kodebase.

Aftal derfor drift og vedligehold før lanceringen og ikke den dag noget går ned.

Hvad du som kunde skal bidrage med

Din egen indsats er den del af budgettet der sjældent står i tilbuddet. Den afgør alligevel en stor del af tempoet. Det her skal være på plads hos dig:

• En beslutningstager. Én person der kender forretningen, har mandat til at sige ja og nej og kan svare inden for en dag eller to. Projekter styret af et udvalg går langsommere.
• Tid. Som tommelfingerregel bør du regne med et par timer om ugen under udviklingen til demoer, spørgsmål og prioritering. I forprojektet og accepttesten skal du afsætte mere.
• Viden om forretningen. Processerne, undtagelserne og de særtilfælde der kun findes i dine medarbejderes hoveder. Det er dem der gør et system brugbart i hverdagen.
• Adgang. Til eksisterende systemer, data, domæne og de konti integrationerne kræver. Del adgangskoder og nøgler via en password manager og aldrig i en mail.
• Indhold. Tekster, billeder, hjælpetekster, vilkår og mailskabeloner.
• Brugere til test. Et par rigtige brugere der vil se på prototypen og være med i accepttesten.

Kan du ikke afsætte den tid lige nu, er det bedre at vente med at starte end at starte halvt. En udvikler der venter en uge på et svar, står enten stille eller bygger videre på et gæt, og ingen af delene er godt for dit budget.

Hvor lang tid tager det, og hvad påvirker prisen?

Som groft skøn kan et lille internt værktøj med få skærmbilleder bygges på nogle uger. En første version af en kundeportal, en MVP (den første, enkle version af et produkt) eller et internt system med et par integrationer tager ofte to til seks måneder fra forprojekt til lancering. Større platforme med mange brugerroller tager længere og bliver ofte lanceret i etaper.

Det der især trækker tid og pris op:

• Antallet af brugerroller, og hvor forskellige deres behov er.
• Integrationer til andre systemer, især ældre systemer med mangelfuld dokumentation.
• Dataflytning fra et gammelt system med rodede data.
• Krav til design, tilgængelighed og dokumentation.
• Hvor hurtigt beslutninger bliver truffet.

Det sidste punkt er det eneste du har fuld kontrol over, og det er ofte det der gør den største forskel på en tidsplan der holder, og en der skrider.

Økonomien følger faserne. Forprojektet har en fast pris. Når det er færdigt, er det realistisk at give en fast pris eller et snævert prisinterval på første version fordi gætteriet er taget ud. Drift og videreudvikling bliver typisk afregnet løbende, fx med en månedlig aftale. Du kan se hvordan jeg sætter mine priser på prissiden.

Hvornår processen ikke passer

Seks faser lyder af meget, og til nogle opgaver er det for meget. Processen skal skaleres efter opgaven, og nogle gange er svaret at du slet ikke skal have bygget noget:

• Små og veldefinerede opgaver, fx en ny integration eller en rettelse i et eksisterende system, kræver ikke et forprojekt. Her er en kort beskrivelse og et estimat nok.
• Findes der standardsoftware der dækker det meste af behovet, er det ofte billigere at købe end at bygge. Et ærligt forprojekt bør også kunne ende med den konklusion.
• Skal design, tekst, research og udvikling ske på samme tid, og haster det, kan et bureau med et helt hold være et bedre valg end en freelancer. Jeg er én udvikler: det giver direkte kontakt og korte beslutningsveje, men ikke fem personer på samme tid.
• Er softwaren selve din forretning, og skal der udvikles på den på fuld tid i mange år, bør du på sigt ansætte dine egne udviklere. En freelancer kan sagtens bygge første version og hjælpe med overdragelsen.

Næste skridt: sådan kommer du i gang

Du behøver ikke en færdig kravspecifikation for at tage første skridt. Men du kommer hurtigere i gang hvis du har tænkt over spørgsmålene herunder.

Har du svar på de fleste, er du klar til en første snak. Mangler du svar på nogle af dem, er det netop det et forprojekt skal hjælpe med. På siden om udvikling af webapps og platforme kan du se hvilke typer systemer jeg bygger, og hvordan et samarbejde starter.

Ofte stillede spørgsmål

Hvad står SDLC for?+

SDLC står for software development life cycle, altså softwareudviklingens livscyklus. Det er den engelske fællesbetegnelse for de faser et system gennemgår fra idé til drift og til sidst udfasning. Modellerne varierer i antal faser og navne, men rækkefølgen er stort set den samme. Faserne i denne guide er en praktisk udgave af samme tankegang.

Skal jeg have en kravspecifikation før jeg kontakter en udvikler?+

Nej. En kort beskrivelse af problemet, brugerne og hvad der findes i dag er nok til en første snak. Kravspecifikationen bliver lavet i forprojektet, hvor udvikleren kan stille de spørgsmål der afslører huller. Har du allerede noget på skrift, så send det gerne med, for det gør samtalen mere præcis.

Hvem ejer koden der bliver skrevet undervejs?+

Det afgør aftalen, så få det skrevet ind fra start. Hos mig ejer kunden koden fra første dag. Generelt overgår ophavsretten til kode skrevet af en ekstern udvikler ikke automatisk til dig, sådan som den gør når en ansat skriver et program som led i sit arbejde. Det er ikke juridisk rådgivning, så få kontrakten tjekket hvis der står meget på spil.

Kan et projekt gå hurtigere hvis man sætter flere udviklere på?+

Sjældent midt i et projekt. Nye udviklere skal sætte sig ind i koden og forretningen, og koordineringen tager tid fra dem der allerede er i gang. Det der typisk hjælper mest, er at skære første version ned til det vigtigste og træffe beslutninger hurtigere. Flere udviklere fra start kan være fornuftigt på store projekter der kan deles op i selvstændige dele.