Innehållsförteckning
Mallens struktur och innehåll
Mallen är indelad i följande övergripande sidor. Alla delar är idag inte obligatoriska att använda vilket framgår i tabellen nedan.
Övergripande sidor i mallen | Beskrivning | Obliga-torisk att fylla i |
|---|---|---|
Överblick/Overview | Startsida för lösningen | Ja |
Arkitektur | Arkitekturbeskrivningen. Lösningsdokumentationen följer övergripande alla de lager i arkitekturen som beskrivs i https://jiragu.atlassian.net/wiki/spaces/GA. | Ja |
Användarhandbok | Sida med ingångar till användarhandböcker | Ja |
Krav | Den samlade kravbilden, som hanteras under en egen sida så att kravbilden kan underhållas över tiden. | Ja |
Projekt | Information om projekt och inititativ för lösningen. Det är avgörande att separera projektinformation från lösningsinformation. Projekt dör efter hand, men lösningen består. Det är ok att dokumentera projektinformation, men detta ska ligga under sidan Projekt. | Nej |
Förvaltning | information som behövs för att förvalta och drifta lösningen. Genom att dokumentatera via Förvaltning och Arkitektur, kan man underhålla samma information som man gör i wiki.it.gu.se. | Nej |
Risk- och sårbarhetsanalys | Information om lösningens risk- och sårbarhetsanalys | Ja |
Lösningens livscykeln - håll dokumentationen uppdaterad
Det är naturligtvis viktigt att dokumentationen är aktuell och korrekt. Därför ingår det i samtliga projekts och förvaltningspersonals uppgifter att rätta fel och ändra dokumentationen när lösningen ändras.
Lösningar är inte statiska utan förändras kontinuerligt. Därför är det viktigt att se dokumentationen som en del av lösningen och säkerställa att den hänger med i förändringen.
Tanken är därför att informationen ska vara levande
Man startar i förstudie och fyller i så djupt man kan. Här kan as-is och to-be scenarier finnas med i olika stycken. Det kan också finnas olika varianter av lösningsförslag.
Man utvecklar framförallt lösningsarkitekturen under projektets gång. Lösningar som förkastas flyttas till arkivsidan för att uppnå spårbarhet. I slutet av projektet kvarstår bara de implementerade lösningarna. As-is flyttas till arkivet, to-be ligger kvar men behöver ingen rubrik för “to-be”.
Man påbörjar förvaltningsinformationen under projektet och dokumenterar löpande så att informationen växer fram successivt som en del av lösningen.
Vid överlämning till förvaltning kontrolleras att deploymentdiagram och driftsinformation är korrekta.
Dokumentationen underhålls löpande vid normalt systemunderhåll. Kommer nya målbilder om framtida lösningar, kan det vara aktuellt att införa as-is och to-be scenarios igen.
Nya projekt som berör lösningen dokumenteras normalt i samma i Confluenceyta (space). Skapar man en helt ny lösning som ersätter den gamla skapar man en ny yta för den nya lösningen och arkiverar den gamla ytan när man pensionerat den gamla lösningen.