Teknik och samhälleDatavetenskap

Examensarbete15 högskolepoäng, grundnivå

Att skapa statiska länkar från dynamiskt JSP-innehåll

The generation of static links from dynamic JSP content

Monika Memedova

Examen: Kandidatexamen 180 hpHuvudämne: InformationssystemProgram: TELMahDatum för slutseminarium: 2012-09-20

Handledare: Kristian EkbergExaminator: Bengt J. Nilsson

Resumé

Hur dynamiska länkar skapas och fungerar är inget man dagligen går runt och funderarpå. När internet låg i sin linda var hemsidors innehåll statiska och länkarna hårdkodade iHTML. Detta fungerade bra men med tiden ökas behovet för avancerad hemsidefunktio-nalitet i snabb takt då applikationer blir webbaserade. Många hemsidor har gått till att blidynamiska och innehållet kan förändras beroende på besökare och vad de utför på hem-sidorna. Detta kräver att funktionalitet för länkgenerering skapas, länkarna kan därmedskapas dynamiskt under drift och parametrar kan skickas mellan sidor för bearbetning. Idetta arbete har författaren fått i uppgift av Hewlett-Packard att ta fram en lösning för attskapa statiska länkar utifrån dynamiskt JSP-innehåll i en webbapplikation som används iett Intranät.

Arbetet börjar med att samla in de krav som ställs på nya funktionaliteten. Kravenanalyseras och vattenfallsmetoden väljs ut som den metod att följa under utvecklings-projektet. Den utveckling som gjordes testas först med hjälp av integrationstestning. Närutvecklingen anses vara klar utförs ett användaracceptanstest UAT (User Acceptance Test)med hjälp av två slutanvändare från SKF. Resultatet av UAT är lyckat och funktionali-teten för att skapa statiska länkar från de dynamiska länkarna i webbapplikationen finnsenligt kravspecifikationen.

Mitt uppriktiga tack till:Mentor/Handledare: Kristian Ekberg, Malmö Högskola, SverigeMentor/Handledare: Göran Pettersson, Hewlett-Packard, SverigeMentor: Göran Hagert, Malmö Högskola, SverigeExaminator: Bengt J Nilsson, Malmö Högskola, Sverige

Abstract

How dynamic links are created and how they work is not something that one daily thinksabout. When internet was in its infancy web content was static and the links were hardco-ded in HTML. This worked fine, but as time went on the need for advanced web sitefunctionality grew at a rapid pace as applications become web-based. Many web sites havebecome dynamic and the content can change depending on the visitors and how they inte-ract with the sites. This calls for the creation of link generation functionality, the links canthen be created dynamically during run-time and parameters can be sent between pages forprocessing. In this thesis, the author was given the task from Hewlett-Packard to developa solution that creates static links from dynamic JSP content in a web application that isused within an Intranet.

This work begins with the gathering of requirements for the new functionality. Therequirements are analyzed, and the waterfall method is chosen as the method to followduring the development project. During the development, integration testing is carriedout. After completion, a User Acceptance Test UAT is carried out with the help of twoend-users from SKF. The result from the UAT is successful and the functionality to createstatic links from the dynamic links in the web application is in accordance with the requi-rement specification.

My sincere thanks to:Mentor: Kristian Ekberg, Malmö University, SwedenMentor: Göran Pettersson, Hewlett-Packard, SwedenMentor: Göran Hagert, Malmö University, SwedenExaminer: Bengt J Nilsson, Malmö University, Sweden

Innehåll

Ordlista 1

1 Inledning 21.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Målgrupp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Teori 52.1 Teknologier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.3 Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.4 JavaServer Pages - JSP . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.5 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.6 Databasen Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.7 Länkar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Systemutvecklingsprocesser . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Vattenfallsmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Spiralmodellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.3 Inkrementell bygg och testmetod . . . . . . . . . . . . . . . . . . . . 112.2.4 Den evolutionära leveransmodellen . . . . . . . . . . . . . . . . . . . 12

2.3 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1 Modultest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.2 Integrationstestning . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.3 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.4 Acceptanstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Metod 153.1 Vetenskapligt perspektiv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2 Forskningsstrategi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3 Konstruktiv studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4 Metodval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.4.1 Vetenskaplig metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.2 Val av utvecklingsprocess . . . . . . . . . . . . . . . . . . . . . . . . 18

3.5 Insamlingsmetoder av teori och empiri . . . . . . . . . . . . . . . . . . . . . 203.6 Analysmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.7 Förväntningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.8 Tekniska förutsättningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 Genomförande 224.1 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3.1 Summering av implementationen . . . . . . . . . . . . . . . . . . . . 294.4 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.1 Testmiljö . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.2 Testmetod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.3 Integrationstestning . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4.4 Systemtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.5 Granskningar inför UAT . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.6 Testpersoner för UAT . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4.7 Testfall för UAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Resultat 345.1 Programvaran och den tekniska lösningen . . . . . . . . . . . . . . . . . . . 345.2 Kvalitet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3 Organisationens behov . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.4 Arbetets genomförande . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Analys 35

7 Diskussion 367.1 Metodkritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367.2 Källkritik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377.3 Slutsats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8 Förslag till framtida forskning 39

9 Referenser 40

Ordlista

HP: Förkortning för Hewlett-Packard [16] som räknas till ett av världens största IT-bolag. De tillverkar och utvecklar skrivare, datorer, servrar samt sköter drift, utvecklingoch underhåll av applikationer.

IDE: Utvecklingsmiljö som används inom programmering som står för “Integrateddevelopment environment” [25]. Den är vanligtvis grafisk med menyer och körs som enapplikation. Vanliga IDE för Java-utveckling är Eclipse [10], Netbeans och JBuilder.

JDBC: För att koppla ihop en Java-applikation med en databas används vanligtvisett ramverk som heter JDBC (Java Database Connectivity) [33] som innehåller metoderför att manipulera databaser genom Java-applikationer.

PLM: Product Lifecycle Management förkortat PLM [1] är en process för att sköta enprodukts hela livscykel. Från idé, design, utveckling, implementation, underhåll och slut-ligen när produkten nått slutet av sin livscykel. PLM kan användas inom olika områden,t.ex. industri eller inom IT.

SFTP: Teknik för filöverföring över internet och förkortningen står för “Secret FileTransfer Protocol” [42]. Jämfört med filöverföringstekniken FTP “File Transfer Protocol”är SFTP säkrare då överföringen sker med hjälp utav kryptering.

SKF: En av världens ledande tillverkare av lager och tillhörande produkter är SKF[40] som tidigare hette Svenska kullagerfabriken.

SQL: Structured Query Language vilket förkortas SQL är ett språk som används föratt hämta och manipulera data i en relationsdatabas.

Tolerans: En tolerans berättar hur mycket ett mått får avvika från det angivna värdet,t.ex. innerdiametern är satt till 10mm och toleransen är ±0.1. Det innebär att det ärgodtagbart med en innerdiameter på lägst 9.9mm samt högst 10.1mm.

1

1 Inledning

När webbplatser används är det lätt att inte tänka på hur sådana fungerar, men i grundenfinns det mycket arbete och teknik som ligger bakom för att få dem att fungera. Applika-tioner som är åtkomliga genom webbläsare kallas för webbapplikationer [46] och fler skaffarenheter som datorer och smarta telefoner med internetuppkoppling. Enligt Boda m.fl. [9]beräknas 50 miljarder enheter vara uppkopplade år 2020 och detta medför ett ökat behovav avancerade webbplatser och webbapplikationer.

Webbapplikationer används även inom företag då klientinstallationer och konfiguratio-ner inte behövs, vilket förenklar administrationen. Nya funktioner kan läggas till genomvidareutveckling och implementation sker genom driftsättning på en server. Genom dettafår alla användare tillgång till den senaste versionen av webbapplikationen utan att be-höva göra något. Vi kommer i detta examensarbete att vidareutveckla och driftsätta enwebbapplikation åt HP.

1.1 Bakgrund

Hewlett-Packard har ett IT-kontrakt med SKF och utvecklar samt sköter driften av mångasystem hos SKF. Ett sådant system är Toleransdatabasen, som innehåller toleranser för la-ger och andra produkter som företaget tillverkar. Genom Toleransdatabasen kan ingenjörerhämta, redigera och ta bort toleranser. Toleransdatabasen lagrar och hämtar informationi en Oracle-relationsdatabas [32] samt i ett tredje-partssystem kallat Windchill [36]. Självaapplikationen är en webbapplikation som körs genom en webbläsare. Toleransdatabasenär en Java EE-applikation [24] och är således skriven i JSP (Java Server Pages), Java,Javascript och HTML. Den är skapad av HP och det finns ingen tredjepartsleverantör attkontakta för att få hjälp med utvecklingen.

Dagens version av Toleransdatabasen saknar möjlighet att skapa statiska HTML-länkartill tabeller som visar filtrerad toleransdata. Detta medför att användare inte har någotsätt att enkelt kunna dela med sig av dessa tabeller. Användarna får förlita sig på att angehela sökförloppet i Toleransdatabasen, som att välja ut enstaka toleranser och inom vilkamått som är intressanta för stunden vilket medför risk för felinmatning samt att dennaprocess är tidsödande för användarna.

Att lägga till funktionalitet för att kunna skapa statiska länkar från dynamiskt JSP-innehåll kommer att ge användarna ett enkelt sätt att dela med sig av toleranstabeller ochäven spara ner länkarna för att snabbt återkomma till intressanta toleranstabeller. Uttryc-ket statiska länkar kommer att användas i uppsatsen för att beskriva länkar som pekar påett statiskt innehåll lagrat i en databas, och uttrycket kommer från den problembeskriv-ning som erhållits. Den potentiella lösningen på detta problem med länkhantering inomJSP är intressant då tidigare forskning inom detta område saknas.

2

1.2 Problemformulering

Företaget SKF använder Toleransdatabasen som är ett system för att registrera informa-tion om toleranser hos olika produkter som företaget tillverkar. Problemet som uppståttär att det finns en annan äldre lösning för att hämta toleransinformation hos SKF. Dennalösning består av statiska länkar till fakta om de olika toleranserna presenterad i tabellformoch kan liknas vid att titta i ett textdokument. Detta kräver att någon manuellt sitter ochuppdaterar information och länkning vilket är väldigt tidsödande samt kan leda till attfelaktig information presenteras.

Nuvarande version av Toleransdatabasen bygger upp tabellerna med toleransinforma-tion dynamiskt genom ett HTML-formulär som sedan skickar vidare informationen till enJSP-sida som bygger upp tabellen. Detta sker dolt i bakgrunden och för att kunna göra enstatisk länk av detta måste en lösning hittas för att spara den information som krävs förtabellens uppbyggnad.

SKF vill därför att Toleransdatabasen får funktionalitet för att kunna generera statis-ka länkar till tabeller med toleransdata och har därför gett detta i uppdrag till HewlettPackard (HP) som sköter utveckling, drift och underhåll utav Toleransdatabasen. GenomHP har författaren till detta arbete fått i uppdrag att ta fram en lösning för detta problem.

Användarna skall även kunna använda filtrering för att bara visa den toleransinfor-mation som de är intresserade av och detta skall även tas i beaktning när länkarna skallskapas. Länkarna skall bara genereras när användarna vill genom att en knapp skapas fördetta ändamål. När användaren trycker på knappen skall den information som behövs föratt senare kunna visa samma tabell sparas i en ny tabell i databasen tillsammans med ettunikt 64-bits hash ID. Om en användare försöker att spara en likadan filtrerad toleransta-bell skall ett felmeddelande visas. När länken genererats och sparats i databasen skall ettmeddelande visas och det finns önskemål att länken automatiskt skall sparas i klippboken.

Ett annat problem som uppstår i samband med den nya funktionaliteten är att Tole-ransdatabasen kräver inloggning för att autentisera användarna. Om en statisk länk klickaspå skall även lösningen innehålla stöd för att autentisera användarna för att kunna visa defiltrerade toleranstabellerna.

För att summera problemet rent tekniskt, sökningen som får fram toleranstabellen görsmed hjälp av ett HTML formulär och värdena från formuläret är dolda som element.

Värdena som skickas måste inhämtas och behandlas samt sparas i en databas. Därefterskall en länk visas och funktionalitet behöver implementeras för att hantera den sparadeinformationen och kunna presentera en toleranstabell.

3

1.3 Frågeställning

Målet med uppsatsen är att ta fram en fungerande lösning på problemet med det dynamiskaJSP-innehållet och statiska länkar åt HP och SKF, samt att utreda vilken forskningsme-todik som är bäst lämpad för ändamålet. De frågor som skall besvaras i denna uppsats ärdärför följande:

• Finns det något sätt att generera statiska länkar från dynamiskt JSP-innehåll?

• Vilken systemvetenskaplig utvecklingsprocess är bäst lämpad att använda sig av föratt komma fram till en fungerande lösning?

1.4 Syfte

Syftet med arbetet är att se om det går att ta fram en teknisk lösning för att göra omdynamiskt innehåll till något som kan hanteras genom statiska länkar i en befintlig webbap-plikation skriven i JSP. Valet av utvecklingsprocess att använda sig av under framtagandetav lösningen kommer att ha stor inverkan på om en lösning kommer att bli framtagen itid. Detta då det finns en tidsgräns på 5 månader och utvecklingsprocessen styr hur förfat-taren kommer att arbeta under arbetet med lösningen på problemet med det dynamiskainnehållet. Lösningen måste uppfylla de krav som SKF ställt, länkarna skall gå till en sidasom visar toleransinformation presenterad i tabellform. Kraven på den nya funktionalitetenhar tagits fram av SKF och överlämnats till HP som sedan gett dem till författaren. Efterkravanalys kommer olika utvecklingsprocesser att ställas mot varandra för att välja ut eneller flera som kommer att användas under utvecklingsarbetet. Ambitionen är att HP ochSKF skall använda den nya versionen av Toleransdatabasen i produktionsmiljö.

1.5 Målgrupp

Studien är riktad mot dem som är intresserade av webbutveckling, speciellt dynamiskawebbplatser och webbapplikationer. Särskilt intressant är studien för dem som står införproblematiken att kunna göra om dynamiskt innehåll till innehåll som kan tas fram genomstatiska länkar.

Målgruppen är således personer som är utvecklare inom området webbutveckling.

4

1.6 Avgränsningar

”Avgränsningar anger gränserna för vad man gör anspråk på att kunna uttalasig om.” Lindgren [7]

HP kräver att tystnadsavtal ingås innan examensarbete kan starta, detta gör att even-tuell programkod inte får presenteras. Det innebär att presentationen avgränsas till attförklara i text hur lösningen tagits fram.

Då Toleransdatabasen är en Java EE webbapplikation kommer en lösning tas fram sompassar applikationer baserade på den plattformen.

Tidsaspekten är också en viktig begränsning att ta upp. Detta utvecklingsprojekt fickterminen ut på sig att bli slutfört, 5 månader för att forska, analysera, utveckla, testa samtdriftsätta. Om andra avgränsningar framkommer kan det leda till att andra forskningsme-toder eller områden kan bli aktuella. Avsnitt 8 tar upp förslag till framtida forskning.

2 Teori

För att kunna förstå frågeställningen med tillhörande teknologier förklaras det teoretiskaunderlaget i detta kapitel. Studiens forskningsområde är inom datavetenskapen. Detta be-ror på problematiken som skall lösas och därför tillhör de teorier som presenteras i dettakapitel till det datavetenskapliga ämnet.

För att få en god förståelse över hur studien genomförts, samt vilka tekniker och deprocesser som använts under utvecklingen bör detta kapitel studeras.

2.1 Teknologier

I arbetet behandlas flera olika teknologier som används under mjukvaruutveckling. De olikateknologierna förklaras i styckena som följer.

2.1.1 .NET

.NET [26] är ett ramverk tänkt att hjälpa programmerare att skapa applikationer ochwebbtjänster för olika plattformar. Det innehåller APIer som är gemensamma för allaplattformar. Företaget som står bakom .NET är Microsoft. Även om .NET kan användas påmånga olika plattformar, så som i smarta telefoner, datorer och på webbservrar, är kravetatt det är en Microsoft-plattform som körs [26]. Utvecklingsmiljön heter Visual Studio [27]och kommer i olika versioner, från den enklare gratisversionen som heter Express till dendyraste utgåvan med namnet Ultimate som innehåller full funktionalitet.

2.1.2 Java

Java är ett objektorienterat programmeringsspråk som hämtat mycket av sin syntax ifrånprogrammeringsspråken C och C++. Applikationer skrivna i Java [29] kan köras på de

5

flesta plattformar och operativsystem. Detta då javaapplikationer exekveras genom en såkallad Virtuell maskin som följer med flera operativsystem och kan laddas ner och installe-ras på många andra. Namnet virtuell maskin kommer sig av att java-koden inte kompilerastill maskinkod utan till bytekod som sedan tolkas av den virtuella maskinen som även kanliknas vid en virtuell dator som kan exekvera bytekoden som om den vore maskinkod.

2.1.3 Java EE

Java Platform, Enterprise Edition [24] förkortat Java EE [31], är en plattform som användsför att utveckla och exekvera applikationer tänkta att användas i företagsmiljöer.Java EE innehåller ett API, Application Programming Interface, som är ett gränssnitt somanvänds för kommunikation mellan olika komponenter, i Java kallat paket. Paketen inne-håller färdiga metoder som kan användas när kod skrivs.

Flera alternativ finns till Java EE, .NET [26] och PHP [35] är andra teknologier förwebbapplikationer. Alla har sina styrkor och svagheter. Joseph Williams [14] anser att enav de största fördelarna Java EE har mot .NET är att Java EE är plattformsoberoen-de. .NET webbapplikationer måste köras på Microsoft-servrar. Det finns lösningar somMono [28] som är tänkta att lösa detta och låta .NET applikationer kunna exekveras påandra plattformar men i dagsläget kommer Mono inte åt alla .NETs APIer vilket gör attmånga applikationer inte fungerar. Gerry Miller [14] menar .NET har flera fördelar motJava EE, mindre kod behöver vanligtvis skrivas mot samma funktionalitet i Java EE, ut-vecklingsmiljön Visual Studio [27] anses vara den bästa utvecklingsmiljön på marknadenoch applikationerna exekveras snabbare. Teknologin PHP är skriptbaserad och helt fri attanvända men som enligt Meloni och Telles [19] menar ofta får kritik för att inte passa in iföretagsmiljöer då den inte är objektorienterad. Åsikterna om teknologierna går vanligtvisisär och vilken som passar ens behov bäst går inte att svara på utan att först göra en analysav ens behov, budget och tidigare kunskap inom områdena.

2.1.4 JavaServer Pages - JSP

En webbapplikation som använder sig av Java består av JavaServer Pages vilket är filersom har filändelsen .jsp och som består av HTML-kod med inbäddad Java-kod. JSP web-bapplikationer kan även använda sig av externa Java-klassfiler som kallas för servlets.

För att hantera en sådan webbapplikation behövs en server samt servlet/JSP-motorsom kompilerar och levererar innehållet till besökarnas webbläsare [20]. Ett exempel på ensådan servlet/JSP-motor är Apache Tomcat [44].

2.1.5 JavaScript

JavaScript är ett objektbaserat scriptspråk som inte har något samröre med Java. Ävenom syntaxen är väldigt lik den man finner i Java är de inte kompatibla enligt Joel Murrachoch Andrea Steelman [31]. JavaScript är ett standardspråk som hjälper utvecklare attskapa dynamiska webbplatser och koden exekveras i användarnas webbläsare. Kod som

6

skall exekveras vid händelser som knapptryckningar placeras i så kallade funktioner somkan liknas vid Javas metoder.

2.1.6 Databasen Oracle

Inom företagsvärlden är ett skäl till att relationsdatabasen Oracle används att den stödjerpartitionering av stora datatabeller. Oracle har också stöd för kluster vilket innebär attflera databasservrar kan kopplas ihop för att utnyttja datahanteringskraften på ett mereffektivt sätt. Genom klustret kan databasservrarna använda sig av alla processorer ochprocessorkärnor samtidigt [32].

2.1.7 Länkar

För att förenkla navigering och publicering på internet används hyperlänkar. Länkar gör såatt besökare på en webbplats kan klicka sig vidare för att t.ex. komma till en annan webb-sida, webbplats eller för att anpassa innehåll och utseende på det som visas. Det vanligaförfarandet på webben har varit länkar som är skrivna och hårdkodade i HTML-koden,dessa kallas för statiska länkar [18] [17].

Nedanstående exempel visar en statisk länk.

<a href=“newpage.html”>New page</a>

Motsatsen till en statisk länk är en dynamisk länk. Dessa länkar byggs upp genomanrop till en dynamisk sida (t.ex. JSP eller PHP) och kan följas efteråt av parametrar medtillhörande värde.Parametrarna behandlas sedan i sidan, antingen direkt eller skickas vidare till t.ex. en Ja-vaScript eller en Java-metod [18] [17].

Nedan följer ett exempel på en dynamisk JSP-länk till sidan process.jsp med variabelnfoo som har värdet test.

<a href=“process.jsp?foo=test”>Process</a>

Dynamiska länkar kan även skapas genom att värden skickas från HTML-formulär [8].Genom detta förfarande kan värden som skickas från användarna döljas. En programmatisklösning för att få ut och spara de värden som är intressanta är att begära värdet från de pa-rametrarna och spara värdena i strängar genom t.ex. Java metoden request.getParameter()som finns i Java APIet javax.servlet [30].

2.2 Systemutvecklingsprocesser

Då denna studie har som syfte att besvara om det går att ändra dynamiskt JSP-innehålltill statiska länkar i en befintlig webbapplikation blir inriktningen systemvetenskaplig ochbesvaras med programvaruutveckling. I samband med detta behöver ytterligare en frågabesvaras, vilken systemutvecklingsprocess är bäst lämpad att använda sig av för att ta

7

fram lösningen?

Flera processer existerar för att underlätta programvaruutveckling. Vissa är mer linjä-ra och tillåter inte avsteg ifrån kravspecifikationen under utveckling medan andra är merflexibla och är utvecklade för att ge möjlighet att justera utvecklingen när nya krav upp-kommer.

Nedan presenteras flera olika arbetssätt som är vanliga inom mjukvaruutveckling. Pro-cesserna diskuteras för att senare välja ut någon/några modeller som passar att använda sigav under utvecklingsprojektet med att ta fram en lösning på problemet med det dynamiskaJSP-innehållet.

2.2.1 Vattenfallsmodellen

Enligt Khalifa och Verner [23] passar denna modell in på linjära utvecklingsprojekt därkraven är väl specificerade och där utrymme saknas för ytterliggare krav efter projektstart.Modellen kallas för vattenfallsmodellen då den är sekventiell. Detta inebär att den delasin i olika faser även kallade steg, och de olika faserna brukar visas i form av ett vattenfallmed flödet som går nedåt.

Figur 1: Vattenfallsmodellens olika steg enligt De Hoog m.fl. [37].

De Hoog m.fl. [37] anser i artikeln Constraint-Driven Software Design: An Escape Fromthe Waterfall Modell att de olika stegen som vanligtvis används i vattenfallsmodellen börjarmed steget krav, i vilket kraven fastställs och dessa gås igenom tillsammans med uppdrags-givaren. Därefter analyseras kravspecifikationen och designen av mjukvaran skapas.

8

Efterföljande steg är utveckling, testning och driftsättning av den nya mjukvaran samtdokumentation.

I den första fasen är det bra att föra en dialog med kunden för att reda ut frågeteckenom sådana finns samt att se till att vara helt säker på att de krav som lämnats är de somkunden vill ha.

Under designfasen skapas den design som kan tänkas behövas inför programmeringen, iform av modeller och diagram. Under implementationsfasen sker själva programmeringenoch skapandet av eventuella databaser, detta testas sedan av kund under testningsfasenför att verifiera att kraven har uppfyllts på ett bra sätt. Om något inte stämmer ses de-signfasen över igen eller om felet är mindre blir det att gå till implementationsfasen förvidare förbättring.

Slutligen när alla krav har uppfyllts, testats och accepterats av kund blir driftsättnings-fasen nästa instans. Den nya mjukvaran skickas ut till kund, eller, som med webbutvecklinginstalleras den nya versionen på en applikationsserver. Den sista fasen efter driftsättningblir dokumentering då det antecknas hur och vad som skiljer sig mot den tidigare versionensamt skapandet av en enkel användarmanual.

Fördelen med att använda sig av denna modell för utveckling är att den har en enkelstruktur att följa, varje steg skall avslutas innan nästa påbörjas och när kraven är noggrantspecificerade kan arbete läggas ner på att analysera kravspecifikationen för att ha en bragrund till vidare utveckling.

9

Flera nackdelar finns med denna modell. Det synbara resultatet för kunden dröjer tillsimplementationsfasen är färdig för test och kunden kan inte komma med kravändringar närarbetet har startat. Om kunden kommer med ändringar behöver den första fasen startasom igen, vilket leder till tidsspill.

2.2.2 Spiralmodellen

Boehm [3] har med ett citat från en kund i sin artikel A Spiral Model of Software Deve-lopment and Enhancement som har funnits i tankarna under arbetets gång:

“I can’t tell you what I want, but I’ll know it when I see it.”

Om en kund uttrycker sig på liknande sätt blir det svårt att använda sig av vattenfalls-modellen då kraven inte blir tillräckligt specificerade under projektets start.

En av de första som försöker råda bot på vattenfallsmodellens nackdelar är Boehm [3]med spiralmodellen som han är upphovsman till. Boehm anser att det som skiljer model-len från andra är att den har ett riskstyrt tillvägagångssätt som mjukvaruprocess, jämförtmed vattenfallsmetodens mycket dokumentstyrda handlingssätt. Syftet med modellen, en-ligt Boehm, är att ta tillvara på styrkor och fördelar med andra modeller och metoder samtatt lösa många av de problem som finns hos dem.

Figur 2: Boehms spiralmodell enligt de Hoog m.fl. [37]

10

Till skillnad mot vattenfallsmodellen är spiralmodellen iterativ. De flesta steg som finnsi vattenfallsmodellen genomförs men istället för att beta av alla krav på en gång väljs etteller några krav ut som för analys, design, implementering och testning för att sedan börjamed nästa krav (se figur 2). Detta löper på i något som kan liknas en spiral och däravnamnet.

Denna modell möjliggör att kunden kan lägga till eller ändra i krav under utvecklingensgång då bara ett fåtal krav arbetas med åt gången.

Enligt de Hoog m.fl. [37] genomförs en riskanalys som det första steget. Riskanalysenligger till grund för att välja ut de delar av utvecklingen som har högst risk först vilketgör att den del av utvecklingen som har minst inverkan på projektet utförs sist. Dettaför att minimera risken att de mer komplicerade delarna inte drar ut på tiden i slutet avutvecklingen eller att de har negativ inverkan på andra delar. Att upptäcka detta i slutetnär tid eller budget är liten kan riskera hela projektet.

Valet av utvecklingsordning efter riskanalysen sker i design- och planeringssteget. Dettredje steget är det steg i vilket utvecklingen sker. Efter utvecklingen går man igenomvad som gjorts och kommit fram till i tidigare stege. Allt skall vara slutfört innan manbörjar ett nytt varv i spiralen. Skall en stor och komplex grafisk applikation utvecklas ochden dokumentstyrda vattenfallsmodellen följs, kan det få stora konsekvenser om det undertestningen visar sig att gränssnittet är förvirrande eller om funktioner inte är logiska enligtanvändarna. Enligt de Hoog m.fl. [37] visar sig den iterativa spiralmodellen vara väldigtanvändbar då test av en tidig version av gränssnittet sker tidigt, och möjlighet ges att fortgöra ändringar vilket leder till att onödig kod utvecklas.

2.2.3 Inkrementell bygg och testmetod

En annan utvecklingsmetod är den inkrementella bygg och testmetoden [11]. I den delas ut-vecklingsprojektets alla delar in i olika inkrement. Varje inkrement innehåller en funktionelldel av koden, krav, designdokumentation, testdokumentation och användardokumentation.

Den inkrementella bygg och testmetodens tre första steg liknar vattenfallsmetodens:kravspecifikation, systemdesign och detaljerad design. Kodning och testning räknas somett steg samt även integration och testning. Stegen liknas av Graham [11] som block och detvå sista blocken delas in i flera mindre inkrement. En liten del av programkoden arbetasmed och testas. När det inkrementet är klart, integreras och testas den nya programvaru-koden. Nästa steg är att återvända till programmerings- och testningsblocket. En annanmindre del av programvarukoden arbetas med och på så vis itereras det om och om igentills all kod är integrerad samt testad.

11

Figur 3: De olika stegen som ingår den inkrementella utvecklingsmetoden enligt Graham[11].

Den första iterationen skall avslutas med en funktionell kod för användarna att tes-ta. Enligt Graham [11] behöver koden inte ha mycket funktionalitet men bör ändå varatillräcklig för att ge nytta åt användarna.

2.2.4 Den evolutionära leveransmodellen

Graham [11] anser att den evolutionära leveransmodellen är den mest extrema formen avinkrementell utveckling och leverans då den itererar genom varje steg från början till slutinnan nästa påbörjas. Detta skiljer sig från t.ex. den inkrementella bygg och testmetodensom bara itererar igenom de två sista stegen.

I figur 4 visas hur kravspecifikationen, systemdesign och detaljerad design skapas ochanalyseras samt programmeras, testas och integreras för varje iteration. Enligt Graham[11] skall det som ger mest nytta att färdigställa väljas ut och i nästa iteration tas det nästbästa och så vidare. Det handlar om att prioritera det som är bäst för stunden, beställarenhar mycket att säga till om när det kommer till detta.

12

Figur 4: Flödet i den evolutionära leveransmodellen enligt Graham [11].

För att få påbörja nästa iteration behöver kod finnas med ny funktionalitet för använ-darna att kunna testa. Koden skall vara dokumenterad samt tränings- samt användarma-nualer skall medfölja innan leveransen anses vara färdig.

2.3 Test

När ett system utvecklas måste det säkerställas att det fungerar som det var tänkt genomtestning.Test av mjukvara delas enligt Hou m.fl. [48] in i tre faser:

1. Modultest

2. Integrationstest

3. Systemtest

13

2.3.1 Modultest

Hou m.fl. [48] menar att en applikation vanligtvis är uppdelad i delar kallade moduler.Med hjälp av den uppdelningen kan test utföras på varje modul och testen är oberoendeav de andra modulerna. Om applikationen är mindre, t.ex. om den bara består av en klassfinns ändå en modul att testa, den enda klassen räknas som en modul.

2.3.2 Integrationstestning

För att lyckas med ett bra resultat krävs en hel del testande. Under utvecklingens gångkallar Leung och Wong [15] i artikeln “A study of user acceptance tests” detta för “integ-rationstestning” då man testar utvald funktionalitet men inte gör ett komplett systemtest.

2.3.3 Systemtest

Enligt Jorgensen och Erickson [6] är ett systemtest ett test som utförs på en produk-tionsplattform. Systemtest kan inte utföras i en utvecklingsmiljö. Detta då Jorgensen ochErickson [6] anser att in- och utdata skall vara exakt samma som för slutanvändarna ochde kommer använda sig av systemet på produktionsplattformen.

2.3.4 Acceptanstest

Om bara de som sköter utvecklingen är de som testar mjukvaran finns en stor risk attkunderna kan bli missnöjda eftersom utvecklarna inte alltid har samma tycke och smaksom de som skall använda mjukvaran i sitt dagliga arbete. Det är således viktigt att någraslutanvändare tillåts att testa Toleransdatabasen innan den läggs upp på produktionsmil-jön. Det bästa är att använda sig av liknande miljö som använts under systemtestet.

Ett sådant test kallar Leung och Wong [15] för ett User Acceptance Test, förkortatUAT. Enligt dem genomförs detta UAT när applikationsutvecklingen är i sitt slutskede.Ett lyckat UAT leder till att Toleransdatabasen är redo att sättas i produktion.

Leung och Wong [15] anser att testkriterier som kan uppfyllas måste finnas inför ettUAT. Dessa baseras till stor del av de krav som finns i kravspecifikationen. Till testkri-terierna finns en acceptansnivå som är att de krav som finns uppsatta blir uppfyllda ochatt funktionaliteten blir accepterad. Om något kriterie inte uppfyllts ses felen över alter-nativt analyseras varför testpersonen anser att kravet inte uppfyllts. Efter diskussionen ärdet tillbaka till utvecklingsfasen som gäller och där rättas det som inte blev godkänt. Närgenomfört integrationstest och ett godkänt resultat erhållits kallas testdeltagarna till ettnytt UAT som förhoppningsvis får ett bättre resultat.

14

I det beställningskontrakt som SKF och HP godkänt finns det antecknat att UAT skallgenomföras vid projektets slut. Ett godkänt UAT är förutsättningen för att projektet skallklassas som slutfört. Att ha med UAT i kontrakt mellan beställare och de som skall utföraarbetet är vanligt i utvecklingsprojekt.

3 Metod

Enligt Terminologicentrum är en metod:

"ett formaliserat sätt att utföra en viss aktivitet eller ett visst arbete och denbygger på utprovning och upprepning"[47]

I detta kapitel förklaras de vetenskapliga metoder som kommer att tillämpas.

3.1 Vetenskapligt perspektiv

Denna studie kommer att bedrivas med ett hermeneutiskt förhållningssätt. Patel och Da-vidson [4] förklarar hermeneutiken med att de forskare som använder sig av det veten-skapliga förhållningssättet först ser på helheten av det som är forskningsobjektet i grovadrag för att bilda sig en förståelse av det som skall studeras. Efter detta väljs delar ut somnoggrant gås igenom för att förbättra förståelsen.

Forskningsobjektet är Toleransdatabasen, och för att få en förståelse kring problemati-ken med det dynamiska innehållet och länkhantering måste funktionaliteten i Toleransda-tabasen studeras. När områden hittas som berörs av problemställningen analyseras dessamer noggrant. Forskningsansatsen är således kvalitativ och använder sig av den hermene-utiska metoden.

En annan forskningsansats som är en kvalitativ metod är “Grounded theory” [2] vilkenanvänder sig av intervjuer som metod för att samla in data. Även observationer och doku-ment är metoder som används inom Grounded theory för datainsamling. Att inte kommeratt användas har att göra med att andra teorier som kan vara till hjälp skall undvikas ochforskaren skall vara så öppen som möjligt inför det som kan upptäckas inom det valda om-rådet. Ansatsen är även tänkt att användas för att skapa teorier om människors beteenden.Detta passar inte in på systemvetenskaplig forskning.

Ansatsen för skapandet av en lösning på problemet blir med hjälp av systemutvecklingdå det är en applikation som skall få ny funktionalitet och praktiskt arbete krävs för att fåen fungerande prototyp. Till hjälp under systemutvecklingen finns modeller och metodersom förklarar hur moment skall genomföras.

15

3.2 Forskningsstrategi

Järvinen [34] förklarar konstruktiv forskning som forskning med mål att nå ett slutstadium.Med detta menas att ett objekt som redan existerar men som behöver en lösning för attta sig från det tillstånd objektet befinner sig i som kallas för begynnelsetillståndet. Dettapassar in på denna studie då syftet är att lösa ett problem som finns med ett befintligtobjekt.

Två andra tillstånd finns inom den konstruktiva forskningen, Järvinen [34] kallar dessaför byggprocessen och måltillstånd. Under byggprocessen skapas själva lösningen, i dettafall utvecklingen av Toleransdatabasen. I måltillståndet skall en lösning på problemet hauppnåtts, dock anser Järvinen [34] att det räcker med en fungerande prototyp och inte enfullständig implementation.

Under systemutvecklingen skapas en prototyp av applikationen med den nya länkfunk-tionaliteten som efter godkännande från SKF kommer att bli uppsatt i produktionsmiljö.Prototypen blir därmed omvandlad från prototypstadie till produktionsklar implementa-tion. Den systemvetenskapliga process som kommer att användas under utvecklingen ärvattenfallsmodellen vilken passar in på ett linjärt utvecklingsarbete som avhandlas i dennauppsats.

3.3 Konstruktiv studie

Tillvägagångssättet för studien är ett utvecklingsarbete. En lösning skall skapas för ett pro-blem som existerar i Toleransdatabasen och datainsamlingen sker med hjälp av kvalitativforskning. Patel och Davidson [4] anser att kvalitativt inriktad forskning använder sig avverbala analyser av insamlad data från t.ex. intervjuer. Intervjuer är tänkta att hållas medhandledaren från HP för att få en bra inblick i systemet och dess problem som behöveråtgärdas.

Verktyg under intervjuerna är en dator som har möjlighet att visa upp versionen avToleransdatabasen som behöver åtgärdas för att få statisk länkgenereringsfunktionalitetsamt dess tillhörande databas.

Detta sätt att forska på kallas för en Konstruktiv studie då den innefattar konstruktivforskning för skapandet av lösningen med kvalitativ forskning som hjälp i början underinsamlingen av den initiala datan.

3.4 Metodval

3.4.1 Vetenskaplig metod

Butler [45] anser att den kvalitativa metoden hermeneutik ökar i popularitet som forsk-ningsansats inom området informationssystem. Tanken bakom metoden är att förstå ochtolka det man skall studera för att kunna hjälpa till att sprida informationen vidare. Attanvända sig av den forskningsmetoden för att förstå en webbapplikation och det problem

16

som framkommit passar in bra på den metoden. Den kunskap och förståelse man får understuderandet av applikationen tas med till utvecklingen där man tar hjälp av systemveten-skapen för att skapa lösningen.

Eriksson och Wiedersheim-Paul [22] beskriver att utredningsmetoden används för attlösa bestämda problem eller förändra något, och genomförandet bedrivs vanligtvis i sam-råd med de som blir påverkade av det som utredningen kommer fram till. Syftet med denkonstruktiva studien är att ta fram en lösning på ett bestämt problem, och de berörda par-terna är med under delar av utvecklingsprojektet, vilket leder till att utredningsmetodenär lämplig att använda sig av under studien.

Figur 5: Utredningsmetoden enligt Eriksson och Wiedersheim-Paul [22].

Enligt Eriksson och Wiedersheim-Paul [22] är forskning inte det första som associerastill en utredning men ofta forskas det inom utredningar och forsknings- och utredningsme-tod kan användas som synonymer.

17

Den kvalitativa intervjumetod som kommer att användas är den ostrukturerade in-tervjun. Corbin och Morse [21] beskriver den ostrukturerade intervjun med att den skallgenomföras i en miljö där intervjuobjektet känner sig trygg och lättare delar med sig avinformation. Frågorna är ofta inte helt bestämda innan, vissa frågor finns inom det om-råde man vill ha svar på men under intervjun bestäms frågorna efter de svar som ges avintervjuobjektet.

I avsnitt 2.2 behandlas de olika systemvetenskapliga utvecklingsprocesser som kan passain att användas under systemutvecklingen som utförs under denna studie. Då alla utveck-lingsprocesser har för- och nackdelar ser författaren till den process som kan ge mest nyttamed de förutsättningar som ges i denna studie.

3.4.2 Val av utvecklingsprocess

Spiralmodellen valdes inte då det inte finns ett stort antal krav att uppfylla i utvecklings-projektet. Detta leder till att spiralmodellen ter sig onödig då det behövs fler verifierings-sessioner med kunden vilket tar tid både från utvecklingsteamet och kunden och det ärdet främsta skälet till att denna modell inte används under utvecklingen. Ett annat skäl äratt användargränssnittet redan är godkänt av SKF sedan tidigare och det är väl beprövat iden nuvarande versionen av Toleransdatabasen. Den mesta förändringen sker under skaleti funktionaliteten och inte i användargränssnittet.

Nästa metod som analyserats är den inkrementella bygg och testmetoden. Till störs-ta del är detta en bra metod för utvecklingsprojektet. Krav och design gås igenom baraen gång för att sedan börja med programmeringen. Problemet med denna metod var attbeställaren skall få ta del av varje färdigställd iteration. När det gäller små utvecklingspro-jekt kan detta extra moment innebära att tidsramarna spräcks då felaktig feedback kanmottagas på grund av att det som beställaren får ta del av inte motsvarar det förväntade.Detta kan bero på att i den ena iterationen har en viss funktionalitet lagts till men somsaknar iordningställd grafisk presentation som är tänkt att komma med nästa iteration.På grund av risken med den extra interaktionen mellan utvecklare och beställare kommerdenna metod ej att väljas.

Den evolutionära leveransmetoden blir svår att använda under utvecklingsprojektetpå grund av att efter varje iteration skall kunden få tillgång till funktionell kod, även alldokumentation skall följa med. Med detta menas fullt dokumenterad kod, utbildning ochanvändarmanualer. Även de krav som skall uppfyllas under iterationen skall gås igenom ochfastställs och dessa är redan fastställda innan projektstart. Detta passar inte in tidsmässigtsamt att de olika enskilda delarna av kraven är för små för att användas på detta sätt. Detfullständiga dokumenteringskravet och alla steg per iteration gör att denna metod inte ärpassande för projektet.

18

Vattenfallsmodellen bygger på att välutformade krav som inte får ändras under utveck-lingens gång finns tillgängliga. Projektet delas inte upp i mindre delar som skall presenterasvar för sig för beställaren, istället presenteras det färdigställda resultatet när det anses varaklart. Stegen som följs i vattenfallsmodellen gör det lätt för en ensam utvecklare att arbetadå kraven inte delas upp i mindre delar. Detta passar det projekt som avhandlas i dennastudie vilket skall utföras av endast en utvecklare.

Vattenfallsmodellen har använts vid programvaruutvecklingen av den nya funktionali-teten för Toleransdatabasen. Modellen skall vara ett stöd och finnas till hjälp för att se tillså att projektet utvecklas åt rätt håll. Den används även för att se om den passar in påett utvecklingsprojekt av denna typ och storlek.

Modellen valdes på grund av sin enkelhet, att den är beprövad, och kan användas avenskilda utvecklare. Ett projekt som detta med väl specificerade krav gör det lätt att följade olika stegen som anges i modellen. Khalifa och Verner [23] menar att vattenfallsmodelleninte är lämpad för projekt där krav ofta byts ut eller ändras.

Historiskt har vattenfallsmodellen använts i projekt av varierande storlek men nuförti-den finns det ett flertal andra metoder och modeller som sägs vara till större hjälp samtleder till att projektmålen nås snabbare. På grund av den snäva tidsaspekten på att slutförautvecklingen på 5 månader fanns inte tid att använda olika metoder för utvecklingsarbetet.

Modellen innehåller ett antal systemvetenskapliga metoder som används av författarenunder studien och utvecklingen. Dessa är: kravspecifikation, analys, design och implemen-tation.

Toleransdatabasen kan ses som en applikation under ständig förändring. Den utvecklingsom görs för att få statisk länkfunktionalitet är ytterligare ett inkrement i dess livscykel. Enny version av Toleransdatabasen följer vattenfallsmodellen med planering, analys, design,implementation, test och leverans. När nästa version av Toleransdatabasen skall utvecklasstartas nästa inkrement enligt vattenfallsmodellen (se figur 5). Dock är det inte säkert attnästa påbyggnad kommer att använda sig av just vattenfallsmodellen, men nästa versionkan ses som ett inkrement i produktens livscykel.

19

Figur 6: Toleransdatabasens livscykel med vattenfallsmodellens steg i form av Boehmsspiralmodell [3].

3.5 Insamlingsmetoder av teori och empiri

Detta avsnitt tar upp de olika metoder som används för att samla in material och faktainför studien samt vilka förväntningar författaren har på resultatet av arbetet.

Under förstudien insamlas information under den ostrukturerade intervjun i vilkenhandledaren från HP är intervjuobjekt. För att få fram fakta gällande metoder och pro-cesser används vetenskapliga artiklar och publicerad facklitteratur vilka återfinns i refe-renslistan och referenser är angivna i de stycken som använder sig av dessa. För att fåen djupare inblick i de olika teknologier som berörs under arbetets gång används internetsom informationskälla för att leta efter information, och vanligtvis hittas informationen påtillverkares eller huvudmäns officiella sidor, samt tryckt facklitteratur.

20

Grunden för den empiriska studien är att hämta in och analysera de krav som be-ställaren har ställt på utvecklingsprojektet. Kraven används för att planera upp utveck-lingsarbetet vilket innefattar skapandet av lösningar för genereringen av statiska länkar.Handledaren från HP tillhandahåller information om problemets natur och bakgrunden tillvarför applikationen existerar.

Genom att erfarna slutanvändare får testa webbapplikationen för att se om förbättrings-arbetet uppfyller alla krav ges en bra återkoppling till om ett godkänt resultat uppfyllts.Detta sker genom UAT [15].

3.6 Analysmetod

Det litterära materialet bestående av kravspecifikation, programvarudokumentation, ve-tenskapliga artiklar och facklitteratur, tillsammans med resultatet från UAT, är det somkommer att användas under analysen och utvecklingsarbetet. Genom att använda sig avden informationen kan detta ge en indikation om frågeställningen besvarats.

3.7 Förväntningar

De förväntningar som finns är att kunna generera statiska länkar till enskilda sidor medtoleranstabellinformation. Detta skall ske genom att användaren trycker på en knapp place-rad på den sida som innehåller toleransdatatabellen. Den skapade länken skall presenterasi ett meddelandefält på samma sida tillsammans med ett meddelande om att exekveringenvar lyckad (se figur 8).

Under ytan skall länken sparas i en databastabell tillsammans med ett unikt ID. Län-karna skall inte ta användaren direkt till toleranstabellsidan utan de skall ta användarentill inloggningssidan för att på så sätt se till att endast behöriga användare får ta del avinformationen.

3.8 Tekniska förutsättningar

Teknisk information om Toleransdatabasen erhålles genom en ostrukturerad intervju [21]med handledaren från HP. Den information som kom ifrån intervjun är att den versionav Toleransdatabasen som skall modifieras för statisk länkgenerering är driftsatt och an-vänds dagligen av användare med tilldelad behörighet. Applikationsservern som levererarinnehållet till webbläsaren är Apache Tomcat [44] och Java sköter kompileringen av Java-koden. Apache Tomcat körs på en Sun Solaris server. Databasen är också driftsatt och ärlokaliserad på en separat server.

21

De verktyg som tillhandahållits är Eclipse IDE för programmeringen som enligt Geer[10] är den mest använda IDE:n för Javautveckling och Squirrel SQL för databasmanipu-lationen. Tillgång till källkod finns och den är inlagd i IDE:n Eclipse. För filmanipuleringpå servern har SFTP (Secure Shell File Transfer Protocol) klienten Bitvise SSH Client [5]använts med vilken man kan manipulera filer på servrar med SFTP stöd.

4 Genomförande

Information inhämtas i början av utvecklingsprojektet från intervjuer, dokumentation, kravoch litteratur.

Figur 7: De forskningsmetoder som kommer att användas under genomförandet för attbesvara forskningsfrågorna.

22

En fullständig kravspecifikation skriven av SKF togs emot ifrån HP och analyserades,resultatet av detta blir en förståelse av vilken funktionalitet som SKF vill ha. Ytterligareinformation om Toleransdatabasen och problemet som skall lösas kom genom en ostruktu-rerad intervju med handledaren från HP.

För att sedan kunna bilda sig en förståelse för hur Toleransdatabasen är uppbyggd ochfungerar delas den upp i två delar, webbapplikationen, och databasen. Toleransdatabasenutforskas, funktioner testas för att sedan hitta de delar av applikationen som kommer attberöras av den nya funktionaliteten. När de berörda delarna hittas studeras koden för desidor som har med toleranstabeller att göra. När en god förståelse uppnås är nästa stegatt utforska databasen. Det intressanta är att ta reda på vad för sorts databas Tolerans-databasen använder sig av, och hur den är kopplad mot Toleransdatabasen.

En litteraturstudie genomförs för att få mer förståelse av de olika teknologierna ochutvecklingsprocesser som är inblandade i Toleransdatabasen. Facklitteratur och teknolo-gileverantörers dokumentation studeras först i stora drag för att välja ut de intressantadelarna som hur JSP-applikationer kommunicerar med Oracle-databaser och hur länkhan-teringen fungerar.

Nästa steg är designen i vilken själva designen skapas för hur Toleransdatabasapplika-tionen och dess databas skall se ut efter att funktionaliteten lagts till. Efter designstegetbörjar utvecklingsarbetet med programmering samt databasadministration. Utvecklingensker med hjälp av den systemvetenskapliga utvecklingsprocessen vattenfallsmodellen. Närutvecklingssteget slutförts startades testningen och slutligen installerades resultatet av själ-va arbetet på produktionsmiljön. Efter varje slutfört steg skall kontakt upprättats med HPför att stämma av att allt utförts tillfredställande.

Uppdraget innebar att ta fram en lösning för att ge Toleransdatabasen möjlighet attskapa och spara statiska länkar från dynamiskt JSP-innehåll och i samband med dettabegärdes en kravspecifikation. Själva uppdraget gavs till författaren av HP efter att förfat-taren tagit kontakt med HP och frågat efter möjliga examensarbeten. När denna erhöllsgenomfördes en kravgenomgång tillsammans med handledaren från HP för att förstå kra-ven bättre och för att reda ut eventuella frågetecken. Stödet ifrån HP var väldigt bra.Access till den källkod som behövdes för att kunna ta sig an uppgiften delades ut. Ävenförslag på litteratur att studera och för att använda som uppslag under utvecklingen deladeförmedlades.

Då Toleransdatabasen är en webbapplikation som baseras på plattformen Java Enter-prise Edition 5 i språket JSP (JavaServer Pages) [31] behöver den en applikationsserversom kompilerar och presenterar de filer som Toleransdatabasen är uppbyggd av. HP harvalt Apache Tomcat [44] som applikationsserver. Tomcat är väldokumenterat och detta vartill stor hjälp under förberedelsen av hur den är uppbyggd och fungerar i praktiken.

23

Nästa del i Toleransdatabasen som behövde ses över för att bygga upp en förståelse avhur allt fungerar var dess databas. Det är en relationsdatabas baserad på Oracle [32] medJDBC-koppling genom en xml-fil i applikationsservern [43]. Det verktyg HP tillhandahöllför databasmanipulering var SQuirrel SQL Client [41]. En databasmodell över den tabellsom skall läggas till skapades och med hjälp av den skapades tabellen med de kolumnersom krävs samt dess funktionalitet i databasen.

4.1 Krav

SKF har dokumenterat de krav de vill ha uppfyllda i en kravspecifikation och dessa över-lämnas till HP för vidare spridning till författaren av denna studie. Kravspecifikationenanalyseras först i stora drag för att efterhand gå ner på enskild kravnivå för att få braförståelse över dess sammanhang och vad som verkligen skall uppfyllas.

Ett av kraven som finns i kravspecifikationen är att länkarna skall sparas i en tabelli Toleransdatabasens databas. Varje länk skall få ett unikt ID genererat, samt ett unikthashat värde. Implementationen av en sådan funktion skall ske i JavaScript och detta ge-nom en egen funktion då JavaScript saknar stöd för hashgenerering.

Generering av hyperlänkar skall ske genom ett tryck på en knapp i webbapplikationenoch denna knapp skapas inte dynamiskt utan består av en statisk bild som HP har till-handahållit (se “Link to this page” i figur 8). SKF har som krav att efter att hyperlänkengenererats skall ett meddelande visas i ett nytt meddelandefält på toleransdatatabellsidan.Meddelandet skall informera om att länken har skapats utan problem, och den skapadelänken skall få formen av en klickbar HTML-länk. Toleransdatabasen består av flertaletHTML- och JSP-sidor med underliggande Java-kod som används för att visa innehåll. Enanalys av detta genomfördes för att leta reda på vilken JSP-sida det är som genererartabellen då knappen är tänkt att placeras på den sidan som presenterar toleranstabellen.

Återkoppling med handledaren från HP har skett varannan dag eller vid behov för attavrapportera status på arbetets gång samt för informationsutbyte. Kontakten har skettmed hjälp av telefon eller genom e-post. Detta steg har varit väldigt nyttigt, och upp-dragsgivaren har också uppskattat detta.

4.2 Design

En försvårande faktor med utvecklingsarbetet är att Toleransdatabasen till stora delar sak-nar kommentarer i källkoden vilket gör att funktioner och metoder kan vara svåra att följa.

Det som användarna skall interagera med för att skapa länkar i Toleransdatabasen ären knapp (se figur 8). Knappen visas genom HTML-kod vilken länkar till en JavaScript-funktion, som skapar länken och sparar denna till databasen.

24

Figur 8: Designförslag

Ett meddelandefält skapas genom att lägga ett anrop i HTML-koden vilken placeras ien lämplig HTML-tabell för att öka synligheten då texten hamnar i det område som kallasför Message Area i figur 8.

HTML-taggen <B> för att visa texten i fetstil, har valts för att öka synligheten. Närknappfunktionen har körts igenom skrivs informationen till variabeln och HTML-elementetladdar om sidan med det nya värdet i variabeln, alltså skrivs meddelandet ut tillsammansmed länken i meddelandefältet genom ett innerHTML element.

Toleransdatabasens utseende styrs av en CSS-formatmall (Cascading Style Sheets). An-vänds de CSS-taggar som anges i den behålls utseendet som det var tänkt att den skall haäven efter att nya förändringar i webbapplikation som rör HTML har gjorts.

25

Databasen skall få en ny tabell av typen LOOKUP vilken enligt Alapati [38] är en typav tabell i Oracle tänkt att användas som en referenstabell med innehåll som skall varastatiskt. Detta är utmärkt för den typen av information som är tänkt att sparas genomlänkgenereringen då varje länk skall sparas på en enskild rad och ingen skall manipulerainformationen efter den har skapats. Det går att redigera informationen efter den har ska-pats i en sådan tabell men en Lookup tabell är optimerad för att snabbt leverera resultatfrån SQL frågor. Detta skiljer sig från andra tabelltyper som är tänkta att ofta förändrasgenom UPDATE-kommandon.

Tabellen kommer inte att ha någon relation till någon annan tabell i databasen, denkommer bara att användas för att spara information som rör länkarna. Ingen annan tabelleller funktion i databasen skall använda den nya tabellen.

Den första kolumnen i tabellen skall vara av typen “NUMBER” med längden 8 teckenför att i den kolumnen är det tänkt att ett autogenererat ID på maximala 64-bitar skall spa-ras. ID-kolumnens värden är de som sedan skall användas som parametervärde i de länkarsom användarna kan använda sig av för att komma till toleranstabellen. Toleransdataba-sen skall sedan använda ID:t för att göra en fråga mot databasen och svaret som kommerskall innehålla information som behövs för att komma till den formaterade toleranstabellen.

Figur 9: Schema som visar vad tabellen skall innehålla.

Det behövs fler kolumner i tabellen. Den andra kolumnen skall innehålla själva sökkri-terierna, vilket inkluderar filtreringen som skapade själva toleranstabellen. Detta innebäräven vilken källa som använts, om toleransen är godkänd eller icke godkänd samt om bilderskall visas. Kolumntypen skall vara “VARCHAR2” med storleken inställd på 4000 bytes vil-ket är det maximala en “VARCHAR2” kan innehålla och värdena som kommer att sparas idenna kolumn är okända. Då storleken på det som skall lagras i kolumnen är okänd är detonödigt att begränsa kolumnen och på detta sättet minskas risken att länkgenereringenmisslyckas på grund av att sökkriterierna inte kan sparas i sin helhet.

Den tredje kolumnen skall innehålla ett hashat värde som skapas genom en algoritmfrån det variabla innehållet i sökkriteriekolumnen och presenterar därefter ett värde sommed fördel är unikt, samt representerar det värde som finns i sökkriteriekolumnen.

26

Oracle innehåller en sådan funktion för att göra detta vilken kommer att användas till-sammans med Toleransdatabasen. Två likadana länkar skall inte kunna sparas i databasen.Genom att se till så att kolumnen innehållandes hashningen blir unik med hjälp av enbegränsning löses problemet då det inte kommer att gå att spara samma värde på fler änett ställe i kolumnen. En funktion som kan skapa hash-strängar ifrån de strängar som ärsparade i sökkriteriekolumnen är “DBMS_UTILITY.GET_HASH_VALUE”. Det finns ennyare funktion för hashning som heter “ORA_HASH” vilken är lättare att använda mensom inte fungerar i den version av databas som Toleransdatabasen använder sig av.

Kunden vill att användaren som skapar länken skall få sitt ID sparat i en kolumn.Användar ID:na består av en blandning av alfanumeriska tecken och kolumntypen skallsåledes skapas med typen “VARCHAR2” och med längden satt till 8 för att ha plats förlånga ID.

Nästa kolumn skall innehålla datum och tid för genereringen. Oracle innehåller fleraautomatiska typer för datum men bara en typ som även innehåller tiden. Denna datumtypheter “TIMESTAMP” vilket innebär en tidsstämpel för det som inträffat och i detta fallblir det när en ny länk skapats samt sparats. Längd behöver inte tänkas på då detta redanfinns specificerat i “TIMESTAMP”-typen. Formen på tidsstämpeln blir med datumet förstför att sedan visa tiden ner till sekundnivå.

Sista kolumnen som behöver skapas är en med typen “VARCHAR2” och längden 4000byte. Kolumnen skall innehålla textsträngar i vilka delkoden samt de toleranser som finnssynliga på skärmen i toleranstabellen. Om tabellen kommit till genom filtrering skall äventexten “(Filtered)” sparas sist i strängen.

Det som kan klassas som det svåraste med uppgiften är att komma underfund med hurtoleranstabellen byggs upp. Hur fungerar själva anropen till databasen och hur skall dettagöras om till statiska länkar? Om inte en direktlänk med attribut och variabelanrop kanfinnas är tanken att en sida byggs upp som är möjlig att fylla upp med toleranstabellinne-håll. Det första steget i analysen är att titta på hur funktionen på den knapp som genom-för toleranssökningen fungerar som sedan skickar användarna till toleransdatatabellsidan.Knappen anropar en JavaScriptfunktion vilken i sig anropar två andra JavaScriptfunktio-ner. De två funktionerna anropar i sig ett flertal andra funktioner. Funktionerna ligger ien extern JavaScriptfil medan funktionen som knappen anropar finns internt i JSP-filensom har sökknappen. En metod för att få ut de värden som anropas i strängform behöverskapas.

4.3 Implementation

Databastabellen skapas genom kommandoradsgränssnittet i Squirrel SQL Client [41] vil-ken är uppkopplad mot Oracle-databasen. Strukturen för tabellen anges tillsammans medtyperna för varje kolumn samt längd och om de inte eller skall tillåtas att innehålla såkallade “null” värden.

27

Tabellen skapas med namnet “CREATED_LINK” och de flesta kolumnerna i tabel-len skapas som typen “VARCHAR2”. Undantag från detta blir den första kolumnen “ID”som får typen “NUMBER” och som tilldelas att bli primärnyckel genom “CONSTRAINTPRIMARY KEY”. Primärnyckelns värde skall starta på ett och sedan skall värdet på denautomatiskt öka med ett för varje rad i tabellen som skapas. En upptäckt efter mycketforskande är att Oracle saknar en “autoincrement”-funktion för primärnycklar som mångaandra databaser har. Lösningen blir att skapa en så kallad “trigger” som tillåter att kodblir tilldelad och som sedan kan använda tillsammans med en systemhändelse som “insert”.För att öka värdet med ett används en sekvens inom triggern med hjälp utav funktionen“NEXTVAL”.

Kolumnen med tidsstämpel skapas genom att ange “TIMESTAMP” efter kolumnnam-net. Hashkolumnen skapas med hjälp av en “DBMS_UTILITY.GET_HASH_VALUE”funktion tillsammans med en begränsning som kallas “UNIQUE CONSTRAINT”. Funk-tionen ser till att så att det inte går att spara samma sökkriterie flera gånger och bara harunika sökkriterier i databasen.

När nu databasen har fått den tabell med de kolumner som behövs börjar arbetet medatt skapa den kod som skall användas för att generera de statiska länkarna som skall sparasi tabellen. Det första som skapas är knappen och dess position. Kunden har gett riktlinjerangående placering av denna och den skall befinna sig över själva toleranstabellen. Knap-pen skapas genom att en bild blir tilldelad en “a href”-tagg så den även blir till en länkoch denna länk pekar på en JavaScript-funktion. Funktionen skapas i samma JSP-sida somknappen finns och blir därmed en intern JavaScript-funktion.

Ett JavaScript-funktionsskelett skapas som platshållare bland de andra interna Java-Scripten. Nästa steg blir att se över meddelandefältet som skall visa den skapade länken till-sammans med ett meddelande. I den skapade JavaScript-funktionen lägges ett dokument-ID till för meddelandefältet samt att det skall använda sig av “innerHTML”. Meddelande-fältet refererar till det ID som skapas i funktionen, inget kommer att visas på sidan tillsfunktionen anropas. Texten “Successfully created static link! Please refer to this page forfuture reference:” visas tillsammans med den skapade länken genom ett variabelanrop somläggs till textsträngen i meddelandefältet, Message area (se figur 8).

I databasen behöver information sparas som användar-ID och delkod som berättarvilken sorts produktgrupp tolleranserna tillhör, samt de toleranser som syns i tabellen.Användar-ID hämtas genom en Java-metod, görs om till en sträng genom metoden “toSt-ring()” och sparas sedan i en variabel. Även variabeln för användar-ID skickas med i funk-tionsanropet när knappen trycks på och funktionalitet ser till att spara den som en variabeli JavaScript-funktionen. Förfarandet är likvärdigt för att hämta ut nuvarande delkod, ettdelkod-objekt skapas i Java som sedan anropas med en get-metod och lagrar resultatet ien sträng. Strängen skickas sedan med till JavaScript-funktionen när den statiska länkge-nereringsknappen anropas.

28

Nästa sträng som behöver sparas är källan som använts för att hämta toleransinforma-tionen. En Javametod som anropar en get-metod skapas och skickar med den informationentill JavaScriptet för att sedan kunna sparas i databasen.

De värden som hittills hämtats ut genom metoder är statiska i stor mån, användar-IDär likadant för sessionen och kan bara innehålla ett enda användar-ID. Delkoden är ocksåstatisk på det sätt som den anropas på men den byts ut om användaren gör en förnyadsökning mot en annan delkod. Detta är inget som behöver tänkas på då Toleransdatabasenvisar upp toleranser för endast en delkod på toleranstabellsidan.

Ett sätt att hämta ut toleranskoder i strängform behöver skapas. Metoderna som kanhämta detta itereras för att få ut alla toleranskoder då de sparar dessa i en array. Det kanvara en eller flera toleranskoder som listas i toleranstabellen och alla dessa måste sparas i entextsträng. Det krävs många försök och testning för att kunna få ut strängen på korrekt vis.

För att manipulera databasen behövs en databas-fråga byggas upp i textsträngformsom skall användas när databasen anropas. I JavaScript-funktionen byggs frågan upp ge-nom att hårdkoda frågestrukturen och använda de variabler som fyllts upp som värden ifrågan på rätt ställen.

Genom att hitta rätt Java-objekt som skapas när en användare genomför en toleransta-bellsökning används serialisering vilken är en metod som används för att få ut användbarinformation som kommer att lagras i sökkriteriekolumnen. Informationen som fås genomserialiseringen är i binärform men görs om till läsbar strängform genom XML-serialisering.

En JSP-sida skapas tänkt för att hantera de statiska länkarna genom att primärnyc-keln i databasen skickas med till sidan med hjälp av ett JSP-anrop. ID tas om hand aven Javametod i sidan som anropar databasen och hämtar hem informationen som finns isökkriteriekolumnen med hjälp av primärnyckeln. Efter att sökkriterieinformationen erhål-lits så anropas en annan sida med hjälp av ett jsp forward page-anrop. I anropet skickassökkriteriet med som ett parametervärde. Sidan som anropas i jsp forward page-anropetskapas utifrån den kod som redan finns för att rita upp toleranstabeller. Modifieringar görsför att hantera sökkriterier från en JSP-parameter.

Den nya toleranstabellsidan använder sökkriterierna för att hämta toleranser och devärden som är kopplade till delkoden för att rita upp en likadan toleranstabell som fannsnär den statiska länken skapades.

4.3.1 Summering av implementationen

Implementationsarbetet har inneburit att koden som rör det grafiska användargränssnittetuppdaterats med en knapp för länkgenerering och ett meddelandefält. HTML-koden fördetta ligger i en JSP-fil och en extern CSS-fil användes för att få ett enhetligt utseende.

29

Figur 10: Schema som visar en översikt över vad som sker i den nya länkfunktionaliteten.

CSS-filen innehöll stöd för de HTML-taggar som användes under implementationsarbetetoch filen redigerades därför inte. I JSP-filen skapades ny JavaScript-kod för knappen ochlänkfunktionen. JSP-filen innehåller även Java-kod som anropar en databas connector-klassför databasanrop. En SQL-fråga byggs upp med hjälp av variabler och hårdkodad text. IOracledatabasen skapades en ny tabell med hjälp av SQL innehållandes ett flertal kolum-ner. Den nya tabellen har ingen relation med någon annan tabell och tabellen innehållersåledes ingen sekundärnyckel eller främmande nyckel. SQL-frågan används för att uppda-tera databastabellen med en ny länk efter att länkgenereringsknappen anropats.

En ny JSP-fil skapades för att hantera länkanrop från länkar genererade av knappeni det grafiska användargränssnittet och den innehåller funktionalitet för att hämta infor-mation från den nya databastabellen skriven i Java-kod. Genom Java-koden skapas en nykoppling till databas-poolen och en SQL-fråga anropar databasen för att hämta hem deninformation som finns i en viss rad med hjälp av ett ID. När SQL-frågan har hämtat infor-mationen anropas JSP-sidan som skapar toleranstabellerna med hjälp av ett GET-anropoch de parametrar som behövs för att skapa tabellen skickas med.

Implementationsarbetet har tagit ca 300 timmar i anspråk och arbetet har skett ihemmet med hjälp av källkod och verktyg tillhandahållna från HP. Handledarmöten underimplementationsarbetet har skett över telefon och e-post samt vid två tillfällen på HPskontor.

30

4.4 Test

Genom att fortlöpande testa de förändringar som görs med Toleransdatabasen minskarman risken att programmeringsfel eller feltolkningar gör att färdigställandet försenas.

4.4.1 Testmiljö

För att inte riskera att störa produktionsversionen har en komplett version av dess miljösatts upp som är dedikerad för utveckling och test. Miljön är densamma som för produk-tionsmiljön, det vill säga Apache Tomcat [44] som applikationserver och Oracle [32] somdatabas. En sådan miljö kallas inom HP för Greenhouse.

4.4.2 Testmetod

De tre faser som Hou m.fl. [48] anger för test av mjukvara; modultest, integrationstest samtsystemtest har använts under utvecklingen av länkhanteringsfunktionaliteten för Tolerans-databasen. I denna studie finns även en fjärde test-fas med, acceptanstest. Denna har valtsatt läggas till då ett acceptanstest ger nyttig feedback om hur systemet upplevs. Miljön förtestningen och de olika testfaserna förklaras i efterföljande delkapitel. Modultestning hargenomförts på de klassfiler och de JSP-filer som ändrats och skapats för att sedan läggasupp var för sig i Greenhouse där integrationstestning genomförts.

När all integrationstestning blivit klar har ett komplett systemtest gjorts tillsammansmed handledaren från HP. Alla testade delar från integrationstestningen låg på Greenhouseför detta moment. Efter att systemtestet hade fått klartecken från HP flyttades testandettill den sista fasen, acceptanstest.

Om utvecklingsprojektet hade varit större skulle automatiserad testning lagts till somtestmetod. Yoonsik och Leavens [12] skriver i sin artikel A Simple and Practical Approachto Unit Testing: The JML and JUnit Way om den nytta en sådan testmetod har på störresystem. Men de tar även upp problem som kan uppstå när t.ex. klass- eller metodnamnändras efter att de automatiserade testfilerna är skapade. Är namnen ändrade så slutar denautomatiserade testningen att fungera och testklasserna måste skrivas om för att matchaden ändrade koden som skall testas.

4.4.3 Integrationstestning

Integrationstestet sker genom att Toleransdatabasen som ligger på utvecklingsmiljön “Gre-enhouse” manuellt stängs ner genom Apache Tomcats Manager. Det finns sedan två sättatt ladda upp nya versioner av webbapplikationen. Ett sätt är att skapa en WAR-fil, vilketär ett paket som innehåller hela webbapplikationens struktur och filer. WAR-filen laddasupp genom Tomcats Manager-gränssnitt. Det andra sättet är att manuellt ladda upp filergenom en SFTP-klient [42] direkt in i webbapplikationens katalogstruktur.

31

De två olika metoderna har sina för- och nackdelar. Det är enkelt att bara behöva laddaupp ett paket som sedan Apache Tomcat [44] extraherar och installerar men det kräver attett sådant paket skapas, antingen genom Eclipse eller genom kommandoraden. Fördelenmed att ladda upp enskilda filer eller kataloger genom SFTP [42] är att arbetet med attskapa WAR-filen inte behövs och kontroll på vilka filer som förs över erhålls.

Har bara en förändring gjorts i en fil så är det smidigt att bara ladda upp den föränd-rade filen. Om det är flera förändrade filer i olika kataloger blir det svårt att hålla reda påvilka de är och enstaka filer kan glömmas bort att laddas upp. Detta kan leda till att Tole-ransdatabasen beter sig felaktigt eller att den ger kompileringsfel som leder till att testetmisslyckas. Versionshantering över SSH kan vara en lösning på problemet men servern somtillhandahölls saknar stöd för detta. En annan nackdel som lätt kan glömmas bort är attmed den manuella filuppladdningsmetoden bör Toleransdatabasens Work-katalog tömmasvilken befinner sig i Apache Tomcats rotkatalog. Glöms detta bort kommer förändringarsom kräver kompilering inte att ske då Apache Tomcat redan har en eller flera kompileradeversioner av filen eller filerna.

Efter att den nya versionen av webbapplikationen som skall testas är uppladdad till ser-vern får webbapplikationen startas upp igen genom Apache Tomcat Manager. När sedantestningen av webbapplikationen påbörjas kommer applikationen till en början att kännaströg och långsam på grund av att filerna kompileras för första gången. Nästa tillfälle somsamma filer anropas igen är de redan kompilerade och svarstiderna blir således bättre.

Att specificera vilka webbläsare som webbapplikationen skall fungera i är fördelaktigtinnan utvecklingen startar, vilket även förenklar testningen. I detta fallet är Toleransdata-basen testad med Internet Explorer, Firefox samt Google Chrome och således kommer deändringar som görs testas i de webbläsarna.

Test av en webbapplikation [46] kräver mycket arbete och är tidskrävande. Efter varjeny testversion behöver användarna alltid logga in för att bli autentiserade, sedan reagerarwebbapplikationen långsammare då den kompilerar de nya filerna. En annan faktor somhar betydelse är databasanrop. Dessa tar längre tid ju mer komplexa sökningar som görsoch/eller om resultatet av anropet är väldigt stort.

Har något misslyckats under programmeringen kan det dyka upp kompileringsfel elleratt den önskade funktionaliteten uteblir. Blir det kompileringsfel ges en detaljerad krash-rapport ifrån Javas-kompilerare som är till stor hjälp vid felsökning.

Integrationstestning används till stor del inom utvecklandet av den statiska länkgene-reringen. För detta ansvarar utvecklarna, i detta fall författaren.

32

4.4.4 Systemtest

Toleransdatabasens systemtest innebär att använda en server med samma specifikationersom i produktion, både hårdvaru- och mjukvarumässigt placerad inom samma miljö somproduktionsplattformen. Testarna får då samma in- och utdata och de fel som kan uppståt.ex. uppkopplingsproblem till databasen hade visat sig på samma sätt som på produktions-plattformen. Det är alltså en kopia av produktionsplattformen uppkopplad mot samma nät,placerad i samma miljö (serverhall) men som inte stör den riktiga produktionsmiljön.

4.4.5 Granskningar inför UAT

Den testperson som är med under integrationstestningen är författaren själv som utvecklareoch när den funktionalitet som lagts till har fått acceptabelt resultat genomför handledarenfrån HP ett integrationstest för att validera resultatet.

4.4.6 Testpersoner för UAT

Testpersoner som skall genomföra UAT blir två användare från SKF. När dessa använ-dare godkänt alla kriterier som UAT innehåller kan den nya Toleransdatabasen ersättanuvarande version i produktion.

4.4.7 Testfall för UAT

För att genomföra ett UAT [15] behöver testdeltagarna följa ett antal testfall för att kunnatesta om den önskade funktionaliteten uppfyllts.

1. Gå till applikationen “Toleranstabellen” och logga in i applikationen.

2. Skapa en toleranstabell lista genom det normala tillvägagångssättet med valfri for-matering av det som tabellen skall innehålla.

3. Tryck på knappen “Link to this page”.

4. Kontrollera att ett liknande meddelande dyker upp på sidan:

Successfully created static link! Please refer to this page for future refe-rence:""http://serveraddress:portnummer/applikationens katalog/hanterande sida?id=id"

5. Klicka på länken under meddelandet.

6. Kontrollera att login-sidan visar sig och logga in.

7. Kontrollera att samma information i toleranstabellen visar sig som på sidan somdyker upp.

33

5 Resultat

Den nya funktionaliteten att kunna spara ner dynamiskt JSP-innehåll till statiskt i enJSP-applikation verifierades genom användaracceptanstest UAT med beställare och slu-tanvändare av Toleransdatabasen.

Resultatet från UAT var att webbapplikationen har fått den efterfrågade funktionali-teten att kunna skapa och lagra statiska länkar från dynamiskt JSP-innehåll. Ett godkäntresultat är i detta fall när Toleransdatabasen uppfyllt de krav som ställts i kravspecifi-kationen. Det slutgiltiga godkännandet av den nya funktionaliteten kom efter genomfördUAT med bra utfall.

Det som lade grunden till att studien uppvisar en lösning på frågeställningarna är denvetenskapliga ansats som valdes. Den kvalitativa forskningen med hermeneutiken som me-tod för förståelse av litteratur och kravspecifikation gav en god förståelse av problematikenoch Toleransdatabasens funktion. Detta då metoden grundligt förklarar hur man först skallbilda sig en överblick av det som skall studeras för att sedan välja ut de viktiga delarnaför ytterligare studie. Valet av utvecklingsprocessen vattenfallsmodellen föll också väl ut.Vattenfallsmodellens metoder följdes steg för steg och detta i samband med den godaförståelsen av applikationen och problematiken ledde till att utvecklingen blev lyckad.

Nedan anges de sätt resultatet kontrollerats på.

5.1 Programvaran och den tekniska lösningen

Efter genomförd testning meddelar användarna ett positivt resultat av UAT. Kraven äruppfyllda och klartecken ges att implementera den nya versionen av Toleransdatabasen iproduktion. Tillsammans med handledaren från HP planeras driftsättning in vid en tid-punkt då applikationsstillestånd medges från SKF. Med applikationsstillestånd menas närapplikationer kan tas ur bruk under en period för uppdatering eller underhåll.

Lösningen på problemet med de dynamiska länkarna var att hitta ett sätt att läsa ut devariabler som skickas vidare till JSP-sidan som tar fram toleranstabellerna. När väl dessavar funna skapades en metod för att skicka den informationen till en tabell i databasen.För att kunna använda den dynamiska länken igen skapas en statisk länk som anropar enny JSP-sida med ett attribut som är ett unikt ID i databasen. Med hjälp av det ID kanvariablerna hämtas från databasen och skickas till sidan som ritar upp toleranstabellerna.På detta vis kan samma information återges med hjälp av den skapade länken. Den nyalänkfunktionaliteten levererades inom den fastställda fem månaders tidsramen.

34

5.2 Kvalitet

För att mäta ett systems kvalitet krävs gedigna tester med testspecifikationer som tarupp alla funktioner som Toleransdatabasen har. Detta kräver mycket tid om applikationeninnehåller många funktioner vilket Toleransdatabasen gör. Att testa hela Toleransdataba-sens kvalitet är utanför detta arbetes omfång då uppdraget är att ta fram en lösning föratt skapa statiska länkar. Således kontrolleras kvaliteten på det som innefattas i de kravsom kunden ställt genom integrationstest efter varje testbar funktion som utvecklats ochslutligen genom UAT i testmiljön.

5.3 Organisationens behov

SKF hade ett behov av att kunna återanvända länkar till toleranstabeller i Toleransdata-basen. Problemet var att de skapades dynamiskt och de variabler som skickas är osynligaför användarna. De behövde få ny funktionalitet som omvandlade den dynamiska funktio-naliteten till länkar som används för att hämta statisk information, dessa kallas för statiskalänkar. Behovet är uppfyllt i och med den framtagna tekniska lösningen.

5.4 Arbetets genomförande

Det första som gjordes var att samla in information om Toleransdatabasen och problemetsom skulle lösas. Därefter planerades hur arbetet skulle läggas upp med tidsramen att bliklar under terminen. Arbetet genomfördes enligt plan inom tidsramen. Forskningen be-drevs kvalitativt under den initiala analysen av problemet, applikationen och kraven, föratt sedan övergå till den systemvetenskapliga utvecklingsprocessen vattenfallsmodellen ochdess metoder för utvecklingsarbete.

6 Analys

Det måste nämnas att ingen möjlighet gavs att presentera kodlösningar och liknande upp-gifter då tystnadsavtal har ingåtts med HP. Istället beskrivs den tekniska lösningen sådetaljerat som möjligt utan att för den sakens skull presentera kod som använts underToleransdatabasens utveckling. Något annat som är värt att notera är att det endast vartvå slutanvändare som genomförde UAT. Användarna valdes ut av SKF, och det är använ-dare som är väldigt insatta i hur Toleransdatabasen skall uppföra sig och en av dessa ärbeställaren hos SKF.

De har väldigt god kännedom om vad de ville få för resultat utifrån de krav som ställtsdå de båda var de som tagit fram kraven. Båda använder Toleransdatabasen dagligen ochhar väldigt god datorvana vilket gjorde att de inte behövde fler instruktioner än de somdelades ut inför UAT och ingen hjälp krävdes under själva testet.

35

Värt att notera är att alla användare av Toleransdatabasen är ingenjörer med godproduktkännedom och de arbetar varje dag med Toleransdatabasen som arbetsverktyg.Informationen om användarna framkom under intervjun med handledaren från HP.

Forskningsansatsen var kvalitativ genom hela studien, och utredningsmetoden har vi-sat sig fungera väldigt väl. Tidigt under forskningen valdes metoden ut då det framkomatt ett bestämt problem skulle lösas under en kort tidsperiod. Detta framkom vid denostrukturerade intervjun med handledaren från HP.

Valet av vattenfallsmodellen som utvecklingsprocess att följa har visat sig fungera brai detta projekt. Kravspecifikation innehåller relativt få krav och de är alla tydliga vilketlett till ett lätthanterligt projekt samt att kraven levererades färdigställda till författaren.Hade kraven varit fler, svåra att tyda eller om krav ändrats eller lagts till under projektetsgång hade resultatet av att vattenfallsmetoden valts säkerligen visat sig ha varit felaktigt.

7 Diskussion

Den metod som valdes att följa under studien var utredningsmetoden med en kvalitativforskningsansats. Det är en konstruktiv studie, det är ett utvecklingsarbete riktat mot attutreda om ett visst problem går att lösa. I detta fall var den första frågan om dynamisktinnehåll i JSP kunde göras om till statiska länkar och på så sätt enkelt kunna visa sammainformation. Under utvecklingsarbetet besvarades den andra frågan om vilken systemut-vecklingsprocess som var mest lämpad att använda under utvecklingen av en lösning påproblemet med det dynamiska innehållet genom användningen av vattenfallsmodellen.

7.1 Metodkritik

Hermeneutiken [45] har tidigare använts inom systemvetenskap, men inte för att lösa ettsystemvetenskapligt problem utan för att utreda ett socialt fenomen. Metoden visade siglyckad att följa under granskningen för förståelsen av problemet och applikationen. Den ärinte passande för systemutveckling då metoder för programvaruutveckling saknas.

För den systemvetenskapliga delen valdes vattenfallsmodellen ut för att användas sommjukvaruutvecklingsprocess att följa under utvecklingsprojektet med lyckat resultat. Dessmetoder var till stor hjälp under framtagandet av lösningen på problemet med länkhante-ringen. Detta på grund av de olika systemvetenskapliga metoderna som design och imple-mentation. Skulle resultatet blivit annorlunda om någon annan utvecklingsmetod valts utförutom vattenfallsmetoden? Slutsatsen som författaren kommit fram till är att det hadeblivit ett annorlunda resultat. De andra metoderna är inriktade på att genom olika gra-der av iteration gå igenom de olika stegen för att till sist få en färdigställd mjukvara. Enutvecklingsprocess som saknar itereringssteg kunde användas för att ta fram lösningen dåfärdigställda krav från SKF tillhandahölls från HP redan från början.

36

Att välja en modernare iterativ metod hade troligen försenat leveransen av utvecklings-projektet. Detta då de bygger på en nära kontakt med beställaren och möjlighet ges attändra på krav under utvecklingens gång vilket leder till att projektet skulle ha tagit mer tidatt färdigställa. Hade projektet varit större bör det motsatta hända, om beställaren i slut-skedet inte gillar den färdigställda produkten vore det troligt att mycket av den kod somframställts hade fått slängas. Genom det förfarandet förloras mycket tid och alla inblan-dade parter blir negativt påverkade. Hade projektet varit större och haft flera involveradeutvecklare samt en beställare som ofta återkom med nya förslag hade den inkrementellabygg och testmetoden valts som utvecklingsmetod att följa.

7.2 Källkritik

Eriksson och Wiedersheim-Paul [22] anger att med källkritik menas att kritiskt granskadokument. De källor som valts ut är sådana som är tänkta att hjälpa i förståelsen förde begrepp, metoder och teknologier som presenteras i arbetet och detta har lett till attantalet vetenskapliga källor är få men relevanta.

Detta arbete har som syfte att ta fram en lösning och i slutändan resultera i en fär-dig produkt. Det har inte kunnat genomföras undersökningar där olika teknologier ställsmot varandra eller genomföra användartester med olika lösningar. Detta kommer sig avatt kunden har lämnat klara instruktioner om hur de vill att det färdiga resultatet skallse ut och tid fanns ej för att skriva om Toleransdatabasen med hjälp av ett annat pro-grammeringsspråk/teknologi. Även faktorn att det saknas tidigare forskning inom områdetdynamiskt JSP-innehåll till statiska länkar har gjort att antalet vetenskapliga källor harbegränsats.

7.3 Slutsats

Genom mycket vilja, analys och god hjälp ifrån HP har resultatet av arbetet löpt väl ut.Toleransdatabasen har numera funktionalitet att kunna skapa statiska länkar ifrån dyna-miskt JSP-innehåll.

Valet av en kvalitativ forskningsansats med den hermeneutiska metoden tillsammansmed utredningsmetoden för att få en förståelse av problemet och hur Toleransdatabasenfungerade föll väl ut. Att sedan arbeta med systemvetenskapen och systemutvecklingspro-cessen vattenfallsmodellen med dess metoder gjorde att det blev lätt att följa då metodernainnehöll klara instruktioner om vilka moment som skulle utföras. Kraven som erhölls varredan fastställda och förändrades aldrig. Detta innebar att de olika utvecklingsfaserna,analys, design, utveckling och test inte behövde itereras. På de grunderna passade vatten-fallsmodellen bäst in efter att flera olika systemutvecklingsprocesser analyserats.

37

Att följa kravspecifikationen och envetet arbeta efter vattenfallsmodellens steg mot attfå till en bra lösning på problemet för att kunna spara statiska länkar från de dynamiskavisade sig vara rätt väg i detta projekt. Kraven ändrades inte under projektets gång ochdetta var en av anledningarna till att metoden var rätt för projektet. Fler anledningarvar att projektet gick ut på funktionstillägg och inte utveckling av en hel webbapplikationsamt att projektet bara hade en utvecklare vilket gjorde att projektet inte behövdes delasupp mellan flera projektmedlemmar.

Den tekniska lösningen för att generera statiska länkar från dynamiskt JSP-innehållblev lyckad. Den nödvändiga informationen för toleranstabellskapandet som skickas mellanformulär och JSP-sidor hämtades ut och dessa sparades ner i strängformat vilka laddadesin i en databas. En ny JSP-sida skapades som har funktionalitet att visa toleranstabellerfrån den data som lagrats vilket ledde till att kraven uppfylldes.

Hade nu SKF valt att komma med ändringar mitt i projektet finns en stor sannolikhetatt projektet inte hade fått samma resultat. Spiralmodellen hade passat in om förutsätt-ningarna var sådana, men idag finns många andra iterativa systemutvecklingsmetoder somhar som syfte att få utvecklingen att bli klar snabbast möjligt. Om utvecklingsgruppen ärstörre med minst tre utvecklare finns Scrum [39] som hade fungerat väldigt väl även medett litet projekt som avhandlats i detta arbete. Ett sådant arbetssätt där kraven delas uppmellan utvecklarna vore att föredra men i detta projekt var författaren ensam utvecklareoch en äldre väl beprövad utvecklingsmetod som vattenfallsmetoden passade.

Om inte tidsbegränsningen på 5 månader funnits, eller om två utvecklare varit invol-verade, hade den ena utvecklaren använt sig av vattenfallsmodellen och den andra kundet.ex. ha använt spiralmodellen. Efteråt kunde resultatet analyseras; löste båda problemetoch hur lång tid tog det?

Den litteratur som valts ut har varit till stor hjälp under utvecklingens gång och haranvänts som uppslagsverk för att öka kunskapen om JSP och databasen Oracle. Uppdragethandlade om att ett behov av ny funktionalitet uppstått under Toleransdatabasens livscy-kel. Detta skedde som en påbyggnad till den tidigare skapade Toleransdatabasen.

Genom detta arbete har författaren till denna rapport fått en inblick och en känsla avhur det är att arbeta som konsult inom IT-sektorn. Ute i näringslivet finns mängder avapplikationer som har blivit färdigutvecklade vid en viss tidpunkt men som senare visar sigsakna funktionalitet som skulle varit med, eller så fanns inte behovet vid den tidpunktenför applikationens färdigställande. Toleransdatabasen passar in på det med att ett behovav ny funktionalitet framkommit och genom detta har författaren fått arbeta med det somi branschen kallas för Product Lifecycle Management, förkortat PLM.

Då slutanvändare valdes som testpersoner för webbapplikationen under UAT erhölls enbra feedback för de hade god insikt i hur Toleransdatabasens nya funktionalitet skulle varasamt att de även varit delaktiga i framtagandet av kraven.

38

En tanke som kommit är om slutanvändarna borde ha varit involverade under integra-tionstesterna, men slutsatsen är att det hade försenat leveransen då mer tid hade gått åtför test, samt att det lätt blir att specifikationer ändras som leder till mer utvecklingsarbete.

Att förbättra en applikation som har utvecklats för ett flertal år sedan, och efter detfått utökad funktionalitet från olika utvecklare under applikationens livscykel, är inte detlättaste. När de flesta Java-metoder och JavaScript-funktioner saknar, eller har bristfäl-lig kommentering gör inte det hela lättare. Tack vare gott stöd av handledaren från HP,litteratur, att färdiga krav tillhandahölls och valet av den systemvetenskapliga processenvattenfallsmodellen under utvecklingen ledde till att projektet fick ett lyckat resultat.

8 Förslag till framtida forskning

Det finns stora möjligheter för vidare forskning inom området att skapa statiska länkarifrån dynamiskt innehåll. Finns det någon lösning som kan fungera bättre än den somframkommit i detta arbete? Kan en standardisering av en metod för att skapa statiskalänkar ifrån dynamiskt innehåll vara möjlig? Vilka mjukvaruutvecklingsmetoder och mo-deller fungerar bäst i små projekt med en ansvarig utvecklare? Skall testgruppen breddastill även de som inte använder webbapplikationen i sitt dagliga arbete när en applikationsom har en specifik användargrupp skall testas?

Fördjupningen behöver inte vara inom just området Java EE, andra teknologier somASP.net och PHP har sin länkhanteringsteknologi som kan vara önskvärd att ta framlänkgenereringslösningar till.

39

9 Referenser

[1] A. Immonen, A. Saaksvuori, Product Lifecycle Management. Springer (2008) 1-6.

[2] A. Strauss, J. Corbin, Grounded Theory Research: Procedures, Canons, and EvaluativeCriteria. Qualitative Sociology Vol 13 No 1 (1990).

[3] B. W. Boehm, TRW Defense System Group, A Spiral Modell of Software Developmentand Enhancement. IEEE Computer Society (Maj 1988) 61-67.

[4] B. Davidson, R. Patel, Forskningsmetodikens grunder. Att planera, genomföra ochrapportera en undersökning. Studentlitteratur (2011) http://doc.utwente.nl/50426/1/K50426__.PDF, 2012-02-13

[5] Bitvise Limited, Bitvise SSH Client http://www.bitvise.com/tunnelier, 2012-09-23

[6] C. Erickson, P. C. Jorgensen, Object-Oriented Integration Testing. Communications ofthe ACM Vol 37 No 9 (September 1994)

[7] C. Lindgren, Stockholms Universitet, Att skriva uppsats. Företagsekonomiska institu-tionen (November 2001)

[8] D. Raggett, W3C HTML 3.2 Reference Specification, http://wwwusers.di.uniroma1.it/~reti/Reti2_html/docum/HTML/REC-html32.html#form, 2012-06-17

[9] D. Boda, L. Brohult, E. Mörner, T. Nilsson, R. Pixell, Uppkopplade prylar - En rapportom Internets framtid och hur apparaterna går online, .SE:s Internetguide Nr 19, Version1.0 (2009). http://www.iis.se/docs/Uppkopplade-prylar_webb.pdf, 2012-09-23

[10] D. Geer, Eclipse Becomes the Dominant Java IDE, http://www.computer.org/csdl/mags/co/2005/07/r7016.html, 2012-02-13

[11] D. R. Graham, Incremental development: review of nonmonolithic life-cycle develop-ment models Science direct Volym 31, utgåva 1 (1989) 7–20.

[12] G. T. Leavens, C. Yoonsik, Iowa State University, A Simple and Practical Approachto Unit Testing: The JML and JUnit Way Department of Computer Science (No-vember 2001) http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.92.9880&rep=rep1&type=pdf, 2012-07-21

[13] Google, Inc, Google Scholar http://scholar.google.se/schhp?sciui=1&hl=sv&as_sdt=0, 2012-04-10

[14] G. Miller, J. Williams, The Web Services Debate. Communications of the ACM Vol46 No 6 (Juni 2003)

[15] H. K. N. Leung, P. W. L. Wong, A study of user acceptance tests. Software QualityJournal 6 (1997) 137–149.

40

[16] Hewlett-Packard, Hewlett-Packard Development Company, L.P., http://www8.hp.com/se/sv/hp-information/index.html, 2012-02-13

[17] H. Huang, J. Offutt, Y. Wu, X. Du, Bypass Testing of Web Applications, http://ieeexplore.ieee.org.proxy.mah.se/stamp/stamp.jsp?tp=&arnumber=1383117,2012-06-16

[18] H. Huang, J. Offutt, Y. Wu, X. Du, Modeling and Testing of Dynamic Integ-ration Aspects of Web-based Applications, http://cs.gmu.edu/~offutt/classes/821-webtest/papers/webmodel-821.pdf, 2012-06-16

[19] J. Meloni, M. Telles, PHP 6 Fast and easy web development. Course Technology (2008)

[20] J. Murach, A. Steelman, Murach’s Java servlets and JSP 2nd Edition. Murach (2008)

[21] J. Corbin, J. M. Morse, The Unstructured Interactive Interview: Issues of Reciprocityand Risks When Dealing With Sensitive Topics Qualitative Inquiry Volym 9, utgåva 3(2003) 335-354.

[22] L. T. Eriksson, F. Wiedersheim-Paul, Att utreda, forska och rapportera 8 upplagan.Liber AB (2006)

[23] M. Khalifa, J. M. Verner, Drivers for Software Development Method Usage. In IEEETransactions on Engineering Management Vol 47 No 3 (2000) 360-361.

[24] M. Desertot, D. Donsez, P. Lalanda, A Dynamic Service-Oriented Implementation forJava EE Servers. LSR-IMAG Domaine Universitaire France (2006)

[25] M. Hall, S. Krasner, Java Integrated Development Environments (IDEs) and Editors,http://www.apl.jhu.edu/~hall/java/IDEs.html, 2012-05-05

[26] Microsoft, .NET for business, http://www.microsoft.com/net/businessmanagers,2013-01-14

[27] Microsoft, Visual Studio editions, http://www.microsoft.com/visualstudio/eng/products/visual-studio-overview, 2013-01-14

[28] Mono, FAQ: General, http://www.mono-project.com/FAQ:_General, 2013-01-14

[29] Oracle, Java, http://www.oracle.com/us/technologies/java/features/index.html, 2012-02-13

[30] Oracle, Java 2 Plattform EE, http://docs.oracle.com/javaee/1.3/api/javax/servlet/ServletRequest.html, 2012-08-18

[31] Oracle, JavaServer Pages Technology, http://www.oracle.com/technetwork/java/javaee/jsp/index.html, 2012-02-13

[32] Oracle, Oracle9i Database Online Documentation, http://www.oracle.com/pls/db92/homepage, 2012-02-13

41

[33] Oracle, JDBC Database Access, http://docs.oracle.com/javase/tutorial/jdbc/index.html, 2012-05-06

[34] P. Järvinen, On research models. Juvenes-Yhtiöt (2004)

[35] PHP Group, PHP, http://php.net/, 2013-01-14

[36] PTC, Windchill, http://www.ptc.com/product/windchill/, 2012-05-06

[37] R. De Hoog, T. De Jung, F. De Vries, Constraint-Driven Software Design: An EscapeFrom the Waterfall Modell. Performance Improvement Quarterly 7(3) (1994) 49-51.

[38] S. R. Alapati, Expert Oracle Database 11g Administration. Apress (2008)

[39] Scrum.org, Scrum.org Improving The Profession Of Software Development, http://www.scrum.org/, 2012-05-06

[40] SKF, SKF Group, http://www.skf.com/portal/skf/home/about?contentId=000493&lang=en, 2012-02-13

[41] SQuirrel, SQuirrel SQL Client, http://www.squirrelsql.org/, 2012-02-13

[42] The Internet Society, SFTP, http://tools.ietf.org/id/draft-ietf-secsh-filexfer-13.txt, 2012-05-10

[43] The Apache Software foundation, Apache Tomcat4 JNDI Datasource HOW-TO, http://tomcat.apache.org/tomcat-4.1-doc/jndi-datasource-examples-howto.html,2012-02-13

[44] The Apache Software foundation, Apache Tomcat, http://tomcat.apache.org/,2012-02-13

[45] T. Butler, Towards a hermeneutic method for interpretive research in informationsystems. Journal of Information Technology No 13, sid 285-300 (1998).

[46] T. Sundström, Webbapplikationer, http://www.anvandbart.se/ab/webbapplikationer, 2012-05-04

[47] TNC, Terminologicentrum, http://www.tnc.se/modell-eller-metod.html, 2012-02-13

[48] Y-P. Chang, R-H. Hou, S-Y. Kuo, Needed Resources for Software Module Test, Usingthe Hyper-Geometric Software Reliability Growth Model. IEEE Transactions on reli-ability Vol 45 No 4 (1996) 541-542.

42