Baggrund

Som et led i den løbende vedligeholdelse af NSP skal hver komponent regulært igennem et inventory-tjek. Ideen med dette er at give Product Owner for komponenten en mulighed for dels at få et overblik over tilstanden, dels at igangsætte vedligeholdelsesopgaver. Et inventory-tjek udføres både af PO'en, platformsleverandøren og vedligeholdelsesleverandøren i hver sin RFC.

Vejledning

Inventory-tjekket gennemføres ved at udfylde skemaet i hver inventorys RFC. Hver række indeholder et målepunkt/attribut og for hver af disse er der beskrevet det forventede udfaldsrum. Skemaet udfyldes ved at kopieres første kolonne ind i en kommentar og indsætte værdierne i en ny kolonne. Hvis der er yderligere noter til en attribut end der kan være i et skema, skrives disse under skemaet så det tydeligt fremgør hvilken attribut noten omhandler.
Der er en del attributter med udfaldsrummet "Ja / Nej / Mangler", her er det vigtigt at skelne mellem om en komponent burde have en bestemt attribut eller om det er korrekt at denne ikke er til stede.

Opfølgning

Når sagen er leveret til QA tjekkes værdierne igennem af kvalitetssikringen og herefter fører PO'en dem ind i et samlet NSP Inventory.


Product owner check list 

Product owners gennemgår komponent-tjeklisten efter den er blevet QA-godkendt, udfylder herefter statuslisten og gemmer den i nspop, samt tilføjer dens link til komponentens oversigtsside.

I dette link SDS-5820 - Inventory: Komponentnavn AFVENTER kan du se eksempel på PO-tjekliste

Attribut

Udfaldsrum

Komponentens navndokumentdelingsservice
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)


Platform attributter - Arosii

Inventory


Attribut

Udfaldsrum

Komponentens navndokumentdelingsservice
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

SDS-5832 - Inventory: Komponentnavn (leverandør attributter) AFVENTER


Leverandør attributter - KIT

Spørgsmål

Svar

Action

Komponentens navndokumentdelingsservice
Dato for udfyldelse14-12-2022
BrugerhistorierJa/Nej/ManglerDDS - Brugerhistorier - NSP services - Global Site (nspop.dk)
Bruger den Security-API?Ja
 
(checker afhængigheder for komponenten med kommando:
$mvn dependency:tree | grep security-api
[INFO] +- dk.sds.nsp.security:security-api:jar:1.0.5:provided
[INFO] +- dk.sds.nsp.security:security-api:jar:1.0.5:provided
[INFO] +- dk.sds.nsp.security:security-api:jar:1.0.5:provided
)

Bruger den Audit-API?Ja
 
(checker afhængigheder for komponenten med kommando:
$ mvn dependency:tree | grep audit-api
[INFO] +- dk.sds.nsp.audit:audit-api:jar:1.0.1:provided
[INFO] +- dk.sds.nsp.audit:audit-api:jar:1.0.1:provided
[INFO] +- dk.sds.nsp.audit:audit-api:jar:1.0.1:provided)

Lever den op til krav om code-coverage?Nej
 
(Den nuværende procent er 54%
Aflæser coverage procent på byggejobbet:  https://jenkins.nspop.dk/job/DDS/job/DDS_build/)
hvad gør vi? opretter RFC på det? hvem afgøre 
Indeholder den ignorerede unittests?Ja
 
(Følgende liste - 10 tests ignored:


YdernummerValidatorImplTest.testValidateYdernummersInvalid
TreatmentRelationInvokerTest (alle 7 tests heri)DDSContextTest.testDDSContextUserNoHsuidCorrectPrivileges
DDSContextTest.testDDSContextOrgWhitelist
MinspaerringTest (1 test heri)|
 
 
 

Er integrationstesten fyldestgørende?Ja / Nej: Se tabel nedenfor
SVN eller Git?SVN
https://svn.nspop.dk/svn/components/dds/

Bruger den egen database?Ja
(Komponenten anvender ikke liquibase til at styre databaseopdateringer)

Services i komponentenDDS Registry
DDS Repository

Kalder den NAS i produktion?Nej
Kalder den MinLog i produktion?Ja
Kalder den STS i produktion?Ja
Kalder den CPR-opslag i produktion?Ja
(Personinformation til validering af cprnummer samt oplysninger vedr. forældremyndighed og værgemål)

Kalder den MinSpærring i produktion?Ja
Kalder den BRS i produktion?Ja
Hvilke andre komponenter kalder den?DDS har en række backends, som den er "proxy" for
Disse er konfigurerbare (de skal blot sættes op i databasen).
De nuværende er
 
DDS Reposiory:
  • OpenXds Repository
  • AO
  • FSK
  • Labsvar Adapter
     
    DDS Registry:
  • NXRG
  • AO
  • FSK Registry
  • Labsvar Adapter

Hvilke eksterne services er den afhængig af?DDS har en række backends, som den er "proxy" for.
Disse kan være eksterne for NSP - i praksis:
  • PLSP (aftaler) - både DDS Repository og DDS Registry
  • KIH (spørgeskema og hjemmemålinger) - DDS Repository




Oversigt over integrationstests:

Generelt er der mange integrationstests i DDS og der genereres pæne testreports vha frameworket Cucumber. Disse kunne godt publiceres på en måde, så PO kan læse dem.

Der mangler dog tests vedr "på vegne af sundhedsfaglig". Det kræver nok en snak om, hvordan denne brugertype præcis skal forstås for at meningsfyldte tests kan udarbejdes. Derudover er der ikke tests, der verificeres af "idws" snitflader ikke kan kaldes af et "dgws" kald og vice-versa.


Service

Brugertype:
Borger

Brugertype:
Borger på vegne af borger

Brugertype:
Sundhedsfaglig
med autorisation

Brugertype:
Sundhedsfaglig
uden
autoriasation

Brugertype:
På vegne af
sundhedsfaglig

DDSRegistryNoDgwsWs.documentRegistryIdwsRegistryStoredQuery (idws)  forældre og værge scenarierIkke tilladtIkke tilladtIkke tilladt
DDSRegistryWS.documentRegistryRegistryStoredQuery (dgws)(sundhed.dk adgangen)(sundhed.dk adgangen forældre og værge scenarier) der testes både med spærringer og med/uden værdispring Forskellige nationale roller og uden nationali rolle
DDSRepositoryNoDgwsWs.documentRepositoryIdwsRetrieveDocumentSet (idws)
Ikke tilladtIkke tilladtIkke tilladt
DDSRepositoryWS.documentRepositoryRetrieveDocumentSet (dgws)


Komponent list