8.5 Avsluttende prosjekt

Alt på ett sted

Nå er det tid for å bringe alt du har lært sammen i ett avsluttende prosjekt – din mulighet til å vise kompetanse innen programmering, databaser, nettapplikasjoner, testing, versjonskontroll og systemutvikling. Men et godt prosjekt starter ikke med kode; det starter med en god idé og en plan.

Første fase er idégenerering og valg. En god prosjektidé løser et reelt problem, har passe omfang for et par–seks ukers arbeid, lar deg demonstrere flere kompetansemål, og er noe du er motivert for. Eksempler er en treningslogg, en budsjettapp, en quiz-plattform, en oppskriftsapp eller et bookingsystem.

Andre fase er kravspesifikasjon – å dokumentere hva systemet skal gjøre. Her skiller vi mellom funksjonelle krav, som er konkrete funksjoner («brukere skal kunne registrere seg med e-post og passord»), og ikke-funksjonelle krav, som handler om kvalitetsegenskaper («søk skal returnere resultat på under ett sekund», «passord skal hashes med bcrypt»). For å prioritere bruker vi MoSCoW: Must have er kritisk funksjonalitet, Should have er viktig men ikke kritisk, Could have er fint å ha, og Won't have er utenfor scope denne gangen. Å sette krav i Won't have er like viktig som de andre – det er slik du holder prosjektet realistisk.

Teknologivalg og prosjektplan

Med kravene på plass kommer teknologivalg. Her tar du i bruk alt du har lært gjennom kurset. For en treningslogg-app kan valgene være Flask som backend, SQLite som database (med PostgreSQL i produksjon), HTML, CSS og JavaScript med et bibliotek som Chart.js til frontend, pytest til testing, og Git med GitHub til versjonskontroll. Du designer også et databaseskjema med tabellene du trenger – for treningsloggen kanskje users, exercises, workouts og workout_sets, koblet sammen med fremmednøkler slik du lærte i databaseseksjonen.

Deretter lager du en prosjektplan med en realistisk tidsplan. En firukers plan kan se slik ut: uke 1 settes av til oppsett av Flask og database, samt autentisering med tester. Uke 2 går til CRUD for treningsøkter og sett. Uke 3 til frontend og visualisering. Og uke 4 til testing, feilretting, dokumentasjon og presentasjon. Ved å bryte arbeidet ned i milepæler – konkrete delmål – ser du tydelig om du ligger i rute.

Et smart prinsipp er å bygge en MVP først, et Minimum Viable Product. Det er en versjon med bare de mest kritiske funksjonene (Must have), som faktisk fungerer ende til ende. Får du MVP-en på plass tidlig, har du alltid noe som virker å vise fram, og kan legge til Should have og Could have hvis tiden tillater. Dette beskytter deg mot den vanligste fellen: å bruke all tiden på avanserte detaljer og ende opp uten et fungerende produkt.

Gjennomføring og presentasjon

Nå begynner selve byggingen, og her bruker du metodene fra de tidligere kapitlene i praksis. Jobb iterativt, ett delmål av gangen, og bruk Git med brancher og commits underveis. Skriv tester kontinuerlig – ikke vent til slutten – slik at du fanger feil tidlig og trygt kan endre kode. Dokumenter mens du går, med docstrings og en README, mens detaljene er ferske i minnet.

En viktig advarsel er scope creep – at prosjektet sniker seg til å vokse med stadig nye «kjekke» funksjoner som ikke sto i planen. Det er en av de største truslene mot å bli ferdig. Forsvaret er å holde fast ved MoSCoW-prioriteringen din og motstå fristelsen til å legge til Could have-ting før Must have er ferdig og testet. Et annet klokt grep er å la noen andre teste appen din før innlevering. Du kjenner systemet for godt og klikker automatisk «riktig»; en utenforstående avslører forvirring og feil du selv er blind for.

Til slutt kommer presentasjonen, der du viser fram både prosess og resultat. Du demonstrerer det fungerende produktet, forklarer teknologivalgene dine, viser hvordan du planla og prioriterte, og reflekterer over hva som gikk bra og hva du ville gjort annerledes. Da knytter du sammen alt faget har handlet om: ikke bare å skrive kode som virker, men å planlegge, samarbeide, kvalitetssikre og kommunisere – kjernen i å være en profesjonell utvikler.

Oppsummering

Det avsluttende prosjektet samler hele faget. Du starter med en god idé og en kravspesifikasjon der funksjonelle og ikke-funksjonelle krav prioriteres med MoSCoW. Deretter gjør du teknologivalg, designer databaseskjema, og lager en prosjektplan med milepæler og en realistisk tidsplan – gjerne med en MVP først, slik at du alltid har noe som virker.

I gjennomføringen jobber du iterativt med Git, skriver tester og dokumentasjon kontinuerlig, og vokter deg mot scope creep ved å holde fast ved prioriteringene. Du lar andre teste appen, og avslutter med en presentasjon av både prosess og resultat. Da har du vist det viktigste IT 2 lærer deg: at god programvareutvikling er like mye planlegging, samarbeid og kvalitetssikring som det er å skrive kode. Gratulerer – du har fullført IT 2.