Arkitekturbeskrivningen ingår i en mallsite som innehåller strukturen för hela lösningsdokumentationen, https://jiragu.atlassian.net/wiki/spaces/M2 . Arkitekturbeskrivningen finns under sidan /wiki/spaces/M2/pages/1281097746. Lösningsdokumentationen följer övergripande alla de lager i arkitekturen som beskrivs i https://jiragu.atlassian.net/wiki/spaces/GA/overview.
Hur fyller man i mallen?
Mallen utgör en struktur för att man ska känna igen sig och hitta information på samma ställe i olika lösningar.
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 /wiki/spaces/M2/pages/1290567695. Krav hanteras under en /wiki/spaces/M2/pages/1280671779 så att kravbilden kan underhållas över tiden. /wiki/spaces/M2/pages/1281097746beskriver lösningen och ska underhållas löpande.
Instruktionstext och exempel är definierade som informationsrutor. Instruktionstext tas bort. Exempel ersätts med faktisk information utan informationsruta.
Instruktionstext som ska tas bort när man fyller i mallen med faktisk information.
Värden som ska ersättas med faktiskt information står mellan <>.
Omfattande information går det bra att bryta ner i undersidor så länge som man länkar från rätt stycke på toppnivån.
Man bör inte ta bort rubriker. Skriv N/A eller en kort kommentar om varför information inte är relevant. Det ska gå att utläsa att man beaktat stycket även när det saknas relevant information att fylla i.
Det går bra att markera text som behöver kompletteras eller som inte stämmer med hjälp av t.ex. rödtext eller kursiv text.
Vi tar inte bort information om olika lösningsförlag. Vi sparar allt under en arkivsida för att kunna gå tillbaka och förklara varför man inte slog in på den ena eller andra vägen. Syftet är att spara tid i situationer där gamla beslut ifrågasätts. Då ska det finnas dokumenterat varför man valde eller inte valde ett visst spår.
Tanken ä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.
Nya projekt som berör lösningen dokumenteras normalt i samma i Confluence-space. Skapar man en helt ny lösning som ersätter den gamla skapar man ett nytt Confluence-space för den nya lösningen och arkiverar det gamla spacet när man pensionerat den gamla lösningen.
Alla Confluence-space som rör lösningar är taggade med kategori Lösning för att lätt kunna sortera ut lösningar i Space Directory