Inventory-analyser for alle komponenter kan findes i Jira via det overordnede epic: [SDS-5819] NSP-komponent inventory analyse - SDS JIRA (nspop.dk)

Baggrund

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 af henholdsvis vedligeholdelsesleverandøren (leverandørattributter), platformsleverandøren (platformatributter) og PO'en i hver deres RFC. 

PO har ansvaret for at Inventory gennemføres, og at de relevante opfølgningsopgaver defineres og prioriteres.

Vejledning

Inventory-tjekket afrapporteres ved at udfylde skemaet i hver inventory-RFC. Hver række indeholder et målepunkt/attribut, og for hver af disse er det forventede udfaldsrum beskrevet.

Der er oprettet 3 skabelon-RFC’er, svarende til de inventory-opgaver som henholdsvis platformleverandøren (SDS-5831), vedligeholdelsesleverandøren (SDS-5832) og PO’en (SDS-5820) skal løse. På baggrund af disse skabeloner opretter PO de tilsvarende RFC'er for de enkelte komponenter.

Når et inventory-tjek gennemføres, kopieres skemaet i den relevante RFC ind i en kommentar på samme RFC, og 2. kolonne omdøbes til "Svar". Svarværdierne skrives ind i denne kolonne. Hvis der er behov for opfølgning, oprettes en eller flere RFC'er til dette, og jira-nummer anføres. 
Der er en del attributter med udfaldsrummet "Ja / Nej / Mangler". Det skal tydeligt fremgå, om attributten er relevant for komponenten.

Proces

Oprettelse og behandling af inventory RFC'er

1. For hver komponent, som fremgår af [SDS-5819] NSP-komponent inventory analyse - SDS JIRA (nspop.dk), opretter PO'en 3 RFC'er som kopi'er af de 3 skabelon-RFC'er.
2. PO sammenkæder RFC'erne. 
3. PO tilføjer leverandør ( pr. 2024 henholdsvis Arosii, KIT Dok/Sik eller KIT Reg. og SDS)
4. PO lægger RFC'erne direkte i status "Klar til planlægning" som "mindre driftsrelaterede opgaver".

Leverandør-attribut-RFC’en:

1. Ansvarlig for Vedligeholdelsesleverandøren udfylder skemaet med leverandørattributter og sender RFC’en videre til kvalitetssikring hos QA-leverandøren.
2. Når QA er gennemført tildeler QA-leverandøren RFC'en til PO og sætter den i status "Åben".

Platform-attribut-RFC’en:

1. QA-leverandøren udfylder skemaet med platformattributter og sende RFC’en videre til kvalitetssikring hos SDS-arkitekterne.
2. Status sættes til "Åben" og tildeles til en navngivet arkitekt.
3. Arkitekten gennemfører kvalitetssikring, tildeler RFC'en til PO og sætter den i status "Åben".

PO-RFC'en:

1. PO udfylder PO-skemaet.
2. RFC’er med opfølgningsopgaver oprettes på baggrund af besvarelserne omkring leverandør- og platform-attributter.
3. Et overblik over oprettede opfølgningsopgaver skal fremgå af PO-inventory-RFC'en enten som aktivitetssammenkædninger eller i en kommentar.
4. 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. 
5. I "Oversigt over PO på komponenter og leverandør support" udfyldes kolonnen "Komponentstatus" med link til PO-RFC'en og dato for afslutning af Inventory-analysen. 
6. 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). Den enkelte RFC lever således videre, og den nye inventory-analyse dokumenteres i samme RFC som den forrige. Mister vi så historik?

Platformattributter (udfyldes af QA-leverandøren)

Leverandørattributter (udfyldes af vedligeholdelsesleverandøren)

PO tjekliste