Principper for dokumentation
- Rune Gram-Madsen (Unlicensed)
- Natasha Dsouza Krogh
- Stine Gjetting Stage
- Former user (Deleted)
Udviklingsleverandørerne skal vedligeholde den eksisterende dokumentation som den forefindes på STAR’s WIKI.
Dokumentationen er primært fremkommet gennem releaseprocessen, hvor opdateret dokumentation er en del af releasens godkendelseskriterier.
STAR ønsker at dokumentation udarbejdes ud fra følgende principper:
P30 | Dokumentation målrettet kørende kode Fokus er leverance af kørende kode. Dette betyder, at dokumentationen skal udarbejdes med det formål at sikre kørende kode. Dette omfatter dokumentation, der understøtter idriftsættelse, videreudvikling og vedligehold, integration med eksterne parter og evt. overdragelse til ny leverandør. |
|---|---|
P31 | Overordnet dokumentation målrettet grundlæggende forståelse Dokumentation, der ikke er tæt knyttet til kørende kode, giver værdi ved at beskrive vores systemlandskab på et så højt niveau, at den bidrager til umiddelbar forståelse for systemernes funktion og indretning. |
P32 | Korrekt dansk, alternativt engelsk STAR mener, at god og korrekt anvendelse af dansk i dokumentation og kommunikation giver bedre kvalitet. EESSI anvender i udpræget grad engelsk i teknisk dokumentation og europæisk kommunikation. |
Udmøntning af ovenstående principper skal ske under overholdelse af følgende krav:
K30 | Overordnede systemdokumentation Udviklingsleverandøren skal vedligeholde den overordnede systemdokumentation på et sådant niveau, at Videreudvikling og Vedligeholdelse på et hvert tidspunkt kan overdrages til en leverandør uden forudgående kendskab til systemet. |
K31 | Snitfladebeskrivelser og webservicedokumentation Udviklingsleverandøren skal vedligeholde og forbedre beskrivelse af snitfladerne, herunder webservicedokumentationen, så denne til en hver tid indeholder fyldestgørende forretningsmæssige samt tekniske beskrivelser. |
K32 | Systemdokumentation i den agile proces ISB’er, Epics og User stories er grundlaget for udvikling og vedligehold og er udtryk for de løbende krav til systemet. Epics og User stories er ikke blivende dokumentation efter udviklingen er afsluttet, men relevante dele indarbejdes i den blivende dokumentation. |
K33 | ISB og Epic Udviklingsleverandøren udarbejder ISB’er og Epics efter en af STAR udarbejdet skabelon. Dette dokumenteres i det fælles værktøj Jira. |
K34 | User Stories User Stories dokumenteres i det fælles værktøj Jira. |
K35 | Testdokumentation For Delsystemer, der anvender Det Fælles Setup, skal der i Opstartsfasen aftales format for dokumentation til brug for STAR’s Kundetest. Epics indgår i dokumentationen til Kundetest, men det er den aftalte dokumentation, der er det endelige testgrundlag. For Delsystemer der understøtter EESSI udarbejdes materialet i samarbejde med DK EESSI Service Desk og repræsentanter fra slutbrugerinstitutionerne (de Kompetente Institutioner). |
K36 | Testcases Udviklingsleverandøren leverer efter en aftalt skabelon testcases, intern integrationstest og E2E-test. |
K37 | Anonymitet Dokumentation skal udarbejdes på en sådan måde, at det ikke er muligt at identificere enkeltpersoner (borgere og konsulenter, der anvender sig selv eller kollegaer som testdata). |
K38 | FDA Dokumentation skal overholde Fællesoffentlig Digital Arkitektur (FDA) retningslinjer [1]
|
K39 | Dokumentation til Statens Arkiver Der skal udarbejdes dokumentation i overensstemmelse med krav fra Statens Arkiver. |
[1] Der henvises til:
https://arkitektur.digst.dk/node/563 og https://arkitektur.digst.dk/sites/default/files/josao_retningslinjer_for_formidling_og_dokumentation_af_arkitektur_i_digitaliseringsprojekter.pdf