Searchanalytics. Kandidatarbete inom Data- och informationsteknik. Institutionen för Data- och informationsteknik

Storlek: px
Starta visningen från sidan:

Download "Searchanalytics. Kandidatarbete inom Data- och informationsteknik. Institutionen för Data- och informationsteknik"

Transkript

1 Searchanalytics Kandidatarbete inom Data- och informationsteknik Vincent Andersson Jonathan Daugaard David Svensson Mattias Warnqvist Institutionen för Data- och informationsteknik CHALMERS TEKNISKA HÖGSKOLA Göteborg, Sverige 2011 Kandidatarbete DATX02-27

2 SAMMANFATTNING Rapporten beskriver produktionen av ett system som skapar visualiseringar från data i sökloggar. Målet med systemet var att det skulle vara distribuerat, modulärt samt användarvänligt och ha låg responstid. Under utvecklingen har även arbetsmetoden Scrum undersökts med målet att se om den passar i liknande arbeten. Metoden som använts är i grunden Scrum, men denna har förfinats efter varje iteration för att passa kandidatgruppen. Resultatet visar att projektets syfte uppnåtts eftersom systemet som utvecklats uppfyller de krav som satts upp och arbetsprocessen anses ha passat arbetet och varit enkelt att modifiera. Rapporten innehåller bakgrund, analys, resultat, diskussion och slutsats medan genomförandeavsnitt återfinns i separata sprintrapporter.

3 ABSTRACT The report describes the production of a system for creating visualizations from search engine logs. The aim was to create a distributed and modular system with high usability and low response time. During the process Scrum has also been examined to see if the method is appropriate for projects similar to the one described in the report. The core methodology consisted of Scrum, which was then fine tuned after each sprint to fit the requirements of the bachelor s group. The result fulfills the aim of the project since the application meets its requirements and the methodology has been found to work well, and to be easy to adjust. The report does not contain an implementation section since this is presented in separate sprint reports.

4 FÖRORD Vi vill inleda med att tacka Henrik Strindberg samt övrig personal på Findwise. Vi vill även tacka vår handledare Sven-Arne Andreasson.

5 INNEHÅLLSFÖRTECKNING 1 Inledning Syfte och effektmål Rapportens struktur Bakgrund 2 2 Metod Scrum 5 3 Analys och resultat Scrum Mjukvarans delar 7 4 Vidareutveckling och vidare forskning Databas utan krav på datastruktur Datamining Integration 16 5 Diskussion Slutprodukten Har vi nått målen? Feedback från produktägaren Scrum 18 6 Slutsats 20 7 Källhänvisning 21 Appendix A Sprintrapport 1 Sprintrapport 2 Sprintrapport 3 Sprintrapport 4 Sprintrapport 5

6 1 INLEDNING Denna rapport behandlar framtagandet av ett webbaserat verktyg för att visualisera data från sökloggar. För att underlätta informationsåtkomsten för sina anställda har en mängd större organisationer börjat använda interna sökmotorer för att hitta bland dokument och annan information. Förutom att ge snabbare tillgång till information för den anställda, kan data från dessa sökmotorer också ge värdefulla insikter för organisationen. När en sökning görs av en anställd kan sökningen loggas. Genom att sammanställa data om sökningar från sökmotorns samtliga användare kan mönster uppmärksammas, behov belysas och trender granskas. Detta projekt är ett försök att utveckla ett webbaserat verktyg för att visualisera data från dessa sökloggar på ett snabbt och flexibelt sätt. Projektet är genomfört tillsammans med företaget Findwise 1, som är ett konsultbolag specialiserat på sökteknik. Den data som systemet är utvecklat kring kommer från den söktjänst som Findwise utvecklat för SKF 2. Findwise har tidigare försökt implementera en lösning på samma problem men inte nått fullgott resultat. De vill kunna använda mjukvaran internt, för att förbättra sina övriga produkter, samt visa upp den för kunder för att se om det finns kundvärde i produkten. Denna rapport är främst riktat till studenter inom data- eller informationsteknik och det antas att läsaren har en grundläggande kunskaper inom mjukvaruutveckling. 1.1 SYFTE OCH EFFEKTMÅL Projektets mål är att skapa mjukvara som kan hantera och skapa rapporter från sökloggar från Findwise produkter. Mjukvaran skall ha flera abstraktionsnivåer som möjliggör anpassningar genom byte av komponenter. Programmet skall kunna lagra och visualisera data. Programmets responstid ska vara låg. Användarvänligheten ska vara hög. För att förstärka nyttan av projektet måste slutprodukten kunna vidareutvecklas såväl in-house som externt. Det system som produceras för Findwise skall kunna användas som en färdig produkt hos kunder. Det skall också användas för att utreda kundvärdet i ett system som tar fram visualiseringar och statistik från sökloggar, något som skall hjälpa Findwise att vidareutveckla sina tjänster och på så sätt behålla och ta marknadsandelar. Förutom att utveckla produkten så har arbetet även haft som syfte att undersöka och dokumentera användandet av den agila metoden Scrum

7 1.2 RAPPORTENS STRUKTUR Delsyftet med att spegla arbetssättet Scrum har fått spegla rapportens struktur. Därför har stora delar av genomförandet och den löpande analysen flyttats ut till fem stycken sprintrapporter. Var och en av sprintrapporterna beskriver arbetet samt reflektioner kring både utveckling och arbetssätt för respektive sprint. Som en följd av detta går denna huvudrapport inte in i detalj angående genomförande. Istället beskrivs analys och resultat i ett delat avsnitt efter en beskrivning av den metod och de utvecklingsverktyg som använts. Därefter följer tankar kring vidareutveckling och ett diskussionsavsnitt som även innefattar diskussion kring metod. Avslutningsvis ges de slutsatser som arbetet har lett till. 1.3 BAKGRUND I kommande avsnitt ges en bakgrund till grundläggande koncept i rapporten. Först förklaras sökloggsanalys, sedan arbetsmetoden Scrum och till sist användarhistorier samt tidigare lösningar SÖKLOGGSANALYS Någon omfattande forskning kring sökloggsanalys har inte skett, men vissa beskrivande texter samt paralleller dragna till andra typer av logganalys har gjorts. Vad det gäller beskring av området samt definition av centrala begrepp kan framför allt Jansens Search log analysis: What it is, what's been done, how to do it nämnas (Jansen 2006). Jansen beskriver sökloggar som en typ av transaktionslogg (Jansen 2006). En transaktionslogg i sin tur beskrivs som en logg över kommunikation(transaktioner) mellan ett system och dess användare. Vidare definierar Jensen tre steg för att utföra analys av sökloggar/transaktionsloggar: insamling, förberedelse och analys. 1. Datainsamling (Data Collection) Först måste data samlas och detta sker när en användare utför en sökning. I de flesta fall sparas denna information i loggfiler specifika för servern som sökmotorn körs på eller i ett format specialutvecklat av söktjänstens utvecklare. 2. Förberedelse (Preparation) När väl data är insamlad, förbereds den för analys. Det handlar framför allt om att lägga in den i en databas och formatera den på ett lämpligt sätt (Jansen). Under förberedelsen kan också data som ej är önskvärd tas bort. 3. Analys (Analysis) När sökloggarna är i ett lämpligt format i databasen kan den analyseras för att hitta samband. Möjliga analyser kan delas upp på tre nivåer: a. Term - Analys för enstaka ord, t ex: job b. Fråga (query) - Analys av en fullständig söksträng, t.ex. job posting 2

8 c. Session - Analys av flera frågor efter varandra av en och samma användare under en begränsad tidsperiod. Sessionsanalys visar ofta på en förfining eller specificering av sökfrågor, t ex 1: jobs, 2. job postings, 3: job postings Gothenburg I det här projektet var insamlingen av data gjord vid projektets start. Insamling av data har endast berörts i mycket liten utsträckning under projektets slutfas. Vad det gäller förberedelse av data så har framförallt databasoptimering varit aktuellt. Projektet har framförallt handlat om steg 3 i Jensens definition, analys av data och då framför allt på frågenivå. Vidare kan projektet klassificeras mer som ett verktyg för att möjliggöra analys av data snarare än ett verktyg som genomför analys SCRUM Scrum är en agil utvecklingsmetod vilket innebär att istället för att lägga stor fokus på att planera hela utförandet i projektets inledning planerar man istället för att saker förändras. Huvudidén är att man bygger projektet i mindre omgångar, sprintar, som alla resulterar i en köroch testbar produkt men som saknar en del av den funktionalitet som slutprodukten förväntas ha. Som andra agila metoder sätter även Scrum kunden i centrum genom att utse en person från kundens sida som ansvarar för kundens önskemål. Denna person kallas produktägare. Utvecklingsgruppen har också en ledare, scrum master, som leder alla möten och ser till att gruppen arbetar åt samma håll. Scrum mastern har också till uppgift att skydda utvecklarna från produktägaren. Varje sprint inleds med att utvecklingsgruppen och produktägaren kommer överens om vad som ska göras den nästkommande perioden på ett sprintmöte. Detta i jämförelse med vattenfallsmetoden där utvecklingsgruppen i början av projektet genomför en detaljerad analys där alla krav låses. Efter sprintmötet arbetar utvecklingsgruppen självständigt från produktägaren. När sprinten når sitt slut hålls ett retrospectivemöte där framstegen visas upp för produktägaren och denna kan kontrollera att projektet är på väg åt rätt håll. Tanken är att man på så sätt bara ska behöva göra om en kortare periods arbete om något krav ändrats istället för att behöva göra om hela projektet. Agil utveckling i allmänhet och Scrum i synnerhet är inte bara en teoretisk metod utan har visat sig fungera mycket väl i ett stort antal projekt, (Green 1999; Alliance 2007). För att stödja arbetet används en whiteboardtavla eller liknande som ett schema och en fast punkt för utvecklarens dagliga arbete. På tavlan finns alla arbetsuppgifter för den aktuella sprinten anslagna på Post-It-lappar. Man indikerar direkt på tavlan vad man arbetar med, vilka andra arbetsuppgifter som måste lösas innan man kan fortsätta och så vidare. Under sprintarna genomför utvecklarna så dagliga korta möten, så kallade daily stand-ups. På mötena presenteras vad som gjorts sedan förra stand-upen, vad ska göras kommande dag och vilka problem som uppstått. Detta leder till att gruppmedlemmarna får högre förståelse för hela systemet och kan hjälpa varandra med problem. 3

9 1.3.3 USER STORIES/ANVÄNDARHISTORIER Istället för en omfattande kravspecifikation är kraven från produktägaren formulerade i så kallade user stories (användarhistorier). En user story är kort mening som beskriver en användarroll, en handling som denna ska kunna genomföra och varför. Ett exempel på detta kan vara: Som säljare vill jag kunna generera ett histogram över hur antalet sökningar varierat det senaste året, detta för att kunna locka fler kunder. För en utvecklare är det främst rollen och vad som ska genomföras som är intressant och därför utelämnas ofta anledningen. En user story talar om vad som är det förväntade slutresultatet men inte vad som krävs av mjukvaran för att åstadkomma detta. Därför bryts under sprintmötet alla enskilda user stories ner till ett flertal steg som måste uppfyllas för att slutmålet ska uppnås TIDIGARE LÖSNINGAR Findwise har tidigare haft en databas för att hantera sökstatistiken. Den har dock inte varit kopplad till ett webbgränssnitt utan istället så har Excel använts för att göra visualiseringar, något som varit för långsamt för att användaren ska kunna arbeta smidigt. För att kandidatgruppen ska se vad som inte har fungerat tidigare har Findwise gjort databasdesignen tillgänglig. 4

10 2 METOD Under projekts gång kommer metoden Scrum användas vilket var ett önskemål från produktägaren. Det kommer även användas ett antal utvecklingsverktyg för att förenkla utvecklingsprocessen. 2.1 SCRUM Att jobba iterativt är nästan en självklarhet i moderna mjukvaruprojekt. Allmänt för dessa iterativa, agila metoder gäller att de inte innehåller några direkt obligatoriska moment. Man använder helt enkelt de delar som passar och stryker resten eller plockar in delar från någon annan metod. Under detta arbete kommer kandidatgruppen behöva anpassa sig efter scrum, men även anpassa metoden till gruppens arbetssätt. Detta kommer vara en process som sträcker sig över stora delar av projektet och nya arbetssätt skall testas då en förbättring verkar möjlig. Under arbetet kommer rollen produktägare innehas av gruppens handledare på Findwise. Det kommer även finnas en scrum master samt ett utvecklingsteam. Varje sprint kommer sträcka sig över en period av två arbetsveckor och inledas med ett sprintplaneringsmöte. Under planeringsmötet kommer user stories finfördelas till uppgifter som sedan värderas. Efter sprintens gång kommer ett retrospective möte hållas där resultatet från sprintens arbete demonstreras för produktägaren och eventuellt andra intressenter. Då produktägaren även är gruppens handledare på Findwise kommer denne även närvara under de delar av sprintmötena där en produktägare normalt ej skulle närvara. Under dessa delar kommer handledaren dock inte inneha produktägarrollen. Kandidatgruppen kommer inte ha tillgång till en beständig whiteboardtavla, där den aktuella sprintens arbete kan följas som är brukligt inom scrum. Det kommer därför testas alternativ till denna med startpunkten i det webbaserade verktyget Pivotal Tracker. För att se till att resultatet motsvarar användarens förväntningar kommer produktägaren ha kontakt med intressenter både hos Findwise och deras uppdragsgivare SKF. Detta kommer även innebära att kandidatgruppen genomför presentationer och demonstrationer för intressenterna UTVECKLINGSVERKTYG Under kandidatarbetet kommer gruppen till stor del följa Findwise val gällande utvecklingsverktyg. Detta för att arbetet ska vara lätt att lämna över vid kandidatarbetets slut men även för att Findwise expertis ska kunna utnyttjas till fullo. Vissa saker som användandet av applikationsservern Tomcat, versionshanteringssystemet Subversion, byggverktyget Maven och testramverket JUnit var krav från Findwise sida. I så här stora system underlättas arbetet om man använder ett IDE, Integrated Development Environment. När det gäller Java finns det två stora open source-varianter, Eclipse och Netbeans. Det visade sig att Eclipse integrering med Maven var bristfällig. Netbeans integrerar enkelt genom ett plugin vilket motiverade valet av Netbeans, dessutom använde utvecklarna på Findwise också Netbeans. 5

11 3 ANALYS OCH RESULTAT Följande kapitel tar upp hur krav och processer analyserats och lösts under projektet. 3.1 SCRUM Arbetsprocessen har kontinuerligt förändrats under projektets gång. En del ändringar orsakades av svårigheter som var kända från början medan andra är resultatet av problem som uppstått efter hand. Vissa ändringar har även genomförts för att åstadkomma en slutprodukt som motsvarar kraven från Findwise ROLLER Efter att handledaren på Findwise guidat kandidatgruppen genom de olika möten som genomförs under en sprint tog medlemmarna själva över ansvaret för mötena. Tanken i projektets startfas var att en anställd på Findwise skulle agera scrum master åt gruppen men detta visade sig inte möjligt. För att alla medlemmar i gruppen skulle få prova på så stor del av metodiken som möjligt infördes ett rullande schema för vem som skulle agera scrum master, länken mellan produktägaren och utvecklargruppen. Produktägaren fick således också större frihet i att prioritera user stories utan att ta hänsyn till gruppens arbetsätt och därför fokusera på att få en önskvärd slutprodukt istället för att ta hänsyn till gruppens arbetsbelastning VÄRDERING AV USER STORIES En stor del av planeringsmötet inför varje sprint går åt till att värdera arbetsbördan för alla uppgifter. Enheter på värderingen är egentligen inte intressant då det är den relationen mellan de olika uppgifterna som avgör hur tidskrävande det är. Har man har två uppgifter, A och B, där A tar dubbelt så lång tid som B, ska värderingen för A vara dubbelt så stor som värderingen för B. För enkelhet valdes att använda mantimmar som enhet. Det betyder att en uppgift med värderingen 4 tar antingen en person 4 timmar att genomföra, två personer 2 timmar var och så vidare. Tidsåtgången för värderingen minskade markant under projektets fortlöpning. I början saknade kandidatgruppen erfarenhet om systemets omfattning och kunskapen att tidsbedöma arbete. Det iterativa arbetssättet gav upphov till att liknande delar av arbetet vid tillägg av ny funktionalitet hade genomförts tidigare. Detta gjorde att uppgiften enkelt kunde estimeras då loggar av tidsåtgång under tidigare sprintar fanns sparade KOMMUNIKATION INOM GRUPPEN En hörnsten i Scrum är att utvecklingsgruppen arbetar på samma plats, något som sällan passat i gruppmedlemmarnas olika scheman. Detta har medfört att det korta dagliga möte som traditionellt genomförs i scrum inte varit möjligt att genomföra. På grund av detta kan frågor inte ställas direkt till en person och det är svårt att veta vem som arbetar med vad. Under kandidatarbetet har därför ett flertal substitut provats för att kunna uppnå samma resultat trots att utvecklarna inte träffas. Resultatet som kandidatgruppen nådde var att inget substitut med direktkontakt används. Istället dokumenteras vem som skall arbetar med vad och även ungefär när arbetet skall genomföras i sprinten under planeringsmötet och frågor ställs via mail. 6

12 3.1.4 SCRUMTAVLAN Centralt i Scrum finner man whiteboardtavlan och för att arbeta effektivt utan en Scrumtavla krävdes en del testande. Som resultat efter test av flera metoder användes Post-It-lappar vid planeringsfasen och sprintens scrum master ansvarade sedan för att dessa fördes in i ett kalkylblad. Detta kalkylblad var något mer begränsande än vad en tavla är. Det innehöll endast uppgiftens namn, dess värdering, ansvarig gruppmedlem samt i vilken av sprintens två veckor denna skulle utföras i. Frekvent mailkonversation blev således nödvändig för att fastställa vilka uppgifter som var slutförda ANVÄNDARKONTAKT Produktägaren representerar generellt flera användare och även i detta projekt var fallet så. Kandidatgruppen genomförde därför ett flertal presentationer för dels intressenter. De presentationer som genomfördes var på Findwise månadsmöte där projektets status redogjordes för, en slutpresentation på Findwise, en presentation och demonstration på Findwise kund SKF samt ett överlämningsmöte för fortsatt utveckling. Utöver presentationer har körbara iterationer under projektets gång installerats på Findwise interna nät där anställda har kunnat testa systemet. Dessa har genererat feedback som sedan diskuterats i samråd med produktägaren. I projektets slutfas påbörjades även en testning för användare från SKF. 3.2 MJUKVARANS DELAR En del av problembeskrivningen var att systemet skulle vara modulärt. Produktägaren ville att systemet skulle bli uppdelat i delarna databas, datalager, tjänstelager och webblager. Lagrena datalager och tjänstelager ska köras på samma maskin och i övrigt så ska systemet kunna vara distribuerat på flera olika maskiner, se bilden nedan för bättre översikt. Figur 1. Systemets övergripande arkitektur. De streckade linjerna indikerar vilka lager som kan driftsättas på fristående servrar. 7

13 3.2.1 DATABAS Ett viktigt steg i analysfasen var att komma fram till en databasdesign som är snabb men samtidigt flexibel nog för att kunna hantera den varierande data en söklogg innehåller. Då Findwise tidigare haft en databas för att hantera sökstatistiken är ett naturligt första steg i optimering att testa och analysera prestandan för några vanliga frågor mot den. Analysen visade att inga index eller genomtänkta datatyper har används. Detta har medfört att databasen i sitt ursprungliga utförande ej varit lämplig för något annat än att stoppa in information i och väldigt begränsad uthämtning. För att optimera databasen så kontrolleras vad som är den mest relevanta informationen. Behovet från produktägaren är att sökord och datum ska vara snabba att komma åt. Förändringarna blev därför att göra en databasdesign som använder korrekta datatyper och att lägga in index. Vidare så görs en utbrytning av redundant information i datatypen VARCHAR och ersätts av ett id-nummer av typen INT istället, se bilden nedan för exempel. För mer detaljer se sprintrapport 2,3 och 4. Figur 2. Hur förändringen av databasen har gått till gällande val av datatyper. Efter förändringarna i databasen så ökade hastigheten kraftigt. De frågor som går snabbt att genomföra är: Vilka de mest eftersökta orden är och hur många gånger de blivit sökta Hur mycket de olika entrypoints har används Hur mycket som sökts från olika länder. Med de ovanstående grundfrågorna kan stora delar av de andra frågorna lösas. Till ett flertal av frågorna kan även filter adderas vilka begränsar resultatet, ett exempel på detta är att det går att ta fram de sökord som varit vanligaste i Tyskland under DATALAGER Findwise ställde krav på att datahantering måste skötas på ett smidigt sätt samt att alla komponenter måste kunna bytas utan att påverka varandra. För att datalagret ska vara oberoende av underliggande databas behövs ett ramverk som sköter hantering och översättning av databasfrågor samt hanterar kopplingen mot databasen, ett ramverk som uppfyller detta är Hibernate. 8

14 Hibernate är ett ramverk som tillåter kommunikation med ett flertal relationsdatabaser 3. Ramverket konfigureras genom en fil vid namn hibernate.cfg.xml som berättar var databasen finns, användarnamn, lösenord och ett antal andra saker. Genom endast en mindre förändring i konfigurationsfilen så går det att byta databastyp. För att Hibernate ska fungera behövs klasser som modellerar databasens struktur, dessa kan genereras från en befintlig databas eller skapas från grunden. Om typsäkrade frågor skall användas behövs även klasser som modellerar de olika svar som ges. Anledningen till att svaren har separata modeller är att vissa svar inte består av hela objekt så som de ser ut i databasen. Ett bra exempel på detta är sökningar efter de högst rankade sökorden. Svaret som fås är ett sökord och ett heltal med antalet sökningar. Detta är en beräkning av värden i databasen och finns på så sätt inte lagrat någonstans. För att minimera antalet tunga frågor som går till databasen så implementeras en cachefunktion. Det finns ett flertal olika cachefunktioner som fungerar direkt med Hibernate, se (Shanmugam) för mer inblick i vilka som finns och hur de används. I detta system valdes Ehcache eftersom den är lättviktig, snabb, enkel att implementera och stödjer de operationer som behöver utföras på databasen. Det finns ett antal andra färdiga cachefunktioner att välja bland. Den funktionalitet som vissa av de andra alternativen erbjuder är möjlighet till mer konfigurering, stöd för clusterbaserade databaser och äkta transaktionssäkerhet.. Då dessa egenskaper inte är något som eftersökts och Ehcache egenskaper är fullgoda för hur det är tänkt att användas så väljs den. För att lager ovanför datalagret skall bli oberoende av datalagrets implementation behövs ett standardiserat gränssnitt som kan användas av andra komponenter som vill få fram sökningsdata. Detta har lösts genom att ett Javainterface specificerats. Varje frågetyp hanteras av en klass i datalagret som implementera ovan nämnda interface och klasserna ansvarar för att ansluta till databasen och hämta de önskade objekten själva TJÄNSTELAGER Tjänstelagrets primära funktion är att förmedla informationen från datalagret vidare mot användaren. Detta görs utan att ändra eller påverka informationen utan endast ändra representationen av den. Syftet med att tjänstelagret är att tydligt avgränsa datalagrets uppgift till att enbart vara en informationshämtare samt att göra databasens data åtkomlig utifrån. Detta görs genom att standardisera informationen mellan datalagret och tjänstelagret med ett Javainterface, se datalager för mer detaljer. För att tjänstelagret och datalagret på ett enkelt sätt ska kunna köras på en separat server ska tjänstelagret exponera en webbtjänst. Några tekniker som kan användas för att skicka meddelanden till och från en sådan är REST och SOAP. Dessa akronymer står för REpresentational State Transfer och Simple Object Access Protocol. Båda dessa använder HTTP-protokollet för att dela data mellan två applikationer eller maskiner, men det finns ett par skillnader. REST förlitar sig på existerande tekniker medan SOAP använder nya XML-specifikationer. I detta arbete valdes REST då det är en simplare och lättare arkitektur(asaravala 2002). Detta gjorde att det gick enkelt att implementera utan speciella utvecklingsverktyg. 3 9

15 3.2.4 WEBBLAGER Webblagret innehåller ett användargränssnitt för att kunna ta fram visualiseringar och en MVCstruktur som understödjer det arbetet. Först redovisas den arkitektur som uppnåtts och sedan ges en inblick i hur användargränssnittet ser ut och fungerar. Arkitektur Mycket arbete har lagts ner på att uppnå en god ansvarsuppdelning där paket och filer sköter väldefinierade uppgifter. Kodbasen kan i stort delas upp i kod som körs på serversidan och kod som körs på webbklienten. På serversidan är koden skriven i Java med Spring MVC som ramverk och på klientsidan är koden framförallt skriven i html och JavaScript med hjälp av biblioteken jquery och Google Visualization API. Struktur på serversidan Koden på serversidan har delats in i två kategorier som behandlas var och en för sid nedan. Navigationskontroller och modeller Eftersom den sista versionen av användargränssnittet endast innehåller en sida behövs endast en navigationskontroll. Förutom att se till att rätt vy returneras ansvarar kontrollen också för att alla länder som finns i databasen skickas med till vyn så att användaren kan använda dessa för att filtrera sina sökningar. Datakontroller De klasser som kategoriseras som datakontroller används för att koppla samman webblagret med tjänstelagret. För att kunna göra det innehåller klasserna metoder som givet ett antal parametrar kan genomföra anrop till tjänstelagret. Som svar på anropen fås ett XML-dokument som plockas isär och delarna används för att skapa ett dataobjekt som sedan konverteras till ett JSON-dokument som är specialanpassat för Google s grafer. JSON-dokumentet skickas sedan till den klient som utfört det ursprungliga anropet. I praktiken innebär det att det hela kan ses som två REST-gränssnitt, ett på tjänstelagret som producerar XML och ett i datakontrollerna som producerar JSON. Skapandet av JSON skulle kunna flyttas till tjänstelagret, men då skulle tjänstelagret bry sig om ett specifikt grafbibliotek något som inte ansågs lämpligt. Datakontrollerna skulle även kunna flyttas ut till en egen WARfil och på så vis kunna köras på ytterligare en server. Struktur på klientsidan Det finns fyra JavaScript-filer som tillsammans ansvarar för funktionaliteten i användargränssnittet och i synnerhet formuläret för att ställa frågor. form-changer.js ser till att formuläret anpassas dynamiskt för den typ av fråga som ska ställas. form-fixer.js sköter skapandet och borttagandet av nya element. Graferna ritas upp av Graph.js men det är form-fixer.js som lägger in graferna på den aktuella sidan. form-validator.js genomför som namnet säger valideringar av formuläret innan formulärdata skickas vidare till datakontrollerna. 10

16 event-handlers.js sköter hantering av klickhändelser i grafer så att kontextuella navigeringar mellan grafer kan genomföras. En annan JavaScript-fil som spelar en mycket central roll är Graph.js som är ett JavaScriptbibliotek för att hantera uppritandet av diagram. Filen är i första hand en wrapper kring Google Visualization API och gör så att grafer kan hanteras mer generellt i resten av applikationen. Grafer skapas genom att köra en initialiseringsfunktion i Graph.js med framför allt graftypen samt en data-url som parametrar. Data-URL:en är URL:en till datakontrollen (se ovan) som sköter datahämtning från tjänstelagret för den aktuella typen av fråga. Anropet sker asynkront och när ett svar kommit körs en svarsfunktion som laddar en graf från Google Visualization API, adderar den aktuella data och sedan lägger till grafen på sidan. Anledningen till att webblagret ser ut som det gör är en följd av ett antal designbeslut som tagits under projektets gång. På webblagret är det framförallt användarens upplevelse som varit i centrum och många beslut har tagits för att förbättra denna. Uppdelningen av kod har också gjorts för att det ska vara lätt att hitta i projektet för en ny utvecklare vid eventuell vidareutveckling. Webbgränssnittets är uppdelat efter principen att varje fil ska innehålla kod som ansvarar för en sak, varken mer eller mindre (Seperation of Concerns)(Hürsch and Lopes 1995). I tidiga sprintar hjälpte MVC-strukturen att uppnå detta men allt eftersom användargränssnittet blev mer baserat på JavaScript gick det inte att hantera på samma sätt. Istället skedde ett flertal utbrytningar av funktionalitet för att varje JavaScript-fil skulle få ett eget ansvarsområde. Anledningen till att användargränssnittet skapades på en enda sida var att dra ner på de upplevda väntetiderna för slutanvändaren. De olika delarna av formuläret laddas direkt när sidan visas även om vissa delar är dolda. Att all hämtning av data och grafer sker asynkront, med en tydlig indikation om att datahämtning sker, infördes för att kunna ge användaren feedback på vad som händer. Användargränssnitt Det webbaserade gränssnittet är den enda komponent som en slutanvändare behöver använda för att ta fram en visuell representation av sökmotorstatistiken. Gränssnittet skall tillhandahålla möjligheter för en användare att skapa en databasfråga genom användningen av vanliga komponenter som datum-, heltal- och textfält. Vidare skall användaren också kunna välja hur den data som efterfrågats skall representeras. Målet med användargränssnittet var att på ett flexibelt sätt låta användaren ta fram grafer för olika typer av frågor. Som utgång för designen användes Nielsens tio heursestiker för användbara användargränssnitt(nielsen 2005). Framförallt lades vikt på att användaren skulle känna igen sig och att användaren ska få feedback på sina handlingar. Användargränssnittet har förändrats under projektets gång i ett kontinuerligt försök att förbättra användbarheten. Till en början låg de olika frågetyperna på varsin sida med varsitt formulär eftersom det var det enklaste sättet att lösa systemets funktionalitet. För varje iteration har gränssnittet blivit bättre och i slutprodukten har alla formulär slagits ihop på en sida. Vidare så sker alla hämtningar och tillägg av grafer dynamiskt vilket gör att användaren aldrig behöver ladda om sidan. 11

17 Figur 3. Bilden visar hur systemets gränssnitt ser ut innan en frågetyp har valts. Knapparna till vänster på bilden ovan representerar de olika frågetyper som användaren kan få svar på och komponenterna i mitten är de inmatningsfält som delas av frågetyper. Bilden nedan visar hur det ser ut när man väljer en frågetyp och därmed får ytterligare valmöjligheter. De nya fälten visas automatiskt så sidan behöver aldrig laddas om. Figur 4. Bilden visar systemets gränssnitt efter att en användare har specificerat vilken typ av fråga som skall ställas. När användaren väl klickat på add läggs den valda grafen till under formuläret. För varje gång som användaren lägger till en ny graf så läggs den till ovanför de gamla och på så sätt kan man titta igenom sin historik genom att scrolla nedåt. 12

18 Figur 5. GUI efter att en graf blivit hämtad. Grafen som syns nedan är en av den fem graftyper som användargränssnittet stödjer. Kryssknappen i övre högra hörnet kan användas för att ta bort en graf som man inte längre är intresserad av. 13

19 Figur 6. En värmekarta som visar hur det totala antalet sökningar i systemet fördelar sig över världens länder. Med hjälp av en graf kan kontextuella navigeringar genomföras, vilket innebär att användaren med hjälp av data från ett diagram kan ta fram ett nytt diagram. Ett möjligt scenario är till exempel att en användare tar fram ett diagram med de mest eftersökta orden under en tidsperiod. Diagrammet visar att det populäraste ordet har varit analytics vilket gör användaren nyfiken på hur trenden för det ordet sett ut under samma period. Allt som han behöver göra då är att klicka på ordet i grafen så visas en meny som länkar till andra diagram som kan visas för analytics och däribland en trendgraf. Dessa kontextuella navigeringar gör att det går mycket snabbare att ta fram närliggande diagram om ett ämne och gör följaktligen systemet lättare att använda. Distribuering För att uppnå kravet på att systemet skall gå att distribuera över ett flertal servrar behövdes enkla medel för att konfigurera på vilka adresser de olika lagren befinner sig. Den distribuering som tillåts är över tre servrar, en databasserver, en server som kör data- och tjänstelagret samt en webbserver för användargränssnittet, se figur 1 för systemarkitektur. Eftersom både databasen och tjänstelagret skickar svar till den adress frågan kom från behövdes således två konfigurationsfiler. En i datalagret som talar om vart databasen befinner sig och en i webblagret som talar om vart tjänstelagret ligger. Hibernate's konfiguration Hibernate's konfigurations fil hibernate.cfg.xml måste finnas i datalagrets classpath för att en anslutning till databasen ska kunna etableras. Eftersom datalagret inkluderas i tjänstelagret vid byggning lades denna fil i tjänstelagret. Detta gör att filen inte blir inbyggd i javaarkivet som tjänstelagret använder utan istället ligger i tjänstelagrets rootmapp. Filen ligger således fortfarande i datalagrets classpath men filen kan ändras utan att datalagret behöver byggas om, en lösning som Findwise ingenjörer föreslog. 14

20 3.2.5 KONFIGURATION AV WEBBLAGER För att det ska gå lätt att välja vilken adress webblagret ska använda för att anropa tjänstelagret behövdes även här en konfigurationsfil som kan ändras utan att bygga om applikationen. Då en generisk parser hade använts för XML-svaren från tjänstelagret ansågs det vara lämpligt att återanvända denna för att tolka en konfigurationsfil i XML. Filen läses in från classpath via klassen ClassPathResource, en inbyggd klass i Spring. Figur 7 illustrerar ett exempel på hur filen kan se ut om webb- och tjänstelagret ligger på samma server. Tagen baseuri specificerar sökvägen till huvudmappen där alla REST-resurser i tjänstelagret finns tillgängliga. Sättet konfigurationsfilen är uppbyggd på tillåter enkel utbyggnad med fler alternativ om så önskas. <Settings> <baseuri> </baseuri> </Settings> Figur 7. Exempel på konfigurationsfil 15

21 4 VIDAREUTVECKLING OCH VIDARE FORSKNING I vidareutvecklingsavsnittet tas endast stora övergripande punkter upp, medan förslag på funktionalitet har lämnats till produktägaren separat. 4.1 DATABAS UTAN KRAV PÅ DATASTRUKTUR När arbetet avslutas krävs att databasen har en viss struktur för att systemet skall fungera. Vidare arbete skulle kunna fokuseras på att kunna använda en databas utan fast struktur, som till exempel en NoSQL-lösning. Detta skulle medföra att applikationen skulle kunna användas på en bredare marknad. 4.2 DATAMINING I projektet har inga ansatser till att analysera data genomförts, något som skulle kunna arbetas vidare på. Till exempel skulle systemet kunna lära sig vad som är avvikande beteenden och ge varningar vid förändringar. 4.3 INTEGRATION Under arbetets gång har integration med andra system varit på tal vid ett flertal tillfällen. Att titta på vanliga system som används av företag och sedan skriva integrationslager eller moduler till dessa skulle göra applikationen lättare att sälja in. 16

22 5 DISKUSSION Systemet som utvecklats under kandidatarbetet hade ett huvudsyfte samt ett delsyfte. Dessa syften diskuteras var för sig i avsnitten nedan. 5.1 SLUTPRODUKTEN I följande avsnitt diskuteras huruvida slutprodukten når upp till de krav och mål som sattes upp för systemet. Först diskuteras de övergripande kraven som ställts på systemet, sedan enskilda beslut som haft stor inverkan på slutprodukten och till sist hur kandidatgruppen upplevt att Findwise mottagit produkten. 5.2 HAR VI NÅTT MÅLEN? Målet med projektet var att snabbt och enkelt producera grafer baserade på de sökloggar som fanns sparade från Findwise söktjänster. Vid projektets slut fanns en välfungerande webbapplikation som gör det lätt för en användare att få fram grafer. Användaren kan ange en mängd olika parametrar, frågeställningar och välja graftyper. Ett av de stora övergripande kraven på systemet var att det skulle vara distribuerat och modulärt uppbyggt något som uppnåtts i alla delar av mjukvaran. Att den övergripande designen inte behövt göras om beror till mycket stor del på den inledande hjälp som Findwise tillstod med. Eftersom gruppen inte hade någon erfarenhet av att designa distribuerade system skulle detta med stor sannolikhet ha misslyckats vid de första försöken. Inför den första sprinten gjordes mycket research på hur varje lager i sig bör byggas men det var mycket svårt att hitta bra information om hur man bygger hela kedjan på ett bra sätt. Modulariteten i systemet har förbättrats under varje sprint vartefter som gruppen hittat beroenden som man ej förutsett. En begränsning i modulariteten är att endast databastyper som stöds av Hibernate kan användas, något som gör att NoSQL lösningar och liknande inte stöds. Detta innebär att det skulle krävas ett helt nytt datalager för att koppla på en sådan databas. Eftersom Findwise själva har definierat att detta räknas som tillräckligt modulärt med avseende på vilka databaser som de brukar använda så får målet ses som uppnått. Ett tredje övergripande krav var att systemet skulle vara lätt att vidareutveckla av ingenjörer på Findwise, externa konsulter eller andra studenter. Detta är ett av de mer komplexa kraven eftersom det innefattar att väldigt många saker skall stämma samman. All kod måste ha Javadoc och komplicerade passager ha inline kommentarer. Det måste finnas övergripande förklaringar för hela systemet och branschstandarder behöver användas överallt där sådana finns. Alla dessa punkter kräver väldigt mycket att uppnå och i ett iterativt arbete där mycket kod försvinner efter hand är det lätt att det slarvas med dokumentation eftersom koden sannolikt kommer försvinna senare. En officiell överlämning kommer att ske efter det att projektet genomförts i sin helhet och det är egentligen inte förrän då som det går att se om målet uppnåtts eller ej. Ytterligare egenskaper som systemet skulle inneha var hög användarvänlighet och låg responstid. Eftersom det system som Findwise använde tidigare kunde arbeta med en fråga i upp till 30 minuter var det svårt att avgöra vad som är låg responstid. Egentligen borde kravet uppdaterats efter hand för att ha något att jämföra mot men det har inte gjorts. Däremot kan man utan tvekan säga att det nya systemet har en extremt låg responstid i jämförelse med det 17

23 gamla. De frågorna som tar längst tid i det nya systemet tar ungefär en minut vilket alltså är 30 gånger bättre än det gamla systemet. Användargränssnittet utvecklades i enlighet med väl beprövade tekniker för att uppnå god användbarhet. Kandidatgruppen och produktägaren är mycket nöjda med gränssnittet men formella tester hade kunnat säkerställa användbarheten ytterligare. 5.3 FEEDBACK FRÅN PRODUKTÄGAREN Under hela arbetet har responsen från produktägare och intressenter varit positiv och det faktum att kandidatgruppen har tillåtits visa upp och installera systemet hos Findwise kunder pekar tydligt på att de är nöjda med produkten. Samtidigt så finns det en annan aspekt och det är om övriga ingenjörer på Findwise är nöjda med produkten. När gruppen fick hjälp med att rulla ut systemet hos SKF poängterades vissa brister som självklart rättades till. Det hade sannolikt räckt med en mindre kodgenomgång för att säkerställa att koden håller förväntad standard, något som inte har genomförts. 5.4 SCRUM Då metoden är väldigt lättviktigt var det enkelt att sätta sig in i arbetssättet. I början märktes dock avsaknaden av erfarenhet då diskussioner drog ut på tiden och gruppen hade svårt att komma till ett beslut. Detta gällde speciellt vid värderingar av uppgifter, ett område där Findwise erfarenheter av Scrum visade sig mycket värdefulla. En viktig del av projektets uppstart var att se vilka delar av scrum som fungerade i gruppens arbetssätt. Exempel på svårigheter som uppstod var gruppens varierande scheman. Då flera i gruppen hade ickeflexibla åtagande att utföra under olika dagar var det svårt att hitta tider för arbete tillsammans. De tider alla gruppmedlemmar kunde närvara blev till stor del reserverade för de möten som inte var så flexibla, det vill säga sprintplanering och sprintretrospective. I efterhand kan det konstateras att gruppen och arbetet hade tjänat mycket om större möjlighet att arbete tillsammans och att ha dagliga möten existerat. Detta hade gett hela gruppen större insikt i alla delar av projektet samt bättre insikt i vilken gruppmedlem som arbetade med vilka delar. Under projekts gång anpassades metoden efter gruppens behov. Mycket av kommunikationen mellan gruppmedlemmarna sköttes via mail, något som fungerade ganska bra men fördröjningen vid frågeställningar gjorde utvecklingen lite långsammare. Att gruppen inte hade tillgång till en whiteboardtavla var synd. Förmodligen hade detta förenklat arbetet avsevärt då det alltid hade varit klart vem som gjorde göra vad, vilka saker som var slutförda och i vilken ordning uppgifter behövde utföras. Skulle man göra mer utförliga undersökningar kan man säkert hitta ett digitalt verktyg som kan utföra detta nästan lika smidigt som en tavla. Detta var dock inget som ingick i kandidatarbetets problembeskrivning. Den lösning med ett kalkylblad som användes mot projektets slut fungerade tillräckligt bra och hade man utvecklat den lite mer skulle man kanske lägga mer kraft på att uppdatera status på de olika uppgifterna oftare. Rollen som Scrum master var intressant att testa och innebar till stor del att försvara besluten om hur mycket nya user stories som gruppen kunde åta sig under varje sprint. Rollen som scrum master gav också värdefull erfarenhet av att leda möten och se till att hela gruppen jobbade åt samma håll. Det hade varit intressant att se hur en person med mer erfarenheter i denna roll hade agerat under senare delar av projektet något som tyvärr var för svårt att genomföra. Att 18

24 inneha rollen som Scrum master visade också hur viktigt det är att leverera i enlighet med sina åtaganden. Att inte lova för mycket som inte går att genomföra men samtidigt producera tillräckligt mycket för att tillfredställa produktägaren. Upplevelsen av Scrum som arbetsmetod har under arbetets gång varit positiv. De regelbundna mötena med produktägaren har hela tiden fört arbetet framåt eftersom ny funktionalitet har efterfrågats kontinuerligt. Att efter varje sprint presentera körbara exempel gjorde att fokus låg på att producera ny funktionalitet vilket i sin tur drev behovet att förbättra kvalitén på befintlig kod. Hade inget gjorts för kodens kvalité hade den nya funktionaliteten inte kunnat integreras väl. Detta innebar i vissa fall att byta ut egenskriven kod mot färdiga bibliotek som det tidigare inte lagts tid på att hitta. Detta innebär att koden får bättre kvalitet när mer funktionalitet läggs till. En annan central del av Scrum är att kraven samlas in under processens gång i till skillnad från vattenfallsmodellen där samtliga krav ska samlas in innan produktionen börjar. Detta ställer andra krav på kunden i form av att ställa en kontaktperson till förfogande för utvecklingsgruppen. Kontaktpersonen benämns produktägare i arbetsmetoden. Om detta är kostnadseffektivt för kunden har vi ej gått in på i detta projekt. Dock så är det inte sannolikt att detta projekt hade fått ett bättre resultat om resurserna varit samma och istället gjorts med vattenfallsmodellen. Detta antagande görs rent spekulativt och tar hänsyn till mängden tid som varit tillgänglig från kund, den stora mängden nya utvecklingstekniker för utvecklingsgruppen samt hur intressenter har under projektets gång påverkat projektet. 19

25 6 SLUTSATS Som en sammanfattning av resultat och diskussion kan det konstateras att projektet resulterat i ett system som är modulärt, distribuerat och har en extremt mycket lägre responstid än tidigare system. Användargränssnittet fungerar väl och relevanta grafer kan ritas upp. Målet, att utveckla en applikation som kan visualisera data från sökloggar, har därmed nåtts. Vidare kan det konstateras att Scrum visat sig vara en bra metod för mjukvaruutveckling i projekt som dessa. Det har varit lätt att ändra riktning på de delar av projektet där kraven förändrats mycket. Det har även fungerat bra att modifiera metoden efter gruppens behov. 20

26 7 KÄLLHÄNVISNING Alliance, S. (2007). Scrum Alliance Membership Survey Shows Growing Scrum Adoption and Project Success. Asaravala, A. (2002). "Giving SOAP a REST." Retrieved 0419, 2011, from Green, P. (1999). Measuring the Impact of Scrum on Product Development at Adobe Systems, IEEE Computer Society. Hürsch, W. L. and C. V. Lopes (1995). "Separation of concerns." Jansen, B. J. (2006). "Search log analysis: What it is, what's been done, how to do it." Library & information science research 28(3): Nielsen, J. (2005). "Ten Usability Heuristics." Retrieved 0501, 2011, from Shanmugam, V. "Introduction to Hibernate caching." Retrieved 0501, 2011, from 21

27 APPENDIX A Sprintrapport 1 Sprintrapport 2 Sprintrapport 3 Sprintrapport 4 Sprintrapport 5

28 SPRINTRAPPORT 1 1 SYFTE Syftet med den första sprinten var att tillverka ett distribuerat system som kan ta fram de mest eftersökta orden ur en valfri datumperiod. Vidare så skulle systemet vara mycket modulärt och uppdelat i fyra olika delar. Delarna är en relationsdatabas, datalager, tjänstelager och till sist ett gränssnitt som användaren kan ansluta till för att använda systemet. Ett underordnat syfte var att få systemet att utföra hämtningen av resultat så snabbt som möjligt. 2 METOD Under den första sprinten valdes bara en user story då sprinten blivit försenad några dagar. Det beslutades att sluttiden inte skulle ändras utan att sprinten istället skulle vara lite kortare. För att gruppen skulle förstå hur ett sprintmöte fungerar så fick handledaren på Findwise agera guide för gruppen och förklara processen. Vidare så antog han även rollerna som Scrum master och produktägare. Gruppen har inte tillgång till någon tavla så alla medlemmar har själva fått ansvara för att ta vara på de lappar som de har tilldelats och vem som gör vad. Pivotal Tracker kommer under sprinten användas för att bedöma om det fungerar som ett substitut. På de områden där Findwise inte hade angett några önskemål om vilka ramverk som skulle användas bestämdes att kortare undersökningar av alternativ skulle genomföras. Parallellt med arbetet genomfördes även informella tester på databasen för att kunna hitta och åtgärda flaskhalsar. 3 ANALYS OCH GENOMFÖRANDE Under sprinten tillverkades programvara för att lösa sprintens syfte som var att sätta upp ett modulärt distribuerat system som an ta fram de mest eftersökta orden inom ett tidsintervall. En beskrivning av hur implementering och analys gått till indelad efter de olika applikationslager som använts och möten som genomförts följer nedan. SPRINTMÖTE Innan mötet så hade ett antal önskemål på funktionalitet tagits fram och första punkten på mötets dagordning var att prioritera dessa. Nästa steg var att välja den grundläggande user story som prioriterats högst och dela upp den i olika funktionella delar. Syftet med uppdelningen var att enklare kunna bedöma tidsåtgången och svårigheten för varje del. Efter förtydligande av vissa uppgifter så fick samtliga uppgifter en uppskattad mängd tid som ansågs skulle behövas för att lösa uppgiften. I de fall då det fanns svårigheter att tidsbedöma en uppgift fick handledarens expertis användas. När detta var gjort delades varje deluppgift ut till en medlem i kandidatgruppen och ett övergripande schema över antal timmar till förfogande och vilka arbetsuppgifter som skulle utföras skapades. 1

29 Efter mötets avslut var varje gruppmedlem ansvarig för att lägga in sina uppgifter i verktyget Pivotal Tracker. Vid insättning upptäcktes att verktyget inte använde manstimmar för värdering av uppgifter. Istället användes ett system med värden från 0 till 4. Således behövdes värderingen också konverteras till denna skala. Som utgångspunkt förslogs webbtjänsten Pivotal Tracker av handledaren på Findwise. Detta verktyg hade Findwise tidigare delvis provat och kunde testas gratis i 6 månader. Detta verktyg föll på den dåliga flexibiliteten hos värderingar. Det kunde dessutom inte riktigt ersätta flexibiliteten hos Post-It-lapparna i planeringsstadiet. DATABAS En MySQL databas installerades på kandidatgruppens server och en dump av en databas innehållande sökloggar lades in. Efter att en analys av den befintliga databasen, och av hur databasen förväntas bli använd ansåg gruppen att vissa förändringar behövde göras. De kolumner som topsökningsfrågan nyttjar är datum och sökordet så därför får dessa kolumner index. DATALAGER Sökningarna och aggregeringarna i databasen går långsamt så för att minska väntan vid användning av datalager och dels för att minska antalet frågor i databasen så implementeras en cache. Detta medför att datalager kommer i första hand kontrollera om det som söks redan finns i cachen innan den använder sig av databasen. Systemet förväntas bli använt under en längre tidsperiod utan att nollställas så därför har cachen samma krav. Cachen får ej läcka minne men ska kunna ge snabbt svar på om frågan redan finns och snabbt kunna få in ny information. I cachen så lagras par av frågor och svar i form av element. Cachen implementeras med en Hashmap som gör insättning och uttag på logaritmisk tid förhållande till mängden element i cachen. För att undvika minnesläcka så blir även elementen i cachen länkade till varandra i en kedja. När ett nytt element läggs in så hamnar den först i kedjan. När ett element blir sökt på så flyttas det ett steg mot första platsen i kedjan. Om ett element ska läggas in i cachen när cachen är full så kommer det element som är sist i kedjan att kastas ut. För att datalagret skulle bli oberoende av underliggande databas så används ramverket Hibernate. Hibernate används även av andra utvecklare på Findwise och därför är favoriserat från produktägaren. Mappningsklasserna som Hibernate kräver skapas genom reverse engineering och konfigureras med annotationer istället för XML på produktägarens önskemål. För att möjliggöra kommunikation med överliggande lager så skapas ett interface och i detta deklareras en metod för att kunna hämta de mest eftersökta orden. En klass skapas som implementerar interfacet och den metod som hämtar information från databasen. Metoden använder Hibernate s egna frågespråk HQL som har en syntax som liknar SQL men är java specifik och därför kan typsäkrade frågor skapas, se figur 1 för exempel. Detta innebär att det går i frågan kan specificera vilken typ av objekt som returneras. 2

30 String query ="select new se.findwise.thesis.statistics.datamodel.model.topsearchtable(qu.query, count(qu.query))" + " from Queries qu" + " where qu.date between :start and :end" + " group by qu.query order by count(qu.query) desc"; Figur 1. Exempel på HQL fråga för ta ut typsäkrat de mest sökta orden. Eftersom det i sprinten endast skulle genomföras en frågetyp fick metoden som gör detta själv hantera öppnande och stängande av sessioner mot databasen samt att skapa och hantera Hibernate frågor. Det stod snart klart att mycket av den kod som gör detta skulle bli duplicerad i alla kommande datalagermetoder och därför valde gruppen istället en generell implementering. Den generella lösning som togs fram använder en omslagsklass för Hibernatefrågor och en metod för att utföra dessa. Omslagsklassen innehöll en HQL frågesträng samt listor för att hantera parametrar till frågan. Arbetsgången blir att metoden som genomför databasfrågor tog ett objekt av omslagsklassen som parameter, öppnar en databassession, skapar en Hibernate fråga, genomförde frågan och returnerade en lista med objekt tillbaks till den anropande metoden. För att aktivera cachen behövdes endast en rad kod för att titta om frågan redan blivit ställd och en rad kod för att lägga till frågerepresentation och resultat i cachen. TJÄNSTELAGER Att ha ett tjänstelager, som gör det möjligt att lägga datalagret och webblagret på olika servrar, var en del av önskemålen från Findwise. Enligt önskemålen skulle uppdelningen också ge möjlighet till att koppla olika användargränssnitt till samma tjänst. Sprinten innehöll bara en user story och inga fler krav ställts på tjänstelagret. Sprint 1 handlade därför om att på ett så enkelt sätt som möjligt göra kommunikation möjlig mellan de två servrarna för den specifika frågan (topplista över sökord). Vid en granskning av olika arkitekturer/protokoll för kommunikation mellan servrar övervägdes flera alternativ. Ett krav som fanns var att kommunikationen skulle vara plattformsoberoende. Webblagret skulle kunna bytas ut mot en godtycklig applikation skriven för valfritt språk och operativsystem. Java-specifika lösningar som till exempel sockets eller remote procedure calls var därför inte aktuella. Istället letades efter en standard gjord för webbaserade tjänster, och här är de stora arkitekturerna SOAP och REST. Båda är baserade på HTTP anrop och har vanligtvis meddelanden hoppackade i XML-filer. SOAP är dock en betydligt mer komplex standard och innehåller en hel del onödig funktionalitet. REST valdes alltså som arkitektur för kommunikation mellan tjänstelagret och webblagret både på grund av enkelhet att sätta sig in i och enkelhet att implementera. Till REST-tjänsten behövde sedan ett filformat som data skulle sändas i. Vanliga format är XML, JSON och HTML. Dessa tre format har gemensamt att de består av strukturerad text som är enkel att parsa för en dator men ändå är läsbar av en människa. XML valdes som format då det löste uppgiften bra och dessutom verkade vara det vanligaste formatet i sammanhanget. 3

31 För att få till funktionaliteten som användarhistorian krävde utifrån ovan nämnda beslut, behövde följande implementeras, se figur 2 nedan: Ta emot en REST-förfrågan från webblagret. Be datalagret om rätt data. skapa en XML-sträng av data. Skicka XML-filen till webblagret. Figur 2. Hur informations flöde går mellan tjänstelagret och webblagret fungerar. REST REST-anrop och svar skapades med hjälp av pluginen RESTful Web Services till Netbeans, javas standardpaket JAX-RS (javax.ws.rs) samt Jersey. Jersey är referensimplementationen av JAX-RS och implementerar koden bakom annotationerna. Java-klassen där resursen beskrivs innehåller metoder med annoteringar för vilken URI de ligger på och vilka parametrar som tas. En resurs skapades i tjänstelagret som svarar på ett HTTP-anrop med metoden GET och parametrar för att ta fram en topplista, det vill säga ett startdatum, ett slutdatum och en avgränsning på hur många resultat. Till svar skickar resursen en XML-fil. Se figur 3 för exempel. import public class public String String enddate){ String XML; return XML; } } Figur 3. Exempel på implementation av REST-resurs: 4

32 XML I denna första sprint var data som skulle skickas upp till webblagret så simpel att inga extra bibliotek användes för att bygga ihop XML-filen. Istället byggdes XML-filen ihop med vanlig konkatenering av strängar. Ett exempel på XML-filen visas i figur 4. <?XML version="1.0" encoding="utf-8"?> <statistics> <toplist> <entry> <query>foo bar</query> <sum>345</sum> </entry> <entry> <query>random things</query> <sum>120</sum> </entry> <entry> <query>key words that some one searched for</query> <sum>64</sum> </entry> </toplist> </statistics> Figur 4. Exempel på hur XML-fil kan se ut WEBBLAGER Att användargränssnittet skulle vara webbaserat var ett av önskemålen från Findwise, i önskemålen fanns även som tidigare nämnts att lagret skulle vara separerat från de övriga delarna. Då resten av utvecklingen skedde i java och Findwise gärna såg att Spring MVC användes som ramverk för webblagret valde kandidatgruppen att använda det utan någon större undersökning av andra alternativ. Vidare fanns inget specificerat om användargränssnittets funktion utöver användarhistorien så även här valdes att lösa problemet så enkelt som möjligt. Två stycken webbsidor behövs för att kunna utföra användarhistorian. Dels en sida med formulär samt en sida där resultatet visas. På första sidan ska användaren kunna välja hur många sökord som ska visas och mellan vilka datum sökningen skall gjorts. För att få tag i data använder webblagret tjänstelagret. De tre värdena från formuläret skickas till tjänstelagret med ett REST-anrop och tillbaka fås en XML-fil (se figur 4 ovan). Den andra sidan ska sedan generera ett stapeldiagram med hjälp av Google Visualization API. För detta behöver data extraheras från XML-filen och göras tillgänglig för den andra sidan så att JavaScript-koden kan använda den. 1. Webbsida med formulär 2. Skicka formulärdata till tjänstelagret 3. Ta emot XML från tjänstelagret och parsa till lämplig datastruktur 4. Visa sida med diagram från Google Visualization I slutet av sprinten lades även en funktion till för att visa felmeddelanden i webblagret, främst för att underlätta utvecklingen. 5

33 VY OCH KONTROLL I sprintmötet avsattes tid för att läsa in sig på Spring MVC, vilket är ett ramverk baserat på designmönstret MVC. MVC står för model-view-controller eller modell-vy-kontroll på svenska. Tanken är att logik och datalagring hålls i modeller och isär från presentation som sker i vyn, Kontrollen ansvarar för navigering och samsynkning av modell och vy. Med hjälp av Netbeans kunde ramverkets struktur generas. I fallet med en enkel fråga och med en logik som ligger i data- eller tjänstelagret behövdes två metoder i en kontroll med varsin vy. Den första kontroll-metoden gör i princip inget mer än att se till att vyn med formuläret renderas när användaren går in på rätt URL. Den andra kontroll-metoden tar emot data från formuläret skickar en GET-request till tjänstelagret med parametrar från formuläret. För att hålla onödiga funktioner och kod borta från första sprinten lades konverteringen från XML till Java-objekt först i denna kontroll, detta refaktoriserades sedan ut till en egen klass vid sprintens slut. Efter att XML-filen parsats renderas vyn med diagrammet. XML-PARSNING Flera olika bibliotek för att konvertera XML-filen testades, flera av dessa krånglade tillsammans med Spring eller den XML-fil som skapades i tjänstelagret, det bibliotek som först gav en fungerande lösning var dom4j. För att hitta ett element i en XML-fil behövs en syntax för att ange vilka eller vilket element som kan kommas åt, för detta finns flera standarder, framförallt SAX, Dom och Xpath. Först försöktes målet uppnås med Xpath, då denna syntax är mer kompakt och i detta fall var det inget avancerat problem som skulle lösas. Som ovan nämndes var det problem med några av biblioteken som testades och detta gjorde att Dom i slutändan användes istället för Xpath. GOOGLE VISUALIZATION API För att rita grafer i JavaScript finns det ett antal färdiga ramverk vilket underlättar uppgiften avsevärt. Findwise hade tidigt i projektet uttryckt intresse för standarddiagram som tabeller, stapel- och cirkeldiagram, men också mer specialiserade grafer så som värmekartor. Detta reducerade antalet möjliga bibliotek kraftigt och googles var det som ansågs lösa detta smidigast. I JavaScript skapas en tabell med data. JavaScript använder data som av controller har gjorts tillgänglig i vyn. Tabellen har två kolumner, den ena innehållande söksträngen och den andra innehållande antalet gånger strängen sökts på. Med hjälp av denna tabell skapar visualization API ett vanligt stapeldiagram med söksträngen på x-axeln och antalet sökningar på y-axeln. 6

34 4 RESULTAT Efter första sprinten var den grundläggande arkitekturen uppbyggd för att klara den valda user storyn, visa de mest eftersökta strängarna i ett tidsintervall. DATABAS Efter att index implementerats över kolumnerna sökord och datum så blev det en markant tidsförändring. Tidigare tog det ca 20minuter för att ta ut de 10 vanligast orden i hela sökintervallet och efter förändringen så tog samma fråga mindre än 5minuter. Om datumintervallet begränsas kommer söktiden att minskas proportionerligt i samtliga fall men aldrig till nackdel för lösningen med index (MySQL 5.0 Reference Manual 2011). Varje inlagd textsträng behöver då jämföras med alla andra i samma tabell för att avgöra vilken som är störst. Finns det ett index kan då inlägget snabbt kollas upp i en lista och dess position direkt avgöras i relation mot andra inlägg i samma tabell. DATALAGER Datalagret blev implementerat så att det är mycket modulärt mot databasen. Det är möjligt att byta ut databasen mot valfri annan relationsdatabas som Hibernate har stöd för. Datalagret har ett interface som kan nyttjas utifrån och därför kan antingen ovanliggande eller datalagret själv bytas ut utan förändringar i den delen som är kvar. Cachen implementeras enligt tidigare beskrivning och verkar enbart i datalagret. Att ta fram information eller sätta in information fungerar enligt kraven. Även den egenskap att cachen kastar ut det element som sist användes när insättning av nytt element och max kapacitet är uppnådd. När det kommer till tiden för att ta fram de vanligaste sökorden så är det kraftigt förbättrat och om den frågan är i cachen så är det direkt. Vissa problem uppstod dock på grund av att cachen implementerats mycket generellt och alltså inte specificerade exakt vilken typ av objekt som returneras. Detta ledde till att metoden som ville ha en fråga utförd tvingades kasta resultatet på följande sätt, se figur 5: ArrayList<Object> result =(ArrayList<Object>) querybuilder(qw); ret = (ArrayList<TopSearchTable>)(ArrayList<?>) result; Figur 5. Ta ut information ur databasen Datalagret innehåller också efter sprintens avslut en metod för att hämta de mest eftersökta frågorna under en tidsperiod. Denna metod använder sig av en generell omslagsklass för hibernatefrågor och en metod som genererar och ställer databasfrågor genom Hibernate. Metoden utnyttjar även den ovan nämnda cachen innan en fråga ställs. TJÄNSTELAGER Vid sprintavslutet hade tjänstelagret funktion för att ta emot en GET-request, fråga datalagret efter den aktuella data, bygga ihop en XML-fil av data och skicka data som svar på requesten. 7

35 WEBBLAGER I sprintens slut har webblagret ett formulär där en användare kan efterfråga en topplista över sökningar med en parameter för antal och parametrar för startdatum och slutdatum. Aktuell data hämtades sedan från tjänstelagret, XML-filen som tjänstelagret skickar parsas och data kontrollen gör data tillgänglig för vyn. Ett diagram generas sedan från data med hjälp av Google Visualization API. 5 DISKUSSION Under första sprinten blev det en del tid som gick åt att sätta sig in i hur allt fungerade och anpassa sitt arbetssätt till scrum. Upplevelsen med scrum var inledande lite utmanande men tankesättet gjorde att man fokuserade på att få funktionalitet istället för att tänka för komplicerat. Detta gav oss i slutändan något som är en delmängd av den färdiga produkten. DATABAS Det mönstret som har nyttjas för att spara data har varit gjort enbart i syfte att spara och minsta möjliga jobb från utvecklaren. Detta medförde att förändringarna i databasen gick väldigt långsamt. Med långsamt så menas att körtiden innan förändring är klar var väldigt lång. Att jobba med något där varje förändring tar mer än 10 minuter och resultatet går enbart att observera efter att tiden är klar blir väldigt ineffektivt och det är svårt att jämföra de olika alternativen. Nackdelen att lägga in index är att de tar utrymme och fördröjer insättning i databasen. Utrymmet är försumbart och insättning är ej del av denna sprint. DATALAGER Valet av Hibernate verkar helt rätt då det enkelt kan konfigureras för att ändras till andra relationsdatabastyper. Denna konfigurering görs enbart i en konfigurationsfil och sedan gäller för samtliga delar. Vi använder oss av annotationer för att mappa Hibernate klasserna mot databasens tabeller. Fördelen med detta är att alla inställningar för tabellen hamnar i samma fil istället för en.java fil och en XML fil. Vi valde att göra en egen cache istället för att använda ett färdigutvecklat cachebibliotek. Anledningen till att vi tog detta beslut var för att dels så uppskattades tiden för att utveckla en egen var kortare än läsa in sig på någon annan och sen implementera den. Det bedömdes även att en egen tillverkad cache var mer lätt konfigurerad för att tillfredställa kraven nu och vara utbyggningsbar. Det finns vissa skillnader i hur ren SQL fungerar jämfört med Hibernate's egna query languange HQL. En fördel med HQL är att det går att typsäkra både parametrar och returtyper. Gällande hastighetsskillnader mellan att köra via Hibernate eller direkt i konsol till MySQL så finner vi inga större skillnader i tid. Innan implementeringen startade diskuterades i vilket lager som cachen skulle finnas. Vid första anblick verkade det som att den smartaste lösningen vara att placera cachen så nära användaren som möjligt för att minska överföringstider och antalet anrop. Ett uppenbart problem med detta är att ansvarsuppdelningen mellan lagren blir något diffusa då webblagret förutom att visualisera data även skulle lagra den. Dessutom så skulle en cache som implementerats i webblagret inte vara till någon nytta om man vid ett senare tillfälle skulle välja 8

36 att lägga till ett alternativt användargränssnitt. Med detta som motivering togs beslutet att lägga cachen i datalagret. Vid sprintens slut uppdagades att det även fanns en automatisk cache närmre användaren i form av webbläsaren som sparar svaret på ett anrop internt. Detta visade ytterligare att placeringen varit korrekt. Att cachen inte returnerade typade objekt, vilket föranledde ett lite obskyrt kast av objekt, var egentligen inte något problem. Metoden bestämmer sin egen resultattyp eftersom den skickar in en typsäkrad frågesträng och på grund av detta kommer lösningen vara kvar trots att den inte följer god programmeringssed. Det generella upplägget underlättade också arbetet med att koppla på cachen eftersom varje instans av omslagsklassen representerade en fullständig, och unik, databasfråga. Hashkodmetoden i varje instans kunde därför användas som nyckel i cachen och resultatet efter att frågan körts som värde. Att vi valde att implementera en generell lösning för frågorna i datalagret går emot de scrumprinciper som säger att man endast skall lösa det problem som man behandlar just nu. Även att implementationen med största sannolikhet kommer kunna användas i nästa sprint så är det inte helt säkert vilket medför att arbetet kan ha gjorts i onödan. Att vi ändå valde att göra detta motiverar vi med att vi insett möjligheten att skriva frågor på ett standardiserat sätt och att detta löser problemet vi har ställts inför just nu på ett mycket bra sätt. Lösningen följer scrum till viss del då det endast har implementerats stöd för de typer av parametrar som behövs för att lösa nuvarande sprint. TJÄNSTELAGER Som en följd av att försöka jobba agilt valde vi att i tjänstelagret inte använda något bibliotek för skapning av XML-filer. Det vore rimligtvis en bättre lösning på lång sikt att lära sig ett lämpligt bibliotek och att använda det. Vi tolkade det agila arbetssättet, som att vi enbart skulle koncentrera oss på den aktuella sprinten och dess user stories, och inte göra något generellt ifall det ledde till mer tidsåtgång. I fallet med XML-generering gick det så pass snabbt att göra det genom vanliga strängar att det vore svårt att läsa in sig på andra sätt under samma tid. WEBBLAGER Webblagret som implementerades var minimalt och fyllde sin funktion i detta skede. Hela MVC arkitekturen var inte implementerad fullt ut då data ansågs vara så liten att utbrytning i en modell skulle skapa mer komplexitet än elegans. För implementeringen av grafgeneringen lades i detta stadium ingen energi på att göra koden återanvändningsbar. Istället fokuserades på att skapa något att visa upp för att avgöra om vidareutveckling med Google visualization API var önskvärt. Under demonstration för produktägare beslutades att ramverket var tillräckligt bra för att fortsätta användas. SPRINTPLANERING Det första planeringsmötet var svårt då vi inte riktigt visste hur vi skulle gå tillväga. Man märkte också hur vår brist på erfarenhet av större projekt visade sig när vi skulle uppskatta hur många timmar varje uppgift skulle ta. Henrik, vår ansvarige på Findwise, vägledde och gav oss råd men hjälpe oss inte med planering eller tidsestimering. 9

37 ARBETET UNDER SPRINTEN Verktygen Pivotal Tracker har såhär i början mer varit i vägen än tillfört något i arbetet men när vi börjar få mera funktionalitet och moment som är beroende av andra för att fungera tror vi att det kan vara mer användbart. Att jobba iterativt ger mer motivation när man arbetar eftersom man jobbar med så små delmål att man hela tiden får ny funktionalitet och man ser att arbetet går framåt. Vi upplevde att vi behöver ta fram ett bra sätt för att snabbt kunna rapportera vad som gjorts under en dags arbete. SPRINT RETROSPECTIVE Samma dag som sprinten slutade hade vi ett möte med produktägaren för att gå igenom vad vi hade gjort under sprinten och hur vi tyckte att det gått. Vi visade upp funktionaliteten för ta fram de populäraste sökorden under en given tid och Produktägaren var mycket nöjd med resultatet. Utvecklandet skedde nästan ända fram till mötet, detta ledde till att vi hade mycket bruten kod och till mötet hade vi lite svårt att få fram fullt fungerande kod trots att vi hade den. Detta är en lärdom till nästa sprintavslut då vi kommer avsätta en dator som demodator dagen innan mötet. På mötet gick vi även igenom hur väl våra tidsestimeringar hade stämt och insåg att de hade varit ganska bra överlag men att vissa uppgifter flutit samman och överlappat med andra personers uppgifter. Inför nästa sprint skall uppgifterna vara tydligare och mer genomtänkta. Uppgifterna kommer också bli mer konkreta eftersom systemets lagerstruktur redan är uppsatt. I slutet av mötet bestämdes tid för starten av nästa sprint samt att vi skulle byta ansvarsområden för att maximera kunskapen hos alla deltagare. Vi bestämde även att parprogrammering skall testas under sprint nummer två. 6 SLUTSATS Första sprinten inledde arbetet och syftet att bygga upp den grundläggande arkitekturen uppfylldes. Arbetet med att lära sig och förstå de verktyg som skulle användas under projektet utfördes i den mån det behövdes. Detta innebar att endast det nödvändigaste för att uppfylla huvudsyftet undersöktes. Systemet kan på förfrågan från webblagret leverera vilka som varit de mest eftersökta strängarna och sitter därmed ihop i alla lager. Pivotal Tracker kommer inte att användas i kommande sprint då det ej tillfört något. Google Visualization API är ett ramverk som uppfyller de grundläggande krav för att passa i projektet. 7 KÄLLHÄNVISNING MySQL 5.0 Reference (2011) ( ) 10

38 SPRINTRAPPORT 2 1 INLEDNING Då det mesta från sprint 1 var klart kunde ny funktionalitet implementeras. Kvar från första sprinten var i huvudsak endast att optimera databasen ytterligare, ett arbete som skulle fortsätta parallellt med utvecklingen av ny funktionalitet. 2 SYFTE Syftet med den andra sprinten blev att fortsätta på, och förbättra, den infrastruktur som byggts upp i den första sprinten. Produktägaren prioriterade att utöka mängden frågetyper som systemet stödjer och de user stories som adderades var: En användare vill kunna ta fram en tidslinje som visar hur mycket en söksträng har blivit eftersökt över tid. En användare vill kunna ta fram antalet unika användare En användare vill kunna ta fram antal totala sökningar Vidare så skulle även arbete läggas på att förkorta söktiderna för de mest sökta orden som implementerades i sprint ett. 3 METOD För att undvika mycket redundans i koden då ny funktionalitet läggs till ska generiska delar av koden från sprint 1 brytas ut. Detta innebär att ta så stora delar som möjligt av befintlig kod och göra om den. Det blir då också uppenbart att det finns färdiga bibliotek som kan lösa problem som tidigare hade speciallösningar och således minska mängden kod. Allt eftersom arbetet flyter framåt kommer det bli nödvändigt att göra undersökningar om vilka ramverk som ska användas och på vilket sätt de ska användas. Det är också nödvändigt att lära sig mer om de ramverk som implementerades redan i sprint 1 för att kunna utnyttja dess potential så mycket som möjligt. Från och med denna sprint skall rollen som scrum master rotera mellan gruppmedlemmarna vilket är mer i enlighet med Scrum. Parprogrammering skall även användas på prov för att se om det arbetssättet tillför något. Metoden är ett arbetssätt som är starkt förknippat med den agila utvecklingsmetoden extreme programming (XP). Tanken är att två personer arbetar tillsammans med att skriva kod vilket skall öka kvaliteten och ge bättre övervägda designbeslut. Parprogrammering är också ett sätt att sprida kunskap i ett projekt och på så sätt minska riskerna med manfall av olika slag. 1

39 4 GENOMFÖRANDE OCH ANALYS Då systemet utvecklades specifikt för en user story under sprint nummer ett blev det en naturlig del av den andra sprinten att göra systemet mer generiskt. Nedan följer det arbete som krävdes för att lösa sprintens syfte samt genomföra generaliseringar uppdelat efter applikationslager och möten. 4.1 SPRINTMÖTE På mötet tog en gruppmedlem rollen som scrum master vilket gjorde mötet mer likt hur ett planeringsmöte ser ut i verkligheten. Gruppens handledare på Findwise kunde fokusera på sin roll som produktägare men hjälpte fortfarande till med tidsestimeringen. 4.2 DATABAS Det skapades en ny tabell innehållande alla de unika sökorden som existerar och sen ger varje sökord ett unikt id nummer. Detta id nummer används i huvudtabellen där all information om hur sökningen gick till. Sedan läggs det index över id numren i huvudtabellen. Vid skapandet av den nya tabellen så blir sökorden utf-8 istället för latin-1. Förutom strukturskillnader i databasen så ändrades även minnesmängden MySQL får använda. I samband med nya user stories krävdes att nya frågor ställdes till databasen. Frågorna togs fram i SQL först för att sedan skrivas om till Hibernate's eget frågespråk HQL. 4.3 DATALAGRET Cachefunktionen som påbörjats i sprint 1 utvecklas vidare för att kunna ta flera olika sparade element och sätta ihop till ett och samma. Ett element innehåller en tidigare fråga och dess svar. Lösningen baseras på att bygga upp en riktad graf där det finns start och slut nod samt en nod för varje sparat element. Det finns en kant från startnoden till varje annan nod samt en kant från varje nod till slutnoden. Utöver dessa kanter så finns det kant mellan två element om och endast om de inte delar någon tid, på samma sätt som figur 1 nedan illustrerar. Figur1. En riktad graf där noderna är element. Finns endast kant mellan två noder om de ej skär varandra i tid. 2

40 Sedan med hjälp av en longest path algoritm så väljs de noder som tillsammans innehåller mest information om slutfrågan. För att lösa de user stories som satts upp för sprinten krävdes tre nya metoder i datalagrets interface. Metoderna skall användas för att hämta data kring antal unika användare, totalt antal sökningar och hur sökintensiteten på ett sökt ord har fluktuerat under en tidsperiod. Eftersom en generell lösning för att slå in och skapa frågor hade implementerats redan i den första sprinten krävdes nästan enbart att nya HQL frågor skrevs för att kunna hämta den önskade data ur databasen. Datalagret innehåller alltid en representation av databasen i form av annoterade Hibernate klasser. Detta gjorde det tvunget att göra om och lägga till för att återspegla utbrytningen av sökord i databasen. Det innebar dels att formulera om delar av HQL frågan för mest sökta orden för att den ska fungera med den nya strukturen. Men också för att få ner tidsåtgången för att få ut svaret på frågan. Den nya frågan grupperar över sökordets id nummer istället för över sökordet. Men tar fortfarande sökordet från huvudtabellen. En ny funktion implementerades som ska ta fram information för en tidslinje om hur frekvent ett sökord är. Funktionen får namnet QueryTrend och fungerar genom att det summeras på antingen dags-, månads- eller årsnivå hur frekvent ett ord är sökt. Funktionen fungerar genom att gruppera från och med den största tidsenheten till den valda tidsenheten. Den kollar enbart efter de poster i huvudtabellen som har samma id nummer som det ord som funktionen får som argument. Det går även att begränsa inom vilket tidsintervall som informationen ska hämtas ur. Vidare så får resultattyperna i datalagret även annotationer för att stödja den generalisering av XML-generering som genomförs i tjänstelagret. Språket som används i Hibernate för att ställa frågor påminner mycket om vanlig SQL men det finns skillnader. En av de skillnaderna är att med hjälp av HQL går det inte att skriva temporära tabeller eller ha subfrågor i SELECT satsen, se figur 2. SELECT (SELECT query FROM searchword s WHERE s.id = queryid) AS query, COUNT(*) as `count` FROM queries GROUP BY queryid ORDER BY `count` DESC LIMIT 10 Figur 2. Exempel på SQL med subfråga i SELECT satsen. 3

41 4.4 TJÄNSTELAGER I den första sprinten användes en metod som slog ihop strängar till ett XML dokument men den lösningen var svår att generalisera och utveckla vidare. För att förbättra detta så lades ramverket jaxb till vilket kan användas för att skapa XML direkt från java objekt. Ramverket använder XML-annotationer som en mall för hur ett objekt skall se ut när det representeras på XML form. När sådana har lagts till kan man få en XML representation av objektet genom ett enkelt funktionsanrop. För att uppnå en XML struktur som kunde hantera den data som tjänstelagret skulle skicka skapades tre omslagsklasser enligt figur 3. Figur 3. Omslagsklasser för XML-dokument. Den yttersta omslagsklassen, Result, innehåller ett objekt med frågeinformation och ett objekt med resultat och dessa blir föräldranoder i det slutgiltiga XML dokument som genereras. Processen fungerar som så att när en klass i tjänstelagret anropar datalagret får den en lista med resultatobjekt tillbaka som svar. Listan används för att konstruera ett nytt objekt av typen QueryResults som sedan slås in i Result tillsammans med QueryInfo. Efter detta genereras ett XML dokument från Result objektet och detta returneras sedan som svar på det ursprungliga anropet. Processen kräver att objekten som returneras från datalagret har annoterats för att kunna genereras som XML. Under stora delar av arbetet med XML genereringen provades processen parprogrammering vilket innebär att två utvecklare arbetar på samma dator. Vid repetitiva arbetsuppgifter delade paren på sig för att på så sätt öka effektiviteten. 4

42 Under sprinten fick strukturen i QueryResults anpassas så att förfrågningar om hur ett sökords frekvens har varierat över tiden kunde besvaras. Lägger även till så att hämtning från datalagret görs för att till sist skicka informationen vidare till den som frågade om det. 4.5 WEBBLAGER Webblagret byggdes vidare på den enkla struktur som byggts upp för de mest sökta orden i förra sprinten KONTROLLER Nya kontrollklasser för den nya funktionaliteten byggdes enligt samma princip som använts i första sprinten. Det krävdes en kontroller för varje ny funktionalitet. För att minska andelen återupprepad kod bröts formuläret för att välja datumintervall ut TIDSLINJE Vad det gällde uppritandet av grafer var det bara user storyn med en tidslinje som krävde ett nytt diagram. Diagram för toppsökningar fanns sedan förra sprinten och antal användare och antal sökningar var båda endast en enskild summa som skulle presenteras för användaren. Google Visualization innehåller annotated timeline, en interaktiv tidslinje. Denna ger möjlighet för att zooma och scrolla i en tidslinje där datum på x-axeln och värden på y-axeln. Tidslinje gjorde det också möjligt att ha flera linjer i samma graf, något som kunde bli intressant i framtida sprintar. Förutom att lägga till en kontroller för att hämta data för de nya funktionerna och JavaScript för att lägga in data i tidslinjen, gjordes inga större ändringar på webblagret under den här sprinten. Figur 4. Exempel på tidslinje DECORATORS, CSS OCH DESIGN För att på ett enkelt sätt kunna få en standardiserad visning av sidorna i användargränssnittet börjar ramverket Sitemesh användas. Med hjälp av detta ramverk kan man skapa filer, så kallade decorators, som fungerar som en mall för hur en sida skall visas. När en.jsp anropas används decorator-filen som ett filter och de önskade delarna av den anropade sidan plockas ut för att placeras i den fördefinierade mallen. Eftersom det i denna sprint tillkommer flera frågor 5

43 läggs en meny till i dekorator-filen. Denna kan konfigureras centralt. Det definieras också upp ett antal regioner, sidhuvud, innehåll och sidfot, där innehåll kan läggas till. I ett Spring MVC projekt så ligger inga filer tillgängliga publikt, istället hanteras alla anrop av ramverket. För att detta skall fungera måste systemet konfigureras med en XML-fil där det specificeras vilka mappar och vilka filtyper som kan nås. Det samma gäller för statiska resurser som bilder och stilmallar men eftersom dessa ofta har många olika filtyper innebär det väldigt mycket konfigurering för att sätta upp sådan åtkomst. På grund av detta har det blivit vanligt att lägga till en mapp som innehåller alla statiska resurser och som konfigureras med en speciell resurskonfigurering. Detta genomfördes under sprinten och en ny mappstruktur adderades i användargränssnittet. För att slutanvändaren skall kunna använda systemet på bästa sätt så behöver det vara enkelt att lägga in data i formulärfälten. I största möjliga utsträckning skall det inte vara möjligt för användaren att mata in felaktigt formaterad data. För att uppnå detta lades biblioteket jquery UI till. Detta är ett tillägg till jquery och innehåller färdiga komponenter för bland annat datuminmatning. Biblioteket är skrivet helt i JavaScript och användningen är enkel eftersom man endast behöver importera biblioteket på en vanlig.jsp sida, se figur 5 för exempelkod. När det är gjort kan man specificera vilka element man vill förändra anropar den typ av komponent man vill lägga till i en.js fil. $(document).ready(function(){ $(".datepicker").datepicker({ dateformat: 'yy-mm-dd', defaultdate: " }); }); Figur 5. Exempel på jquery för en datumväljare. 5 RESULTAT Efter att arbetat med de user stories som bestämdes på sprintmötet så blev resultatet bra. Resultatet blir indelat efter vilket lager den ägde rum i. 5.1 DATABASEN Efter att sökorden får sin egen tabell och sökords id nummer läggs in i huvudtabellen så går det väldigt mycket snabbare att göra frågan om vilka sökords som är vanligast i ett tidsintervall. Detta för att grupperingen görs på datatypen INT(10) istället för VARCHAR(1000). 6

44 5.2 DATALAGER Frågan om hur de mest sökta orden har ändrats så att den enbart grupperar på INT. Efter förändringen så kan systemet ta fram betydligt snabbare vilka som är de vanligaste sökorden. Tiden för att ta fram de vanligaste sökorden är alltid mindre än 30 sekunder. För att uppnå detta så är det främst att grupperingen sker på INT istället för VARCHAR. Cachefunktionen som började bli implementerad blir väldigt långsam när antalet objekt i den överskrider Samtidigt blev frågorna i databasen betydligt snabbare. Cachefunktionen blir nedprioriterad och ej fullständigt implementerad. QueryTrend fungerar väldigt bra och snabbt. 5.3 TJÄNSTELAGER I förra sprinten hade XML-svaret på anropet från webblagret skapats genom att bygga den manuellt genom att konkatenera ihop alla delar till en lång sträng innehållande XML-filen. Detta ersattes med biblioteket jaxb och skapar en XML från annotationer i datalagret. Funktionen att från datalagret ta fram hur ett sökords frekvens har varierat över tiden och sedan skicka informationen vidare till den som bad om den fungerar väldigt bra och snabbt. 5.4 WEBBLAGER Vid sprintens avslut fanns det i webblagret möjlighet att se en söksträngs popularitet över tid uppritad på en tidslinje unika antalet användare i ett givet datum intervall totala antalet sökningar i ett givet datum intervall Under sprinten fick webblagret även en decorator som tillser att alla sidor renderas på samma sätt. I samband med detta lades även sidhuvud, meny och sidfot till samt komponenter för datuminmatning. Vidare så har Spring MVC konfigurerats ytterligare för att alla statiska resurser ska kunna ligga på en och samma plats. I sin helhet var produktägaren mycket nöjd med resultatet och ropade in en av firmans chefer för att titta på vad vi åstadkommit hittills. Detta satte direkt igång en diskussion om att integrera vår lösning i ett annat av företagets projekt och ett möte för att diskutera detta närmre efterlystes. 6 DISKUSSION Denna sprint visade det sig att valet att försöka skriva en egen cache till frågorna inte kunde leda till den prestandaökning som önskat. I efterhand kan det verka som den tid som lades på cachen var bortkastad men det resulterade i en bättre insikt i vad som händer när systemet har varit igång ett tag. Då en av de fysiska begränsningarna i projektet är överföring av data mellan olika maskiner är idén att bara hämta den information som är nödvändig från databasen högst rimlig. 7

45 6.1 DATABAS Det är väldigt svårt att göra förändringar i databasen då de tar lång tid innan de ger felmeddelande. I samband med ta ut de unika sökorden och sätta in de i sökordstabellen så var tidsåtgången mer än 30 minuter och blev det problem mellan vad som är unikt i utf-8 och latin- 1 så kunde det dröja väldigt länge. Annat problem med databasen var att vi av misstag körde flera frågor samtidigt som låste tabellerna för varandra. Värsta fallet var en fråga som tog mer 91 timmar. Frågan skulle ta ca 45 minuter och sattes igång strax innan hemgång inför helgen och frågan var inte klar när vi kom tillbaka efter helgen. Frågan hade troligen blivit låst av annan fråga. Vid hämtning utav data så tar det längre tid att hämta i ett stort datumintervall jämfört med hela intervallet. Detta för kontrollen av vilka ord som ligger i intervallet. Slutsatsen är hämtning ur databas handlar mer mängden i databasen än jämfört med sprint 1 där det var stor tidsvinst att begränsa tidsintervallet. 6.2 DATALAGER Då dokumentationen för Hibernate säger att det går att ställa subfrågor i SELECT satsen så la vi mycket tid på att få det att fungerar. Efter många misslyckanden och mycket läsande på forum, dokumentation och fråga personal på Oracle så beslutar vi att ej lägga mer tid på detta utan istället hitta en alternativ lösning senare och lägga detta i backloggen. Cachefunktionen som skulle klara av att sätta ihop flera element var byggd för att klara av problemet med det elfte elementet. Ett problem med att slå ihop flera cachade objekt är att vi endast har informationen som finns i elementen och inte all som finns i databasen. Ett problem med detta är när det finns sju dagsrapporter i följd på de tio vanligaste sökorden och det efterfrågas en veckorapport. Då kan dessa tio sökorden vara olika för varje dag men det elfte vanligaste sökordet var samma för varje dag. Detta kan medföra att det elfte sökordet var det mest sökta under hela veckan men det finns inte i cachen. Lösningen på detta var att summera jumboplatsen för varje dagsrapport och sen jämföra det med den summerade veckorapporten. Alla sökord som har färre sökningar än summa jumboplats kan ej garanteras deras plats och alla över kan garanteras deras topplaceringsplats. Då tidsåtgången för cachen att hitta bästa möjliga mängd objekt för att kapsla in datum perioden och hämta de missade bitarna tar ungefär lika långtid som hämta hela intervallet så flyttas Cachefunktionen till backloggen. QueryTrend gick snabbt att implementera i jämförelse med annan funktionaliteten. Detta är troligen pga. att vi som utvecklare har blivit bättre på hur vi ska jobba med Hibernate. 6.3 TJÄNSTELAGER Förändringen som innebar att XML genereras automatiskt förenklar arbetet i kommande sprintar och snyggar även till strukturen i tjänstelagret. Problemet som uppstod efter den första sprinten där en metod som var mycket svår att arbeta vidare på har alltså lösts och en god generallitet har uppnåtts. Trots detta så är inte implementeringen perfekt eftersom den kräver att resultattypen från datalagret är annoterad. Detta går inte att specificera på något bra sätt annat än genom god dokumentation. Systemet blir därför inte riktigt modulärt och klarar alltså inte de krav som produktägaren satt. Trots detta så är vi nöjda med hur enkelt det är att skapa XML dokument numera men inser att vi kommer behöva arbeta vidare på lösningen. 8

46 6.4 WEBBLAGRET Trots att den design som GUI:t fått är mycket enkel så underlättar den användartestning av systemet och ger ett mer samlat intryck när systemet visas upp. Förändringen innebär också att det blir enklare att ändra i designen eftersom layouten på alla sidor uppdateras samtidigt. Datumväljaren var ett mycket enkelt tillägg till användargränssnittet men höjde ändå användbarheten avsevärt. Det innebär också att utvecklaren inte behöver vara lika orolig för att formulärfält missförstås eller används på fel sätt. Detta minskar behovet av förklarande texter. Att alla statiska resurser kunnat samlas på ett och samma ställe genom en ny konfiguration gav webblagret en klarare struktur ur ett utvecklingsperspektiv. Man skulle självklart kunna låta alla filer vara tillgängliga för anrop utifrån eftersom projektet inte har några krav på att vara säkert. Dock tjänar man egentligen ingenting på ett sådant upplägg som utvecklare. Det är alltid bättre att följa de konventioner som satts upp för ett ramverk. Eftersom systemet kanske kommer utvecklas vidare efter kandidatarbetets slut är det viktigt att våra beslut tas i enlighet med standarder i så stor utsträckning som möjligt. 6.5 SPRINTPLANERING Planeringsmötet denna gång gick betydligt smidigare än det första. Under återblicken från förra sprinten uppdagades att mer tid bör tillägnas att få alla individuellt skriva delar av systemet att passa ihop. Det lades därför separata uppgifter för integrering under denna sprint. Att ha en av gruppmedlemmarna som scrum master fungerade bra och produktägaren kunde fokusera helt på sitt ansvar. 6.6 ARBETET UNDER SPRINTEN Ett problem som uppstår är att vi som grupp jobbar vid olika tidpunkter och därför har svårt att fråga varandra vid behov av hjälp. Detta medför att vissa mer lättlösta problem ska lösas på nytt. Fördelen med att inte ha låst tid när vi alla ska sitta tillsammans är att individen väljer själv när han ska jobba och så sätt sällan har en dålig dag som drar ner gruppen. Detta har även gjort att vi har en tendens att specialisera oss på något område av utvecklingen. Som förtydligande så har vi mycket tid där gruppen jobbar samtidigt men gruppen jobbar inte alltid samtidigt. Bristen på sammanfallande tid gör också att vi tagit bort en av grundpelarna i Scrum, daily standup. Tanken är att genomföra en snabb genomgång av vad varje individ gjorde igår, vad den skall göra idag och om den har några hinder i sitt arbete. Processen skall ge transparens mellan utvecklarna och få upp eventuella problem till ytan så snabbt som möjligt. För att kompensera tänker vi försöka skicka mail med de saker man arbetar på och hoppas att detta skall väga upp. Under den gångna sprinten bestämdes att vi skulle parprogrammera i den utsträckning vi hade möjlighet. Vi provade vid några tillfällen och var nöjda med upplägget i stort men insåg ganska snabbt att det inte passar för alla typer av uppgifter. Eftersom tanken är att en person kodar och en person övervakar och att man på så sätt skall producera bättre kod upplevde vi att det var ypperligt att använda vid komplexa problem och vid strukturbeslut. Man får då två infallsvinklar på ett problem och undviker i många fall småfel som annars kan ta mycket lång tid att upptäcka. Det möjliggör också för en bättre kunskapsspridning så att utvecklarna lär sig nya saker kontinuerligt. De tillfällen när vi inte tyckte att programmeringssättet passade var vid 9

47 tidskrävande och repetitiva arbetsuppgifter som till exempel refaktorisering. Visserligen är det lätt att man tappar koncentrationen när sådana uppgifter utförs, vilket ofta leder till slarvfel, men det gäller båda programmerarna så att vara två hjälper inte. Vi ansåg att det vid sådana tillfällen var resursslöseri att använda två programmerare och försökte därför anpassa arbetssätt efter arbetsuppgift. Förutom kvalitets- och effektivitetsaspekten så reflekterades det även kring att det kan kännas stressande att ha någon som hela tiden tittar över axeln, men det tros vara en vanesak som släpper med tiden. 6.7 SPRINT RETROSPECTIVE Under första sprintens avslut hade vi problem med att få fram fungerande kod trots att vi i princip hade den. Det var vidareutveckling som satte den största käppen i hjulet och på grund av detta hade vi bestämt att en dator skulle avsättas för demo. Detta följdes inte till punkt och pricka vilket medförde att vissa problem smög sig in även under det andra retrospective mötet. På grund av att det ännu en gång blev körigt inför uppvisandet av systemet försökte vi nu sätta en fastare deadline för integrationen och när vi skulle dra en gräns för vidareutveckling. Att skapa en stabil förgrening, branch, i vår SVN togs även upp för diskussion. Deltagarna hade tidigare erfarenhet av problem med att slå samman denna typ av förgreningar och därför avvaktar vi med en sådan lösning. 7 SLUTSATS Produktägaren är hittills nöjd med systemet och vill få fler intressenter och anställda involverade i projektet. XML-genereringen har förbättrats avsevärt men klarar inte de övergripande kraven på modularitet som satts upp av produktägaren och måste därför prioriteras i kommande sprint. Vi har modifierat Scrum genom att ta bort daily standups och skall prova att skicka mail som kompensation för den förlorade transparensen. Parprogrammering har fungerat väl och kommer eventuellt att användas vid komplexa arbetsuppgifter i kommande sprintar. Ett möte för att diskutera integrering med andra system skall genomföras vilket kan ha stora implikationer på fortsatt arbete. 10

48 SPRINTRAPPORT 3 1 SYFTE Efter de två första sprintarna fanns en generell arkitektur där tillägg av ny funktionalitet var relativt simpel. Produktägaren ville utnyttja detta och fokusera på mycket ny funktionalitet. De user stories som valdes var: En användare vill kunna ta fram en intensitetskarta som visar: antalet unika användare per land antalet totala frågor per land hur många procent av användarna i ett land som använder sig av söktjänster (användningsgraden). Vid skapandet av den tidslinje som implementerats tidigare vill en användare kunna: använda wildcards när söktermen bestäms välja att gruppera på olika tidsintervall lägga till flera ord och på så sätt jämföra dessa med varandra Användaren vill kunna specificera för vilket land som den vill se de mest eftersökta termerna. En användare vill kunna ta fram hur fördelningen mellan olika entrypoints 4 varit. Förutom detta skall det även genomföras refaktorisering av JavaScript. Hastigheterna skall höjas i databasen och kravet på annotationer skall tas bort från returklasserna i datalagret. Vidare skall även en presentation av systemet genomföras på Findwise. 2 METOD I relation mot föregående sprint ska inga förändringar i metoden genomföras och rollen som scrum master roterade vidare. 3 GENOMFÖRANDE OCH ANALYS Eftersom mycket av arbetet i sprint nummer två syftade till att skapa en struktur som skulle vara enkel att arbeta vidare på krävdes relativt små ansträngningar för att lägga till ny funktionalitet och det arbete som utförts presenteras nedan. 4Entrypoint är vilket sökgränsnitt som använts 1

49 3.1 SPRINTPLANERING Sprintplaneringen genomfördes enligt rutin och arbetsuppgifter delades ut till alla gruppmedlemmarna. 3.2 DATABAS För att snabbt kunna ta fram hur de olika entrypoint har använts anpassas databasen på liknande sätt som de olika sökorden. Konkret innebar det att en ny tabell skapades innehållande de unika entrypoint som existerar samt ett id-nummer. I huvudtabellen lades det till en kolumn innehållande entrypoint-id av typen INT. I kolumnen för entrypoint-id sattes ett matchande idnummer från tabellen med de unika entrypoint in. I denna sprint var det även önskvärt att kunna ta fram hur stor del av de anställda i ett visst land som använde sökverktygen. Denna så kallade användningsgraden baseras på antalet anställda i varje land, data som vid detta tillfälle inte fanns tillgänglig i databasen. För att lösa detta temporärt, till korrekt data införskaffats, slumpades data fram. 3.3 DATALAGER För att ta fram de mest sökta orden så ändras flödet. Först hämtar datalagret de id-nummer som var mest sökta och därefter hämtas de riktiga sökorden. Det senare steget sker för varje ord och inte i en klump. I tidigare sprintar så har datalagret haft metoder som returnerar objekt lämpligt annoterade för den uppgiften tjänstelagret ska lösas. Det ändras genom att varje metod i datalagret som används för att ta fram information ur databasen blir en egen klass istället. Klasserna som innehåller funktionaliteten för att ta fram information ur databasen följer ett och samma interface. Interfacet kräver ett visst antal getters och setters. Funktionen QueryTrend, som skapades i sprint 2, förbättrades. Tidigare kunde den enbart ta fram hur sökningarna för ett ord varierade över ett stängt tidsintervall. Förändringarna tillåter gruppering av ord till samma linje till exempel ferie jobb och sommar jobb. Användningen av wildcards möjliggjordes även. Detta för att till exempel kunna söka efter alla söksträngar som börjar med kalle och då också få med Kalle-Anka. Även tillägget att få flera olika ord var för sig i samma tidsintervall t.ex. Kalle-Anka sökningar och Långben sökningar implementerades. Den sistnämna förändringen är för att kunna se hur två ord förändras mot varandra under samma tid. För att inte klumpa hela resultatet när man jämför två olika ord och samtidigt grupperar flera ord så körs endast grupperingsfrågorna samtidigt. Detta gör att om funktionen nyttjas för att jämföra flera olika ord kommer lika många frågor som antalet ord köras mot databasen. Eftersom det i sprinten skulle ställas frågor på specifika länder implementerades klasser för att kunna hämta alla länder som finns tillgängliga i databasen. För att göra systemet så flexibelt som möjligt skapades även klasser för att hämta den Enum som specificerade vilka grupperingar som datalagret stödde. Det var även nödvändigt att implementera metoder för att hämta hur många användare som finns i varje land och det totala antalet frågor för varje land. I sprint två implementerades liknande metoder som saknade uppdelningen i länder. Istället för att göra om de befintliga metoder och förlora funktionalitet skrevs två nya. 2

50 Söktjänsten som Findwise erbjuder till sina kunder kan komma i flera olika former till exempel via webbläsare, program eller toolbar. Syftet med user storien om entrypoints är att ta fram information om hur många sökningar som skett med vardera entrypoint inom ett bestämt tidsintervall. Implementeringen för lösa denna uppgift är liknande den som tar fram de vanligaste sökta orden, med undantaget att grupperingen sker på entrypoint-id istället för sökordets id-nummer. Databasen anpassades för att klara av den nya funktionaliteten. Detta krävde att Hibernate's mappningsklasser blir uppdaterade för att matcha den nya databasstrukturen. För att kunna ta fram den så kallade användningsgraden delar man antalet unika användare i ett land med antalet anställda i det landet. Detta producerad ett problem där kvotvärdet med 3 decimaler inte gick att representera i den existerande mallen för XML. Istället för att definiera ännu ett XML-schema multiplicerades kvotvärdet med 1000 och skapade således ett heltal. 3.4 TJÄNSTELAGRET Tidigare antog tjänstelagret att resultatobjekten var annoterade på ett lämpligt sätt för att generera ett XML-dokument som kunde skickas vidare. Detta antagande kontrollerades aldrig utan det förutsattes att annoteringar hade införts. För att förändra detta så kräver tjänstelagret att svarsobjekten från datalagret följer interface QueryModel. I QueryModel så finns det getters och setters för de värden som ett svarsobjekt kan ha. Med hjälp av dessa getters och setters så tas informationen från QueryModel objektet till ett annat objekt som finns i tjänstelagret och som är korrekt annoterat för vidare generering av XML. En hjälpklass med en static metod skapas. Metoden tar emot ett objekt av typen QueryModel och sedan returnerar en String innehållande XML representationen av QueryModel objektet. Hjälpklassen i sig är annoterad för att sedan kunna göras om till XML på liknande sätt som gjordes tidigare. Tjänsten för att få information hur de olika entrypoints läggs till. I och med likheterna till tjänsten mest sökta ord så kopieras stora mängder kod som sedan får enbart mindre justeringar gällande anropsnamn och vilken klass i datalagret som ska användas. 3.5 WEBBLAGER Förutom tillägg av ny funktionalitet gjordes även en större omorganisation av MVC strukturen. På grund av omstruktureringens omfattning blev inte alla user stories klara denna sprint. Det som inte färdigställdes var utritning av användningsgrad på en karta FÖRÄNDRING AV KONTROLLER I tidigare sprintar skickades alla GET-parametrar skilda från varandra vilket innebar att metoddeklarationerna blev väldigt långa och komplicerade. För att slippa detta skapades modellobjekt vilket enklast kan beskrivas som en objektavbild av en sida eller ett formulär. Dessa kan sedan användas både för att visa upp och fånga data. Om modellen skall användas för att hantera skickad data från ett formulär måste den innehålla samma typer av variabler som formuläret har. Utöver detta måste den också innehålla get- och set-metoder för att den automatiska mappningen skall fungera. Förändringen medförde att en ny namngivning behövdes för att särskilja på vilken typ av anrop som utfördes. En ny standard implementerades där sidanrop mappades till resursnamn, formuläranrop till resursnamn.do och dataanrop till data/resursnamn. På så sätt blev de olika anropen lätta att särskilja men ändå konsekventa. 3

51 Implementeringen innebar också en ändring så att alla kontroller returnerar ett objekt av typen ModelAndView istället för att endast returnera en vy. I dessa objekt specificeras vilken sida som skall visas och vilket objekt som skall användas som modell vid just den visningen. Förändringen i funktion vid formuläranrop var att metoden som skall hantera formuläret endast behöver ha ett objekt specificerat som parameter så sköts insättningen av värdena automatiskt GRÄNSSNITT Förändringen av kontroller inverkade på gränssnittet eftersom det gav upphov till möjligheten att visa upp resultat som hämtats från datalagret som alternativ för användarens fältinmatningar. För att detta skall fungera behöver.jsp-sidan inkludera Spring s taggbibliotek för formulär som kan användas för att specificera vilken variabel från sidans modell som skall rendera val och vilken variabel som användarens inmatning skall sparas i. <form:checkboxes items="${command.groupbyoptions}" name="groupby" path="groupby" /> Figur 7 Checkboxar som genereras automatiskt från modellens groupbyoptions variabel och mappas till modellens groupby variabel JAVASCRIPT-REFACTORING I de första sprintarna var uppdelningen i webblagret inte optimal. Nästan all kod låg i kontrollen och vyn och det var svårt att göra en generell lösning, istället återupprepades en mängd kod. Hämtningen av data från tjänstelagret var den aktivitet som tog längst tid och som systemet såg ut vid sprintens start låste detta upp systemet. Ett mål med att omarbeta koden var att istället låta hämtningen av data från tjänstelagret ske asynkront, Vidare skedde sammansättningen av datatabellerna som graferna var baserade i JavaScript i respektive vy, även detta var något som gjorde koden komplex. Systemet som det såg ut innan omarbetning: 1. Kontrollen frågar tjänstelagret efter aktuell data 2. Kontrollen väntar på att tjänstelagret ska svara och skickar sedan vidare data till vyn 3. I vyn används JavaScript för att konvertera data som kontrollen skickat till ett format som Google s diagram förstår. 4. När allt är klart renderas grafen. Se figur 2 för förtydligande. 4

52 Figur 2 Webblagrets sammansättning innan refaktorisering. Omarbetandet av webblagret var egentligen två separata aktiviteter som tillsammans skulle resultera i en bättre uppdelad arkitektur. Steg ett var att flytta ut JavaScript-koden som ritar grafer till ett eget JavaScript-bibliotek och på så sätt få ett kortare och mer allmänt anrop för graf-uppritning på de enskilda sidorna. Steg två var att flytta sammansättningen av data från JavaScript och klientsidan till java och serversidan. De specifika aktiviteterna för att uppnå en bättre struktur var: Kontrollen gjordes om så den bara ansvarar för navigering och renderar vyn direkt. Vyn ändrades så att endast JavaScript som är specifik för den aktuella grafen finns i vyn. Den mesta JavaScript-koden flyttades ut till en extern fil, Graph.js som anropas med de specifika parametrarna för den aktuella grafen. Graph.js skrevs så att den anropar en datakontroller asynkront. Google Visualization Data Source Library är ett javabibliotek som användes för att implementera en datakälla som sedan kan användas av Google Visualization API. Datakällan svarar med en JSON som Google s grafer förstår utan någon nödvändig konvertering VÄRMEKARTOR Denna sprint implementerades värmekartor för totalt antal sökningar och antal unika användare. De befintliga sidorna där bara ett nummer skrevs modifierades således för att visa kartorna där användaren snabbt kan få en överblick över skillnader i olika länder. Det uppstod ett speciellt problem med de totala antalet sökningar. När denna fråga delades upp i länder användes inte hela färgskalan. Det visade sig efter lite efterforskning att användare som inte varit inloggade då de sökt får landet null. Visualization API känner inte igen detta och ritar således inte ut det men dess värde kastas inte bort. Då det är betydligt fler icke inloggade användare än användare i det landet med flest sökningar blir utnyttjas färgskalan inte optimalt bland de riktiga länderna. För att lösa detta filtrerades alla användare som inte var inloggade bort för uppritning på karta. Att filtrera i ett lägre lager var inte önskvärt då även icke inloggade användare ska räknas om till exempel ett stapeldiagram ska användas istället för kartan. 5

53 3.6 PRESENTATION En del av sprinten var att visa hur långt som vi hade kommit för resten utav företagets anställda. Presentationen var av informell karaktär för cirka 20 anställda från att sprida arbetsuppgifter och kontor. I presentationen så visades dels strukturen i hur de olika lagrena samarbetade och även vad systemet klarade av för stunden. Presentationen var på engelska och tog 10 minuter. 4 RESULTAT 4.1 DATALAGER Efter utfört arbete så finns det inga krav på att returklasserna från datalagret ska vara annoterade på ett speciellt sätt. Det blir även lättare att särskilja var funktionaliteten är placerad då varje funktion har fått sin helt klass. Med förändringarna i hur de mest sökta orden tas fram så har tidsåtgången gått ner till under 9 sekunder vid sökningar med start- och slutdatum som innefattar alla databasposter. Om tidsintervallet är helt öppet så görs ingen datumkontroll i databasen och då går det väsentligt snabbare. Därför görs slagningen för att ta fram det specifika sökordet först efter den fullständiga listan med alla mest sökta ord plockats ut. Funktionen som tar fram hur ett enskilt eller klumpat sökord förändras över tid fungerar bra och snabbt. Dess tid beror på hur många olika ej klumpade sökord som valts. I samband med gruppering av sökord körs en fråga mot sökordstabellen som lyfter ut alla matchande idnummer. Dessa id-nummer används sedan som parametrar i frågan som tar ut totala antalet sökningar i grupperingen. Vidare så innehåller datalagret klasser för att kunna hämta alla tillgängliga länder, antalet unika användare grupperat per land, antalet frågor grupperat per land och hur många frågor som ställts via varje entrypoint. User storien användningsgrad blev inte fullt klar. Därför läggs den i backlogg för att slutföras i nästa sprint. 4.2 DATABAS Efter små förändringar, som indirekt har testats i samband med framtagandet av de mest sökta orden, fungerar databasen som förväntat trots tillägg av nya tabeller och omstrukturering i huvudtabellen. 4.3 KONTROLLER När sprinten avslutades användes inte längre lösa GET-parametrar utan istället hela objekt som modellerar formulärens struktur. Samma objekt användes även för att ge användaren möjlighet att välja att endast söka inom tillgängliga länder i databasen. Det skedde även en kategorisering av alla kontroller så att navigeringskontroller och datakontroller särskildes. För de olika typerna av anrop skulle kunna hållas isär skapades en ny konvention för hur URI:er skulle se ut. 6

54 4.4 GRÄNSSNITT Användargränssnittet har efter avslutad sprint nya formulärkomponenter i form av kryssrutor och rullgardinslistor. Förutom att de nya frågetyperna har lagts till i menyn så har inga stora förändringar genomförts utseendemässigt. 4.5 JAVASCRIPT-REFACTORING Vid sprintavslutet har webblagrets struktur fått sig en rejäl förändring. Omarbetningen resulterade i ett webblager där processen för en grafvisning är: 1. Kontroller ansvarar bara för navigering och renderar vyn direkt 2. I vyn finns endast JavaScript som är specifik för den aktuella grafen, Graph.js anropas med specifika parametrar. 3. I Graph.js anropas en datakontroll asynkront 4. Datakontrollen svarar med en JSON som Google s grafer förstår utan någon nödvändig konvertering. 5. Grafen renderas. Den nya strukturen kan ses i figur 3 och kan jämföras med strukturen i figur 2. Figur 3 Webblagrets struktur efter refaktoriseringen VÄRMEKARTOR Totala antalet sökningar och antalet unika användare visas nu på en värmekarta. Användningsgrad blev inte färdigt i webblagret. 4.6 TJÄNSTELAGER Eftersom det ställs som krav att alla svarsobjekt ska vara av typen QueryModel så kontrolleras det att svaret datalagret ger är läsbart för tjänstelagret. Generering av XML blir samma för alla objekt av typen QueryModel. Efter att redan skriven kod flyttats runt uppnås ett system med 7

Guide för Innehållsleverantörer

Guide för Innehållsleverantörer Library of Labs Content Provider s Guide Guide för Innehållsleverantörer Inom LiLa ramverket är innehållsleverantörer ansvariga för att skapa experiment som "LiLa Learning Objects", att ladda upp dessa

Läs mer

PROJEKTDIREKTIV. Genomizer. Dokumenthistorik version datum utförda förändringar utförda av granskad. 1.0 20150327 Utlagd version jp jem, jp

PROJEKTDIREKTIV. Genomizer. Dokumenthistorik version datum utförda förändringar utförda av granskad. 1.0 20150327 Utlagd version jp jem, jp PROJEKTDIREKTIV Genomizer Dokumenthistorik version datum utförda förändringar utförda av granskad 1.1 20150408 Tidpunkt för posterredovisningen uppdaterad, ny tid är 9/4 15.15 jp jp 1.0 20150327 Utlagd

Läs mer

PROJEKTDIREKTIV. Genomizer. Dokumenthistorik version datum utförda förändringar utförda av granskad

PROJEKTDIREKTIV. Genomizer. Dokumenthistorik version datum utförda förändringar utförda av granskad PROJEKTDIREKTIV Genomizer Dokumenthistorik version datum utförda förändringar utförda av granskad 1.1 20140410 Formulerat om kraven på leverabeln Teknisk dokumentation, samt ändrat formateringen av punkterna

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år

Javautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år Javautvecklare 400 YH-poäng, 2 år Utbildningsfakta Kurser (12 stycken) Grundläggande programmering och javaverktyg 50 yhp Grafiskt gränssnitt och interaktion 20 yhp Internet, webb och webbramverk 40 yhp

Läs mer

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete Projektmetodik II HF1005, Informationsteknik och ingenjörsmetodik för Datateknik Projektarbete Förväntade resultatet är t.ex. en produkt Vi behöver arbeta med Analys Faktainsamling Genomförande Rapportering

Läs mer

VAD GÖR DU / VEM ÄR DU?

VAD GÖR DU / VEM ÄR DU? INNEHÅLL Vad blir din roll Databaser vad är och varför Terminologi Datamodellering vad är och varför Utvecklingsprocessen SQL vad är det Data / Information / Kunskap Kapitel 1 delar av. Praktisk Datamodellering

Läs mer

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning

Läs mer

dit06omr@cs.umu.se 12 juni 2009 Projektplan Webb-baserat bokningssystem för flyg Kurs: Applikationsutveckling för internet, TFE

dit06omr@cs.umu.se 12 juni 2009 Projektplan Webb-baserat bokningssystem för flyg Kurs: Applikationsutveckling för internet, TFE Projektplan Webb-baserat bokningssystem för flyg Kurs: Applikationsutveckling för internet, TFE VT-09 Innehållsförteckning Inledning & problembeskrivning...1 Systembeskrivning...2 Affärsobjekt...2 Databasen...4

Läs mer

Drivna av en passion att utveckla våra kunder, har SuperOffice blivit en av Europas ledande leverantörer av CRM-lösningar.

Drivna av en passion att utveckla våra kunder, har SuperOffice blivit en av Europas ledande leverantörer av CRM-lösningar. Caesar CRM CRM på ditt sätt Drivna av en passion att utveckla våra kunder, har SuperOffice blivit en av Europas ledande leverantörer av CRM-lösningar. Vill du öka er försäljning, kundlojalitet och lönsamhet?

Läs mer

Introduktion till MySQL

Introduktion till MySQL Introduktion till MySQL Vad är MySQL? MySQL är ett programmerings- och frågespråk för databaser. Med programmeringsspråk menas att du kan skapa och administrera databaser med hjälp av MySQL, och med frågespråk

Läs mer

PROJEKT ALBYLEN. Datum: 25 mars 2011. AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson

PROJEKT ALBYLEN. Datum: 25 mars 2011. AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson PROJEKT ALBYLEN Datum: 25 mars 2011 AV: Magnus Lindgren, Mattias Jonsson, Alexander Paskota, Jimmie Yngvesson, Erik Nilsson 0 Sammanfattning: Föreningen Albylen som bedriver aktivitets- och friskvårdscentrum

Läs mer

Decentraliserad administration av gästkonton vid Karlstads universitet

Decentraliserad administration av gästkonton vid Karlstads universitet Datavetenskap Opponent(er): Markus Fors Christian Grahn Respondent(er): Christian Ekström Per Rydberg Decentraliserad administration av gästkonton vid Karlstads universitet Oppositionsrapport, C/D-nivå

Läs mer

Hemsideutveckling för Anjool AB

Hemsideutveckling för Anjool AB Beteckning: Akademin för teknik och miljö Hemsideutveckling för Anjool AB Christopher Gidlöf Maj 2012 Examensarbete 15hp B nivå Datavetenskap Internetteknologi Examinator: Carina Petterson Handledare:

Läs mer

ekorren e-tjänst Teknisk målbild

ekorren e-tjänst Teknisk målbild e-tjänst Teknisk målbild Innehåll 1. OM DOKUMENTET... 3 1.1 BAKGRUND... 3 2. UTGÅNGSPUNKTER... 3 3. MÅLBILD... 3 3.1 SKALBARHET... 3 4. ARKITEKTUR... 5 4.1 DATALAGRING... 5 4.2 ÖVERSIKTSBILD FÖR ARKITEKTUR...

Läs mer

Nya webbservern Dvwebb.mah.se

Nya webbservern Dvwebb.mah.se Nya webbservern Dvwebb.mah.se Bakgrund: BIT (Bibliotek och IT) beslutar att ta ner Novell systemet 28/3 som är en katalogtjänst som styr bland annat alla studenter s.k. hemkataloger på Malmö högskola såväl

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

PROV. 13 JSP Standard Tag Library

PROV. 13 JSP Standard Tag Library 13 JSP Standard Tag Library 13.1 Bibliotek med nya JSP-kommandon 13.2 JSP Standard Tag Library (JSTL) 13.3 Filstruktur för webbapplikationer med JSTL 13.4 Deklaration av JSP-kommandon 13.5 Lägga till biblioteksfiler

Läs mer

EVRY One Outsourcing Linköping AB. Erfaranheter av daglig drift och nyttjande av IFS Applications 8.

EVRY One Outsourcing Linköping AB. Erfaranheter av daglig drift och nyttjande av IFS Applications 8. EVRY One Outsourcing Linköping AB Erfaranheter av daglig drift och nyttjande av IFS Applications 8. Vår erfarenhet IFS Applications 8 Ca 10 st genomförda eller pågående uppgraderingar till IFS 8. Första

Läs mer

Agila Metoder. Nils Ehrenberg nils.ehrenberg@mah.se

Agila Metoder. Nils Ehrenberg nils.ehrenberg@mah.se Agila Metoder Nils Ehrenberg nils.ehrenberg@mah.se Agenda Agila Metoder: Scrum och sprints Lean och Design Workshops Kravställning Agil Utveckling Individer och interaktioner istället för processer Fungerande

Läs mer

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions

Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions Testdriven utveckling Magnus Jonsson Siemens Medical Solutions 2 Soarian Stort projekt, ca 400 personer i projektet Distribuerad utveckling i USA, Indien och Sverige Web baserat lösning med admin client

Läs mer

DI Studio 4.3 - nyheter

DI Studio 4.3 - nyheter DI Studio 4.3 - nyheter Sofie Eidensten och Patric Hamilton Copyright 2010 SAS Institute Inc. All rights reserved. 2 Varför DI Studio Snabbare utveckling Enklare underhåll Gör det överskådligt 3 Nyheter

Läs mer

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell. Vattenfallsmodellen SCRUM Analys Kallas också linjär sekventiell modell Introduktion Design Kod Test Rational Unified Process Agile DSDM Adaptive Software Development Crystal Feature-Driven Development

Läs mer

Creo Customization. Lars Björs 2014-10-16

Creo Customization. Lars Björs 2014-10-16 Creo Customization Lars Björs 2014-10-16 Norra Europas största partner och återförsäljare av PTC relaterad programvara (Windchill, Creo, Arbortext, MathCad, Relex) 70 anställda Egen utvecklingsavdelning

Läs mer

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10

Projekt Rapport. RaidPlanner. Jeanette Karlsson UD10 Projekt Rapport RaidPlanner Jeanette Karlsson UD10 Abstrakt: Denna rapport handlar om mitt projekt i kursen Individuellt Mjukvaruutvecklings projekt. Rapporten kommer att ta upp hur jag gått tillväga,

Läs mer

Projekt intranät Office 365 av Per Ekstedt

Projekt intranät Office 365 av Per Ekstedt Projekt intranät Office 365 av Per Ekstedt 1 BESKRIVNING AV UTFÖRANDE Uppdraget planeras att genomföras med ett agilt arbetssätt samt best practice från Microsoft gällande SharePoint online. Uppdraget

Läs mer

Praktikum i programvaruproduktion

Praktikum i programvaruproduktion Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:

Läs mer

1 Slutanvändarguide för installation. 1.1 Installera SmartDashBoard och SmartLog (Smart Console R77.20)

1 Slutanvändarguide för installation. 1.1 Installera SmartDashBoard och SmartLog (Smart Console R77.20) Innehåll 1 Slutanvändarguide för installation...2 1.1 Installera SmartDashBoard och SmartLog (Smart Console R77.20)...2 1.2 Installera SmartEvent (baserat PC-klienten: Smart Console NGSE)...7 1.3 How to

Läs mer

Continuous Integration med Jenkins. Linus Tolke Enea Experts

Continuous Integration med Jenkins. Linus Tolke Enea Experts Continuous Integration med Jenkins Linus Tolke Enea Experts Föredraget Grunderna i mjukvaru-cm Trender inom mjukvaruutveckling Continuous Integration Vad är Jenkins Demo Jenkins i ArgoUML-projektet Problem

Läs mer

Djupstudie - Datorbaserade system för tracking

Djupstudie - Datorbaserade system för tracking Djupstudie - Datorbaserade system för tracking Torbjörn Lundberg, dt05tl3 Joakim Svensson, dt05js8 18 februari 2008 Sammanfattning Tracking är ett hjälpmedel inom projekt för att hålla reda på information

Läs mer

Undervisningen ska ge eleverna tillfälle att arbeta i projekt samt möjlighet att utveckla kunskaper om projektarbete och dess olika faser.

Undervisningen ska ge eleverna tillfälle att arbeta i projekt samt möjlighet att utveckla kunskaper om projektarbete och dess olika faser. WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

Tele2 Växel. Användarmanual Statistik

Tele2 Växel. Användarmanual Statistik Tele2 Växel Användarmanual Statistik Innehåll 1. Tele2 Växel Statistik... 3 1.1 Få tillgång till Tele2 Växel Statistik... 4 1.2 Översikt Tele2 Växel Statistik... 5 2. Tele2 Växel Statistik Bas... 7 2.1

Läs mer

Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter

Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter Wise Business Support Ms Office Kursinnehåll För nybörjare och därefter Mohammad Honarbakhsh 2013 01 11 073 784 22 74 mo.honar@wisebs.com www.wisebs.com Ms Office Ms Word, Ms Outlook, Ms PowerPoint, Ms

Läs mer

1 Systemkrav avantraupphandling

1 Systemkrav avantraupphandling 1 (10) Godkänd av Produkt/Projekt/Verksamhet avantraupphandling 3.0.1 1 Systemkrav avantraupphandling Intranät webb klient Internet applikation klient Förrådssystem Beställningssystem COM+ Server File

Läs mer

Installera din WordPress med 9 enkla steg

Installera din WordPress med 9 enkla steg Installera din WordPress med 9 enkla steg Den här artikeln förutsätter att du har satt upp en webbserver eller har köpt ett webbhotell där du kan placera din nya WordPress hemsida. Om du inte har det,

Läs mer

De t Mobil Tim gl as e t

De t Mobil Tim gl as e t Det Mobila Timglaset Det mobila timglaset Det mobila timglaset är framtaget för att öka förståelsen för hur en organisation påverkas och kan höja sin effektivitet genom att införa mobil ärendehantering.

Läs mer

Workshop IBA internet based assessment

Workshop IBA internet based assessment Workshop IBA internet based assessment 2003-04-02 Ulf Jonsson Målsätttning Efter denna workshop så skall du förstå/kunna: * Beskriva olika delarna som ingår i verktyget Perception. * Konstruera enkla frågor

Läs mer

En CAD-ansvarigs syn på integrering mot CAD.

En CAD-ansvarigs syn på integrering mot CAD. En CAD-ansvarigs syn på integrering mot CAD. Kraven på att minska ledtiderna ökar. Hur kan man med de verktyg som finns på marknaden organisera det hela så att det förenklar konstruktörens arbete och hela

Läs mer

Metoder för Interaktionsdesign

Metoder för Interaktionsdesign Metoder för Interaktionsdesign Föreläsning 4 Projektmetodik och Scrum Kapitel 9-12 + 14, Scrumbok Det högra spåret Vi lämnar nu det vänstra spåret de mjukare delarna och går in på det högra spåret som

Läs mer

Installation och konfiguration av klientprogramvara 2c8 Modeling Tool

Installation och konfiguration av klientprogramvara 2c8 Modeling Tool Installation och konfiguration av klientprogramvara 2c8 Modeling Tool Hämta programpaket, MSI Aktuell version av klientprogramvaran finns tillgänglig för nedladdning på vår hemsida på adress http://www.2c8.com/

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande

Läs mer

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-015 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställd av Sven Arvidson 2011-09-12 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

TMP Consulting - tjänster för företag

TMP Consulting - tjänster för företag TMP Consulting - tjänster för företag Adress: http://tmpc.se Kontakta: info@tmpc.se TMP Consulting är ett bolag som utvecklar tekniska lösningar och arbetar med effektivisering och problemslösning i organisationer.

Läs mer

Malmö StadsAtlas. Ulf Minör Anna-Stina Munsin Johan Lahti GIT-utvecklare Malmö Stad

Malmö StadsAtlas. Ulf Minör Anna-Stina Munsin Johan Lahti GIT-utvecklare Malmö Stad Ulf Minör Anna-Stina Munsin Johan Lahti GIT-utvecklare Stad Disposition Inledning om våra webbkartor - Verksamhetsstöd Stadskarta på malmo.se Webbkartor på väg. smap Samarbete -Lund-Helsingborg Kartor

Läs mer

30 år av erfarenhet och branschexperts

30 år av erfarenhet och branschexperts 30 år av erfarenhet och branschexperts Integrerad Säkerhet Integrerad Säkerhet Varför överordnat system Användarvänlighet Kvalitet Trygghet Kostnadseffektivitet Varför ett överordnat system? Med stora

Läs mer

PM 01 En jämförelse av två analysmodeller för val av komponentteknik

PM 01 En jämförelse av två analysmodeller för val av komponentteknik MÄLARDALENS HÖGSKOLA Institutionen för Ekonomi och Informatik v PM 01 En jämförelse av två analysmodeller för val av komponentteknik Eskilstuna, 2002-12-12 EI0230 Komponentbaserad applikationsutveckling

Läs mer

Agil testning i SCRUM

Agil testning i SCRUM Agil testning i SCRUM Petter Salomonsson Petter.salomonsson@addq.se Tel: 0708-398435 Kort presentation AddQ Consulting AB tydlig fokus på test och kvalitetssäkringstjänster erbjuder mycket erfarna konsulter

Läs mer

Henrik Häggbom Examensarbete Nackademin Våren 2015

Henrik Häggbom Examensarbete Nackademin Våren 2015 AV Henrik Häggbom Examensarbete Nackademin Våren 2015 1 INLEDNING Som examensarbete på min utbildning på Nackademin Programutveckling.NET kommer jag skapa ett webbaserat system för statistik, tabeller

Läs mer

1 Översikt...2. 1.1 Vad är kontokoder?...2 1.2 Konto/Mapp uppbyggnad...2 1.3 Tillgång till Kontokoder...2. 2 Område Kontokoder...5

1 Översikt...2. 1.1 Vad är kontokoder?...2 1.2 Konto/Mapp uppbyggnad...2 1.3 Tillgång till Kontokoder...2. 2 Område Kontokoder...5 Manual för Kontokod 1 Översikt...2 1.1 Vad är kontokoder?...2 1.2 Konto/Mapp uppbyggnad...2 1.3 Tillgång till Kontokoder...2 2 Område Kontokoder...5 2.1 Mapputforskare...5 2.2 Verktygsfält...6 2.3 Hitta

Läs mer

Administrationsmanual ImageBank 2

Administrationsmanual ImageBank 2 Document information ID: P001 Appendix C Rev: 4 Author: Tomas von Peltzer Product nr: Title: Reviewed by: Approved by: P001 ImageBank Administration Manual Product name: Ingvar Falconer Date: 2014-10-22

Läs mer

Utveckling av ett grafiskt användargränssnitt

Utveckling av ett grafiskt användargränssnitt Datavetenskap Opponenter: Daniel Melani och Therese Axelsson Respondenter: Christoffer Karlsson och Jonas Östlund Utveckling av ett grafiskt användargränssnitt Oppositionsrapport, C-nivå 2010-06-08 1 Sammanfattat

Läs mer

Utvecklingen av ett tidregistrerings- och faktureringssystem

Utvecklingen av ett tidregistrerings- och faktureringssystem Datavetenskap Opponenter: Anders Heimer & Jonas Seffel Respondenter: Daniel Jansson & Mikael Jansson Utvecklingen av ett tidregistrerings- och faktureringssystem Oppositionsrapport, C-nivå 2006:10 1 Sammanfattat

Läs mer

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Presentation Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Om AddQ Mission Vi skapar affärsnytta för kunden genom specialisttjänster inom test, kvalitetssäkring och effektivisering Tjänsteområden

Läs mer

Projektplan, Cykelgarage

Projektplan, Cykelgarage Projektplan, Cykelgarage Johan Anderholm, (dt08ja5@student.lth.se) Jon Andersen (dt08ja8@student.lth.se) Marcus Carlberg (dt08mc4@student.lth.se) Simon Ekvy (dt08se2@student.lth.se) Stefan Johansson (dt08sj7@student.lth.se)

Läs mer

Elisabet Stöök Konsult SAS Institute AB Copyright 2003, SAS Institute Inc. All rights reserved.

Elisabet Stöök Konsult SAS Institute AB Copyright 2003, SAS Institute Inc. All rights reserved. Administrera din SAS miljö med SAS Metadata Server och SAS Management Console. Elisabet Stöök Konsult SAS Institute AB Copyright 2003, SAS Institute Inc. All rights reserved. SAS Intelligence Value Chain

Läs mer

TDDC30 Programmering i Java, Datastrukturer och Algoritmer Lektion 5. Laboration 4 Lådplanering Exempel på grafik, ett avancerat program Frågor

TDDC30 Programmering i Java, Datastrukturer och Algoritmer Lektion 5. Laboration 4 Lådplanering Exempel på grafik, ett avancerat program Frågor TDDC30 Programmering i Java, Datastrukturer och Algoritmer Lektion 5 Laboration 4 Lådplanering Exempel på grafik, ett avancerat program Frågor 1 Laboration 4 - Introduktion Syfte: Öva på självständig problemlösning

Läs mer

Datatal Flexi Presentity

Datatal Flexi Presentity Datatal Flexi Presentity En snabbguide för Presentity Innehållsförteckning 1. Login 2 2. Hänvisa 3 2.1 Att sätta hänvisningar 3 2.2 Snabbknappar 4 2.3 Windows gadget 5 3. Samtal 5 4. Status 6 4.1 Exempel

Läs mer

VI ÄR WMD - THE WORKFLOW COMPANY Nordens ledande workflow specialister inom SAP Helt enkelt!

VI ÄR WMD - THE WORKFLOW COMPANY Nordens ledande workflow specialister inom SAP Helt enkelt! VI ÄR WMD - THE WORKFLOW COMPANY Nordens ledande workflow specialister inom SAP Helt enkelt! Det handlar om att spara tid, få överblick, förenkla arbetsprocesser, utnyttja resurser och i slutändan handlar

Läs mer

Användarmanual. Meetings 1.5

Användarmanual. Meetings 1.5 Användarmanual Meetings 1.5 Revisionsnummer: 1 Dokumentnamn: FormPipe Meetings 1.5 - Användarmanual ipad Datum: 2013-12-05 Formpipe Software AB. All rights reserved. 2 (23) Innehållsförteckning 1 INLEDNING...

Läs mer

Snabbguide webbhotellstjänster v 1.0

Snabbguide webbhotellstjänster v 1.0 Snabbguide webbhotellstjänster v 1.0 Innehållsförteckning 1.0 Allmänt...3 2.0 Översikt kontrollpanel...4 2.1 Desktop...5 2.2 Home...6 3.0 Domäninställningar...7 3.1 Ladda upp dina filer information om

Läs mer

Inlämningsuppgift : Finn. 2D1418 Språkteknologi. Christoffer Sabel E-post: csabel@kth.se 1

Inlämningsuppgift : Finn. 2D1418 Språkteknologi. Christoffer Sabel E-post: csabel@kth.se 1 Inlämningsuppgift : Finn 2D1418 Språkteknologi Christoffer Sabel E-post: csabel@kth.se 1 1. Inledning...3 2. Teori...3 2.1 Termdokumentmatrisen...3 2.2 Finn...4 3. Implementation...4 3.1 Databasen...4

Läs mer

INSTALLATION...3 ATT KOMMA IGÅNG...3 PROGRAMMETS DESIGN...4 LÄGGA TILL TABELL...4 EDITERA TABELL...4 EDITERA RELATION...5 SPARA OCH AVSLUTA...

INSTALLATION...3 ATT KOMMA IGÅNG...3 PROGRAMMETS DESIGN...4 LÄGGA TILL TABELL...4 EDITERA TABELL...4 EDITERA RELATION...5 SPARA OCH AVSLUTA... INSTALLATION...3 ATT KOMMA IGÅNG...3 PROGRAMMETS DESIGN...4 LÄGGA TILL TABELL...4 EDITERA TABELL...4 EDITERA RELATION...5 SPARA OCH AVSLUTA...6 2 (6) 2D1954 Programutvecklingsprojekt vt 2003 Installation

Läs mer

Kanban. Marcus Hammarberg. torsdag den 15 september 2011 (v.)

Kanban. Marcus Hammarberg. torsdag den 15 september 2011 (v.) Kanban Marcus Hammarberg Kanban? Vad sjutton är Kanban för något? Jag brukar beställa yakiniku... http://blog.huddle.net/wp-content/uploads/2009/08/team-building-exercises-improving-teamwork.jpg Kanban

Läs mer

Installationsmanual ImageBank 2

Installationsmanual ImageBank 2 Document information ID: P001 Appendix D Rev: 3 Author: Ingvar Falconer Product nr: Title: Reviewed by: Approved by: P001 Installation Manual Product name: Tomas von Peltzer Date: 2014-10-22 Sign: Mattias

Läs mer

Inlämningsarbete Case. Innehåll Bakgrund bedömning inlämningsarbete... 2 Inlämnade arbeten... 4

Inlämningsarbete Case. Innehåll Bakgrund bedömning inlämningsarbete... 2 Inlämnade arbeten... 4 Inlämningsarbete Case Innehåll Bakgrund bedömning inlämningsarbete... 2 Inlämnade arbeten... 4 1 Bakgrund bedömning inlämningsarbete Syfte: Eftersom det står i betygskriterierna att för VG skall deltagaren

Läs mer

Allt du behöver för crowdsourcing

Allt du behöver för crowdsourcing GUIDE Allt du behöver för crowdsourcing DEL 2: Så här följer och visar du resultatet i en dashboard Allt du behöver för crowdsourcing den kompletta guiden steg för steg, del 2 För att utföra uppgifterna

Läs mer

Användarhandbok Ver. 1.3.0.1 2013-12-16

Användarhandbok Ver. 1.3.0.1 2013-12-16 Användarhandbok Ver. 1.3.0.1 2013-12-16 Innehållsförteckning 1 Terminologi... 3 2 Knappar i toppmenyn... 4 3 Logga in i ParaGå... 5 3.1 Starta ParaGå med genväg... 5 3.2 Starta ParaGå utan genväg... 5

Läs mer

L0009B. Moment. Introduktion till geografiska databaser: G:\L0009B\Allmänt\IntroGeoDB.pdf (F)

L0009B. Moment. Introduktion till geografiska databaser: G:\L0009B\Allmänt\IntroGeoDB.pdf (F) L0009B Moment FL 1: Kursintroduktion. Kursinformation: G:\L0009B\Allmänt\KursInformationL0009B.pdf (F) Kursplan: Se https://portal.student.ltu.se/stuka/kurs.php?kurs=l0009b&lang=swe (F) Allt som markerats

Läs mer

Webbservrar, severskript & webbproduktion

Webbservrar, severskript & webbproduktion Webbprogrammering Webbservrar, severskript & webbproduktion 1 Vad är en webbserver En webbserver är en tjänst som lyssnar på port 80. Den hanterar tillgång till filer och kataloger genom att kommunicera

Läs mer

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur

Objekt-orienterad utveckling. Objektorienterad analys och design. Objekt-orienterad programutveckling. Objekt-orienterad analys och design: Litteratur Objekt-orienterad utveckling Saker man vill uppnå: Objektorienterad analys och design Sven-Olof Nyström Uppsala Universitet 16 mars 2005 en systematisk metod för att gå från problembeskrivning till färdigt

Läs mer

Jetshop AB WEBSERVICE-API 1.2 ANVÄNDARMANUAL. Version 1.2 2011-10-12

Jetshop AB WEBSERVICE-API 1.2 ANVÄNDARMANUAL. Version 1.2 2011-10-12 Jetshop AB WEBSERVICE-API 1.2 ANVÄNDARMANUAL Version 1.2 2011-10-12 1. Förord I det här dokumentet ges en generell beskrivning av det Webservice-API som är utvecklat av Jetshop AB, och är avsett för dig

Läs mer

Axalon Process Navigator SP Användarhandledning

Axalon Process Navigator SP Användarhandledning Axalon Process Navigator SP Användarhandledning Axalon Process Navigator SP 2013, senast reviderad: den 11 juni 2014 Innehåll Innehåll... 2 Om denna användarhandledning... 3 Syfte... 3 Vem är denna handledning

Läs mer

F o r d o n s k o n t r o l l N y v e r s i o n 2 0 1 3-0 9 S i d a 1. Ny version 2013-09

F o r d o n s k o n t r o l l N y v e r s i o n 2 0 1 3-0 9 S i d a 1. Ny version 2013-09 F o r d o n s k o n t r o l l N y v e r s i o n 2 0 1 3-0 9 S i d a 1 Ny version 2013-09 F o r d o n s k o n t r o l l N y v e r s i o n 2 0 1 3-0 9 S i d a 2 Innehåll Ny menystruktur... 3 Fordon... 3

Läs mer

Solvändan slutrapport Daniel Hallqvist, Therese Samuelsson & Emil Carlsson

Solvändan slutrapport Daniel Hallqvist, Therese Samuelsson & Emil Carlsson Solvändan slutrapport Daniel Hallqvist, Therese Samuelsson & Emil Carlsson Sammanfattning Det här är slutrapporten för ett projekt som gjordes i kursen Webbprojekt I av tre studenter på programmet webbprogrammerare.

Läs mer

Administrationsmanual ImageBank 2

Administrationsmanual ImageBank 2 Administrationsmanual ImageBank 2 INNEHÅLL 1. Konventioner i manualen 3 2. Uppmärksamhetssymboler 3 3. Vad är imagebank SysAdmin 4 4. Guide för att snabbt komma igång 5 5. Uppgradera din imagebank 1.2

Läs mer

Slutrapport. APFy.me

Slutrapport. APFy.me Slutrapport APFy.me Innehållsförteckning 1 Inledning... 3 2 Mål och syfte... 3 3 Projektbeskrivning... 3 4 Leverabler... 4 5 Resultat... 4 6 Utvärdering och analys... 4 6.1 Utvärdering av resultat... 4

Läs mer

Storegate Pro Backup. Innehåll

Storegate Pro Backup. Innehåll Storegate Pro Backup Välkommen! I denna manual kan du bland annat läsa om funktioner och hur du ska konfigurerar programmet. Läs gärna vårt exempel om versionshantering och lagringsmängd innan du konfigurerar

Läs mer

DOTPROJECT Manual. Projektledare och administratör har tillgång till fler funktioner och mer information än andra roller i det webbaserade systemet.

DOTPROJECT Manual. Projektledare och administratör har tillgång till fler funktioner och mer information än andra roller i det webbaserade systemet. Projektarbeta med DOTPROJECT Projektplattformen Dotproject kan användas direkt via webben med en vanlig webbläsare. Systemet är framförallt lämpligt om du snabbt och enkelt vill dela all projektinformation,

Läs mer

Föreläsning 15: Repetition DVGA02

Föreläsning 15: Repetition DVGA02 Föreläsning 15: Repetition DVGA02 Vad handlar kursen om? Kursen kan i grova drag delas upp i tre delar: 1. Objekt-orienterad programmering 2. Grafiska användargränssnitt 3. Datastrukturer Dessutom genomsyras

Läs mer

Slutrapport Vertikala Sökmotorer Uppdrag från.se:s Internetfond Våren 2008

Slutrapport Vertikala Sökmotorer Uppdrag från.se:s Internetfond Våren 2008 Slutrapport Vertikala Sökmotorer Uppdrag från.se:s Internetfond Våren 2008 Anders Ardö Elektro- och informationsteknik Lunds Universitet Box 118, 221 00 Lund June 18, 2009 1 Inledning Digitala bibliotek

Läs mer

TDDD26 Individuell projektrapport

TDDD26 Individuell projektrapport TDDD26 Individuell projektrapport Kort beskrivning av projektet Vi hade som projekt att utveckla en digital media servicer som skulle hjälpa filmentusiasten att organisera sitt filmbibliotek. Programmet

Läs mer

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.

Mina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu. Mina listor En Android-applikation Rickard Karlsson 2013-06-09 Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.se Innehållsförteckning 2. Innehållsförteckning 3. Abstrakt 4. Inledning/bakgrund

Läs mer

Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue. Ronny Roos, 85-02-27 4098 d04rr

Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue. Ronny Roos, 85-02-27 4098 d04rr Ingenjörsinriktad yrkesträning - Softhouse Crossmedia Avenue Ronny Roos, 85-02-27 4098 d04rr Inlämnad: 16 januari 2008 1 Softhouse - Crossmedia Avenue Crossmedia Avenue, är ett svenskt företag som ingår

Läs mer

Programmering B PHP. Specialiseringen mot PHP medför att kursens kod i betygshanteringen heter PPHP1408.

Programmering B PHP. Specialiseringen mot PHP medför att kursens kod i betygshanteringen heter PPHP1408. Programmering B PHP DTR1208 - Programmering B 50 poäng Specialiseringen mot PHP medför att kursens kod i betygshanteringen heter PPHP1408. Mål Mål för kursen (Skolverket) Kursen skall ge fördjupade teoretiska

Läs mer

Agile - det moderna synsättet på mjukvaruutveckling Ordet Agile kommer från engelskan och kan närmast översättas med flexibel, dynamisk och smidig. Med det menar vi dynamiska projekt som konstruktivt kan

Läs mer

Rätt information till rätt person vid rätt tillfälle

Rätt information till rätt person vid rätt tillfälle Rätt information till rätt person vid rätt tillfälle System för samverkan, effektivitet och konkurrenskraft Du håller säkert med om att ditt företags kanske mest värdefulla tillgång består av all den information

Läs mer

Hitta k största bland n element. Föreläsning 13 Innehåll. Histogramproblemet

Hitta k största bland n element. Föreläsning 13 Innehåll. Histogramproblemet Föreläsning 13 Innehåll Algoritm 1: Sortera Exempel på problem där materialet i kursen används Histogramproblemet Schemaläggning Abstrakta datatyper Datastrukturer Att jämföra objekt Om tentamen Skriftlig

Läs mer

Innehåll. Dokumentet gäller från och med version 2014.3 1

Innehåll. Dokumentet gäller från och med version 2014.3 1 Innehåll Introduktion... 2 Före installation... 2 Beroenden... 2 Syftet med programmet... 2 Installation av IIS... 2 Windows Server 2008... 2 Windows Server 2012... 6 Installation av webbapplikationen

Läs mer

Programbeskrivning. Chaos på Web. Version 1.0 2005-09-21

Programbeskrivning. Chaos på Web. Version 1.0 2005-09-21 2005-09-21 Programbeskrivning Chaos på Web Version 1.0 Chaos systems AB Tel. 08-410 415 00 e-post: info@chaos.se Solna strandväg 18, 6tr Fax. 08-29 06 66 http://www.chaos.se 171 54 SOLNA Reg. nr: 556476-6813

Läs mer

ALEPH ver. 16 Introduktion

ALEPH ver. 16 Introduktion Fujitsu, Westmansgatan 47, 582 16 Linköping INNEHÅLLSFÖRTECKNING 1. SKRIVBORDET... 1 2. FLYTTA RUNT M.M.... 2 3. LOGGA IN... 3 4. VAL AV DATABAS... 4 5. STORLEK PÅ RUTORNA... 5 6. NAVIGATIONSRUTA NAVIGATIONSTRÄD...

Läs mer

lokalnytt.se Manual kundadministration

lokalnytt.se Manual kundadministration lokalnytt.se Manual kundadministration version 2.0 2012-08-23 Innehåll Inledning... sidan 2 Rekommendationer... sidan 2 Gemensamma funktioner... sidan 3 Inloggning... sidan 4 Startsida... sidan 5 Objekt...

Läs mer

WebbSMS från datorn. Innehållsförteckning

WebbSMS från datorn. Innehållsförteckning WebbSMS från datorn Innehållsförteckning 2012-01-02 Nyheter i WebbSMS 120102... 2 ip.1 gör SMS från datorn smartare med WebbSMS... 2 Flera användare med samma information.... 2 Tips och trix... 2 Valfri

Läs mer

PROGES PLUS THERMOSCAN RF. Instruktionsmanual V. 061115

PROGES PLUS THERMOSCAN RF. Instruktionsmanual V. 061115 ThermoScan RF användarinstruktioner 1 PROGES PLUS THERMOSCAN RF Instruktionsmanual V. 061115 Viktigt! Den här manualen innehåller ett antal lösenord som endast är avsedda för administratörerna. Glöm inte

Läs mer

SCRUM. En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte?

SCRUM. En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte? SCRUM En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte? Grundprinciper Projektgruppen organiserar och planerar sitt eget arbete Fokus på verksamhetsnytta Alla krav prioriteras

Läs mer

Vad är nytt i ExOpen Web Reports 2.1?

Vad är nytt i ExOpen Web Reports 2.1? Vad är nytt i ExOpen Web Reports 2.1? Innehåll Notifieringar...1 Schemalagd rapportuppdatering...2 Intranätsintegration och integrerad inloggning (Single Sign-On)...2 Förfinad visualisering...3 Teknik...5

Läs mer

Scrum + XP = sant. Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se. Frederik Blauenfeldt Jeppsson. dt06fb8@student.lth.

Scrum + XP = sant. Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se. Frederik Blauenfeldt Jeppsson. dt06fb8@student.lth. Scrum + XP = sant Kristian Björk D06, Lunds Tekniska Högskola dt05kb1@student.lth.se Frederik Blauenfeldt Jeppsson D06, Lunds Tekniska Högskola dt06fb8@student.lth.se 2010-03-02 1 Abstract Scrum och XP

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer