Differences

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

--- bst:rntriforkshared:public:operation_handbook [2021/12/07 17:37] – [7 Ændringsstyring] rn_sabina
+++ bst:rntriforkshared:public:operation_handbook [2021/12/20 15:37] (current) – [7 Ændringsstyring] mal
@@ Line 68: / Line 68: @@
 == 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).
+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.
+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 med en henvisning hertil.
+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.
@@ Line 128: / Line 128: @@
 Å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_-_fmb.png?nolink&600 |}}
+{{ :bst:rntriforkshared:public:arshjul.png?nolink |}}
 Årshjulet tager udgangspunkt i følgende elementer:
@@ Line 146: / Line 146: @@
-=== 7.3 Typer af ændringer ===
-=== 7.4 Tekniske ændringer ===
-=== 7.5 Applikationsmæssige ændringer ===