Inventory-analyser for alle komponenter kan findes i Jira via det overordnede epic: [SDS-5819] NSP-komponent inventory analyse - SDS JIRA (nspop.dk)
1.1. 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.
1.2. 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 (tryk på "+" 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.
1.2.1. Proces
1.2.1.1. Oprettelse af inventory RFC'er (PO)
- For hver komponent, som fremgår af [SDS-5819] NSP-komponent inventory analyse - SDS JIRA (nspop.dk), har PO oprettet 3 RFC'er som kopier af de 3 skabelon-RFC'er.
- PO har ansvar for
- at RFC'erne er sammenkædet.
- at leverandør er tilføjet
- Vedligeholdelsesleverandører er pr. 2024 KIT Dok/Sik, KIT Reg. eller Arosii
- Platformleverandør er pr. 2024 Arosii
- Det er aftalt, at Inventory-RFC'er ikke skal behandles på CAB. PO lægger dem derfor direkte i status "Klar til planlægning".
1.2.1.2. Behandling af inventory RFC'er
Leverandør-attribut-RFC’en:
-
- Skemaet med leverandørattributter udfyldes.
- 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.
- Leverandør-attribut-RFC’en sendes videre til kvalitetssikring hos QA-leverandøren.
- QA-leverandøren gennemfører kvalitetssikring, tildeler RFC'en til PO og sætter den i status "Åben".
Platform-attribut-RFC’en:
-
- Skemaet med platformattributter udfyldes.
- 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.
- Platform-attribut-RFC’en sendes videre til kvalitetssikring hos SDS-arkitekterne ved at tildele den til en navngivet arkitekt.
- Arkitekten gennemfører kvalitetssikring, tildeler RFC'en til PO og sætter den i status "Åben".
PO-RFC'en:
-
- PO-skemaet udfyldes.
- Et overblik over oprettede opfølgningsopgaver skal fremgå af PO-inventory-RFC'en som aktivitetssammenkædninger.
- Hvis der er påpeget et behov for opfølgning, men det besluttes ikke at igangsætte dette, skal dette begrundes.
- 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.
- 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 navn | Udfyldes af PO ifm oprettelse af RFC |
Dato for udfyldelse | dd-mm-yyyy |
NSP image version | x.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 whitelisting | Ja / 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 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. |
Har den dokumentation for fejlscenarier? | Ja / Nej / Mangler |
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 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 |