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 (platformattributter) 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-RFC'er (skabeloner), som henholdsvis platformleverandøren (SDS-5831), vedligeholdelsesleverandøren (SDS-5832) og PO’en (SDS-5820) skal gennemfø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 der tilføjes en kolonne til svar. 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 PO'en 3 RFC'er som kopier af de 3 skabelon-RFC'er.
  2. PO sammenkæder RFC'erne. 
  3. PO tilføjer leverandør
    1. Vedligeholdelsesleverandører er pr. 2024 KIT Dok/Sik, KIT Reg. eller Arosii
    2. Platformleverandør er pr. 2024 Arosii
  4. Det er aftalt, at Inventory-RFC'er ikke skal behandles på CAB. PO lægger dem derfor direkte i status "Klar til planlægning".


Behandling af inventory RFC'er

Leverandør-attribut-RFC’en:

    1. Skemaet med leverandørattributter udfyldes.
    2. Hvis inventory-analysen har påvist mangler, oprettes 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 videre til kvalitetssikring hos QA-leverandøren.
    4. QA-leverandøren gennemfører kvalitetssikring, tildeler RFC'en til PO og sætter den i status "Åben".


Platform-attribut-RFC’en:

    1. Skemaet med platformattributter udfyldes.
    2. Hvis inventory-analysen har påvist mangler, oprettes 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 videre til kvalitetssikring hos SDS-arkitekterne ved at tildele den til en navngivet arkitekt.
    4. Arkitekten gennemfører kvalitetssikring, tildeler RFC'en til PO og sætter den i status "Åben".


PO-RFC'en:

    1. PO-skemaet udfyldes.
    2. Et overblik over oprettede opfølgningsopgaver skal fremgå af PO-inventory-RFC'en som aktivitetssammenkædninger.
    3. Hvis der er påpeget et behov for opfølgning, men det besluttes ikke at igangsætte dette, skal dette begrundes. 
    4. I "Oversigt over PO på komponenter og leverandør support" udfyldes kolonnen "Komponentstatus" med
      1. Link til PO-RFC'en og 
      2. Dato for afslutning af Inventory-analysen. 
    5. Når det samlede inventory er afsluttet, sættes alle komponentens inventory-RFC'er i status "På hold" indtil det tidspunkt, hvor fornyet inventory skal igangsættes (efter 1 år). Den enkelte RFC lever således videre, og den nye inventory-analyse dokumenteres i samme RFC som den forrige. 



Platformattributter (udfyldes af platformleverandøren)



Komponentens navnUdfyldes af PO ifm oprettelse af RFC
Dato for udfyldelsedd-mm-yyyy
NSP image versionx.y.z
Anvendte ikke-godkendte 3. parts biblioteker?Hvilke (f.eks. Spring Boot)
Tilgår den Stamdata direkte og korrekt?Korrekt / Ukorrekt / Tilgår ikke
Lever status-siden op til forventningerne?Ja / Nej (F.eks. Certifikater mv)
Indeholder den whitelistingJa / Nej / Mangler
Kan den kaldes via DRG?Ja / Nej / Mangler
Har den et cleanup-job?Ja / Nej / Mangler
Er der udviklet automatisk regressionstests?Ja / Nej / Mangler


Leverandørattributter (udfyldes af vedligeholdelsesleverandøren)

Attribut

Udfaldsrum

Komponentens navnfx: service navn
Dato for udfyldelsedd-mm-yyyy
BrugerhistorierJa / 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 komponentenHvilke 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 

Attribut

Udfaldsrum

Komponentens navnfx: service navn
Dato for udfyldelsedd-mm-yyyy
Hvornår er der sidst lavet gennemgang af 3. parts biblioteker?dd-mm-yyyy
Er der større mangler i dokumentationenJa / Nej
Hvornår udløber produktions-certifikaternedd-mm-yyyy (Spørg Netic)
Dato for afslutning af komplet årligt inventory for leverandørattributter, platformattributter og PO-attributterdd-mm-yyyy