Kodrummet

Centralt innehåll

Analys, nedbrytning och modellering av programmeringstekniska problem med lämpligt analysverktyg, till exempel användningsfall.
Skapande av klasser och objekt i ett objektorienterat programspråk utifrån tidigare analys och design.
Design av lämplig lösning ur föregående analys med lämpligt verktyg och metoder som klassdiagram.

1. Systemutveckling

Systemutveckling är hela processen för att ta fram ett system (dataprogram, webbapp). Det är flera olika roller inblandade, t.ex. användare, kravställare, testare, programmerare.

2. Behov

Att utveckla en app börjar med att det finns ett behov eller någon får en idé. Det kan vara ett problem som behöver en lösning.

Det kan t.ex. vara att vi skapa en app för en bank.
Ett bankkonto ska hålla reda på information om namnet på den person som äger kontot och hur mycket pengar som finns på kontot (saldot). Man ska kunna ta ut pengar från kontot och sätta in pengar. Det skall inte gå att plocka ut mer pengar än vad som finns på kontot.

3. Systemutvecklingsprocessen

Systemutvecklingsprocessen består av 6 olika faser: Krav, Analys, Design, Kodning, Test, Leverans

3.1 Krav

Krav på appen, vilken funktionalitet. Vad ska appen göra?
Även krav på t.ex. svarstider, tillgänglighet, aktualitet, säkerhet (s.k. icke funktionella krav).
Beskrivs t.ex. med storyboards eller användningsfall

3.2 Analys

Ser systemet utifrån, vad ska göras?
Försöker förstå problemområdet. Vilka objekt finns och relationerna mellan dem. T.ex. en bank app har objekt som kund, konto.
Framställer dokument som ska användas i designarbetet, t.ex. klassdiagram och terminologi (språket).

3.3 Design

Ser datasystemet inifrån, hur ska det göras rent tekniskt?
Hur objekten kommunicerar med varandra.
Tillräckligt med information för kodning, mer detaljerade klassdiagram.
Om ny teknik används kan det finnas behov av en POC (Proof of Concept), ett sätt att se om idén kan förverkligas. Jämför med prototyp (som kan användas i designprocessen).

3.4 Kodning

Kodning är att programmera.
Här skrivs appen i något programmeringsspråk.
Dokument från designen ska göras om till programmeringskod.

3.5 Test

Kontrollerar kvalitén, att appen fungerar som det är tänkt. Ett fel i en app brukar kallas bugg.
Använd användingsfallen/story boarden från kravanalysen och testa.
Tester utförs av programmerare, testare och några användare.

3.6 Leverans

Installera på användarnas datorer/mobiler.
T.ex. App store och Google Play

3.7 Iteration

Analys, design, kodning och test upprepas och görs flera gånger, där ny funktionalitet läggs till i varje iteration.

Bygga appen bit-för-bit.
Varje iteration tillför ny funktionalitet.
Varje iteration kan medföra förändringar/förbättringar. Det går inte att bestämma allt i förväg.

4. Agil systemutveckling

Agil systemutveckling är ett samlingsnamn för ett antal systemutvecklingsmetoder som kan användas vid programvaruutveckling, även kallade lättrörliga metoder eller iterativa metoder.

Exempel på agila metoder är bl.a. Scrum, Extreme Programming (XP) och Lean Software Development.

4.1 Tolv grundprinciper för agil systemutveckling

Vår högsta prioritet är att tillfredsställa kunden genom tidig och kontinuerlig leverans av värdefull mjukvara.
Välkomna förändrade krav, även sent under utvecklingen. Agila metoder utnyttjar förändring till kundens konkurrensfördel.
Leverera fungerande programvara ofta med tidsskala från ett par veckor till ett par månader, med en förkärlek till den kortare tidsskalan.
Affärsfolk och utvecklare måste arbeta tillsammans dagligen under hela projektet.
Bygg upp projektet runt motiverade individer. Ge dem den miljö och det stöd de behöver, och lita på dem för att få jobbet gjort.
Den mest effektiva metoden för att förmedla information till och inom ett utvecklingsteam är konversation på plats mellan individerna (en: face-to-face).
En fungerande programvara är det huvudsakliga måttet på framsteg.
Agila processer främjar en hållbar utveckling. Sponsorer, utvecklare och användare ska kunna hålla en jämn utvecklingstakt på obestämd tid.
Kontinuerlig uppmärksamhet på förstklassig teknik och god design ökar flexibiliteten.
Enkelhet - konsten att maximera mängden arbete som inte görs - är grundläggande.
Bäst arkitektur, krav och design framträder ur självorganiserande team.
Med jämna mellanrum reflekterar teamet över hur det kan bli mer effektivt, och justerar och anpassar sitt beteende därefter.

Vattenfallsmetoden

Agila metoder jämförs ofta med den gamla vattenfallsmetoden. Vattenfallsmetoden har ingen iteration utan försöker planera hela systemet på en gång och sedan bygga allt med endast en analys, design, kodning och testningsfas.
Den metoden misslyckades ofta att leverera rätt resultat i rätt tid och de agila metoderna utvecklades för att försöka hitta metoder som kunde leverera bättre resultat.

Man kan se manifestet för agil systemutveckling som en motreaktion mot den mer stela vattenfallsmetoden, som försöka förutse och planera allt i förväg. Det agila manifestet säger:

Individer och interaktioner framför processer och verktyg.
Fungerande programvara framför omfattande dokumentation.
Kundsamarbete framför kontraktsförhandling.
Anpassning till förändring framför att följa en plan.

Det vill säga, medan det finns värde i punkterna till höger, värdesätts punkterna till vänster mer.