<p>Rapporten presenterar skapandet av en produktkonfigurator och flera förslag på hur den kan förbättras. Uppdraget gavs av System Andersson till två studenter på Jönköpings Tekniska Högskola som genomförde detta som sitt examensarbete.</p><p>Rapporten diskuterar möjliga lösningar på en produktkonfigurator och visar ett resultat som utgår från dessa lösningar. Produktkonfiguratorn i rapporten består av två delar.</p><p>Dels konfigurationsdelen som hjälper användaren att skapa nya produkter utifrån valda artiklar. Artiklarna sorteras automatiskt av produktkonfiguratorn så att endast kompatibla artiklar kan sättas ihop. Detta sker med ett ”drag and drop” gränssnitt.</p><p>Dessutom innehåller produktkonfiguratorn en kompatibilitetsdel, vars uppgift är att underlätta vid definierandet av kompatibilitet mellan artiklar. Detta kan göras löpande under tiden en produkt konfigureras om så önskas. Användaren kan välja på två eller flera artiklar som ska vara kompatibla med varandra, eller hela kategorier.</p><p>Sist i rapporten diskuteras de val som gjorts under arbetets gång och möjliga förbättringar som kan göras på produktkonfiguratorn.</p>

<p>Thule Sweden AB utvecklar, tillverkar och marknadsför kompletta och funktionella lasthållarsystem för bilar. De erbjuder en mycket stor bredd av olika lasthållare till över 1500 bilmodeller. De tillverkar lasthållare som cykelhållare, boxar, skidhållare, hållare för vattensport och andra tillbehör. För att en bil skall kunna bära en takbox måste det tillverkas en lasthållare som placeras mellan biltaket och takboxen. En del i denna lasthållare kallas för takbleck och dess form tas fram med en speciell takskanner vilken analyserar biltakets form vid kanterna.</p><p>Till detta har en mjukvara tagits fram som Thule kan använda för att söka/lägga till/redigera takbleck, istället för att manuellt söka i en pärm bland 700 olika ritningar. Programvaran var först utvecklad i Microsoft® Visual Studio 2003 (.NET Framework 1.1), men på senare tid omarbetad från grunden i den nyare utvecklingsmiljön Microsoft® Visual Studio 2005 (.NET Framework 2.0).</p><p>Innan programmeringen av mjukvaran sattes igång utformades en kravspecifikation från Thule om vad de ville ha för funktioner i programmet. Denna kravspecifikation har under utvecklingens tid ändrats, både under de möten som hållits och på en speciell webbplats som skapats för återkoppling av programmet (”TBS Felhanterings-center”), i form av buggar/ändringar/annat.</p><p>Förutom en avdelning i rapporten som behandlar hur denna programvara är uppbyggd, vilka problem som uppstod och hur de löstes, finns även teoretisk information om databaser, XML och andra teknologier.</p><p>Resultatet av projektet blev en applikation för hantering av takbleck som kan användas ute i fält (hos kund) utan uppkoppling mot en gemensam databas hos företaget (mot vilken all information synkroniseras). All information som läggs till/redigeras sparas på användarens lokala dator i form av XML som sedan kan synkroniseras mot den gemensamma server-databasen på företaget.</p> / <p>Thule Sweden AB develop, manufacture, and market complete and functional load carriers for cars. They provide a large amount of different load carriers for over 1500 car models. They also manufacture carriers such as bike carriers, roof boxes, ski carriers and water sport carriers. To be able to put a roof carrier on a car, a load carrier must be manufactured and be placed between the car roof and the roof carrier.</p><p>We have developed software that the group of workers at Thule can use to search/add/edit brackets, instead of manually search in a folder containing over 700 drawings. The program was first developed in Microsoft Visual Studio 2003 (.NET Framework 1.1), but has been rewritten in Microsoft’s new develop environment Visual Studio 2005 (.NET Framework 2.0).</p><p>Before we started to write the program, Thule gave us a specification of requirements that contained information of possible functions in the program. The specification of requirements has been changed a couple of times during our work. We have also put up a website where bugs and changes could be reported.</p><p>Except a part in this report, where we describe how the program is built, how we have solved problems, there is also theoretical information about how databases, XML and other techniques work.</p><p>The result of this project became an application, which the personnel at Thule can use while they visit their customers. The saved information can later be synchronised with the server.</p>

This thesis has examined a selection of Swedish universities’ views on the Swedish national publication database SwePub. The study has phenomenography as its methodology, and by means of the survey it has asked questions about the universities’ local publication databases, the national guidelines on documenting a scientific publication and how the universities regard the whole SwePub analysis project.  The purpose was to find out how the universities perceive the whole SwePub phenomenon. For selecting participants in the survey, the selection criteria were size of the university, the subjects offered there and the publishing system used. Regarding the local publication databases, the answers have focused on the difficulties and opportunities with the registration of scientific work using the own publications database. In the section on guidelines, I discuss how the universities relate to two documents on SwePub guidelines and recommendations. The analysis deals with the national guidelines related to the local practice of the universities, where national guidelines may sometimes collide with the institution's own needs and wishes. The section of the analysis that deals with the institutions' views on the SwePub analysis project at large, relates the SwePub project to the terms function and relevance. In conclusion, I discuss to what extent I have found some patterns in the answers, linked to my selection criteria for the size of the university, subject area and type of publishing system.

This study looks at two Swedish image databases of vastly different scale and how they have decided to apply metadata in relation to gender. The databases in question are Kringla, which is a massive database containing more than 2 million photographs from all over Sweden. The second database is Stockholms digitala stadsmusuem’s (Stockholm’s digital museum) database and it is much smaller and contains mostly images from, and around, the city of Stockholm. As a theoretical base I have used Yvonne Hirdman’s theory of men as a social norm (man-lighetsnorm) and applied it on the type of metadata that was applied to images containing men and women. The study also contains a quantitative element where I documented the amount of hits certain gendered, and non-gendered, search terms generated and then discussed them through a Terry Cook and Joan Schwartz inspired lens of power dynamics and archives.

Thule Sweden AB utvecklar, tillverkar och marknadsför kompletta och funktionella lasthållarsystem för bilar. De erbjuder en mycket stor bredd av olika lasthållare till över 1500 bilmodeller. De tillverkar lasthållare som cykelhållare, boxar, skidhållare, hållare för vattensport och andra tillbehör. För att en bil skall kunna bära en takbox måste det tillverkas en lasthållare som placeras mellan biltaket och takboxen. En del i denna lasthållare kallas för takbleck och dess form tas fram med en speciell takskanner vilken analyserar biltakets form vid kanterna. Till detta har en mjukvara tagits fram som Thule kan använda för att söka/lägga till/redigera takbleck, istället för att manuellt söka i en pärm bland 700 olika ritningar. Programvaran var först utvecklad i Microsoft® Visual Studio 2003 (.NET Framework 1.1), men på senare tid omarbetad från grunden i den nyare utvecklingsmiljön Microsoft® Visual Studio 2005 (.NET Framework 2.0). Innan programmeringen av mjukvaran sattes igång utformades en kravspecifikation från Thule om vad de ville ha för funktioner i programmet. Denna kravspecifikation har under utvecklingens tid ändrats, både under de möten som hållits och på en speciell webbplats som skapats för återkoppling av programmet (”TBS Felhanterings-center”), i form av buggar/ändringar/annat. Förutom en avdelning i rapporten som behandlar hur denna programvara är uppbyggd, vilka problem som uppstod och hur de löstes, finns även teoretisk information om databaser, XML och andra teknologier. Resultatet av projektet blev en applikation för hantering av takbleck som kan användas ute i fält (hos kund) utan uppkoppling mot en gemensam databas hos företaget (mot vilken all information synkroniseras). All information som läggs till/redigeras sparas på användarens lokala dator i form av XML som sedan kan synkroniseras mot den gemensamma server-databasen på företaget. / Thule Sweden AB develop, manufacture, and market complete and functional load carriers for cars. They provide a large amount of different load carriers for over 1500 car models. They also manufacture carriers such as bike carriers, roof boxes, ski carriers and water sport carriers. To be able to put a roof carrier on a car, a load carrier must be manufactured and be placed between the car roof and the roof carrier. We have developed software that the group of workers at Thule can use to search/add/edit brackets, instead of manually search in a folder containing over 700 drawings. The program was first developed in Microsoft Visual Studio 2003 (.NET Framework 1.1), but has been rewritten in Microsoft’s new develop environment Visual Studio 2005 (.NET Framework 2.0). Before we started to write the program, Thule gave us a specification of requirements that contained information of possible functions in the program. The specification of requirements has been changed a couple of times during our work. We have also put up a website where bugs and changes could be reported. Except a part in this report, where we describe how the program is built, how we have solved problems, there is also theoretical information about how databases, XML and other techniques work. The result of this project became an application, which the personnel at Thule can use while they visit their customers. The saved information can later be synchronised with the server.

Detta är en avhandling om hur vi utfört ett projekt som ger vår kund Ninetech en enkel översikt av loggar. Letande av specifik information såsom loggar i stora system kan vara tidskrävande. Så var fallet för företaget Ninetech. Företagets vilja var därav att ha en webbplats för att presentera loggar i ett översiktligt format. Webbplatsens syfte var att underlätta och minska tiden vid letande efter loggar. Att förkorta tiden är viktigt eftersom loggarna innehåller värdefull information som företaget använder för att lösa supportärenden. Webbplatsen som skapats är en fullständig produkt som levererats till företaget och körs i produktion. I projektet har vi haft en nära kontakt med kund, därav har en agil metod tillämpats. Som resultat har webbplatsen tillfört behovet att finna loggar snabbt och enkelt. Webbplatsen har blivit en del av Ninetechs vardagliga arbete. Störst fokus i avhandlingen ägnas åt vyn som presenterar loggar. / This is a dissertation on how we performed a project that gives our customer Ninetech a simple overview of logs. Searching of specific information such as logs in large systems can be time consuming. This was the case for the company Ninetech. Therefore, the company’s will was to have a website to present the logs in a simple format. The website’s purpose was to facilitate and reduce the time when searching for logs. It is important to shorten the time because the logs contain valuable information that the company uses to resolve support issues. The website created is a complete product delivered to the company and is currently running in production. In the project, we have had a close contact with the customer, hence has an agile method applied. As a result, the website has brought the need to find logs quickly and easily. The website has become a part of Ninetech's everyday work. The main focus of the dissertation is devoted to the view that presents logs.

Företag som är intresserade av att gå över från ett traditionellttillvägagångssätt att driftsätta sin applikationsmiljö i en mer moderncontainerbaserad miljö saknas ofta den kunskap och erfarenhet som behövs.Det här arbetet syftar till att ge förslag till företag kring hur de bör gå tillvägaför att flytta sin nuvarande traditionella infrastrukturella lösning, vare sig detär fysiska eller virtuella servrar, till en containerbaserad lösning. Projektetsyftar också till att ge företag som är intresserade av en sådan migration enteoretisk grund att stå på för att undvika att gå i de fällor som är vanliga att gåi. Resultatet baseras på en litteraturstudie som i sin tur resulterade i ensammanfattning över vad som bör ingå i en migrationsstrategi samt ett antalpraktiskt tillämpningsbara beslutsträd.

I denna rapport jämförs Azure SQL Database med NoSQL lösningen DocumentDB, under förutsättningarna givna av ett turbaserat flerspelarspel. NoSQL är en relativt ny typ av databas, som till skillnad från dess relationsbaserade kusin har nya lovord angående fantastisk prestanda och oändlig skalbarhet. Det sägs att det är skapt för dagens problem utan gårdagens begränsningar. Warmkitten vill ta reda på om löftena kring NoSQL håller i deras scenario. Eller om den nuvarande SQL lösningen är en bättre match för deras spel med tanke på skalning, snabbhet och anvädningen utav .NET. Jämförelsen gjordes genom att först skapa ett testramverk för spelets flerspelar funktioner. Sedan optimerades både den relations- och den icke-relationsbaserade lösningen, baserat på rekommendationer och experters utlåtande. Testerna kördes sedan under förhållanden som skulle återspegla verkligheten. Rapporten visar att denna nya typ utav databaser helt klart är mogna nog att i vissa scenarion användas istället för de relationsbaserade databaserna, givet att tillräckligt mycket tid ges åt att förstå skillnaderna mellan databastyperna och vad det innebär. Extra betänketid bör läggas på hur NoSQL skalar samt vilka skillnader som det innebär när relations-begränsningarna försvinner. Prestandamässigt så är DocumentDB snabbare under normal användning när det finns lugnare stunder, SQL är bättre för applikationer som behöver köra under långa stunder med hög användning utav databasen. Rapportens slutsats blir en rekommendation till Warmkitten att fortsätta med den redan utvecklade SQL lösningen. Detta då prestandaförbättringarna från NoSQL inte väger upp för den ökade transaktionskomplexiteten, då spelet använder transaktioner i hög utsträckning. / This paper was created to compare Azure SQL Database to the Azure NoSQL solution DocumentDB. This case study is done in the scope of a turn-based multiplayer game created by Warmkitten. NoSQL is a new type of databases, instead of the relational kind we are used to, this new type gives promises of increased performance and unlimited scalability. It is marketed that it is created for the problems of today and not bound by yesterday’s limitations. Warmkitten would like to gain insight if the promises from NoSQL holds for the game they are developing or if the current SQL solution fit their needs. They are most interested in the areas of scaling, performance and .NET interoperability. The comparison was carried out by creating a test suite testing the game functionalities. Then both the SQL and NoSQL solution was optimized based on best practices and expert guidelines. The tests were then run under circumstances mimicking real-world scenarios. The paper shows that NoSQL is a valid replacement to SQL, if enough time and thought is put into the implementation. Given that NoSQL is a good fit for the problem at hand. Our paper shows that performance wise NoSQL is faster under normal load when there are times with less load, SQL is better for applications that will have continuously heavy load. The final verdict of this paper is a recommendation for Warmkitten to continue using SQL for their game. This is because the recorded performance improvements does not outweighs the transactional problems seen in this case study created by the transactional nature of the game.

Denna studie riktar sig på att kartlägga hur materialdokumentation upprättas för att uppfyllaBoverkets krav gällande förslag till lag. Det undersöks även vilka brister företagen upplevermed materialdokumentation och informationshantering. Vidare undersöks om BIM kan vara enlösning till kommunikationsproblem och underlätta informationshantering. I arbetet har detfokuserats på materialdokumentationen endast under projekteringen.Utredningen i studien har verkställts med kvalitativa metoder, litteraturstudie och intervjuer.Data som samlas in med hjälp av intervjuer används som primära källor kring den aktuellastudien. Respondenterna till intervjustudien är aktörer av olika slag och som anses haerfarenheter med materialdokumentation.Resultatet av studien visa att materialdokumentationen upprättas mest under produktioneneftersom företagen köper det mesta materialet under det skedet. Det som görs underprojekteringen är att företagen mest överväger och planerar hur dokumentationen ska gå till.Det som eventuellt kan dokumenteras under projekteringen är sådana material som bestäms itidiga skeden. Det som brister när företagen ska dokumentera är att materialdatabaserna ochklassifikationssystemen upplevs komplexa och överarbetade, vilket leder till att det inte läggsmycket tid på det och även att det ibland undviks att upprättas. BIM visar sig vara en lösningtill kommunikationsproblem och underlätta informationshantering, men den utnyttjas inte tillsin fulla potential eftersom det är många som inte har datorvana och kunskaper inom BIM.Vilket leder till att även BIM oftast väljs bort. / This study aims to identify how materialdocumentation is prepared to meet the requirements of the Swedish National Board of Housing, Building and Planning. It also examines which flaws the companies experience with materialdocumentation and informationmanagement. Also, further investigations on BIM are done, to see if it can be a solution to the problems. This study focuses on the materialdocumentation, but only during the project planning.The study was conducted with qualitative methods, literature studies and interviews. Datacollected using interviews are used as primary sources. The respondents to the interviews are workers of various kinds and are considered to have enough experience of materialdocumentation.The result of the study has shown that the materialdocumentation is mostly used duringproduction, because the companies buy the most material during that stage.The companies lack knowledge when it comes to documenting and using the material databases. This is because the classification systems are experienced to be complex and overworked. BIM turns out to be a solution to the problems, but it isn’t used to its full potential. This is because there are many who don’t have computer experience and knowledge within BIM.

Migration av data innebär att data flyttas från en databas till en annan. Denna åtgärd kan företag behöva av olika skäl, till exempel för att ändra språk eller förnya befintlig databas. Något som diskuteras är hur denna process ska ske och hur data migreras på bästa smidigaste sätt. Ett av IT företagen som var i behov av svaren är XLENT Sundsvall. XLENT har en webbshop där gränssnittet är föråldrat, samt i behov av en bättre serverlösning ur ett förvaltningsperspektiv. Den här studien syftar till att se över möjligheterna att flytta över den befintliga hemsidan till en modern e-handelslösning. Titta på vilket bästa sätt är att migrera datan till en ny databas som är mer lämplig för hemsidan. De metoderna som ska jämföras är en export-import möjlighet och Extract Transform Load ( ETL) verktyg. Export-import metoden visade sig vara den mest lämpade processen för en databas med våra egenskaper, och en migration med valda processen genomfördes. Till migrationsprocessen hör även städning av data. Ett viktigt steg då databasen bestod av redundant data. En jämförelse mellan den nya och gamla databasen visade att städningen vara en lyckad process då den redundanta datan reducerades med 24 procent. Export-import processen valdes då metoden passade bäst för databas egenskaperna. Då databasen hade varit mycket större eller vara skrivet i ett annat SQL språk så vore metoden inte helt optimalt längre. Då skulle ETL verktyget vara med önskvärt. Vid fortsatt arbete så skulle det vara intressant att göra en mer teoretisk jämförelse. Testa att migrera på de olika sätten, med databaser med olika egenskaper för att få en mer övergripande blick av vilken som passar bäst i olika fall. / Data migration means the transfer of data from one database to another. This is something that more and more companies need to do. for various reasons, for example to change the language or renew the existing database. Something that is discussed is how this process should take place and how data is migrated in the best and most flexible way. One of the IT companies that was in need of the answers is XLENT Sundsvall. XLENT has an online shop where the interface is outdated, and in need of a better server solution from a management perspective. This study aims to review the possibilities of moving over the existing website to a more modern solution. Look at the best way to migrate the data to a new database that is more suitable for the website. The methods to be compared are an export-import method and Extract Transform Load (ETL) tool. The export-import method proved to be the most suitable process for a database with our properties, and a migration with the selected process was performed. The migration process also includes cleaning of data. An important step as the database consisted of redundant data. A comparison between the new and old databases showed that cleaning was a successful process as the redundant data was reduced by 24 percent. The export-import process was chosen as the method best suited the characteristics of the existing database. With a database being much larger or being written in another SQL language, it might not be the most optimal solution anymore. Then the the ETL tool would be better. With continued work, it would be interesting to make more than a theoretical comparison. Try migrating with many different databases with different properties to get a more comprehensive look of which one is best suited in different cases.