Page History

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 (platformatributterplatformattributter) 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

Der findes tre typer 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 RFC'er (skabeloner), 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 komponentergennemføre. Komponentspecifikke Inventory-RFC'er oprettes på baggrund af disse skabelon-RFC'er.

Inventory-tjekket afrapporteres ved at udfylde skemaerne i hver komponents inventory-RFC'er. Den enkelte Inventory-RFC lever videre fra den ene Inventory analyse til den næste, så historikken for analyser på den enkelte komponent kan findes samlet i komponentens 3 RFC'er.

Når et inventory-tjek gennemføres, kopieres skemaet i den relevante RFC ind i en kommentar på samme RFC, og 2. der tilføjes en kolonne omdøbes til svar (tryk på "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. 
+" når du står i kommentarfeltet og indsæt tabel - indholdet kan kopieres ind der). Hver række indeholder et målepunkt/attribut, og for hver af disse er det forventede udfaldsrum beskrevet. Der er en del attributter med udfaldsrummet "Ja / Nej / Mangler". Det skal tydeligt fremgå af svaret, om attributten er relevant for komponenten. Hvis der er behov for opfølgning, oprettes en eller flere RFC'er vedrørende dette, og deres jira-numre anføres i skemaet. 

Proces

Oprettelse

...

af inventory RFC'er (PO)

1. For hver komponent, som fremgår af [SDS-5819] NSP-komponent inventory analyse - SDS JIRA (nspop.dk), opretter har PO 'en oprettet 3 RFC'er som kopi'er kopier af de 3 skabelon-RFC'er.
2. PO sammenkæder har ansvar for
   1. at RFC'erne er sammenkædet. 
   PO tilføjer leverandør (
   1. at leverandør er tilføjet
      1. Vedligeholdelsesleverandører er pr. 2024
   henholdsvis Arosii,
   1. 1. KIT Dok/Sik
   eller
   1. 1. , KIT Reg
   . og SDS)
   1. 1. . eller Arosii
      2. Platformleverandør er pr. 2024 Arosii
3. Det er aftalt, at Inventory-RFC'er ikke skal behandles på CAB. PO lægger dem derfor PO lægger RFC'erne direkte i status "Klar til planlægning" som "mindre driftsrelaterede opgaver".

Behandling af inventory RFC'er

Leverandør-attribut-RFC’en:

1. 1. Skemaet med leverandørattributter udfyldes.
   2. Hvis inventory-analysen har påvist mangler, opretter leverandøren de nødvendige RFC'er til at følge op på manglerne. Jira-numre anføres i skemaet og RFC'er sammenkædes med Inventory-RFC'en.
   3. Leverandør-attribut-RFC’en sendes
Ansvarlig for Vedligeholdelsesleverandøren udfylder skemaet med leverandørattributter og sender RFC’en
2. 1. videre til kvalitetssikring hos QA-leverandøren.
Når
3. 1. QA
er gennemført tildeler QA
4. 1. -leverandøren gennemfører kvalitetssikring, tildeler RFC'en til PO og sætter den i status "Åben".

Platform-attribut-RFC’en:

...

1. 1. Skemaet med platformattributter udfyldes.
   2. Hvis inventory-analysen har påvist mangler, opretter leverandøren de nødvendige RFC'er til at følge op på manglerne. Jira-numre anføres i skemaet, og RFC'er sammenkædes med Inventory-RFC'en.
   3. Platform-attribut-RFC’en sendes
QA-leverandøren udfylder skemaet med platformattributter og sende RFC’en
2. 1. videre til kvalitetssikring hos SDS-arkitekterne
.Status sættes til "Åben" og tildeles til
3. 1. ved at tildele den til en navngivet arkitekt.
   2. Arkitekten gennemfører kvalitetssikring, tildeler RFC'en til PO og sætter den i status "Åben".

PO-RFC'en:

PO udfylder
1. 1. PO-skemaet udfyldes.
2. RFC’er med opfølgningsopgaver oprettes på baggrund af besvarelserne omkring leverandør- og platform-attributter.
3. 1. Et overblik over oprettede opfølgningsopgaver skal fremgå af PO-inventory-RFC'en
enten
4. 1. som aktivitetssammenkædninger
eller i en kommentar
5. 1. .
   2. 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
6. 1. dette begrundes. 
   2. I "Oversigt over PO på komponenter og leverandør support" udfyldes kolonnen "Komponentstatus" med
link
7. 1. 1. Link til PO-RFC'en
og dato
8. 1. 1. og 
      2. Dato for afslutning af Inventory-analysen. 
   2. Når det samlede inventory
med ovenstående punkter
9. 1. er afsluttet, sættes alle komponentens inventory-RFC'er i status "På hold" indtil det tidspunkt, hvor fornyet inventory skal igangsættes (efter
ca.
10. 1. 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?
11. 1.  

Platformattributter (udfyldes af QA-leverandørenplatformleverandøren)

...

...

Leverandørattributter (udfyldes af vedligeholdelsesleverandøren)