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), leverandøren af QA og arkitekturbistand (platform-attributter) 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 gennemføres 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.
Når inventory-RFC'en gennemføres, kopieres skemaet ind i en kommentar, og 2. kolonne omdøbes til "Svar". Svarværdierne skrives ind i denne kolonne. Hvis svaret til en attribut er for omfattende til, at det kan være i skemaet, skrives det ind som en note nedenunder skemaet med tydelig angivelse af, hvilken attribut noten omhandler. Hvis opfølgning igangsættes, anføres jira-nummer.
Der er en del attributter med udfaldsrummet "Ja / Nej / Mangler". Her er det vigtigt at anføre, om en komponent burde have en bestemt attribut, eller om det er korrekt, at den ikke er angivet. Hvis der er behov for opfølgning i forhold til en attribut, anføres dette, og behovet uddybes gerne i en note, så opfølgningen let kan igangsættes.
Proces
Der er oprettet 3 skabelon-RFC’er, svarende til de inventory-opgaver som henholdsvis QA-leverandøren (SDS-5831), vedligeholdelsesleverandøren (SDS-5832) og PO’en (SDS-5820) skal løse.
Oprettelse og behandling af inventory RFC'er
- 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.
- PO sammenkæder RFC'erne.
- PO tilføjer leverandør (henholdsvis Arosii, KIT Dok/Sik eller KIT Reg. og SDS)
- PO lægger RFC'erne direkte i status "Klar til planlægning" som "mindre driftsrelaterede opgaver".
Leverandør-attribut-RFC’en:
- Vedligeholdelsesleverandøren udfylder skemaet med leverandørattributter og sender RFC’en videre til kvalitetssikring hos QA-leverandøren.
- 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:
- QA-leverandøren udfylder skemaet med platformattributter og sende RFC’en videre til kvalitetssikring hos SDS-arkitekterne.
- Status sættes til "Åben" og tildeles til en navngivet arkitekt.
- Arkitekten gennemfører kvalitetssikring, tildeler RFC'en til PO og sætter den i status "Åben".
PO-RFC'en:
- PO udfylder PO-skemaet.
- RFC’er med opfølgningsopgaver oprettes, på baggrund af besvarelserne omkring leverandør- og platform-attributter.
- Et overblik over oprettede opfølgningsopgaver skal fremgå af PO-inventory-RFC'en enten som aktivitetssammenkædninger eller i en kommentar.
- 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.
- 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 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.
Platformattributter (udfyldes af QA-leverandøren)
Attribut | Udfaldsrum |
---|---|
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. |
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
...