Differences

This shows you the differences between two versions of the page.

--- bst:rntriforkshared:public:operation_handbook [2021/05/25 14:39] – [2 Fælles Organisering] rn_sabina
+++ bst:rntriforkshared:public:operation_handbook [2021/12/20 15:37] (current) – [7 Ændringsstyring] mal
@@ Line 14: / Line 14: @@
 [[bst:rntriforkshared:public:styringsmodel|2.1 Kundens styringsmodel]]
-[[bst:rntriforkshared:public:noegleroller|2.2 Nøgleroller]]
+[[bst:rntriforkshared:public:noegleroller|2.2 Nøgleroller og ansvarsfordeling]]
-[[bst:rntriforkshared:public:ansvarsfordeling|2.3 Ansvarsfordeling]]
+[[bst:rntriforkshared:public:moederaekkerogfora|2.3 Møderækker og fora]]
-[[bst:rntriforkshared:public:moederaekkerogfora|2.4 Møderækker og fora]]
 ==== 3 SLA-krav ====
@@ Line 66: / Line 64: @@
 Korrespondance om sagen vil som udgangspunkt være mellem indmelder (den regionale forvalter eller LPS-leverandøren) og Netic/Trifork. FSA inddrages i relevante sager. For at kunne følge med i indmeldte sager i Jira, får FSA’en automatisk en advisering hver gang, der oprettes en sag i Jira hos Netic.
-=== 5.4 Eksempel på sagsgang ===
+=== 5.4 Eksempler på sagsgange ===
-<< MAL Eksempel på sagsgang gennem JIRA >>
+I det følgende beskrives nogle eksempler på sagers gang gennem systemet.
+== 5.4.1 Sag der bliver afvist ==
+I dette tilfælde vil en sag blive meldt ind i JIRA. Netic modtager sagen og visiterer den til Trifork i JIRA. Et konkret eksempel kunne være et spørgsmål om en dobbeltordinationsadvarsel. I et tænkt eksempel kunne sagen gå på at brugeren ikke forstår baggrunden for en advarsel om dobbeltordination. I dette tilfælde vil Trifork analysere issuet, og nå frem til at dobbeltordinationsadvarslen f.eks. kan skyldes indholdet af et indholdsstof i et kombinationspræparat som brugeren ikke troede var vigtigt. I dette tilfælde vil Trifork skrive en kommentar i sagen, og motivere et ønske om at lukke sagen i Netics JIRA. Hvis muligt sættes status til AWAITING EXTERNAL REPSONSE (kun på incidents ikke på service requests). Sagen lukkes af indmelderen eller FSA'en.
+== 5.4.2 Sag, der giver anledning til en fejlrettelse ==
+Her meldes en sag ind i JIRA af en regional systemforvalter eller et LPS-system. Netic modtager JIRAen og visiterer den til Trifork. Trifork analyserer sagen, og konstaterer at sagen skyldes en fejl i forhold til systemets specificerede funktionalitet. Trifork opretter en sag i Triforks interne JIRA, der anvendes til at styre udviklingsprocessen internt. Sagen analyseres og prioriteres og det besluttes sammen med Projektet om rettelsen er vigtig nok til at den skal forårsage en nødrettelse, eller om rettelsen kan afvente et kommende release. Rettelsen implementeres hos Trifork, og det kommunikeres i den eksterne sag til kunden hvilket release rettelsen kan forventes at blive leveret med. Efter test af rettelsen lukkes sagen af indmelderen eller FSA'en.
+== 5.4.3 Sag, der giver anledning til oprettelse af et ønske om videreudvikling ==
+Her meldes en sag ind i JIRA af en regional systemforvalter eller et LPS-system. Netic modtager JIRAen og visiterer den til Trifork. Trifork analyserer sagen, og konstaterer at systemets adfærd er som tiltænkt. Projektet kan I dette tilfælde vælge at oprette et ændringsønske på systemets backlog, hvis det vurderes at der er ønske hos brugerne om at tilpasse systemet. I dette tilfælde vil der blive oprettet en sag i videreudviklingsbackloggen, og den oprindelige JIRA-sag vil blive lukket af FSA'en med en henvisning hertil.
 === 5.5 Eskalering ===
-<< MAL og Sabina har begge lektier her >>
+Ved uoverensstemmelse mellem leverandør og forvaltning, vil der kunne være behov for eskalering på begge sider.
+For den fællesregionale forvaltnings side vil FSA'en kontakte sin kontorchef og vicekontorchef, sætte dem ind i situationen, hvorefter der lægges en plan for hvordan den pågældende situation skal håndteres.
+Hos Trifork er ekskalationsstigen opad defineret med trin 1 - ansvarlig for Business Unit og Trin 2 - ansvarlig for Trifork Public - Healthcare.
 ==== 6 Releasestyring ====
@@ Line 88: / Line 100: @@
 Forskellige tidsfrister for varsling af nye releases gør sig gældende, alt afhængig af om det er et major, minor eller patch-release. Major-releases kræver lang forudgående planlægning, da den nye snitflade kan kræve ændringer i anvendersystemerne. Minor-versionerne er knap så krævende ift. lange varsler, men kan indeholde snitfladeændringer der kræver tilpasninger i et anvendersystem, der ønsker at udnytte eventuel ny funktionalitet. Endelig kræver idriftsættelse af patches med bugfixes og små ændringer typisk kortere varsler da der ikke kræves ændringer i anvendersystemerne.
-<<SKEMA MED TIDSKRAV>>
+^ Type af ændring ^ Typisk tidsfrist  |
+| patch    | 14 dage |
+| minor    | 1 måned |
+| major | 3 måneder  |
 Releases planlægges i samarbejde med kunden, og udrulles typisk trinvis til først develop-miljøet (intern test), dernæst til exttest-miljøet (beregnet til test for kunde og eksterne parter) og når verificeret her til produktion. Typisk kan det forventes at et nyt release vil være tilgængelig for test på exttest for anvendersystemer i 1-2 uger inden der releases til produktionssystemet. Nødrettelser der idriftsættes hurtigere kan sevlfølgelig forekomme ved kritiske fejl.
@@ Line 104: / Line 120: @@
 Efter release til produktion overvåges systemet via loganalyseværktøjer med henblik på afdækning af uventede sideeffekter, og for i det hele taget at få bekræftet at systemet er kørende og fungerer efter opdateringen.
-=== 6.3 Levering af release ===
-Er velsagtens dækket af ovenstående?
 ==== 7 Ændringsstyring ====
-FMB er i gang med at etablere et fast årshjul, der bl.a. skal understøtte regionernes muligheder for at planlægge implementering i og indgå kontrakter med anvendersystemerne.
-Årshjulet vil angive de overordnede rammer for major og eventuelt også minor releases. Patches vil kunne frigives løbende efter behov. Helt overordnet planlægges der med et fast årligt major-release, hvor snitfladespecifkationen er færdig <<PRÆCIST HVORNÅR>>, således den kan danne basis for aftaler mellem regioner og anvendersystemer om implementering.
+=== 7.1 Årshjul ===
+FMB har fået etableret og godkendt et fast årshjul, der bl.a. skal understøtte regionernes muligheder for at planlægge implementering i og indgå kontrakter med anvendersystemerne.
+Årshjulet vil angive de overordnede rammer for major og eventuelt også minor releases. Patches vil kunne frigives løbende efter behov. Helt overordnet planlægges der med et fast årligt major-release, hvor snitfladespecifikationen er færdig i december, således den kan danne basis for aftaler mellem regioner og anvendersystemer om implementering.
+{{ :bst:rntriforkshared:public:arshjul.png?nolink |}}
+Årshjulet tager udgangspunkt i følgende elementer:
+== Et fast årligt major release med påkrævede snitfladeændringer (kategori 2) ==
+Et major release leveres som forudsætning for ibrugtagning af ny funktionalitet tilvejebragt via videreudvikling af FMB. Dermed bliver major releases kravsættende overfor anvendersystemerne omkring ibrugtagning af ny funktionalitet og de dermed afledte gevinster. Der leveres altid specifikation i december / release i FMB i marts. Således forventes det, at det faste årlige major release bliver fast ”fix punkt” i forventningen om, at regioner og almen praksis gradvis følger med på nye versioner af snitfladen.
+== Mulighed for flere årlige minor releases med evt. optionelle snitfladeændringer (kategori 1 og 2) ==
+Ifm. optionelle snitfladeændringer, vil anvendersystemerne altid kunne afvikles i uændret form efter frigivelse af nye minor releases (dvs. man kan blive på version 5.0.X selvom der kommer en version 5.1.X). Minor releases skal bl.a. være med til at sikre, at anvendersystemerne kan få nødvendige tilretninger med på snitfladen uden at det påvirker øvrige anvendersystemers snitflade til FMB. Det forventes, at minor releases kan frigives relativt hurtigt (og proaktivt) ift. at kunne understøtte anvendersystemerne, når behovet opstår.
+== Løbende frigivelse af nye patches med fejlrettelse, optimering mv. (kategori 1) ==
+Nye patches har ikke indflydelse på anvendersystemernes snitflade og kan leveres helt uafhængigt heraf. Patches indeholder fx fejlrettelser, optimeringer og kvalificeringer af datagrundlag og advarsler.
-Det er endvidere et scenarie, at der, ved behov, kan gennemføres et ekstra major release en gang om året.
+=== 7.2 Proces for videreudvikling ===
-Det vil i givet fald være et krav at anvendersystemer, der ikke ønsker / har mulighed for at implementere snitfladen umiddelbart kan forblive på den gamle snitfladeversion.
+Forslag til forbedringstiltag kan komme fra forskellige steder fra. Brugergruppen er naturligvis et forum, hvor forbedringstiltag opstår, men de regionale forvaltere spiller også her en vigtig rolle, da det er dem, der skal videreformidle forbedringstiltag fra deres bagland til den fællesregionale forvaltning. Sidst men ikke mindst kan forbedringstiltag opstå som en del af løsningen af en indmeldt sag.
+Processen for udvikling af forbedringstiltag ser ud som nedenstående:
+{{ :bst:rntriforkshared:public:proces_for_videreudvikling.png?nolink&600 |}}
-=== 7.1 Typer af ændringer ===
-=== 7.2 Tekniske ændringer ===
-=== 7.3 Applikationsmæssige ændringer ===