Fagmodulene navngis per prosjekt
Skjelettet over dekker det som er felles. Det som gjør systemet til deres system — selve fagområdet — finnes det ingen liste over, og vi kommer ikke til å lage en. De modulene navngis i hvert enkelt prosjekt, av dem som kan faget.
Oppdiktede eksempler, bare for å vise formen: en kursvirksomhet kan ende opp med en modul som heter «Kurs og påmelding» og en som heter «Instruktører». Et utleiefirma kan ha «Lokaler» og «Booking». Et verksted kan ha «Ordrer» og «Reservedeler». Navnene skal være ordene virksomheten allerede bruker seg imellom, ikke ord en leverandør har med seg utenfra. Kjenner ikke de ansatte igjen kapitteloverskriftene i spesifikasjonen, leser de den ikke — og da får dere heller ikke rettet feilene mens det ennå er billig.
Antall moduler er verdt å telle, ikke gjette. Det er en av de få tallene som sier noe om størrelsen på prosjektet før noen har begynt å estimere enkeltfunksjoner: fem moduler og tjuefem moduler er to helt forskjellige leveranser, uansett hvor lik beskrivelsen av dem høres ut i et møte.
Oversikt eller rapport — skillet som koster mest
Dette er den vanligste og dyreste misforståelsen i omfangsarbeid, så det er verdt å gjenta utenfor rapportsiden. En oversikt er en listevisning: rader hentet rett fra systemet, med søk, sortering og sidevisning. En rapport er aggregert utdata: tall som er summert, gruppert og sammenlignet, gjerne over tid og på tvers av flere kilder.
De ser like ut på en skisse, og de koster helt forskjellig. Lister blir overestimert fordi de har mange kolonner og ser omfattende ut — men de er rutinearbeid med et kjent mønster. Rapporter blir underestimert fordi utdataen er ett tall — men det tallet må defineres presist, hentes fra flere steder, avstemmes mot noe virksomheten kjenner igjen fra før, og gi samme svar hver gang. Sier noen «vi trenger bare en enkel rapport», er neste spørsmål alltid: hvilke tall, brutt ned på hva, sammenlignet med hvilken periode?
Neste steg
Har du modulene på plass, er neste spørsmål hva som skal ligge inne i dem. Det er dekket i funksjonalitetsbiblioteket, mens handlingene hver funksjon består av — liste, søk, redigering — ligger i byggesteinene. De ikke-funksjonelle kravene går på tvers av alle modulene, og hvordan alt dette skrives ned står i artikkelen om kravspesifikasjon.
Spørsmål og svar
Hva er en modul i et system?
En avgrenset del av systemet som kan tas ut av leveransen uten at resten slutter å virke. Kan den ikke tas ut, er den en funksjon inne i en modul. Modulene bestemmer kapittelinndelingen i spesifikasjonen.
Hvor mange moduler bør et system ha?
Det finnes ikke noe riktig antall, men skjelettet på denne siden er gulvet for et system med innlogging. Kommer dere under det, er sannsynligvis noe glemt heller enn spart. Kommer dere langt over, er det verdt å sjekke om noen av dem egentlig er funksjoner som har fått for høy status.
Hvilken modul blir oftest glemt i budsjettet?
Adminsidene. De er usynlige når behovet beskrives, fordi de ikke er en forretningsprosess, men en forutsetning — samtidig som de nesten alltid blir den største modulen.
Er dette en bransjestandard?
Nei. Det er et skjelett vi har satt sammen fordi de samme modulene går igjen. Fagmodulene navngis per prosjekt og finnes ikke i noe register — heller ikke i vårt.
Usikker på hvor stort systemet egentlig blir? Modulinndelingen er det raskeste stedet å oppdage at omfanget er større enn antatt — mens det fortsatt bare koster et møte. DOPS har spesifisert og bygget systemer for norske virksomheter i over 20 år.
Snakk med et fagmiljø