Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 både af henholdsvis PO'en, leverandør for leverandøren af QA og arkitekturbistand (platform-attributter) og vedligeholdelsesleverandøren (leverandørattributter) i hver sin deres RFC. PO har ansvaret for at Inventory gennemføres, og at de relevante opfølgningsopgaver defineres og prioriteres.

...

Inventory-tjekket gennemføres ved at udfylde skemaet i hver inventorys inventory-RFC. Hver række indeholder et målepunkt/attribut, og for hver af disse er der beskrevet det forventede udfaldsrum beskrevet.

Når inventory-RFC'en gennemføres, kopieres skemaet ind i en kommentar og svarværdierne skrives ind i 2. kolonne, som også omdøbes til "Svar". 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.
Der er en del attributter med udfaldsrummet "Ja / Nej / Mangler", her . Her er det vigtigt at anføre, om en komponent burde have en bestemt attribut, eller om det er korrekt, at denne ikke er til stedeangivet. Hvis der er behov for opfølgning i forhold til en attribut, anføres dette som note, 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

  1. For hver komponent, som fremgår af
    Jira
    serverNSI JIRA
    serverIde64c3bc3-001c-3439-bc53-f7a235a8cd61
    keySDS-5819
    , opretter PO 3 RFC'er som kopi'er af de 3 skabelon-RFC'er.
  2. PO sammenkæder RFC'erne. 
  3. PO tilføjer leverandør (henholdsvis Arosii, KIT Dok/Sik eller KIT Reg. og SDS)
  4. PO lægger RFC'erne direkte i status "Klar til planlægning" som "mindre driftsrelaterede opgaver".PO opretter de 3 tilsvarende RFC’er for hver komponent (jf. komponentliste-link). RFC’erne sammenkædes.


Leverandør-attribut-RFC’en

...

:

  1. Vedligeholdelsesleverandøren udfylder ”Klar til planlægning”.Efter udfyldelse af skemaet med leverandørattributter sendes og sender RFC’en videre til kvalitetssikring hos QA-leverandøren.
  2. Efter QA tildeles den Når QA er gennemført tildeler QA-leverandøren RFC'en til PO og sættes sætter den i status "Åben".


Platform-attribut-RFC’en

...

:

  1. QA-leverandøren udfylder ”Mindre driftsrelateret”. Den kan lægges direkte i status: ”Klar til planlægning”.Efter udfyldelse af skemaet med platformattributter sendes og sende RFC’en videre til kvalitetssikring hos SDS-arkitekterne.
  2. Status sættes til "Åben" og tildeles til en navngivet arkitekt.
  3. Efterfølgende tildeles den Arkitekten gennemfører kvalitetssikring, tildeler RFC'en til PO og sættes sætter den i status status "Åben"

...

  1. .


PO-RFC'en:

  1. PO udfylder PO-skemaet.
  2. RFC’er med opfølgningsopgaver oprettes, når leverandør- og platform-RFC’erne er gennemført

...

  1. .
  2. Et overblik over oprettede opfølgningsopgaver skal fremgå af PO-inventory-RFC'en enten som aktivitetssammenkædninger eller i en kommentar

...

  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. 
  3. Kolonnen "Komponentstatus" i "Oversigt over PO på komponenter og leverandør support" udfyldes med link til PO-RFC'en og dato for afslutning af Inventory-analysen.
  4. 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).



Platformattributter (udfyldes af QA-leverandø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 Product owner gennemgår komponent tjeklisten, efter opgaven er blevet QA-godkendt. Udfyld efterfølgende statuslisten og gem den på nspop, derefter tilføj linket til komponentens oversigtsside.

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

...