...
| Innehållsförteckning | ||
|---|---|---|
|
Roll: Driftsättare
User Story: Driftsätta virtuell tjänst i VP
Motiv
Driftssättning av en virtuell tjänst sker med utgångspunkt i paketerade virtuella tjänster, på format som kräver minimal anpassning för varje instans av virtualiseringsplattformen där driftssättning ska ske.
Beskrivning
Som ... vill jag driftsätta en ny virtuell tjänst, så att den blir tillgänglig för nya tjänstekonsumenter, genom att följa enkla instruktioner.
Acceptanskriterier
- En person med grundläggande kundskaper om Mule, men utan insikt i TP-projektet kan driftssätta en virtuell tjänst i en befintlig instans av tjänsteplattformen, inkluderande verifiering, genom att följa anvisningar.Tjänsten är driftsatt och verifierad att den fungerar
- Det tog högst en timme att driftssätta och verifiera en ny virtuell tjänst.
- Beskrivs i driftsinstruktioner
- Beskrivs i SAD
User Story: Driftsätta virtualiseringsplattform på Windows
Beskrivning
Som ... vill jag driftsätta VP så att jag kan göra virtuella tjänster tillgängliga för applikationer i min driftsmiljö, genom att följa en väl beskriven procedur.En anvisning guidar mig genom momenten.
Acceptanskriterier
- Plattformen är driftsatt och verifierad att den fungerar
- Jag har följt enkla och tydliga instruktioner
- Verifiering har varit en del av driftsättningsinstruktionerna
- Beskrivs i driftsanvisningar
User Story: Driftsätta virtualiseringsplattform på Linux
Motiv
Öppen källkod ska stödjas av alla leveranser till vården
Beskrivning
Instruktionerna uppdateras för att täcka Linux-specifika handgrepp
Acceptanskriterier
Samma som för motsvarande Windows-story
Roll: Support, tjänstekonsumenter
User Story: Monitoreringsstöd
Motiv
Den som har applikationssupport för en tjänstekonsument som konsumerar en virtuell tjänst, är den som drabbas när något led i kedjan (inkl. verklig tjänsteproducent) upphör fungera enligt förväntningarna. Det är då av största vikt att virtualiseringsplattformen kan bidra till flesökning genom monitoreringsstöd. Typiska syptom torde vara att virtualiseringsplattformen degenererar med avseende på svarstider, eller att någon enskild verklig tjänstekonsument får svårigheter att svara enligt SLA. Det bästa är om monitoreringen kan larma baserat på i förväg konfigurerade svarstidkrav. Det näst bästa är om det går att i efterhand (vid upplevda problem hos tjästekonsumenten) få hjälp av monitoreringsverktyget att se vilka svarstider som för närvarande levereras av verkliga såväl som virtuella tjänster.
Beskrivning
Som ... vill jag snabbt kunna avgöra vad som är orsaken till tekniska problem eller svarstidproblem. Helst vill jag få larm innan problem blir akuta
Acceptanskriterier
- Genom ett GUI hos VP fick jag fram information om genomsnittlig och senaste svarstider tjänsteproducenterna bakom en virtuell tjänst. Jag kan sortera dem genom att klicka på tabell-rubriker.
- Idé: Min RSS-feed mot VP indikerade tidigt att svarstidskraven för den virtuella tjänsten inte längre uppfylls av en av tjänstekonsumenterna.
- Beskrivs i SAD
- Beskrivs i driftsanvisningar
User Story: Teknisk loggning
Motiv
Alla former av fel måste kunna spåras i efterhand. Under speciella omständigheter kan det vara viktigt med extra mycket språningsinformation. Teknisk loggning enligt gängse standards, samt instruktioner för hur dessa kan konfigureras till olika lognivåer är avgörande för effektiv problemsökning och intrimning av virtualiseringsplattformen, så att den svarar upp mot förväntningsrana från tjänstekonsumenterna.
Beskrivning
Som ... vill jag att det ska finnas loggar som underlättar felsökning. Vid speciella situationer vill jag höja graden av loggning.
Acceptanskriterier
- Fel skrivs ut med tydlig felutskrift
- Instruktioner / anvisningar visar hur lognivåer konfigureras
- Driftanvisningar beskriver hur logfiler ska hanteras
- Beskrivs i SAD
User Story: Felmeddelanden
Motiv
Felmeddelande som orsakas i virtualiseringsplattformen ska rapporteras som SOAPFault till tjänstekonsumenten, samt loggas. ID i SOAPFault ska finnas i logfilen för korrelering. Felsituationer som är förutsägbara baserade på inkoncistens mellan metadata i meddelandetrafik och innehåll i tjänstekatalog, ska redovisas i SOAPFaults med mycket stor tydlighet, så att det inte råder något tvivel som orsaken och vad som behöver göras.
Beskrivning
Som ... vill jag att slutanvändaren (om aktuellt) ska få en tydlig text som genom kontakt till helpdesk snabbt kan resultera i korrigerande åtgärd. Det gäller specifikt förutsägbara fel som rör anropsbehörigheter och missmatch i mnetadat mellan meddelande och tjänsteplattformens databas.
Acceptanskriterier
- Testfall som kan bedömas av produktägaren.
- Felmeddelanden och felhantering beskrivs i SAD
Roll: Integrationsutvecklare
Paketera virtuella tjänster för tjänsteinteraktion
Motiv
Virtualiseringsplattformen är distribuerad till sin natur. Det innebär att ett tjänstekontrakt kan virtualiseras i många instanser av virtualiseringsplattformen, för att undvika single-point-of-failure. Subsidiaritetsprincipen (VIT-boken) är det grundläggande motivet för en dsitribuerad driftssättning. Det innebär att konfiguration av virtuella tjänster behöver kunna genomföras och paketeras/distribueras fristående från de instanser i vilka de kommer att driftsättas.
Beskrivning
Som ... vill jag kunna följa en enkel instruktion som beskriver hur jag utgående från en kanonisk, abstrakt WSDL med tillhörande scheman för ett tjänstekontrakt skapar paketeringar per tjänstekontrakt som kan slutkonfigureras och driftsättas i olika instanser av virtualiseringsplattformen. Jag vill också att instruktionerna visar hur jag verifierar min paketering, så att driftsättare slipper problem som jag kunnat förebygga.
Acceptanskriterier
- En person med grundläggande kunskaper i Mule, men utan förkunskaper om TP kunde följa instruktionerna för att paketera och verifiera.
- Det tog inte mer än två timmar att paketera och verifiera en virtuell tjänst.
- Paketeringsmodell beskrivs i SAD
- Paketering beskrivs i anvisning för integrationsutvecklare
User Story: Referensapplikation
Motiv
En exempelapplikation visar ett komplett uppsatt end-to-end-exempel, baserat på PoC. Det handlar alltså om en version av PoC, men utan de delar som relaterar till mätningar. Detta ger en startpunkt för dem som vill testköra och praktiskt skapa sig en förståelse för tjänsteplattformen.
Beskrivning
Som ... vill jag kunna ladda hem och provköra, samt titta på exempelkod. Det måste inte vara ursprunglig PoC men FitNess-paketeringen där är kraftfull och skulle vara till nytta.
Acceptanskriterier
- En integrationsutvecklare med goda kunskaper i byggverktyget Maven, Git och baskunskaper i Java kunde på 8 timmar få tillgång till exempelapplikationen, bygga den, deploya, starta och köra ett exempel.
- Tjänsteinteraktioner (WSDL, Scheman) följer de principer som etablerats inom TP PoC och som är bas för RIVTA Basic Profile 2.0.
- Beskrivs översiktligt i SAD
- Beskrivs i något som skulle kunna vara mall för beskrivning av virtualiserade tjänster
Roll: Administratör, Tjänstekatalog
User Story: Registrera RIVTA-versioner
Motiv
RIVTA-versioner behöver finnas i tjänstekatalogen som bas för registrering av logiska adresser.
Beskrivning
Som ... vill jag skapa, ändra och tabort RIVTA-versioner i tjänstekatalogen. RIVTA-versioner beskrivs av ett unikt namn.
Acceptanskriterier
- RIVTA-versionen har sparats i tjänstekatalogen
- Endast RIVTA-versioner med unikt namn i tjänstekatalogen kan registreras
- Beskrivs i anvisning för användare eller i hjälptext
User Story: Redigera Tjänsteinteraktioner
Motiv
Tjänstekontrakt för godkända, kanoniska tjänsteinteraktioner behöver finnas i tjänstekatalogen som bas för registrering av logiska adresser och anropasbehörigheter.
Beskrivning
Som ... vill jag skapa, ändra och tabort tjänsteinteraktions tjänstekontrakt i tjänstekatalogen. Tjänstekontraktet beskrivs av dess namnrymd som anges i form av ett URN.
Acceptanskriterier
- Tjänstekontraktet har sparats eller tagits bort i tjänstekatalogen
- Tjänstekontrakt kan bara sparas om det har en unik namnrymd
- Tjänstekontrakt kan tas bort endast om det inte refereras från Logiska adresser eller Anropsbehörigheter.
- Beskrivs i anvisning för användare eller i hjälptext
User Story: Redigera Organisatoriska Sammanhang
Motiv
Organisatoriska sammanhang behöver finnas i tjänstekatalogen som bas för registrering av logiska adresser och anropsbehörigheter. HSA är master för denna information. På sikt används HSA för att söka fram denna info. Där kan jag sedan länka mig in i tjänstekatalogen.
Beskrivning
Som ... måste jag redigera Organisatoriska sammanhang i tjänstekatalogen, så länge tjänstekatalogen inte är integrerad med HSA-katalogen. Ett organisatoriskt sammanhang beskrivs av ett HSA-id ur HSA-katalogen.
Acceptanskriterier
- Organisatoriskt sammanhang har sparats eller tagits bort i tjänstekatalogen.
- Organisatoriskt sammanhang kan bara registreras om HSA-id är unikt bland alla organisatoriska sammanhang.
- Organisatoriskt sammanhang kan tas bort endast om det inte refereras från Anropsbehörigheter eller Logiska adresser.
- Beskrivs i anvisning för användare eller i hjälptext
User Story: Redigera logisk adress
Motiv
Logiska adresser i tjänstekatalogen är de adresser som erbjuds tjänstekonsumenter som vill samverka via virtuella tjänster. I tjänstekatalogen finns sambanden som medger översättning från logiska till fysiska adresser (url:er) för dirigering av meddelanden.
Beskrivning
Som ... vill jag redigera logiska adresser i tjänstekatalogen. För att skapa en logisk adress utgår jag från ett befintligt Tjänstekontrakt, ett befintligt rganisatoriskt sammanhang och den RIVTA-version som tjänsteproducenten följer. Jag skapar sedan en ny LogiskAdress för dessa tre ingånsgvärden. Den logiska adressen ska peka ut en tjänsteproducent. Om den ännu inte finns, erbjuds jag att skapa en ny tjänsteproducent. För att göra det, väljer jag en tjänstekomponent. Om den ännu inte finns, erbjuds jag att skapa en ny tjänsteproducent. Jag anger ett tidsintervall för den logiska adressens giltighet. Jag kan också ändra egenskaper på tjänstekomponenter och tjänsteproducenter.
Acceptanskriterier
- LogiskAdress har sparats eller tagits bort i tjänstekatalogen.
- Om tjänsteproducent eller tjänstekonsument också redigerades har dessa sparats eller tagits bort i tjänstekatalogen,
- En tjänstekomponent kan bara tas bort om den inte refereras från någon Anropsbehörighet och om dess Tjänsteproducenter inte refereras från någon LogiskAdress.
- En LogiskAdress kan bara sparas om den är unik avseende kombinationen av OrganisatorisktSammanhang, Tjänstekontrakt och RivVersion inom angivet tidsintervall.
- Beskrivs i anvisning för användare eller i hjälptext
Registrera Anropsbehörighet
Motiv
En Anropsbehörighet anger vilka system som får samverka med en annan organisation över ett specifikt tjänstekontrakt. Den knyter en tjänstekonsomponent i rollen som tjänstekonsument till ett tjänstekontrakt och en samverkanspart (Organisatoriskt Sammanhang). För att meddelande ska kunna dirigeras från tjänstekonsument till tjänsteproducent med hjälp av en logisk adress, måste en anropsbehörighet vara upprättad mellan adresserad organisation och tjänsteproducenten. Anropsbehörigheten upprättas per tjänstekontrakt.
Beskrivning
Som ... vill jag redigera anropsbehörigheter i tjänstekatalogen. För att skapa en anropsbehörighet utgår jag från ett befintligt Tjänstekontrakt, ett befintligt rganisatoriskt sammanhang och en befintlig tjäntekomponent (tjänstekonsumenten). Jag skapar sedan en ny Anropsbehörighet för dessa tre ingånsgvärden. Om tjänstekomponenten ännu inte finns, erbjuds jag att skapa en ny tjänstekomponent. I denna roll (tjänstekonsument) anger jag inget värde för adress. Jag anger ett tidsintervall för anropsbehörighetens giltighet.
Acceptanskriterier
- En Anropsbehörighet har sparats eller tagits bort i tjänstekatalogen.
- Om tjänstekomponent också redigerades har den sparats eller tagits bort i tjänstekatalogen,
- En tjänstekomponent kan bara tas bort om den inte refereras från någon Anropsbehörighet och om dess Tjänsteproducenter inte refereras från någon LogiskAdress.
- En Anropsbehörighet kan bara sparas om den är unik avseende kombinationen av OrganisatorisktSammanhang, Tjänstekontrakt och Tjänstekomponent inom angivet tidsintervall.
- Beskrivs i anvisning för användare eller i hjälptext
User Story: Inloggning
Motiv
Tjänstekatalogens innehåll styr meddelandetrafik i runtime. Det är av strsta vikt att den inte kommer i orätta eller okunniga händer. Inloggning med stark authentisering är därför ett krav, så snart BIF är på plats. Fram till dess behöver någon form av authentisering användas. I värsta fall Basic Authentication.
Beskrivning
Som ... vill jag identifiera mig i systemet, så att jag känner mig säker på att endast behöriga kan påverka innehållet i tjänstekatalogen.
Acceptanskriterier
- Det går inte att komma åt systemet med mindre än att man enligt någon dokumenterad metod tilldelats behörighet baserat på den användare man loggar in som.
- Administration av behöriga användare kan vara förknippad med systemadministrativa ingrepp under en inledande fas. Men plan för övergång till BIF-inloggning ska finnas.
- Beskrivs i anvisning för användare eller i hjälptext
- Rättighets/användarhantering beskrivs i lämpligt dokument
User Story: Loggning av aktiviteter i tjänstekatalog
Motiv
Med anledning av den skada som kan orsakas av ovarsam användning och att BIF-inloggning inledningsvis inte kommer att finnas, är det viktigt att felaktig användning kan spåras, så att inte systemet förlorar i förtroende, genom att upplevas som felaktigt.
Beskrivning
Som ... vill jag att alla förändringar loggas i en logfil.
Acceptanskriterier
- Det finns en logpost för varje förändring
- Logposterna innehåller objektets identitet och dess värden (vid nyupplägg och uppdatering), identitet på användaren, tidpunkt för ändringen och typ av ändring.
- Beskrivs i SAD
- Beskrivs i anvisning för admin av tjänstekatalog
User Story: Uppdatera VP med TAK ändringar, reset cache
Då TAK är uppdaterad vill administratören att dessa ändringar skall propageras ut till VP.
- En uppdatering av VP's TAK cache görs
- Då VP startar upp
- Då en administratör aktivt valt att starta en uppdatering av VP's cache
- Vid ett lyckat anrop från VP till TAK uppdateras VP's lokala cache
- Rapport loggas i loggar
- Rapport returneras till administratör i manuella fallet
- Vid ett misslyckat anrop från VP till TAK lämnas VP's lokala cache orörd, inget uppdateras
- Felrapport loggas i loggar
- Felrapport returneras till administratör i manuella fallet
Roll: Produktägare
User Story: Virtualisering med vägval
Motiv
T-bokens referensarkitektur
Beskrivning
Som ... vill jag att Virtualisering och vägval fungerar enligt POC-funktionalitet, men utan riv-version-transformering.
Acceptanskriterier
- Vägvalsinformation hämtas från tjänstekatalog m.h.a. RIVTA-baserad webservice vid uppstart av virtualiseringsplattform
- Virtualiseringsplattformen beskrivs i SAD
User Story: Säkerhet enligt WS-I BP 1.1 med mutual auth
Motiv
Insynsskydd genom protokoll/kanal-kryptering är lägsta tänkbara skyddsnivå. För att också ha en pålitlig lösning för att identifiera samverkande tekniska parter, ska SSL Mutual Authentication användas (s.k. klient-certifikat). Klientcertifikatets SerialNumber förutsätts vara tjänstekomponentens (tjänstekonsumentens) HSA-id. Detta utgör då senderId, vilket alltså inte behöver hanteras explicit i RIV-header.
Beskrivning
Som ... vill jag att varje led av teknisk samverkan säkras genom SSL Mutual Authentication, samt att virtuell tjänst såväl som verklig tjänsteproducent verifierar mottagaren som en auktoriserad teknisk samverkanspart baserat på HSAid hämtat från attribut i klient-certifkatet. För virtuell tjänst sker detta baserat på konfigurerade anropsbehörigheter i tjänstekatalog. För verklig tjänsteproducent sker detta genom att identiteter för godkända instanser av virtualiseringsplattformar är kända. Merparten av detaljerna kring detta finns i RIV TA 2.0.
Acceptanskriterier
- Referenapplikation visar exempel på hur detta konfigureras (end-to-end via virtualisering)
- Beskrivs i SAD
User Story: Utkast till hantering av RIVTA-versioner
Motiv
För version 1.0 av virtualiseringsplattformen levereras inte stöd för översättning mellan olika RIVTA-versioner (transformering mellan olika kuverterings- och säkerhetsmodeller). Det är dock av största vikt att detta kan läggas till i nästa version utan befintlig arkitektur eller produkt behöver bytas. Vi behöver därför fundera igenom hur detta skulle kunna taklas, till en nivå att vi bedömer risken liten för att en nya arkitektur skulle behöva etableras för att klara detta krav.
Beskrivning
Som driftsättare vill jag tillföra virtualiseringsplattformen stöd för transformering mellan befintliga RIVTA-versioner och ny RIVTA-version. Jag får en paketering av transformeringsstöd för en ny RIVTA-version att driftssätta i varje instans av virtualiseringsplattformen. Efter omstart är den nya transformeringen aktiv för alla vitualiserade tjänster som fanns driftssatta sedan tidigare.
Acceptanskriterier
- Utkast för hur ovanstående dokumenterat i SAD, samt eventuella förslag till förändringar av 1.0-leveransen baserat på insikter som gjordes under analysen, på godtycklig form.
- Det finns en beskrivning av hur en virtualiserad tjänst vet vilken RIVTA-version den implementerar
- Det finns en beskrivning över hur förmågan att brygga mot en annan RIVTA-version tillförs befintliga virtuella tjänster.
- Det finns en besrkivning av hur en virtuell tjänst identifierar och kanaliserer bryggning mot den komponent som ansvarar för bryggningen - kort och gått vilket avtryck en ny RIVTA-version får i termer av leverabler och vad det innebär att integrera dessa leverabler i befintliga virtuella tjänster.
Roll: Förvaltare
User Story: Utvecklings- och leveransinfrastruktur
Motiv
Offentliga förvaltningar har som policy att all beställd utveckling ska resultera i öppen källkod. Att helt arbeta och leverera enligt modeller och iinfrastruktur för öppen källkod underlättar dessutom leveransprocessen, då allt material alltid är tillgängligt för alla intressenter.
Beskrivning
Som ... vill jag att leveransen sker i öppen källkodsplattform, så som forge.osor.eu.
Acceptanskriterier
- Projektets utvecklingsprocess kan i en gradvis ökande omfattning övergå i ett förvaltningsläge med tickethantering mot kunder etc i samma infrastruktur som används under utveckling.
- Ingen skillnad i intern och extern leverans
- Beskrivs i SAD
- Beskrivs i anvisning för förvaltare
User Story: Lasttester
Motiv
Virtualiseringsplattformen kommer - även om den är distribuerad - att vara förknippad med höga SLA-krav. Robust exekvering av inkomna meddelanden med minimal overhead, timme ut och timme in, är avgörande för att plattformen ska anses tillförlitlig. det är därför av största vikt att leveransen (denna och framtida) kvalitetssäkras av automatiserade lasttester.
Beskrivning
Som ... vill jag att varje leverans lasttestats med tester som redovisar snitttid för dirigering genom virtuell tjänst, max och min tid, baserat på en realistisk last som körts under minst ett dygn.
Acceptanskriterier
- Lasttester kan köras automatiskt
- Virtualiseringsplattformen uppvisar god robusthet och goda svarstider (få millisekunder fördröjning per meddelande)
- Testmetodik beskrivs i SAD
- Beskrivs i anvisning för förvaltare
User Story: Portabla byggen
Motiv
T-bokens krav på portabla byggen och testautomation sk vara uppfyllda
Beskrivning
Som ... vill jag att all utveckling är baserad på portabla, komponentbaserade byggen enligt välbeskriven produktstruktur, med Maven som byggsystem.
Acceptanskriterium
...
Förslag på användningsfall
- Inloggning
- CRUD hantering av enkla entiteter
- CRUD hantering av komplexa entiteter