Kravspecifikationen som ingick i detta projekt har under tiden som gått ändrat sin form.
Ett av kraven ÅF la fram innan projektet startat innehöll en utvärderingen om AMP var en genomförbar lösning till problemen användare och utvecklare stött på i PaperLine.
Som tidigare beskrivet, efter diskussion med kunden blev det tydligt att uppgradering av PaperLine krävdes och ÅF bestämde sig att AMP var den lösning på problemen man ville satsa på. Detta medförde att kraven i kravspecifikationen fick ändras till ett så kallat proof-of-concept med demonstration för kunden av uppgraderingarna på en vy, där AMPs fördelar framför Web forms påvisades.
Dessa förändringar av kravspecifikationen har även inneburit förändringar av vår prioritering i arbetet och implementationen.
Trots att ändringar gjorts i kravspecifikationen bestämdes att alla kraven som ställts under projektets gång inkluderas i kapitlet resultat. De högprioriterade kraven identifierades därför till de tre som beskrivs i avsnittet nedan.
Går projektet att utföra?
Kan gamla systemet och nya tekniken samköras? Sammanfoga gamla systemet med den nya tekniken
Kraven som beskrivits kan ses som en kedja där nästkommande krav bygger på föregående, vilket inneburit att hade de första kraven inte varit genomförbart hade de nästkommande kraven ändrat form eller inte alls existerat.
46
5.1.1 Går projektet att genomföra?
Detta krav existerade enbart i uppstarten av projektet, där kravet lades fram vid det första mötet med ÅF. I kravet ingick att undersöka ifall en deluppgradering av systemet var möjligt eller om kod efter år av utveckling av systemet blivit så sammanlänkat, också kallat
spaghettikod [52], att skulle en del uppgraderas tvingas den resterande av systemet också uppgraderas. Detta krav ansågs ganska snabbt vara genomförbart då de involverade i utvecklingen av den gamla klienten på ÅF tillsammans med oss diskuterade fram lösningar på problemet.
I uppstarten var även AMP en relativt otestad plattform som inte noggrant diskuterats med kunden om den kunde tänkas användas som uppgradering av PaperLine.
Punkten som beskrivits var fråga där resultatet kunde ha slutat i ett genomförbart projekt eller ogenomförbart projekt. En möjlig utgång av projektet i ett tidigt stadie kunde varit att kund inte känt sig säker på AMP som plattform och nya tekniker hade behövts
implementeras, testas och utvärderas. Efter diskussion med kunden kunde plattformen AMP användas som teknik för PaperLine.
5.1.2 Samkörning av gammal och ny klient
Efter beslutet om att projektet var genomförbart, startades en undersökning kring
möjligheten att två klienter kunde samköras. En av lösningarna var att inkludera den klient och mall ÅF tidigare arbetat med för enklare och snabbare uppstart av projektet, beskrivet i avsnitt 3.1. Klienten skulle läggas vid sidan av den gamla klienten och sedan låta dem samköra på en server. De första testerna gick ut på att undersöka ifall några problem kunde uppstå då två klienter skilda från varandra startade upp på samma dator.
Små komplikationer uppstod men löste sig relativt snabbt och klienterna kunde samköras. Trots framgångsrika tester fanns fortfarande ovissheten om dessa två klienter samtidigt kunde kommunicera med servern och även länka mellan varandra.
Enkla tester sattes upp genom att låta den gamla klientens vy inkludera en fast länk till den nya och genom detta kunde man navigera sig fram och tillbaka mellan den gamla och den nya klienten. Testerna var framgångsrika och klienterna kunde samtidigt fungera samt länka mellan varandra och till sista kommunicera samtidigt med samma server.
47 De första kraven hade då blivit genomförda. Det var nu tekniskt bevisat att uppgraderingen var genomförbar och att den gamla klienten stegvis kunde uppgraderas med hjälp av den nya tekniken.
5.1.3 Sammanfogning av AMP och serverlagret
Kravet att sammanfoga det gamla systemet med den nya tekniken sågs som den största utmaningen under projektet. Arbetet med AMP-klientens kommunikation till servern har krävt absolut mest tid och är källan till många av de problem som uppstått på vägen. Då större delen av projektets innehåll var en sammanfogning av AMP och server, delades detta krav upp i mindre delar. De framförallt två stora delarna, front end och back end, kunde urskiljas.
5.1.4 Användargränssnitt
Vyns användargränssnitt har under projektet gång inte prioriterats. Som beskrivet i avsnittet 2.1.1 har användargränssnitt till största delen efterliknats den redan existerande vyn i den gamla klienten. Små ändringar har dock lagts till för att kompensera för vissa krav för hur gränssnittets passform skall se ut. Ett av de delkrav med lägre prioritet har varit att till största mån utveckla ett användargränssnitt där användning för såväl dator som mobil ska kunna användas utan problem. Uppgraderingen av de grafiska komponenterna gjordes till stor del genom att visuellt studera den gamla vyns gränssnitt. Majoriteten av dem var enkla att uppgradera och någorlunda tydligt angivna hur och varför de visade sig för användaren. Ett mindre antal av komponenterna var dock mer komplexa och visades enbart under speciella omständigheter. Dessa komponenter blev lägre prioriterade eftersom de upptäcktes senare i projektet, vilket medförde att de påbörjades men inte till fullo
slutfördes. Några av dess komponenter som påbörjades var hur vyn hanterar utskrifter och exporteringar av rutnät samt hur felmeddelanden hanteras. Anledningar till varför
funktionalitet inte till fullo implementerades beskrivs i avsnitt 5.4.
5.1.5 Serverkommunikation
Stor del av prioriteringen i projektet har gått till kravet kommunikation mellan klient och server. Kravet har inneburit att i största mån undersöka den gamla kommunikationen och efterlikna denna med den nya tekniken. Där bland annat ny kommunikation satts upp
48 blivit uppsatt kommer denna, liksom uppgradering av användargränssnittet, sakna full
funktionalitet då enbart de visuellt synliga uppgraderingarna gjordes(beskrivs vidare i avsnitt 5.4). Några av de funktionaliteter som valdes att inte implementeras var
användarinställningar och grundvyer. Även valideringar av dessa användarinställningar för att bestämma vilka behörigheter användaren har i systemet.