Utveckling av stödverktyg för livsmedels- &
miljöinspektörer
Jonas Ölander & Andreas Löfqvist
2014
Examensarbete, C, 15 hp
Datavetenskap
Dataingenjörsprogrammet
1.
Handledare: Åke Wallin
Examinator: Jonas Boustedt
2.
Utveckling av st¨
odverktyg f¨
or livsmedels- &
milj¨
oinspekt¨
orer
av
Jonas ¨
Olander & Andreas L¨ofqvist
Akademin f¨or teknik och milj¨o
H¨ogskolan i G¨avle S-801 76 G¨avle, Sweden Email: ntn10jor@student.hig.se ndi11alt@student.hig.se Abstrakt
G¨avle kommuns milj¨o- och livsmedelsinspekt¨orer utf¨or inspektioner hos ca 660 f¨oretag
och organisationer inom G¨avle kommun. Information om organisationer och inspektioner
hanteras av ett ¨arendehanteringssystem. Detta ¨arendehanteringssystem ¨ar inte anpassat
f¨or s¨attet inspekt¨orerna arbetar, vilket g¨or att de tvingas komplettera viss funktionalitet
med ett Exceldokument. Detta Exceldokument l¨oser vissa problem men fungerar inte
bra. Detta arbetes syfte och m˚al ¨ar att utveckla en grund till en webbapplikation, i
beta-stadiet, vilket ska kunna ers¨atta det Exceldokument inspekt¨orerna arbetar med och
effektivisera deras arbete genom att g¨ora den verksamhetsanpassad. Arbetet resulterade
i en webbapplikation vilket effektiviserar inspekt¨orernas arbetss¨att. Webbapplikationen ¨ar
utformad med responsivt gr¨anssnitt. Omd¨omet av webbapplikationen var positivt och visade
p˚a ett f¨orb¨attrat arbetss¨att.
Nyckelord: webbapplikation, inspekt¨or, G¨avle kommun, inspektion,
Inneh˚
all
1 Introduktion 1
1.1 Bakgrund . . . 1
1.2 Beskrivning av nuvarande arbetss¨att . . . 1
1.2.1 Problematik i nuvarande arbetss¨att . . . 2
1.3 Syfte och M˚al . . . 2
1.4 Behov . . . 3
1.5 Avgr¨ansning . . . 3
2 Begrepp och principer 4 2.1 Arbetsmetod f¨or b¨attre designad programvara . . . 4
2.1.1 Test Driven Development, TDD . . . 4
2.1.2 Komplexitet och designm¨onster . . . 5
2.1.3 Redundans . . . 6
2.2 Anv¨andarv¨anlighet . . . 6
2.3 Webbserver . . . 7 2.4 Webbapplikation . . . 7 2.5 Frontend . . . 7 2.5.1 Frontend-verktyg . . . 8 2.5.2 JSP . . . 8 2.5.3 Servlet . . . 8 2.6 Databas . . . 8 2.7 Backend . . . 9 2.7.1 MVC . . . 9
2.7.2 Strategy & Factory . . . 9
2.7.3 Mediator . . . 10
2.7.4 DAO . . . 10
2.7.5 Singleton . . . 11
2.7.6 Facade . . . 12
2.7.7 Dependency Injection . . . 12
3 Metod och genomf¨orande 12 3.1 Utveckling av webbapplikation . . . 12
3.2 Datainsamling . . . 12
3.3 Anv¨andartester . . . 13
4 Resultat 13 4.1 Omfattningen av Excel . . . 14
4.2 Enk¨atunders¨okning . . . 14
4.3 Webbapplikation . . . 14 4.3.1 Frontend-design . . . 15 4.3.2 Backend-design . . . 17 4.3.3 Databasdesign . . . 19 4.4 Kundomd¨ome . . . 21 4.5 Alternativa l¨osningar . . . 22 5 Diskussion 22 5.1 Databas . . . 22
5.3 Omfattningen av Excel . . . 23
5.4 Enk¨atunders¨okning . . . 23
5.5 Webbapplikation . . . 24
5.6 Behov . . . 25
6 Slutsats 26 A Tabell ¨over verksamhetsanalys 30 B Enk¨atunders¨okning G¨avle kommun 31 B.1 Svarsexempel p˚a enk¨at . . . 32
C JavaBeans 34
D DEPA - Strategy 35
E UML ¨over backend 37
F UML - Alla DAO 38
G Applikationsmodell 39
H Databasmodell 41
1
Introduktion
F¨oljande kapitel kommer beskriva bakgrunden till arbetet och dess problematik. F¨orst kommer bakgrunden att beskrivas till arbetet, sedan beskrivs problemformuleringen f¨oljt av syfte och m˚al, kravanalys samt hur arbetet ¨ar avgr¨ansat.
1.1 Bakgrund
G¨avle Kommuns Milj¨o- och h¨alsoskyddsavdelning utf¨or livsmedels- och milj¨oinspektioner vid f¨oretag och organisationer inom G¨avle Kommun. Det utf¨ors inspektioner hos cirka 660 verksamheter. Den st¨orsta gruppen utg¨ors av detaljhandel vilket innefattar restauranger, butiker (livsmedelsbutiker, kiosker, bensinstationer), gatuk¨ok och mottagningsk¨ok. Ut¨over dessa ing˚ar ¨aven dricksvattenanl¨aggningar. De har ¨aven registrerade anl¨aggningar vilka de inte har inventerat. Dessa kan exempelvis vara fritidsg˚ardar, transportfirmor och s¨aljare av kosttillskott. [1] (Organisationer, f¨oretag och anl¨aggningar kallas i forts¨attningen, i hela rapporten, f¨or objekt ). Objekt ¨ar placerade i olika riskklasser beroende p˚a typ av verksamhet och deras omfattning. Risklassen, tillsammans med erfarenhetsklassificeringen (se nedan), avg¨or vilken m¨angd kontrolltid objekten tilldelas och d¨armed ¨aven storleken p˚a objektets ˚arliga kontrollavgift. Kommunen f¨oljer Livsmedelsverkets v¨agledning ang˚aende riskklassificering av livsmedelsanl¨aggningar och ber¨aknande av kontrolltid. [1]
Objekt klassificeras efter hur bra de sk¨ott sig. Denna klassificering kallas erfarenhet. Erfarenhetsklassificeringen best˚ar av bokst¨averna A, B och C, d¨ar A ¨ar b¨ast och C ¨ar s¨amst. Klassificeringarna representerar nummer, d¨ar A=0.5, B=1 och C=1.5. Ett objekt som sk¨oter sig bra kan erh˚alla klassificering A, vilket inneb¨ar att deras totala ˚arstid multipliceras med 0.5. Detta g¨or att objektet f˚ar mindre kontrolltid vilket ger en mindre ˚arsavgift.[2]
Hanteringen av dessa objekt sker med hj¨alp av ett ¨arendehanteringssystem kallat Milj¨oReda, vilket ¨ar utvecklat av EDP Consult AB. Av landets 289 kommuner anv¨ander 50% Milj¨oReda. [1].
De SQL-servrar p˚a vilka Milj¨oReda lagrar sin data underh˚alls av G¨avle Kommuns IT-avdelning [3]. Milj¨oReda anv¨ands som huvudsystem, d¨ar all information rapporteras in, och vid sidan av kompletteras Milj¨oReda med ett Exceldokument. Exceldokumentet visar ¨oversikt av f¨oretag och organisationer samt planeringen av inspektioner. [2]
Inspekt¨orerna g¨or, en g˚ang per ˚ar, utdrag ur Milj¨oReda p˚a samtliga 660 objekt och l¨agger in dem i ett Exceldokumentet. Objekten f¨ordelas p˚a 6-7 handl¨aggare. Dokumentet anv¨ands f¨or att inspekt¨orerna skall f˚a en ¨overgripande bild av informationen kring objekt. Informationen innefattar bland annat utf¨ord kontrolltid, arbetsf¨ordelning, kontrollager (f¨oreg˚aende ˚ars kvarvarande inspektionstid) och adress. D˚a arbetade timmar kontinuerligt uppdateras samt att arbetsf¨ordelning med tiden kan ¨andras, g¨or att Exceldokumentet blir till ett ”levande dokument”.
1.2 Beskrivning av nuvarande arbetss¨att
Inspekt¨orerna uppdaterar data in i Milj¨oReda vid utf¨ord inspektion. Det innefattar tid nedlagd p˚a objektet, omd¨ome om de kontrollpunkter vilka inspekterats, eventuell ¨andring av erfarenhetsklassificeringen och inspektionsrapport i form av ett Worddokument.[4] I Milj¨oReda skapar inspekt¨oren ett ¨arende f¨or den utf¨orda inspektionen och i det ¨arendet kan det l¨aggas till handlingar, vilka har med den inspektionen att g¨ora, exempelvis uppf¨oljning av inspektion.
Det finns en exportfunktion till Excel i Milj¨oReda, vilket g¨or deras nuvarande exportering av data till Excel n¨astan helt automatisk.[2]
˚
Arets kontroll tilldelas en inspekt¨or och resttider (f¨oreg˚aende ˚ars timmar) tilldelas en annan inspekt¨or, vars enda uppgift ¨ar att arbeta med resttiderna.[2]
Vid en inspektion ska upp till 15 olika punkter inspekteras. Av dessa 15 punkter finns det ¨
aven 26 stycken underpunkter.[2]
Det finns objekt vilka kommunen ¨ar medvetna om men vilka inte har n˚agon avtalad kontrolltid. Orsaken till detta kan exempelvis vara att det ¨ar ett v¨aldigt litet f¨oretag. Objektet betalar inget d˚a ingen kontrolltid finns och de inte ¨ar riskklassade. Objekten kan komma att inspekteras n¨ar det finns tid och arbetskraft.[2]
1.2.1 Problematik i nuvarande arbetss¨att
De problem inspekt¨orerna st¨oter p˚a i dess nuvarande s¨att att arbeta med Exceldokumentet tas upp i tabellen f¨or verksamhetsanalysen, se appendix A tabell 1.
Det f¨orsta problemet ¨ar att Exceldokumentet inte kan anv¨andas av flera anv¨andare samtidigt. Detta blir ett problem d˚a inspekt¨orerna under en arbetsdag kommer in till kontoret vid n˚agorlunda samma tid och skall uppdatera sin del i Exceldokumentet. Dokumentet l˚ases till den anv¨andare som f¨orst ¨oppnade det. Konsekvensen av att det inte finns en funktion f¨or att arbeta flera samtidigt, ¨ar att rapportering inte alltid kan ske n¨ar rapportering skall g¨oras och tvingas d¨arf¨or skrivas in vid ett senare tillf¨alle.[2]
Det andra problemet behandlar problematiken kring objektens kontrollager (resttid hos objekt). Detta p˚a grund av att dess nuvarande arbetss¨att inkluderar en inspekt¨or vars arbete ¨ar att g¨ora inspektioner hos de objekt med ett kontrollager fr˚an f¨oreg˚aende ˚ar, allts˚a arbeta f¨or att ta igen de inspektionstimmar de ligger efter. Denne inspekt¨or kan i v¨arsta fall g¨ora en kontroll hos ett objekt d¨ar objektets vanliga inspekt¨or har valt att planera in en inspektion under samma dag. Detta g¨or att inspektionen inte har samma betydelse, d˚a objektets kontrollagertimmar inte skiljer sig inspektionsm¨assigt fr˚an de vanliga inspektionerna och g¨or att tv˚a inspektioner f¨orekommer p˚a ett objekt under samma tid vilket resulterar i on¨odig tid nedlagt hos ett objekt eftersom inspektionerna skall ske med en vissa tidsintervall.[2]
Det tredje problemet ¨ar att ingen historik finns om objektens tider. Detta p˚a grund av att dess nuvarande arbetss¨att ¨ar att vid varje ˚arsslut importeras all ny information om objekten fr˚an Milj¨oReda. D˚a Milj¨oReda inte sparar n˚agon historik p˚a tider hos objekt, f¨orsvinner m¨ojligheten till att f˚a en historik med i importen.[2]
Det fj¨arde problemet handlar om objektens kontrollpunkter. Kontrollpunkterna ¨ar de olika omr˚aden som en inspekt¨or skall inspektera under en inspektion. Det inspekt¨orerna saknar ¨ar m¨ojligheten att sortera ut objekt utifr˚an vilka punkter som ¨ar genomf¨orda hos objekten. En s˚adan sorteringsfunktion skulle hj¨alpa inspekt¨orerna att enkelt sortera ut de objekt vilka har samma kontrollpunkter kvar att inspekteras. Detta skulle g¨ora det effektivare f¨or inspekt¨orerna att kunna v¨alja ut objekt efter vilka punkter som beh¨over kontrolleras.[2]
Den sista problematiken best˚ar i att det ¨ar omst¨andligt att f¨ordela om arbete i Exceldokumentet, vid bland annat sjukdom och ledighet. Omf¨ordelningen g˚ar att hantera i dokumentet, men det b¨or f¨orenklas.[2]
1.3 Syfte och M˚al
Syftet med detta arbete ¨ar att unders¨oka G¨avle Kommuns milj¨o- och livsmedelsinspekt¨orers arbetss¨att f¨or att sedan med hj¨alp av denna kunskap arbeta fram en l¨osning, vilket ska st¨odja dem i deras arbete.
M˚alet med detta arbete ¨ar att skapa en grund till en applikation vilket ska ers¨atta Exceldokumentet. M˚alet med applikationen ¨ar att:
1. effektivisera arbetet genom att ta fram ett verksamhetsanpassat verktyg 2. minska administreringstiden genom automatisering
3. f¨orenkla tidsplaneringen ¨over objekten
Applikationen vilken kommer att arbetas fram ¨ar en webbapplikation i ett beta-stadie. Att en applikation ¨ar i beta-stadiet inneb¨ar att vissa funktioner ¨ar f¨ardiga men att det kan finnas buggar vilket bland annat kan orsaka instabilitet, krascher och eventuellt dataf¨orlust. M˚alet best˚ar ocks˚a i att den applikation som utvecklas skall vara en grund med m¨ojlighet f¨or kunden att vidareutveckla.
1.4 Behov
Behovet som finns ¨ar att ta fram ett verktyg vilket skall underl¨atta f¨or inspekt¨orerna i deras arbete. Ett verktyg vilket st¨odjer inspekt¨orerna i deras planering av inspektionerna.
De funktioner/behov som inspekt¨orerna efterfr˚agar ¨ar f¨oljande. De vill kunna: Grundbehov
• g¨ora uts¨okningar och filtreringar p˚a objekt.
• g¨ora uts¨okningar och filtreringar p˚a objekt i kontrollagret respektive den ˚arliga listan. • g¨ora uts¨okningar och filtreringar p˚a kontrollpunkter p˚a objekt.
• g¨ora uts¨okningar och filtreringar p˚a inspekt¨orer. • g¨ora uts¨okningar och filtreringar p˚a tertial. • g¨ora uts¨okningar och filtreringar p˚a arbetsvecka. • g˚alla koll p˚a kontrollager i en 3-˚arsplan.
• arbeta flera samtidigt.
• importera Exceldokument f¨or data. • exportera data till Exceldokument. Ut¨okade behov
• komma ˚at information ute p˚a f¨alt. • importera data tillbaka till Milj¨oReda.
1.5 Avgr¨ansning
Arbetet avgr¨ansas till att skapa en grund till ett hj¨alpverktyg. Verktyget ¨ar i beta-stadiet med en stabil grund f¨or m¨ojlighet till vidareutveckling. Detta p˚a grund av tidsbrist, d˚a kravspecifikationen kommunen har f¨or installation av ny programvara ¨ar s˚a pass sv˚ar att bem¨ota inom den tidsram arbetet har [5].
Utvecklingsarbetet kommer att avgr¨ansas till att anpassas mot G¨avle kommuns livsmedels-och milj¨oinspekt¨orers behov d˚a arbetet kommer fr˚an deras avdelning p˚a G¨avle kommun. Detta ist¨allet f¨or att arbeta mot att g¨ora ett mer generellt verktyg anpassat mot att tillgodose andra kommuners arbetss¨att.
De unders¨okningar som har genomf¨orts ¨ar dels en enk¨atunders¨okning samt en fr˚agest¨allning. Enk¨atunders¨okningen begr¨ansas till G¨avle kommuns livsmedels- och milj¨oinspekt¨orer, detta d˚a denna unders¨okning handlar om dess nuvarande arbetss¨att. Fr˚agest¨allningen som handlar om anv¨andandet av Excel som komplement till Milj¨oReda avgr¨ansas till Milj¨oRedas anv¨andarf¨oreningsregister d˚a det ¨ar mest relevant hos de organisationer vilka anv¨ander Milj¨oReda.
2
Begrepp och principer
F¨oljande kommer l¨agga grunden f¨or de olika tekniker och arbetss¨att som har anv¨ants i arbetet. Bland annat beskrivningen av de olika webbteknologier, programmeringsm¨onster och ramverk vilka har anv¨ants i arbetet.
2.1 Arbetsmetod f¨or b¨attre designad programvara
F¨oljande rubriker kommer behandla principer f¨or hur programvara b¨or utformas f¨or att g¨oras l¨attare att underh˚alla och enklare att ut¨oka med funktionalitet. Dessa principer avser Test Driven Development, komplexitet och designm¨onster samt redundans.
2.1.1 Test Driven Development, TDD
TDD ¨ar en relativt ny metod att skriva programkod p˚a. Testdriven utveckling kombinerar arbetss¨attet test-f¨orst-utveckling med refaktorisering. Det g˚ar ut p˚a att utvecklaren skriver testet f¨or exempelvis en metod f¨ore att produktionskoden har skrivits. Testerna skrivs metod f¨or metod. Testerna skall vara isolerade och automatiska. Att testerna ¨ar isolerade inneb¨ar att ett test inte ska vara beroende av andra tester. Detta f¨or att undvika problemet med att ett misslyckat test g¨or att flera andra tester misslyckas, vilka ¨ar beroende av det f¨orsta testet.
Enligt Beck [6] skall tester skrivas under f¨oljande omst¨andigheter:
• If the interface for a method is at all unclear, you write a test before you write the method.
• If the interface is clear, but you imagine that the implementation will be the least bit complicated, you write at test before you write the method.
• If you think of an unusual circumstance in which the code should work as written, you write a test to communicate the circumstance.
• If you find a problem later, you write a test that isolates the problem.
• If you are about to refactor some code, and you aren’t sure how it’s supposed to behave, and there isn’t already a test for the aspect of the behavior in question, you write a test first. [6]
Tester skall skrivas till alla nya metoder om det ¨ar oklart hur interfacet ska se ut eller om det misst¨anks att implementation av ett interface kan bli det minsta komplicerad. Tester ska skrivas om utvecklaren ¨ar minsta os¨aker p˚a hur koden kommer bete sig efter en refaktorisering. Finns det n˚agra specialfall d¨ar koden borde fungera, ska tester skrivas som testar det. Hittas problem i koden ska det skrivas tester som t¨acker det problemet. Detta f¨or att i slut¨andan vara s¨aker p˚a att den kod som ¨ar skriven ¨ar testad p˚a b¨asta m¨ojliga s¨att. Det g¨or dessutom det enklare att ¨andra i koden och byta ut delar d˚a det redan finns tester vilket visar om den nya koden fungerar p˚a samma s¨att.
2.1.2 Komplexitet och designm¨onster
F¨oljande text kommer behandla hur komplexitet och designm¨onster i programvara kan f¨orb¨attras.
I objektorienterade mjukvaruutvecklingsteknologier likt exempelvis Java och .NET g˚ar det att skriva underh˚allsv¨anlig, ˚ateranv¨andningsbar och testv¨anlig kod tack vare dess stora funktionsrikedom. Trots detta kan stora klasser och m˚anga beroenden dem emellan g¨ora programkod mycket komplex och sv˚ar att f¨orst˚a. Programkomplexitet ¨ar ett st¨andigt problem f¨or mjukvaruutvecklare.[7] En l¨osning p˚a problemet med komplex och sv˚arunderh˚allen kod ¨ar att fr˚an b¨orjan skriva bra objektorienterad kod. Detta kan olika typer av designm¨onster hj¨alpa utvecklarna med. Designm¨onster guidar programmeraren till b¨attre objektorienterad design vilket leder till att programvaran blir l¨attare att underh˚alla, att den blir ˚ateranv¨andbar och att den kan ut¨okas med fler funktioner.[8] Designm¨onster beskriver t¨ankbara l¨osningar p˚a k¨anda ˚aterkommande problem inom programvaruutveckling. Att v¨alja ett passande designm¨onster kan dock vara komplicerat. Ji och Chen [9] presenterar en modell de kallar DEPA (Design Pattern Application). DEPA utg˚ar fr˚an fem steg vid val av designm¨onster: generiskt och dom¨anspecifikt, konkret, specifikt, integrerat samt implementerat designm¨onster. Tanken ¨ar att genom att beskriva designm¨onster, f¨or t¨ankt programvara, i dessa fem steg har man b˚ade f˚att en urvalsprocess och en tydlig dokumentation. Detta g¨or att m¨onstret i programvaran, och programvaran i sig, blir l¨attare att f¨orst˚a och underh˚alla. F¨orfattarna presenterar dessa fem steg:
1. Generiskt - beskriver designm¨onstret i vardagliga ordalag. Vanligen s˚asom b¨ocker om designm¨onster skulle beskriva dem. Man ska f¨orst˚a alla aspekter av det designm¨onstret.
• Dom¨anspecifikt - beskriver designm¨onstret lika abstrakt som generiskt men ¨ar fokuserat ˚at en specifik dom¨an. Exempelvis kan en dom¨an vara en bank eller en skola.
2. Konkret - tar bort det otydliga och abstrakta i beskrivningen av design m¨onstret. V¨ager f¨ordelar mot nackdelar och resonerar kring olika typer av tekniker med design m¨onstret. Allt detta f¨or att f˚a ett konkret design m¨onster vilket avsl¨ojar syftet med det. H¨ar avsl¨ojas ocks˚a klasser, attribut, metoder och relationer mellan klasser.
3. Specifikt - vilket namnet antyder blir beskrivningen nu mer specifik. Det inneb¨ar att beskrivningen av m¨onstret anpassas till en specifik programvara. De klasser vilket f¨orut kallades generiska “designm¨onster-namn” d¨ops nu om till programspecifika namn. Programspecifika metoder och attribut introduceras ¨aven h¨ar.
4. Integrerat - h¨ar kombineras, eventuellt, designm¨onstret med andra designm¨onster. 5. Implementerat - producera programkod av valda och beskrivna m¨onster. [9]
Li m. fl. [10] f¨oresl˚ar att med hj¨alp av ett ramverk analysera den kod som inf¨ors och varna om ¨andringar g˚ar emot den modellstruktur som till¨ampas. De menar att det inte ¨ar ovanligt att utvecklare inf¨or “fulkod” och hastiga f¨or¨andringar, vilket inf¨or obefogad komplexitet och icke optimala beteendef¨or¨andringar. Detta ramverk kan skapa en beteendemodell vilket reflekterar den nya koden. Detta g¨or att utvecklare kan uppt¨acka beteendef¨or¨andringar som bryter mot modellens struktur. [10] Genom att ˚aterspegla koden i exempelvis l¨ampliga uml-diagram kan utvecklarna snabbt uppt¨acka felaktiga beroenden eller felaktiga beteenden.
2.1.3 Redundans
Redundant kod f¨orekommer ofta i programvaror vilket f¨orsv˚arar underh˚allet och utvecklarnas f¨orst˚aelse av den. Detta kan bero p˚a att programspr˚aket ¨ar otillr¨ackligt, att en d˚alig design anv¨ands, att det uppkommit under underh˚all av befintlig programvara eller skapats av verktyg. [11] Jarzabek och Shubiao [11] fann ett exempel p˚a redundant kod n¨ar de studerade Javas Buffer Paket (JDK 1.4.1) och de visade att minst 68% av koden var redundant. Koden uppkom antingen flera g˚anger i olika klasser eller att den i princip var densamma med vissa skillnader. Genom att reducera denna redundanta kod blev programmet l¨attare att underh˚alla och f¨orst˚a. F¨or att l¨osa problemet vid redundant kod kan programmeraren anv¨anda sig av en metod kallad refaktorisering (refactoring). Att refaktorisera kod inneb¨ar att kodens inre struktur ¨
andras, till det b¨attre, utan att ¨andra dess externa beteende. Koden blir inte b¨attre av att bara refaktorisera utan programmeraren m˚aste anv¨anda sitt omd¨ome och refaktorisera efter hur f¨orh˚allandena i koden ser ut. Det f¨orekommer tv˚a olika taktiker vid refaktorisering. Den ena kallas floss refactoring, vilket inneb¨ar att refaktorisering sker kontinuerligt, och den andra kallas root-canal, vilket inneb¨ar att en viss tid avs¨atts speciellt f¨or refaktorisering. F¨orfattaren p˚ast˚ar att det ¨ar rekommenderat att anv¨anda sig av floss refactoring. [12]
Martin [13] beskriver en refaktoriseringsprocess i tv˚a enkla steg. (1) “First, make it work” - Se till att koden har tillr¨ackligt med tester. Att refaktorisera kod vilket inte ¨ar tillr¨ackligt testad g¨or att utvecklaren av misstag kan f¨orst¨ora andra funktioner. (2) “Then make it right” - Refaktorisera koden tills den ¨ar b¨attre. [13]
2.2 Anv¨andarv¨anlighet
N¨ar de kommer till att bygga ett program som skall vara anv¨andarv¨anligt och anpassat mot en speciell grupp anv¨andare, ¨ar ett s¨att f¨or utvecklaren att ˚astadkomma detta att anv¨anda sig av anv¨andarbaserad design. Ett s¨att f¨or utvecklaren att kunna anpassa programmet och ˚astadkomma det ¨ar att fr˚an b¨orjan l˚ata anv¨andarna ha en central plats i utformningen av programmet.[14] Genom att introducera anv¨andarna i ett tidigt skede hj¨alper det utvecklaren att basera sina designbeslut p˚a anv¨andarens tankar ist¨allet f¨or utvecklarens egna. P˚a s˚a s¨att g¨ors besluten mer riktade mot anv¨andarens behov. D˚a utvecklarens tankar ofta kan skilja sig mot vad anv¨andarna vill, ¨ar det b¨attre att l˚ata besluten komma utifr˚an tankarna hos de som skall anv¨anda programmet i ett senare skede.[14]
N¨ar produkt b¨orjar ta f¨ardig form ¨ar det ¨aven bra att l˚ata anv¨andaren testa programvaran. Anv¨andartester anv¨ands f¨or att se hur programmet fungerar, samt hur de slutliga anv¨andarna av programmet uppfattar det. Abras m. fl. [15] tar upp fem m˚al f¨or vad man vill ˚astadkomma med anv¨andartester. Dessa ¨ar:
1. F¨orb¨attra produktens anv¨andbarhet. 2. Involvera verkliga anv¨andare i test.
3. Ge anv¨andarna verkliga uppgifter att utf¨ora.
4. G¨or det m¨ojligt f¨or de som sk¨oter testerna att observera och notera vad deltagarna g¨or. 5. G¨or det m¨ojligt f¨or de som sk¨oter testerna att analysera data som erh˚allits och g¨ora
¨
andringar utifr˚an detta.
F¨or att ˚astadkomma ett bra slutresultat ¨ar det en f¨ordel att anv¨anda sig av flera tester, fr˚an ett tidigt tillf¨alle i produktionen av programmet. Detta g¨or att anv¨andaren f˚ar en st¨orre chans att finna funktioner som inte st¨ammer ¨overens med vad som skall g¨oras eller funktioner som
inte fungerar helt korrekt, vilket kan vara sv˚art att f˚a fram under ett ensamt test. [15] Att vid ett senare tillf¨alle g¨ora tester med samma anv¨andare igen f¨or att f˚a feedback p˚a arbetet som ¨ar gjort, skapar en st¨orre f¨orst˚aelse f¨or anv¨andarens behov. Det ¨ar ocks˚a ett s¨att att bekr¨afta att designens riktning ¨overensst¨ammer med anv¨andarens tankar och behov. [16]
2.3 Webbserver
Apache Tomcat ¨ar en ¨oppen k¨allkods-servlet container/web container utvecklat av The Apache Software Foundation. Tomcat implementerar Java Servlet- och JavaServer Pages- (JSP) teknologier [17]. Tomcat ¨ar licenserat under Apache License, Version 2.0 [18].
N¨ar en klient klickar p˚a en l¨ank (se figur 1), vilket pekar p˚a en servlet, skickas en request till webbservern. Servern vidarebefordrar till Tomcat-Containern, Tomcat delar upp requesten i ett request- och response-objekt vilket skickas in till den beg¨arda servleten. Servleten kan utf¨ora operationer s˚asom att h¨amta data fr˚an en databas, s¨atta olika parametrar med data och dylikt. D¨arefter skickar den tillbaka en response i form av en HTML-fil till klienten. [19]
Figur 1: Modell ¨over hur Tomcat fungerar.
2.4 Webbapplikation
En webbapplikation liknar en webbsida fast med dynamiskt inneh˚all. Java kan utveckla webbapplikationer med dess Enterprise Edition (JavaEE). N¨ar webbapplikationer utvecklas med Java skrivs frontend-delen som JavaServer Pages (JSP), vilket bland annat innefattar HTML-kod, Expression Language (EL), JavaScript och JavaScripts-biblioteket jQuery.
EL ¨ar ett spr˚ak vilket till˚ater access till Java komponenter fr˚an JSP filerna. Detta g¨or det m¨ojligt f¨or webbutvecklaren att g¨ora metodanrop till metoder i Java-koden.
Frontend kommunicerar med backend-delen av applikationen genom ett antal servlets. F¨or illustration se sida 16, figur 7.
2.5 Frontend
Frontend ¨ar den del som anv¨andaren av webbapplikationen ser, sj¨alva webbsidan, som ¨ar uppbyggd av JSP-filer. Denna del kommunicerar med backend genom servlets f¨or att f˚a fram den information som skall visas. Frontend ¨ar ovetande av vad som h¨ander i backend, dess funktion ¨
ska visa. Frontend fungerar allts˚a som ett interface mellan anv¨andaren och backend-delen av applikationen.
2.5.1 Frontend-verktyg
Frontend-delen av applikationen ¨ar utvecklad f¨or att klara av olika plattformar, allt i fr˚an mobiltelefoner till datorer. Den ¨ar utvecklad med hj¨alp av ett webbramverk kallat Bootstrap [20]. Bootstrap ¨ar ett ramverk f¨or att skapa responsiva webbsidor och ¨ar licensierat under MIT [21]. Responsiva hemsidor anpassar sig automatiskt till den sk¨armstorleken sidorna skall visas p˚a. Se figur 8, s. 15 f¨or exempel p˚a datorvy, samt se appendix I f¨or exempel p˚a surfplatta och mobiltelefon.
F¨orutom att applikationen bygger p˚a en responsiv grund, anv¨ands JavaScript-biblioteket jQuery f¨or vissa funktioner. Exempelvis anv¨ands Datepicker vilket ¨ar ett jQuery-script f¨or att v¨alja ut ett datum, utvecklat av Petre [22] och ¨ar licensierat under Apache License, Version 2.0 [18]. En annan funktion ¨ar DataTable vilket ¨ar ett ett plugin till jQuery f¨or att enklare kunna s¨oka ut och sortera i en tabell av information. Den ger en tabell m¨ojligheten att kunna sortera, filtrera och s¨oka ut information. Datatable ¨ar utvecklat av SprayMedia Ltd [23] och ¨ar licensierat under MIT [24].
2.5.2 JSP
JavaServer Page ¨ar uppbyggd med taggar fr˚an standardspr˚aket HTML, likt en vanlig webbsida ¨
ar uppbyggd. Skillnaden mellan JSP- och en vanlig HTML-sida ¨ar att inneh˚allet p˚a en HTML-sida ¨ar statiskt medan teknologin bakom JSP till˚ater utvecklaren att anv¨anda sig av dynamiskt inneh˚all. Detta g¨or att JSP sidor kan g¨oras personliga utifr˚an olika variabler, till exempel en personlig sida via inloggning eller att sidan ¨andras utifr˚an val anv¨andaren g¨or. JSP sidor till˚ater servern att dynamiskt l¨agga in information, fr˚an exempelvis en databas. [25]
JSP fungerar s˚a att n¨ar anv¨andaren laddar en JSP-sida, exekverar servern de JSP-element sidan inneh˚aller och resultatet fr˚an detta sammanfogas med de statiska delarna av sidan f¨or att sedan skicka tillbaka denna dynamiska sida till webbl¨asaren.[25]
2.5.3 Servlet
Java servlet ¨ar en Java-klass vilket ¨arver fr˚an den abstrakta klassen
javax.servlet.http.HttpServlet. Dess funktion i en webbapplikation ¨ar att, i princip, fylla statiska webbsidor med dynamiskt inneh˚all. Servleten tar emot http-beg¨aran fr˚an containern och utf¨or operationer s˚asom att h¨amta data fr˚an en databas och skickar tillbaka ett svar till containern som vidarebefordrar.[26]
D˚a en servlet ¨ar laddad stannar den i serverns minne i form av en instans, vilket g¨or att servleten kan beh˚alla sina externa resurser, som exempelvis en databaskoppling. Detta g¨or att servleten arbetar p˚a ett effektivare s¨att d˚a det i vissa fall kan ta n˚agra sekunder att skapa en databaskoppling.[26] D˚a servlets skrivs i Java ¨arvs den s¨akerhet som medf¨oljer Javaspr˚aket samt att servlet-API:et ¨ar implementerat f¨or att vara typs¨akert. Javas garbage collection g¨or dessutom att servleten generellt ¨ar s¨aker fr˚an minnesl¨ackor.[26]
2.6 Databas
HSQLDB (HyperSQL DataBase) ¨ar en javabaserad databas[27]. Hsqldb ¨ar licensierad under deras egna licens vilken ¨ar baserad p˚a licensen[28]. Hsqldb ¨ar bland annat inbyggd i OpenOffice:s databashanterar Base som ett standardalternativ f¨or att skapa databaser i det programmet
[29]. Hsqldb ¨ar skriven helt i programspr˚aket Java, k¨ors i Javas JVM (Java Virtual Machine) och st¨odjer Javas JDBC (Java Database Connectivity) gr¨anssnitt. [27] Hsqldb f¨oljer den internationella ISO SQL:2011 standarden och st¨odjer de vanligaste sql-funktionerna samt f¨or att skapa procedurer och triggers. [27]
Enligt “HyperSQL User Guide” [27] kan Hsqldb k¨oras p˚a tre f¨oljande vis: • I ramminnet, vilket inneb¨ar att datat f¨orst¨ors d˚a JVM stoppas.
• Som en java resurs, vilket inneb¨ar att databasen placeras som en resurs i projektet som en jar- eller zip-fil och har endast l¨asr¨attigheter.
• Som en fil p˚a h˚arddisken.
Hsqldb kr¨aver inte n˚agon extra programmvara f¨or att k¨oras. Det enda som kr¨avs ¨ar dess drivrutiner, vilket inkluderas som en resurs i form av en jar-fil i projektet.[27]
2.7 Backend
F¨or att l¨asa in data fr˚an exceldokument kan ett Java/Bibliotek fr˚an Apache anv¨andas kallat POI. POI anv¨ands f¨or att l¨asa dokumentformat fr˚an Microsoft s˚asom XLS, DOC, PPT, XLSX, DOCX och PPTX [30]. Biblioteket ¨ar licenserat under Apache Licens 2 [18], men kan dock inkludera andra licenser f¨or dess olika delar [31].
En backend kan best˚a av m˚anga olika komponenter, vilka kan ha m˚anga olika relationer till varandra. F¨or att dessa komponenter ska bli l¨att att underh˚alla och kunna ut¨okas med funktionalitet anv¨ands s˚a kallade designm¨onster av olika slag. F¨oljande avsnitt kommer beskriva n˚agra av dessa m¨onster.
2.7.1 MVC
MVC-designm¨onstret best˚ar av tre komponenter – Model, View och Controller, se figur 2. Model lagrar applikationens data, View visar gr¨anssnittet mot anv¨andaren och Controller hanterar anv¨andarens inmatningar samt uppdaterar datat i model.
F¨ordelen med att anv¨anda MVC-designen ¨ar att de olika komponenterna blir mer flexibla och ˚ateranv¨andningsbara. [32, s. 4-6] Exempelvis, kan en programvara vara f¨orsedd med olika views i form av ett desktopgr¨anssnitt, webbgr¨anssnitt och mobilgr¨anssnitt men att de olika views:en reflekterar samma model och anv¨ander samma controllers.
mainpulerar data hanterar input reflekterar datat Model Controller View
Figur 2: MVC-designm¨onstret.
2.7.2 Strategy & Factory
Strategy-designm¨onstret anv¨ands n¨ar en procedur som ska utf¨oras kan g¨oras p˚a flera olika s¨att. Proceduren g¨or samma sak men p˚a olika vis. Olika algoritmer-klasser implementerar samma interface, med samma metoder, se figur 3a. Kontexten best¨ammer vilken algoritm som anv¨ands.
[32, s. 315-324] Ett exempel kan vara att sortera en lista. Listan kan sorteras p˚a olika vis, i bokstavsordning, nummerordning, omv¨and bokstavsordning eller liknande, men det som utf¨ors ¨
ar en sortering oavsett hur den sorteras.
AlgorithmC + e x c e c u t e ( ) AlgorithmB + e x c e c u t e ( ) «interface» Strategy + e x c e c u t e ( ) AlgorithmA + e x c e c u t e ( ) Context
(a) Strategy-designm¨onstret.
«Interface» Creator +factoryMethod() ConcreteProduct ConcreteCreator +factoryMethod() «Interface» Product (b) Factory-designm¨onstret.
Figur 3: Strategy- & Factory-designm¨onstret.
Factory-designm¨onstret anv¨ands f¨or att dynamiskt skapa objekt, se figur 3b. Beroende p˚a vad anv¨andaren vill g¨ora kan objekt skapas dynamiskt. Parametriserad factory, ¨ar en av flera implementationer, vilket l˚ater factoryn best¨amma vilket objekt som ska skapas beroende p˚a vilken parameter som skickas in till factoryn. [32, s. 107–116]
Factory- och strategy-designm¨onstren kan med f¨ordel anv¨andas tillsammans genom att l˚ata en factory skapa, beroende p˚a in-paramatern, den b¨ast l¨ampade strategyn, se figur 4.
StrategyCreator +createStrategy(input) : Strategy AlgorithmC + e x c e c u t e ( ) AlgorithmB + e x c e c u t e ( ) «interface» Strategy + e x c e c u t e ( ) AlgorithmA + e x c e c u t e ( )
Figur 4: Factory- tillsammans med Strategy-designm¨onstret.
2.7.3 Mediator
Mediator-designm¨onstret (se figur 5a) fr¨amjar l¨osa beroenden mellan objekt d˚a objekten kommunicerar med varandra via mediatorn. Objekten k¨anner till mediatorn och mediatorn k¨anner till objekten. [32, s. 273-282]
2.7.4 DAO
DAO (Data Access Object) ¨ar ett designm¨onster vars syfte ¨ar att ta hand om den best¨andiga datalagringen i ett program, se figur 5b. Genom att d¨olja lagringsmetoden i DAO-objekt blir
det enkelt att byta lagringsmetod vid behov.[33, kap. 7.2.3] Genom att isolera objekten bakom ett gemensamt interface blir implementationen dold f¨or anv¨andaren.
ColleagueE mediator ColleagueC mediator ColleagueB mediator ColleagueA mediator ColleagueD mediator Mediator
(a) Mediator-designm¨onstret.
«Interface» DAOobject +add(...) +remove(...) +update(...) +contains(...) (b) DAO-designm¨onstret.
Figur 5: Mediator- & DAO-designm¨onstret.
Singleton - static uniqueInstance() +getInstance()
+singletonOperation()
(a) Singleton-designm¨onstret.
(b) Facade-designm¨onstret.
Figur 6: Singleton- & Facade-designm¨onstret.
2.7.5 Singleton
Singelton-designm¨onstret anv¨ands d˚a det bara f˚ar finnas en instans av en klass, se figur 6a. F¨or att ˚astadkomma detta g¨ors konstruktorn i klassen privat, vilket inneb¨ar att klassen inte g˚ar att instansiera, en privat statisk klassvariabel av sig sj¨alv skapas och en statisk metod, vilket returnerar variabeln, innf¨ors. I metoden som returnerar variabeln g¨ors en null-koll, utifall variabeln inte har blivit instansierad.[32, s. 127-134] Ett exempel p˚a n¨ar ett singeltonobjekt ¨ar bra att anv¨anda ¨ar n¨ar ett program lagrar data i en lista som f¨orvaras i en klass. Vi vill inte att det ska kunna skapas flera instanser av den klassen, eftersom det skulle inneb¨ara att det skapas flera listor vilket g¨or att det skulle bli d˚alig och of¨oruts¨agbar dataintegritet i programmet.
2.7.6 Facade
Facade-designm¨onstret anv¨ands f¨or att f¨orenkla anv¨andandet av ett subsystem, se figur 6b. Genom att skapa ett gemensamt interface f¨or subsystemet blir systemet enklare att anv¨anda och anv¨andaren beh¨over inte bry sig om detaljer i subsystemet. Allteftersom subsystemet utvecklas ¨okar ocks˚a antalet klasser, vilket g¨or det sv˚arare f¨or anv¨andaren att anv¨anda systemet. Introducerandet av flera designm¨onster kan resultera i fler klasser.[32, s. 185-193]
2.7.7 Dependency Injection
Dependency Injection ¨ar ett designm¨onster vars syfte ¨ar att minska beroenden mellan klasser och g¨ora dess tester oberoende. Att en klass tester blir oberoende med hj¨alp av dependency injection beror p˚a att de klasser som klassen ¨ar beroende av att de fungerar kan ”injiceras” in i den klassen ist¨allet. Detta g¨or att vid tester kan utvecklaren, ist¨allet f¨or att injicera den riktiga klassen, f¨orse klassen med ett bluff-objekt ist¨allet som kan f¨orse klassen med ”r¨att” svar n¨ar det anropas. [33, kap. 7.2.6] Detta kan ˚astadkommas genom att l˚ata de objekt klassen ¨ar beroende av inf¨oras via set-metoder [33, kap. 7.2.6] eller via konstruktorn.
3
Metod och genomf¨
orande
F¨oljande kapitel beskriver hur arbetet har utf¨orts. Det som kommer beskrivas ¨ar utvecklingsutf¨orande med dess metoder och tekniker, datainsamling om hur och vilken data som samlats in samt en beskrivning av de anv¨andartester som utf¨orts.
3.1 Utveckling av webbapplikation
Programvarudesign och utvecklingmetodiken bestod i till¨ampningen av vissa agila arbetsmetoder, vilket innefattade utveckling med kontinuerliga ”releaser”, anv¨andardriven design samt TDD (Test Driven Development). Programvarudesignen har delvis utformats med hj¨alp av DEPA-metoden, se avsnitt 2.1.2 samt i form av kontinuerlig dokumentation i UML-diagram likt Li m. fl. [10] ramverk, se avsnitt 2.1.2. De olika designm¨onster som till¨ampats ¨ar MVC, Strategy, Factory, Mediator, DAO, Singelton, Facade samt Dependency Injection.
F¨or inl¨asning av exceldokumentens data har Apaches Java-bibliotek POI anv¨ants.
Den best¨andiga lagringen har tillhandah˚allits av en databas. Den typ av databas som anv¨ants har varit en inb¨addad databas kallad HSQLDB, se avsnitt 2.6 version 2.3.2, vilket har lagrats som en fil p˚a h˚arddisken.
Webbapplikationen har under utvecklingen installerats p˚a en server med Ubuntu 12.04 i web containern Tomcat 7.
Webb-gr¨anssnittet ¨ar utformat med hj¨alp av webbramverket Bootstrap 3, tillsammans med verktygen Datepicker och Tabelsorter.
3.2 Datainsamling
Insamlingen av information om verksamheten med dess arbetss¨att har skett med hj¨alp av intervjuer/samtal med avdelningschefen och en av inspekt¨orerna. Denna information har legat till grund f¨or att verksamhetsanpassa verktyget. Inspekt¨oren har fungerat som kontaktpersonen f¨or detta arbete.
Ut¨over dessa samtal har datainsamling skett i form av en enk¨atunders¨okning till ¨ovriga inspekt¨orer vid samma avdelning hos G¨avle kommun, vilket ¨ar baserad p˚a den information som insamlats fr˚an intervjuerna/samtalen med avdelningschefen och kontaktpersonen. Enk¨aten har
innefattat fr˚agor hur de ¨ovriga inspekt¨orerna har upplevt dess d˚avarande system. Enk¨atfr˚agorna utformades till att innefatta b˚ade st¨angda och ¨oppna fr˚agest¨allningar. De st¨angda fr˚agorna utformades med ett antal svarsalternativ d¨ar det inte fanns n˚agot mitten-alternativ att v¨alja. Detta f¨or att undvika att den svarande inte tar st¨allning i fr˚agan genom att v¨alja det mittersta alternativet. Den svarande tvingas fundera ¨over vilket alternativ de k¨anner passar b¨ast ¨overens med dess upplevelse.
Svaren p˚a de ¨oppna fr˚agorna ger en b¨attre bild av inspekt¨orernas tankar och id´eer kring systemet. ¨Oppna fr˚agest¨allningar inneb¨ar enligt Biggam [34] att det skall vara fr˚agor d¨ar det inte g˚ar att svara med ett kort allm¨ant svar. Det skall vara fr˚agor som leder den medverkande till att faktiskt uttrycka sin syn p˚a saken i en st¨orre utstr¨ackning, att personen i fr˚aga faktiskt m˚aste t¨anka till och ge ett l¨angre utf¨orligt svar. [34] . Se appendix B f¨or enk¨aten i dess helhet med svarsexempel.
F¨or att ta reda p˚a om fler kommuner anv¨ander Exceldokument, eller liknande, f¨or att komplettera Milj¨oReda skickades fr˚agan ”Anv¨ander ni Exceldokument, eller motsvarande, som ett komplement till Milj¨oReda?” ut via e-post till de organisationer vilka stod med i medlemsregister hos Milj¨oRedas anv¨andarf¨orening [35]. Fr˚agan st¨alldes utan att specificera exakt vilken roll exceldokumentet hade, d˚a fr˚agest¨allning syftade till att ta reda p˚a i vilken utstr¨ackning Excel anv¨ands f¨or att komplettera Milj¨oReda.
3.3 Anv¨andartester
Under arbetets g˚ang utf¨ordes anv¨andartester, detta f¨or att webbapplikationen skulle anpassas p˚a b¨asta s¨att efter inspekt¨orernas behov. I f¨orsta delen av anv¨andartesterna skickades en applikationsmodell ut till kontaktpersonen, se appendix G. En applikationsmodell ¨ar en id´ e-modell ¨over hur utseendet och basfunktionerna skulle kunna se ut och fungera. Med hj¨alp av modellen kunde inspekt¨oren g¨ora ett eget test, d¨ar det gick att navigera likt en vanlig hemsida, f¨or att f˚a en bild av hur webbapplikationen kunde fungera och se ut. En ˚aterkoppling med inspekt¨oren gjordes efter testet f¨or att f˚a ett utl˚atande om dennes tankar kring de funktioner som demonstrerats samt utseende p˚a applikationen.
Utifr˚an resultaten av applikationsmodellen utvecklades sedan den verkliga applikationen. Allt eftersom applikationen tog form arbetades det med anv¨andartester d¨ar inspekt¨oren fick testa applikationens funktioner och komma med id´eer kring utseende och vilken information som skulle visas. Detta f¨or att i b¨asta m˚an m¨ota upp inspekt¨orernas behov och s¨att att arbeta. Anv¨andartesterna utf¨ordes till en b¨orja under m¨oten med inspekt¨oren d¨ar funktionaliteten demonstrerades. Slutligen installerades applikationen p˚a en server, vilket gjorde det m¨ojligt f¨or inspekt¨oren att sj¨alv testa applikationen utanf¨or m¨otena. Detta resulterade i att applikationen kunde testas mer regelbundet och d¨arigenom anpassas under utvecklingens g˚ang p˚a ett mer effektivt s¨att.
4
Resultat
I detta kapitel kommer resultatet av arbetet att presenteras. F¨orst kommer omfattningen av excelanv¨andandet att beskrivas. Sedan presenteras resultatet av enk¨atunders¨okningen som genomf¨ordes hos G¨avle kommuns inspekt¨orer. Efter det beskrivs webbapplikationens uppbyggnad, kundens omd¨ome och till sist presenteras vissa alternativa l¨osningar.
4.1 Omfattningen av Excel
Fr˚agan om Excel, eller liknande, anv¨andes som n˚agon form av komplement till Milj¨oReda, skickades ut till alla kommuner registrerade hos Milj¨oRedas anv¨andarf¨orening. Det visade sig att en betydande andel arbetade med Exceldokument f¨or att komplettera Milj¨oReda p˚a olika s¨att.
Av de 124 registrerade organisationerna svarade 56% p˚a fr˚agest¨allningen ”Anv¨ander ni exceldokument, eller motsvarande, som ett komplement till Milj¨oReda?”. Svaren visade att det anv¨ands p˚a flera h˚all. 46% av dem uppgav att ett komplement anv¨ands i det dagliga arbetet d¨ar Milj¨oReda inte kunde uppfylla vissa funktioner.
4.2 Enk¨atunders¨okning
Enk¨atunders¨okningen anv¨andes f¨or att f˚a en ¨overblick av inspekt¨orernas tankar kring dess nuvarande arbetss¨att. Enk¨aten utformades f¨or att f˚a specifika svar p˚a fr˚agor kring Milj¨oReda, Exceldokumentet och hur arbetet p˚averkas av Exceldokumentet.
Det arbetar sju stycken inspekt¨orer vid G¨avle kommuns milj¨o- och h¨alsoskyddsavdelning och av dessa sju svarade samtliga p˚a den utskickade enk¨atunders¨okningen. Svaren visade att inspekt¨orerna efter en inspektion spenderar upp till en timme med att f¨ora in data, vilket samlats under en kontroll, till Milj¨oReda och Exceldokumentet, exkluderat de inspektionsrapport de skriver. Detta bortsett fr˚an att det inte g˚ar att l¨agga in sin information i Exceldokumentet n¨ar en annan inspekt¨or har det ¨oppet.
Enk¨aten visade att majoriteten inte var helt n¨ojd med det nuvarande arbetss¨attet. De vill se en f¨or¨andring f¨or att skapa ett effektivare arbete. Arbetet med hj¨alpverktyg i form av Exceldokument fungerar inte optimalt d˚a det inte finns m¨ojlighet att arbeta samtidigt i dokumentet samt att det blir f¨or stor del dubbelarbete att fylla i b˚ade ett Exceldokument samt att f¨ora in samma information i Milj¨oReda.
Svaren p˚a hur Exceldokumentet och Milj¨oReda upplevs, visar att inspekt¨orerna inte k¨anner att Exceldokumentet fungerar p˚a ett s¨att som gynnar arbetet. G¨allande Milj¨oReda skiljer sig ˚asikterna mellan inspekt¨orerna d¨ar majoriteten uppger att Milj¨oReda inte fungerar p˚a ett bra s¨att. Majoriteten av inspekt¨orerna upplever ¨aven att det blir dubbelarbete n¨ar det skall fyllas i information i b˚ade Milj¨oreda och Exceldokumentet. Ett enigt svar framkommer vid fr˚agan om Exceldokumentet skapar f¨ordr¨ojningar i arbetsprocessen, d¨ar svaren ”ofta” och ”alltid” ¨ar valda.
P˚a fr˚agan ang˚aende om inspekt¨orerna skulle anv¨anda sig av en applikation f¨or att kunna fylla i informationen p˚a plats under en inspektion var majoritetens svar ”Troligtvis” och ”Ja de skulle jag”.
4.3 Webbapplikation
Detta avsnitt kommer innefatta en lista ¨over webbapplikationens funktioner, beskrivning av frontend-design, beskrivning av backend-design samt beskrivning och modell ¨over databasdesignen. Den funktionalitet som finns implementerad ¨ar f¨oljande:
• Importing av objektinformation fr˚an Exceldokument till databas genom programkod • Lista alla objekt i databasen
• Sortera objekt efter fallande och stigande p˚a vald kolumn • Filtrera objekt utifr˚an s¨okord
• L¨agga till en ny inspekt¨or • Lista vald inspekt¨ors objekt • Visa all information om objekten
• Visa bed¨omning p˚a kontrollpunkter knutna till ett objekt • Uppdatera informationen hos ett objekt
• Uppdatera bed¨omning p˚a kontrollpunkter knutna till ett objekt • L¨agga till kommentar/anteckning till ett objekt
• Responsivt gr¨anssnitt som anpassas efter sk¨armstorlek.
Webbapplikationens design ¨ar uppbygg enligt MVC-m¨onstret, vilket illustreras i figur 7. JSP ¨ar de html fyllda filerna som ¨ar det gr¨anssnitt vilket visas mot anv¨andaren och servlet:erna fyller JSP-filerna med den data anv¨andaren har beg¨art eller behandlar den data anv¨andaren har skickat in. JSP och i viss m˚an servlet-komponenterna ¨ar webbapplikationens frontend (framsida). Servlet:erna kommunicerar med logiken, vilket behandlar den data som anv¨andaren skickat in. Logiken kommunicerar med de olika komponenterna som utf¨or olika funktioner, vilket i detta fall inneb¨ar att kommunicera vidare mot dao eller utf¨ora n˚agon funktion anv¨andaren beg¨art. Dao sk¨oter den best¨andiga lagringen av data, vilket i detta fall ¨ar i form av en databas. Logiken k¨anner inte till att data lagras i en databas. Logik-, dao- och databaskomponenterna ¨
ar webbapplikationens backend. 4.3.1 Frontend-design
Figur 8: Sidan f¨or alla objekt, datorbild. Genom anv¨andandet av Bootstraps
ramverk f¨or responsiv design kan
utvecklaren anpassa utseende
och information efter hur stor sk¨armstorleken ¨ar. Detta g¨ors f¨or att skapa en mer anv¨andarv¨anlig applikation. Exempelvis n¨ar en mobiltelefon anv¨ands minimeras inneh˚allet till att det viktigaste visas medan resterande information d¨oljs, detta g¨or det enklare att navigera f¨or anv¨andaren.
Webbapplikation anv¨ander
Datepicker f¨or att f¨orenkla inf¨orande av datum. Det fungerar p˚a s˚a vis att n¨ar anv¨andaren
v¨aljer ett datum kommer det
fram en datumv¨aljare, en
kalenderruta. Detta g¨or att
anv¨andaren p˚a ett enklare s¨att skall kunna v¨alja mellan ˚ar, m˚anad och dag utan att beh¨ova skriva in datumet sj¨alv. Detta g¨or att fel datumformat inte kan matas in. Applikationen anv¨ander ¨aven DataTable f¨or att ge html-tabellerna s¨ok-, sorterings- och filteringsfunktionalitet. Med hj¨alp av DataTable kan anv¨andaren p˚a ett enkelt s¨att s¨oka ut olika objekt beroende p˚a informationen samt v¨alja vilken information tabellen skall sorteras efter.
MODEL CONTROLLER VIEW resultat uppdatera/ h ä m t a Databas - Model resultat resultat BACKEND svar resultat begär FRONTEND uppdatera/ h ä m t a vidare-befodrar begäran Funktion DAO - Model Logik - Controller Servlet - Controller JSP - View
Figur 7: ¨Overgripande MVC-design av applikationen.
Figur 9: Inspekt¨orens egna sida(”Min sida”), datorbild. Webbapplikationens
frontend-del ¨ar utformad s˚a att startsidan, se figur 8, ¨ar den sida d¨ar alla inlagda objekt visas i en lista. D¨ar finns den mest intressanta informationen vald av inspekt¨orerna [4]. Detta f¨or att skapa en ¨overblick av objekten och d¨arigenom ¨aven kunna filtrera ut objekt. Denna lista best˚ar av
namn, adress, information om
erfarenhet, typ av verksamhet, ˚arlig tid, arbetad tid, kontrollagertid (resttid), riskklassificering samt vilken inspekt¨or objektet tillh¨or.
Denna lista har funktioner som g¨or att anv¨andaren kan v¨alja hur m˚anga objekt som skall visas, samt en s¨ok funktion. S¨okfunktionen filtrerar listan ord f¨or ord, de vill s¨aga att anv¨andaren kan skriva in tv˚a skilda ord och funktionen filtrerar d˚a de orden separat och inte som en mening.
Den ¨ovre panelen visar en dropdown d¨ar anv¨andaren v¨aljer inspekt¨or. Vidare i panelen finns en flik ”Min sida” se figur 9. Den sidan visar den valda inspekt¨orens objekt. Varje inspekt¨or kan d˚a se listan med dess egna objekt samt objektets mest relevanta information [4].
information listas, se figur 10a. P˚a denna sida kan anv¨andaren ¨andra informationen om objekten. Ut¨over objektets specifika information finns en lista d¨ar anteckningar om objektet sparas. Dessa anteckningar ¨ar till f¨or att anv¨andas under en kontroll, d¨ar inspekt¨oren kan skriva in ¨ovrig information som uppkommit under en kontroll. Denna sida ¨ar, i och med det, starten vid en ny kontroll. P˚a denna sida kan till exempel arbetad tid ¨andras efter en kontroll. Sidan kan ¨aven visa kontrollpunkter samt dess status, detta kommer upp i ett popup-f¨onster (figur 10b) vilket endast ¨
ar till f¨or att f˚a en ¨overblick av kontrollpunkterna och dess bed¨omning. Fr˚an popup-f¨onstret g˚ar det inte att ¨andra status p˚a punkterna.
(a) Sidan f¨or ny kontroll, datorbild.
(b) Popup-f¨onster fr˚an sidan med
objektinformation, f¨or att visa
kontrollpunkterna, datorbild. Figur 10: Sk¨armbilder p˚a sidan ¨over objektinformationen.
Anv¨andaren kan, p˚a sidan som listar ett objekts information, sedan v¨alja ”Ny kontroll”, se figur 11. P˚a denna sida kan inspekt¨oren ¨andra bed¨omningar p˚a kontrollpunkterna, samt l¨agga till en anteckning till objektet. Av de 15 kontrollpunkterna har sju av dessa underpunkter, dessa visas inte f¨or anv¨andaren f¨orr¨an huvupunkten klickas. Dessa underpunkter g˚ar att individuellt ¨
andra bed¨omningen p˚a. Denna sida kan anv¨andas under en inspektion d˚a inspekt¨orern kan ¨
andra bed¨omningen av de kontrollpunkter denna har granskat samt l¨agga till en anteckning om inspektionen.
4.3.2 Backend-design
F¨or fullst¨andig uml ¨over backend-systemet se appendix E. Backend-system ¨ar uppbyggt i en skiktad arkitektur, se figur 12b s. 19. Det ¨ovre skiktet kan bara kommunicera med dess undre. Detta g¨or att det blir ett tydligare datafl¨ode, l¨attare att testa de olika delarna och ett minskat beroende mellan de olika delarna.
Servleterna, se figur 12b, tar hand om anv¨andarens input och anropar metoder i ObjectSystem f¨or att utf¨ora operationer, i enighet med vad anv¨andaren har beg¨art, vilket kan innefatta att spara data, ta bort data, uppdatera data eller liknande. Servleterna h¨amtar ¨aven all data fr˚an ObjectSystem, vilket Servleterna senare fyller JSP-filerna med.
DatabaseManager, se figur 12a, ¨ar en modul som hanterar uppkopplingen mot databasen. Den ¨ar bygg enligt singelton-designm¨onstret (se avsnitt 2.7.5) vilket g¨or att det endast finns
Figur 11: Sidan f¨or ny kontroll, datorbild.
en instans av den klassen i hela systemet. Detta f¨or att undvika att skapa flera kopplingar till databasen d˚a HSQLDB endast till˚ater en koppling.
ObjectSystem, se figur 13a, fungerar som en fasad (facade, se avsnitt 2.7.6) f¨or servlet:erna. ObjectSystem anropar andra delar att utf¨ora de beg¨arda funktionerna. Exempelvis, om anv¨andaren vill importera data fr˚an en fil in i systemet, kommer ObjectSystem be FileParser att extrahera data fr˚an filen, den data skickar sedan ObjectSystem vidare till Importer-modulen, vilket sk¨oter importeringen av data in i systemet.
DaoManager, se figur 12b, fungerar som en mediator (se avsnitt 2.7.3) vilket bringar ordning i det objekt-kaos vilket annars skulle intr¨affa d˚a det finns fler ¨an en DAO. Objectsystem och Importer beh¨over bara k¨anna till DaoManager f¨or att kunna kommunicera med alla DAO-objekt. DAO-objekten, se figur 13b, ¨ar de moduler vilket kommunicerar med databasen. Se appendix F f¨or alla doa-klasser. DAO st˚ar f¨or Data Access Object och ¨ar ett designm¨onster (se 2.7.4) vars syfte ¨ar att d¨olja hur data lagras.
F¨orutom DaoManager k¨anner inga andra objekt i systemet till hur data lagras. DaoManager m˚aste k¨anna till detta d˚a den med dependency injection (se avsnitt 2.7.7) injicerar databaskopplingen in i de DAO-objekt som ¨ar beroende av databaskopplingen. P˚agrund av denna injecering kan DAO-objekten testas oberoende av databsen. Eftersom bara DAO-objekten vet hur data lagras g¨or det att vid ett eventuellt byte av lagringss¨att beh¨over bara DAO-objekten p˚averkas.
Data ¨overf¨ors i systemet med hj¨alp av JavaBeans, se figur 14. En JavaBean, i dess enklaste utformning, ¨ar en klass med privata attribut vilket ¨ar ˚atkomliga via setter och getters samt har bean i slutet av klassnamnet [36]. F¨or samtliga JavaBeans i systemet se appendix C.
ObjectSystem ¨ar den klass vilket servleterna kommunicerar med f¨or att erh˚alla information fr˚an databasen eller uppdatera information i databasen, se figur 13a. ObjectSystem implementerar facade-designm¨onstret, vilket g¨or att servleterna, vilka kommunicerar med klassen, f˚ar ett enkelt gr¨anssnitt att kommunicera med och de beh¨over inte bry sig om vad som sker i bakgrunden.
FileParser i figur 12b ¨ar en modul som har till uppgift att extrahera data fr˚an en fil och returnera data i form av en lista med ObjectBeans. Listan med ObjectBeans skickas sedan in i en importerings-modul, kallat Importer, som ¨overf¨or informationen till Model.
«Class» DatabaseManager - connection : Connection - dbm : DatabaseManager - DatabaseManager() + getInstance() : DatabaseManager + connectToDB() : Connection + getConnection() : Connection + closeConnection() + isConnected() : boolean + backupDatabase() + restoreDbFromLatestBackup() Responsibilities - - H a n d l e d a t a b a s e c o n n e c t i o n Pattern: Singelton (a) DatabaseManager
-hanterar uppkopplingen mot
databasen DatabaseManager d a t a Parsing resultat FileParser resultat resultat uppdatera/ begäran DaoManager resultat uppdatera/ begäran Databas resultat resultat begär uppdatera/ begäran begäran Importer DAO ObjectSystem Servlets (b) System¨oversikt.
Figur 12: DatabaseManager & system¨oversikt.
Det dokumentformat som st¨odjs ¨ar Mircosofts nya Excel-format, xlsx. Data extraheras fr˚an dokumentet med hj¨alp av Apaches Java-bibliotek POI [30].
Importeringsfunktionen ¨ar uppbyggd med strategy- och factory-designm¨onstren, se figur 15 f¨or modell ¨over funktionen och avsnitt 2.7.2 f¨or beskrivning av m¨onstren. Parser-objektens uppgift ¨ar att extrahera information ur det dokument den f˚ar skickade till sig. Parser-komponenten ¨ar uppbyggd enligt strategy-designm¨onstret, eftersom alla Parsers extraherar data fr˚an filer och de skiljer sig endast med vilken filtyp den extraherar data ur. ParserFactory ¨ar en Parser-skapare. Dess uppgift ¨ar att skapa r¨att Parser f¨or den fil som skickas till den. Om ParserFactory inte kan skapa en passande Parser kastas ett fel. F¨or att l¨agga till st¨od f¨or en annan filtyp ¨an, i detta fall, excel beh¨over en utvecklare endast implementera Parser-interfacet och l¨agga till den Parsern i ParserFactory.
F¨or designen av dataextraherings-funktionen gjordes en grundl¨aggande utv¨ardering enligt DEPA-modellen, se appendix D.
4.3.3 Databasdesign
Databasen ¨ar designad efter hur inspekt¨orerna arbetar och efter den information de sparar om objekten. Figur 16 f¨orest¨aller en objektmodell av databasen med endast objekt och dess relationer. Se appendix H f¨or fullst¨andig databasmodell. Databasen utg˚ar fr˚an objektet Objekt, se figur 16, vilket faller sig naturligt d˚a det ¨ar informationen om objekten databasen skall lagra. Nedan beskrivs Objekt:s relationer vilket utg˚ar ifr˚an figur 16.
Ett Objekt kan ha en eller flera Tids:objekt. Tids:objeket ¨ar beroende av Objekt d˚a det inte kan finnas n˚agon Tid utan ett Objekt.
Ett Objekt kan ha en Anl¨aggningsstatus och Anl¨aggningsstatusen kan tillh¨ora flera Objekt. Ett Objekt kan ha ett eller flera ¨Arenden, vilket i sin tur kan ha ett eller flera Handlingar. Ett ¨Arende kan inte existera utan ett Objekt, likt en Handling inte kan existera utan ett ¨Arende.
«Class» ObjectSystem - daoManager : DAOManager - Importer : importer - ParserFactory : parserFactory
+ addCaseToObject(aCase : CaseBean, objectID : int) + addInspector(inspector : InspectorBean) + getAllObjectInformation() : ArrayList<DataBean> + getControlPointRatings() : ArrayList<DataBean> + getControlPoints(nestedControlPoints : boolean) : ArrayList<DataBean> + getExperiences() : ArrayList<DataBean> + getInspectors() : ArrayList<DataBean> + getListOfStatus() : ArrayList<DataBean> + getObject(id : int) : ObjectBean
+ getObject(name : String) : ArrayList<DataBean> + getRoles() : ArrayList<DataBean> + importDataFromFile(file : File) + removeInspector(inspector : InspectorBean) + removeInspectorFromObject(object : ObjectBean, inspector : InspectorBean) + setInspectorToObject(objectId : int, inspector : InspectorBean) + updateCase(caseId : int, aCase : CaseBean)
+ updateObject(object : ObjectBean) + updateObjectControlPoints(
controlPoints : ArrayList<ControlPointBean>, objectId : int)
+ updateTime(objectId : int, time : TimeBean) Responsibilities
- - D e l e g a t e t a s k s
Pattern: Facade
(a) ObjectSystem - navet i applikationen.
«interface» DAO
+add(thing : DataBean) +get(id : int) : DataBean +get(name : string) : DataBean +getAll() : ArrayList<DataBean> +remove(bean : DataBean) +update(bean : DataBean) +contains(id : int) : boolean +contains(name : String) : boolean Responsibilities - - S t o r e s d a t a -- Retrieve data -- Update data -- Remove data (b) DAO-interfacet. Figur 13: ObjectSystem & DAO-interface.
«Class» ControlPointBean - dateChecked : Date - rating : String - subControlPoints : ArrayList<ControlPointBean> + getters & setters
+ hasSubControlPoints() : booelan Responsibilities
- - H o l d i n f o r m a t i o n a b o u t a c o n t r o l p o i n t w i t h i t s c o n t r o l p o i n t s
Figur 14: Exempel p˚a en JavaBean - en bean f¨or en kontrollpunkt.
¨
Arende har valts att kallas ”anteckning” i webbgr¨anssnittet. Detta eftersom ¨Arende och Handlig ¨
ar n˚agot som inspekt¨orerna arbetar med i Milj¨oReda och att det i detta fall ¨ar en f¨orberedelse f¨or en eventuell vidareutveckling d¨ar ¨aven dessa ¨ar inkluderade i applikationen.
Objekt kan ha ett eller flera Objektkontroll:er. Objektkontroll:er best˚ar av ett eller flera Kontrollpunkt:er samt en Kontrollpunktsbed¨omning. En Kontrollpunkt kan inneh˚alla flera underpunkter. Kontrollpunkten har en rekursiv relation. F¨or att f¨ortydliga, Objektkontroll inneh˚aller ett Objekts kontrollpunkter. Kontrollpunkterna f¨or ett Objekt har en bed¨omning.
Objekt kan ha en Verksamhetstyp och en Verksamhetstyp kan ha flera Objekt. Samma g¨aller f¨or Erfarenhet, Riskklass och Postnummer.
Ett Objekt kan ha en eller flera Objektinspekt¨orer. Objektinspekt¨orer best˚ar av ett Objekt, en Roll och en eller ingen Inspekt¨or. Roll ¨ar den roll/f¨orh˚allande en inspekt¨or har till ett Objekt, exempelvis standard inspekt¨or eller kontrollager inspekt¨or. Antalet Inspekt¨orer knutna till ett Objekt begr¨ansas av hur m˚anga olika roller en inspekt¨or kan ha till ett Objekt. Nuvarande system inneh˚aller tv˚a olika roller. Dessa ¨ar kontrollager och standard. Detta betyder att antalet inspekt¨orer knutna till ett objekt ¨ar begr¨ansat till tv˚a, en kontrollagerinspekt¨or och en standardinspekt¨or.
ObjectSystem
Importer
Importer (daoManager : DAOManager) +importData(data : ArrayList<ObjectBean>) : void Responsibilities - I m p o r t d a t a i n t o D A O «Class» ExcelParser Responsibilities
-- Parse excel file
«Interface» Parser
+excecute (file: File): ArrayList<DataBean> Responsibilities
-- Parse file
Pattern: Strategy
«Class» ParserFactory
getParse(file : File): Parser Responsibilities
-- Choose a parser
-- Error if incompatible file.
Figur 15: Dataimporteringsfunktionen - uppbyggd med factory- och strategy-designm¨onstret.
Figur 16: Databasdesign - Objektmodell.
4.4 Kundomd¨ome
En inspekt¨or har testat applikationen i samband med en inspektion av ett objekt ute p˚a f¨altet. Inspekt¨oren anv¨ande d˚a applikationen p˚a en mobiltelefon (Iphone). Inspekt¨oren upplevde att applikationen gjorde det enklare att f˚a fram all information om objektet d˚a det nuvarande s¨attet var att skriva ut den informationen innan en inspektion. Detta f¨orenklade ¨aven situationer d˚a den planerade verksamheten inte ¨ar ¨oppen och inspekt¨oren d˚a m˚aste g¨ora en inspektion p˚a en annan verksamhet, vilket g¨or att denne m˚aste s¨oka fram den nya verksamhetens information.[4] Testet visade ¨aven att s¨okfunktionen fungerade p˚a ett bra s¨att och att de var enkelt f¨or inspekt¨oren att s¨oka fram information, d˚a det till exempel b˚ade g˚ar att s¨oka bland objekt och gatuadresser f¨or att specificera sin s¨okning. Applikationen visade sig fungera bra ¨
aven med en mindre sk¨armstorlek, d˚a testet utf¨ordes p˚a en Iphone. Inspekt¨oren tyckte att sk¨armstorleken r¨ackte v¨al till att exempelvis fylla i kontrollpunkterna samt skriva en kortare kommentar/anteckning under inspektionen. Inspekt¨oren k¨ande ¨aven att en mobiltelefon skulle vara enklare att anv¨anda ¨an en surfplatta d˚a den enkelt g˚ar att stoppa undan. Detta underl¨attar, d˚a arbetet ofta inneb¨ar att inspekt¨orerna kollar runt i kyl, frys, l˚ador, under b¨ankar med mera, vilket g¨or att de m˚aste anv¨anda h¨anderna. En annan positiv aspekt med applikationen var att
den fungerar b˚ade ¨over mobiltelefonen samt p˚a dator, d˚a inspekt¨oren efter en inspektion skall skriva inspektionsrapporten p˚a sin dator.[4]
Inspekt¨oren reflekterade ¨over att det var en f¨ordel att flera kunde arbeta med systemet samtidigt, d˚a dess nuvarande system med Exceldokumentet g¨or att bara en inspekt¨or kan arbeta med dokumentet i taget. Inspekt¨oren menar att applikationen effektiviserar arbetet ute p˚a f¨alt: ”Programmet ute p˚a inspektionen i j¨amf¨orelse med dagens redskap (papper, penna, skrivplatta) betydligt smidigare”.[4]
En vidareutveckling n¨amndes efter testet, detta var en funktion att kunna ta bilder med telefonen eller surfplattan f¨or att direkt kunna spara ner i applikationen. Detta d˚a inspekt¨oren ofta under inspektioner tar bilder kopplade till kontrollpunkterna.[4]
4.5 Alternativa l¨osningar
En m¨ojlighet f¨or kommunen ¨ar att anv¨anda sig av Google Docs Spreadsheet. Google Docs Spreadsheet ¨ar en molntj¨anst vilket har st¨od f¨or att flera anv¨andare redigerar samtidigt i samma kalkylark. Denna applikation l¨oser kommunens multianv¨andarproblematik samt att applikationen har st¨od f¨or en m¨angd funktioner vilket kan l¨osa problematiken med filtrering av objekt och arbetsf¨ordelning av objekt. [37] Tj¨ansten har ocks˚a mobila applikationer till bland annat IOS och Android [38], vilket ger kommunen m¨ojlighet att under inspektioner direkt kunna l¨agga in uppgifter om f¨oretag. Google har tv˚a prisplaner f¨or f¨oretag. Den ena kostar antingen fyra euro per m˚anad per anv¨andare eller 40 euro per ˚ar per anv¨andare. Den andra, vilket har en del extra funktionalitet, kostar ˚atta euro per anv¨andare och m˚anad. [39]
Ett annat alternativ ¨ar att anv¨anda Microsoft Office SharePoint Services
dokumentationsserver med Excel Calculation Services aktiverad. F¨or att dela och samarbeta i ett Exceldokument sparas Exceldokumentet i en arbetsbok p˚a servern, tillg¨angligt f¨or alla samarbetspartners, d¨ar den markeras som delad. Detta g¨or att flera personer kan redigera samma Exceldokument samtidigt. En arbetsbok kan inneh˚alla flera Exceldokument. [40]
Office 360 har ocks˚a st¨od f¨or redigering av samma dokument samtidigt [41].
Box ¨ar ett annat alternativ vilket har st¨od f¨or dokumentsamarbete via tredjepart fr˚an Google Apps. [42]
5
Diskussion
Valet av att utveckla en webbapplikation gjordes p˚a grund av att det verktyg vilket skulle ers¨atta Exceldokumentet dels skulle ha st¨od f¨or flera anv¨andare samtidigt och dessutom att det skulle kunna anv¨andas ute p˚a inspektioner och fr˚an kontoret. Detta ledde till att en webbapplikation var en valm¨ojlighet f¨or att ˚astadkomma detta. D˚a specifikationen om regler och riktlinjer g¨allande installation av programvara hos kommunen var s˚a pass omfattande ans˚ag vi att en webbapplikation var l¨attare ¨an ett program att anpassas till att bem¨ota denna specifikation[5]. Slutligen tyckte vi att med hj¨alp av hur tabeller ¨ar uppbyggda i HTML kan en webbapplikation anpassas p˚a ett s˚adant s¨att att ¨overg˚angen fr˚an ett Exceldokument till tabeller p˚a en hemsida inte blir speciellt komplicerad.
5.1 Databas
Anledningen till att anv¨anda en inb¨addad databas var f¨or att en s˚adan l¨osning skulle underl¨atta f¨or kommunen d˚a en installation av webbapplikationen g¨or att de endast beh¨over installera och konfigurera Tomcat-server.
Anledningen till att just Hsqldb valdes som databas berodde p˚a att OpenOffice anv¨ander den databasen och eftersom dem g¨or det finns det anledning att tro att den ¨ar tillr¨ackligt testad och stabil. Det finns m˚anga andra inb¨addade databaser, varav de antagligen mest k¨anda ¨ar SQLite och InnoDB fr˚an Oracle, men valet f¨oll p˚a Hsqldb.
5.2 Problematik kring kontrollager
F¨or att undvika en situation d¨ar kontrollagerinspekt¨oren och objektets vanliga inspekt¨or planerar in en inspektion under samma tid, en krock av inspektioner, har inspekt¨orerna ett m¨ote varje vecka d¨ar de g˚ar igenom sin planering f¨or att se att ingen krock hos objekt uppkommer.
D˚a detta var ett problem som fanns med fr˚an b¨orjan av arbetet och det visade sig att problemet berodde p˚a inspekt¨orernas arbetss¨att, gjordes, i samtycke med kontaktpersonen, valet att inte l¨osa detta problem i webbapplikationen. Detta p˚a grund av att den enklaste l¨osningen f¨or inspekt¨orerna ¨ar att ist¨allet f¨or att en inspekt¨or endast ska arbeta med objekts kontrollager, l˚ata denna inspekt¨or ta ¨over ett antal egna objekt och arbeta med objektets ˚arliga timmar samt dess kontrollager ist¨allet. Detta skulle d˚a g¨ora att varje inspekt¨or f˚ar f¨arre objekt att inspektera men ist¨allet ¨aven r¨akna med inspektioner f¨or att jobba bort timmar p˚a kontrollagret hos objekten.
Det valdes allts˚a bort p˚a grund av att en f¨or¨andring av uppdelningen av objekt skulle l¨osa problemet p˚a ett b¨attre s¨att ¨an webbapplikationen skulle kunnat gjort. Funktionen f¨or att l¨agga till en inspekt¨or som kontrollagerinspekt¨or finns dock kvar, eftersom det f¨orhoppningsvis kan underl¨atta planeringen i alla fall.
5.3 Omfattningen av Excel
Fr˚agan som skickades ut till de organisationerna, vilka stod med i medlemsregistret hos Milj¨oRedas anv¨andarf¨orening, visade att Excel anv¨ands i en st¨orre utstr¨ackning till uppgifter vilket det inte ¨ar helt anpassat till. Exceldokument anv¨andes av en betydande andel till att samla information f¨or att ˚astadkomma en ¨overblick ¨over till exempel planering och verksamhetsinformation. En ¨overblick, vilket programmet de arbetar med egentligen skall klara av att visa, ist¨allet f¨or att ett komplement skall beh¨ova anv¨andas f¨or att arbetet skall g˚a att utf¨ora p˚a ett bra s¨att. D˚a Excel ¨ar ett program f¨or att ber¨akna och analysera data, ett s˚a kallat kalkylbladsprogram, ¨ar anv¨andandet av Excel f¨or planering och verksamhetsinformation en indikation p˚a att programmet inte anv¨ands till den tillt¨ankta uppgiften.
D˚a svaren visar att en s˚a pass stor andel av organisationerna beh¨over ett kompletterande program f¨or att utf¨ora sitt dagliga arbete, ¨ar det en indikation p˚a att ett nytt system beh¨ovs, d¨ar funktionerna ¨ar verksamhetsanpassade. Ett system vilket uppfyller och effektiviserar arbetet.
5.4 Enk¨atunders¨okning
Enk¨aten som skickades ut till inspekt¨orerna var fr˚an b¨orjan t¨ankt att bara best˚a av ¨oppna fr˚agor f¨or att f˚a mer utf¨orliga svar fr˚an dem om deras tankar kring nuvarande arbetssystemet, d˚a vi endast haft kontakt med en inspekt¨or.
D˚a vi tidigt i arbetet informerades om att de andra inspekt¨orerna valt att inte l¨agga n˚agon tid f¨or att st¨odja v˚art arbete, p˚a grund av dess redan r˚adande tidsbrist med inspektioner, t¨ankte vi om g¨allande enk¨aten. Av den anledningen valde vi att ist¨allet anv¨anda oss av ett antal mer st¨angda fr˚agor samt tre ¨oppna fr˚agor i slutet av enk¨aten f¨or att den inte skulle ta lika l˚ang tid f¨or inspekt¨orerna att genomf¨ora och d¨arav en st¨orre chans p˚a en h¨og svarsfrekvens.
De st¨angda fr˚agorna utformades med ett j¨amnt antal svarsalternativ. Detta f¨or att undvika att den svarande v¨aljer mittenalternativet i en fr˚aga d¨ar de inte k¨anner sig s¨aker p˚a svaret.
