Slik fungerer prosessen for utvikling av skreddersydd programvare

01Hva er skreddersydd programvare, og når trenger du det?

Skreddersydd programvare er programvare utviklet etter en bestemt virksomhets arbeidsflyt, regler og brukere. Forskjellen fra ferdige pakker er at programvaren tilpasses virksomheten, ikke at virksomheten tilpasser seg programvaren.

Ikke alle behov krever skreddersydd programvare. For et standard regnskaps- eller e-postbehov finnes det modne ferdige løsninger. Skreddersydd programvare gir mening når prosessen inneholder en metode som skiller deg fra konkurrentene, når flere systemer må kobles sammen, eller når ferdige verktøy løser halve jobben og lar resten gjøres for hånd.

Et annet tegn er Excel-slitasje. Hvis en kritisk prosess drives med regneark som kopieres til hverandre, WhatsApp-meldinger og kontroller som bygger på hukommelsen, er både risikoen for feil og tidstapet stort. I et slikt tilfelle kan riktig utformet programvare vise investeringsverdien raskt.

02Programvareprosjektet: oversikt

Selv om prosjekter drives med ulike metoder etter størrelse, er fasene i hovedsak de samme. Tabellen under oppsummerer hva som produseres i hver fase og hva som forventes av virksomheten.

03Hvorfor er analysefasen kritisk?

Den dyreste feilen i et programvareprosjekt er å gjøre feil ting riktig. Behovsanalyse reduserer denne risikoen ved å avklare hva som skal lages før det skrives kode.

I denne fasen kartlegges prosessen steg for steg: hvem henter hvilken informasjon hvor, og sender den videre til hvem? Hvilke beslutninger tas manuelt, og hvilke kan knyttes til regler? Hvilke systemer må kobles til? Svarene blir et referansedokument som senere forhindrer omfangsglidning.

Under analysen er det også viktig å skille mellom «må ha»- og «fint å ha»-funksjoner. Å holde første versjon liten og solid og vokse med tilbakemeldinger fra brukerne er i de fleste prosjekter den sunneste veien. Denne første versjonen kalles ofte MVP (minimum viable product).

• Hvordan fungerer prosessen i dag, og hvor stopper det opp?
• Hvem skal bruke systemet, og med hvilke rettigheter?
• Hvilke rapporter og varsler trengs?
• Er det koblinger til regnskap, frakt, betaling eller andre systemer?
• Behandles det personopplysninger, og hva bør oppbevaringstidene være?

04Omfang, tilbud og tidsplan

Omfanget som kommer ut av analysen er grunnlaget for tilbudet. Et godt programvaretilbud oppgir ikke bare totalbeløpet, men skriver tydelig hvilke moduler som er inkludert, hva som ligger utenfor omfanget, leveransefasene og akseptkriteriene.

Tidsplanen må være like tydelig. Store prosjekter deles vanligvis inn i sykluser på to til fire uker, og ved slutten av hver syklus vises en fungerende del. Slik følger virksomheten fremdriften på skjermen, ikke i dokumenter.

Når du sammenligner tilbud, kan det være misvisende å se bare på tallet. Sjekk om poster som vedlikehold, hosting, opplæring og eierskap til kildekoden er inkludert. Faktorene som påvirker budsjettet har vi gått gjennom i artikkelen Hva koster programvareutvikling.

05Design: grensesnitt og arkitektur

Grensesnitt og brukeropplevelse

Skjermskisser (wireframes) viser hvordan brukeren skal samhandle med systemet før det skrives kode. En endring i denne fasen tar noen minutter; den samme endringen kan ta dager mot slutten av utviklingen. Å bygge flyter brukerne faktisk skal bruke etter prinsippene for UI/UX-design reduserer også behovet for opplæring.

Datamodell og arkitektur

I denne fasen bestemmes hvilke opplysninger som skal lagres, hvordan de henger sammen og hvilke deler systemet skal bestå av. Riktig datamodell er grunnlaget for rapportering og funksjoner som legges til senere. Hvordan systemet snakker med andre systemer designes vanligvis gjennom et API.

06Slik går utvikling og testing for seg

Utviklingen går modul for modul ut fra det godkjente designet. Koden styres med versjonskontroll, hver endring gjennomgås, og delleveranser vises jevnlig for virksomheten. Språk og teknologi velges etter behov; til arbeid med mye databehandling og automasjon foretrekkes ofte språk som Python.

Testing er ikke et trinn som utsettes til slutten av utviklingen, men en prosess som går parallelt med den. I tillegg til de automatiske testene teamet skriver, er akseptansetesten virksomheten gjør med reelle scenarioer grunnlaget for endelig godkjenning.

I denne fasen er også kommunikasjonsrutinene avgjørende. Et kort ukentlig statusmøte, en felles oppgaveliste og én ansvarlig person forhindrer at beslutninger forsvinner i e-posttrafikken. Å utpeke en kontaktperson med beslutningsmyndighet på virksomhetens side hindrer at saker som venter på godkjenning hoper seg opp, og beskytter tidsplanen. Tidlig tilbakemelding på delleveranser reduserer dyre endringer senere.

• Enhetstester: bekrefter at en enkelt funksjon fungerer riktig.
• Integrasjonstester: bekrefter at moduler og eksterne systemer fungerer sammen.
• Brukerakseptansetest: virksomheten prøver med sine egne reelle arbeidsflyter.
• Ytelses- og sikkerhetskontroll: oppførsel under belastning og motstandskraft mot kjente hull.

07Lansering og vedlikehold

Lansering består av serveroppsett, overføring av eksisterende data, opprettelse av brukerkontoer og opplæring. I kritiske systemer reduserer det risikoen ved overgangen å kjøre det gamle og det nye systemet parallelt en kort periode.

Programvare er ikke ferdig når den settes i drift. Når nettlesere, operativsystemer og tjenester den kobler til endres, trengs det oppdateringer. Etter hvert som brukerne tar systemet i bruk, oppstår også nye behov. Derfor er vedlikeholdsavtalen en post som bør diskuteres helt i starten av prosjektet.

Sikkerhetskopiering, tilgangslogger og sikkerhetsoppdateringer er også en del av vedlikeholdet. For KVKK-forpliktelsene (tyrkisk personvernlov, sammenlignbar med GDPR) i systemer som behandler personopplysninger, bør du sjekke gjeldende regelverk og rådføre deg med juridisk rådgiver.

08Råd til deg som vil bestille programvare

Ved bransjespesifikke behov er det også et alternativ å tilpasse en moden løsning i stedet for å starte fra bunnen av. Bransjeprogramvare laget for områder som reiseliv, overnatting, eiendom og restaurant er eksempler på denne veien. Bransjeprodukter som hotellprogramvare kan tilpasses virksomhetens regler, og på butikksiden bygger integrasjonsløsninger for nettbutikk bro til eksisterende systemer.

1. Beskriv problemet, ikke løsningen: si «godkjenning av bestillinger tar to dager» i stedet for «jeg vil ha en skjerm».
2. Involver den som kjenner prosessen: inviter brukeren fra gulvet til analysemøtene også.
3. Start smått: begrens første versjon til den mest kritiske flyten.
4. Avklar eierskap til kildekode og data: det bør stå tydelig i kontrakten.
5. Se referanser og et fungerende system: undersøk prosjektene firmaet har levert tidligere.
6. Spør om vilkårene for vedlikehold og support: svartider og omfanget av oppdateringer bør være klare.