Arbetssätt i projekt

Mål

Efter kapitlet ska du kunna...

• använda programmering för att lösa ett verkligt behov
• arbeta metodiskt från problem till redovisning
• bedöma testresultat, risker och rimlighet
• använda checklistor under hela projektet

18.1

Programmering är ett verktyg

I ett teknikprojekt börjar arbetet med ett problem eller behov – inte med syntax.

Koden är en del av lösningen tillsammans med planering, testning, dokumentation och redovisning.

Exempel på behov

Vad kan programmet lösa?

• beräkna energiförbrukning
• hantera bokningar
• planera en budget
• hålla ordning på ett lager
• planera skolarbete

Två kurser – samma metod

Gemensamma förmågor

18.2

Projektets tio steg

Hela processen

Från behov till resultat

Processen är iterativ

Du får gå tillbaka

Ett test kan visa att designen behöver ändras.

En användare kan upptäcka att ett krav saknas.

Att förbättra planen är en del av metoden – inte ett misslyckande.

18.3 · Problem

Börja med ett konkret behov

Något tar lång tid, blir ofta fel eller kan göras enklare.

Användare och syfte

Vem och varför?

• Vem ska använda lösningen?
• Vilket problem har användaren?
• I vilken situation används programmet?
• Hur märker vi att lösningen hjälper?

Krav

Beskriv vad som ska uppfyllas

• Användaren ska kunna lägga till en läxa.
• Varje läxa ska ha ämne och datum.
• Programmet ska visa kommande läxor.
• Felaktiga datum ska ge ett tydligt felmeddelande.

Design

Planera innan du bygger

Implementering

Bygg minsta fungerande version

1. Skapa programmets kärnfunktion.
2. Kör och testa den.
3. Lägg till nästa funktion.
4. Spara en ny version.

Använd variabler, villkor, loopar, funktioner och felhantering där de behövs.

18.4 · Testning

Nästan fungerar räcker inte

Testprotokoll

Jämför förväntat och faktiskt

Det andra testet visar vad som behöver förbättras.

Risker

Vad händer om något går fel?

• Felaktig inmatning kan krascha programmet.
• En felaktig beräkning kan ge dåliga beslut.
• Information kan visas eller sparas fel.
• Ett orimligt resultat kan se korrekt ut.

Rimlighetsbedömning

Fråga om svaret kan stämma

Koden kan ha körts utan fel, men resultatet är ändå orimligt.

Användbarhet

Programmet är till för någon

• Är instruktionerna begripliga?
• Har knappar tydliga namn?
• Förklarar felmeddelandet hur felet rättas?
• Går text och resultat att läsa?

Dokumentation

Visa både produkt och process

• problemet och användaren
• plan, krav och design
• hur programmet byggdes
• testresultat och förbättringar
• slutresultat och kvarvarande begränsningar

18.5 · Innan

Förbered projektet

• välj problem, användare och syfte
• skriv krav och planera lösningen
• gör pseudokod eller skiss
• skapa projektmapp och GitHub-repository
• skriv en enkel README.md

Under

Arbeta spårbart

• bygg och testa stegvis
• använd tydliga namn och felhantering
• bedöm om resultat är rimliga
• ladda upp varje programmeringstillfälle
• skriv tydliga commits och notera lösta problem

Efter

Kontrollera helheten

• sluttesta mot alla krav
• rätta fel och städa koden
• färdigställ README och dokumentation
• ladda upp slutversionen
• utvärdera och förbered redovisningen

Interaktiv projektkontroll

Vad ska du kontrollera nu?

Välj projektfas.

Kort modell

Innan · under · efter

Sammanfattning

Kom ihåg

• Utgå från ett verkligt problem och en tydlig användare.
• Krav beskriver vad lösningen ska uppfylla.
• Design och stegvis implementation minskar risken för fel.
• Testning ska omfatta funktion, risker och rimlighet.
• Dokumentation visar hur och varför lösningen skapades.