Page History
...
Som et led i den løbende vedligeholdelse af NSP skal hver komponent jævnligt igennem et inventory-tjek. Ideen med dette er at give Product Owner for komponenten en mulighed for dels at få et overblik over komponentens tilstand, dels at igangsætte vedligeholdelsesopgaver. Et inventory-tjek udføres både af henholdsvis PO'en, leverandør for leverandøren af QA og arkitekturbistand (platform-attributter) og vedligeholdelsesleverandøren (leverandørattributter) i hver sin deres RFC. PO har ansvaret for at Inventory gennemføres, og at de relevante opfølgningsopgaver defineres og prioriteres.
...
Inventory-tjekket gennemføres ved at udfylde skemaet i hver inventorys inventory-RFC. Hver række indeholder et målepunkt/attribut, og for hver af disse er der beskrevet det forventede udfaldsrum beskrevet.
Når inventory-RFC'en gennemføres, kopieres skemaet ind i en kommentar og svarværdierne skrives ind i 2. kolonne, som også omdøbes til "Svar". Hvis svaret til en attribut er for omfattende til at det kan være i skemaet, skrives det ind som en note nedenunder skemaet med tydelig angivelse af hvilken attribut noten omhandler.
Der er en del attributter med udfaldsrummet "Ja / Nej / Mangler", her . Her er det vigtigt at anføre, om en komponent burde have en bestemt attribut, eller om det er korrekt, at denne ikke er til stedeangivet. Hvis der er behov for opfølgning i forhold til en attribut, anføres dette som note, og behovet uddybes gerne i en note, så opfølgningen let kan igangsættes.
Proces
Der er oprettet 3 skabelon-RFC’er, svarende til de inventory-opgaver som henholdsvis QA-leverandøren (SDS-5831), vedligeholdelsesleverandøren (SDS-5832) og PO’en (SDS-5820) skal løse.
Oprettelse og behandling af inventory RFC'er
- For hver komponent, som fremgår af
, opretter PO 3 RFC'er som kopi'er af de 3 skabelon-RFC'er.Jira server NSI JIRA serverId e64c3bc3-001c-3439-bc53-f7a235a8cd61 key SDS-5819 - PO sammenkæder RFC'erne.
- PO tilføjer leverandør (henholdsvis Arosii, KIT Dok/Sik eller KIT Reg. og SDS)
- PO lægger RFC'erne direkte i status "Klar til planlægning" som "mindre driftsrelaterede opgaver".PO opretter de 3 tilsvarende RFC’er for hver komponent (jf. komponentliste-link). RFC’erne sammenkædes.
Leverandør-attribut-RFC’en
...
:
- Vedligeholdelsesleverandøren udfylder ”Klar til planlægning”.Efter udfyldelse af skemaet med leverandørattributter sendes og sender RFC’en videre til kvalitetssikring hos QA-leverandøren.
- Efter QA tildeles den Når QA er gennemført tildeler QA-leverandøren RFC'en til PO og sættes sætter den i status "Åben".
Platform-attribut-RFC’en
...
:
- QA-leverandøren udfylder ”Mindre driftsrelateret”. Den kan lægges direkte i status: ”Klar til planlægning”.Efter udfyldelse af skemaet med platformattributter sendes og sende RFC’en videre til kvalitetssikring hos SDS-arkitekterne.
- Status sættes til "Åben" og tildeles til en navngivet arkitekt.
- Efterfølgende tildeles den Arkitekten gennemfører kvalitetssikring, tildeler RFC'en til PO og sættes sætter den i status status "Åben"
...
- .
PO-RFC'en:
- PO udfylder PO-skemaet.
- RFC’er med opfølgningsopgaver oprettes, når leverandør- og platform-RFC’erne er gennemført
...
- .
- Et overblik over oprettede opfølgningsopgaver skal fremgå af PO-inventory-RFC'en enten som aktivitetssammenkædninger eller i en kommentar
...
- .
- Hvis der er påpeget et behov for opfølgning, men det besluttes ikke at igangsætte dette, skal der skrives en begrundelse ind i en kommentar.
- Kolonnen "Komponentstatus" i "Oversigt over PO på komponenter og leverandør support" udfyldes med link til PO-RFC'en og dato for afslutning af Inventory-analysen.
- Når det samlede inventory med ovenstående punkter er afsluttet, sættes alle komponentens inventory-RFC'er i status "På hold" indtil det tidspunkt, hvor fornyet inventory skal igangsættes (efter ca. 1 år).
Platformattributter (udfyldes af QA-leverandøren)
...
Attribut | Udfaldsrum |
---|---|
Komponentens navn | fx: service navn |
Dato for udfyldelse | dd-mm-yyyy |
Brugerhistorier | Ja / Nej / Mangler |
Bruger den Security-API? | Ja / Nej / Mangler |
Bruger den Audit-API? | Ja / Nej / Mangler |
Lever den op til krav om code-coverage? | Ja / Nej |
Indeholder den ignorerede unittests? | Ja / Nej |
Er integrationstesten fyldestgørende? | Ja / Nej |
SVN eller Git? | Link til repo |
Bruger den egen database? | Ja / Nej |
Services i komponenten | Hvilke f.eks. SCES, SYES, SKRS etc. |
Kalder den NAS i produktion? | Ja / Nej |
Kalder den MinLog i produktion? | Ja / Nej |
Kalder den STS i produktion? | Ja / Nej |
Kalder den CPR-opslag i produktion? | Ja / Nej |
Kalder den MinSpærring i produktion? | Ja / Nej |
Kalder den BRS i produktion? | Ja / Nej |
Hvilke andre komponenter kalder den? | F.eks. CAVE etc. |
Hvilke eksterne services er den afhængig af? | F.eks. MidWifeRegistration, Digst Fuldmagt, CVR-RID |
PO tjekliste Product owner gennemgår komponent tjeklisten, efter opgaven er blevet QA-godkendt. Udfyld efterfølgende statuslisten og gem den på nspop, derefter tilføj linket til komponentens oversigtsside.
Attribut | Udfaldsrum |
---|---|
Komponentens navn | fx: service navn |
Dato for udfyldelse | dd-mm-yyyy |
Hvornår er der sidst lavet gennemgang af 3. parts biblioteker? | dd-mm-yyyy |
Er der større mangler i dokumentationen | Ja / Nej |
Hvornår udløber produktions-certifikaterne | dd-mm-yyyy (Spørg Netic) |
Dato for afslutning af komplet årligt inventory for leverandørattributter, platformattributter og PO-attributter | dd-mm-yyyy |
...