In modern software development, continuous integration has become a integral part of agile development methods, advocating that developers should integrate their code frequently. Configura currently has one dedicated machine, performing tasks such as building the software and running system tests each time a developer submits new code to the main repository. One of the main practices of continuous integration advocates for having a fast build in order to keep the feedback loop short for developers, leading to increased productivity. Configura’s build system, named Build Central, currently uses a sequential build procedure to execute said tasks and was becoming too slow to keep up with the number of requested builds. The primary method for speeding up this procedure was to utilize the multi-core architecture of the build machine. In order to accomplish this, the system would need to deploy a scheduling algorithm to distribute and order tasks correctly. In this thesis, six scheduling algorithms are implemented and compared. Four of these algorithms are based on the classic list scheduling approach, and two additional algorithms are proposed which are based on dynamic scheduling principles. In this particular system, the dynamic algorithms proved to have better performance compared to the static scheduling algorithms. Performance on Build Central, using four processing cores, was improved with approximately 3.4 times faster execution time on an average daily build, resulting in a large increase of the number of builds that can be performed each day.

Upgrading or migrating a build system can be a daunting task. Complete build system migration requires significant effort. To make the process more effective, we automated the first steps of migration, and attempted to analyze the new build results to find anomalies. Our findings show promise for automation as a first step of migration, and we see that automated evaluation could have some potential.

In recent years the industry has been exhorted to increase its use of offsite technologies, or 'Modem Methods of Construction', in order to address the under-supply and poor build quality of housing. Despite the well-rehearsed benefits of such technologies, the take-up within the industry has been slow. Many studies have attempted to scrutinise the barriers and seek solutions, but the perspectives and practices of housebuilders of using offsite remain unclear. This is significant given that housebuilders contribute nearly 90% to the housing unit completions by the industry overall. This thesis aims to provide a strategy for optimising the use of offsite in housebuilding by investigating UK housebuilders' views on, and utilisations of, such technologies. This has been achieved through a combination of a survey of the top 100 firms, a one and-half-year case study of a large housebuilding organisation, and a series of validation interviews and group exercises, within the existing theoretical framework. The thesis reveals that the current low level of offsite usage in large housebuilders was likely to increase given the pressures to improve quality, time, cost, productivity and health & safety. However, a wider take-up was inhibited by perceived higher capital costs, interfacing problems, long lead-in time, delayed planning process and current manufacturing capacity. For addressing this a framework of strategies is presented, surrounding changing the industry's perceptions, improving procurement, providing better cost data, tackling planning and regulations, encouraging political levers, and providing guidance on decision-making and offsite integration. The thesis then contextualises these findings into the organisational and project contexts, examining the historical and current offsite practices within the general housebuilding business. It reveals that housebuilders primarily aspired to improve business efficiency and mitigate financial risks through the use of offsite despite a complicated agenda for such usage. For using offsite housebuilders developed strategies centred on process, procurement, learning & benchmarking, and training. However, the current heuristic approach to decision-making, coupled with the lack of knowledge of build system selection (BSS) for housebuilding, prevents the benefits from offsite being fully realised. A robust, structured and transparent decision support tool for BSS is developed, transferring knowledge in operational and construction management research to the housebuilding context. It provides an improved decision-making process and databases for system selection. Both the process and data were validated within the wider industry and academic domain, by which the tool was claimed as an effective mechanism for optimising the use of offsite and enhancing organisational learning. The thesis contributes to a better theoretical understanding of offsite and provides strategies for its increased take-up in housebuilding. This helps housebuilding organisations to achieve long-term profitability, but also contributes to addressing the current under-supply of housing. The thesis also contributes to knowledge of decisionmaking and construction management research. This has an implication for wider organisational and decision theory.

<p>The products The Company manufactures are used in an area of the industry where errors leading to a stop in production can be quite expensive. Therefore are testing of the products important and the tests can also give indications about the quality of the products.</p><p>The Company is in a phase where they are developing a new product line to support all existing and future products. In this phase, it was decided that all products will use a common framework for unit testing and a common build system for all products. One part of the thesis was to investigate and evaluate different frameworks for unit testing and tools for a build system. The unit test framework that were evaluated are Cppunit, cfix, NUnit, Boost test library, Unit Testing++ and CxxTest. The result of the evaluation was that CppUnit were recommended. For the build system MSBuild, NAnt, Automated Build Studio and Cruise Control .NET were evaluated. The recommended tools for a build system is MSBuild in combination with Cruise Control .Net if The Company is interested in the functionality Cruise Control .Net has to offer.</p><p>The Company also has an interest in evaluating the current test processes and identify improvements as a part of The Company’ s objective were all products should follow a common test process. In order to identify these improvements a literature study of four test process improvement frameworks (Test Process Improvement, Test Maturity Model Integrated, Minimal Test Practice Framework and Test Improvement Model) were carried out. Out of these four frameworks Test Process Improvement (TPI) were chosen to assist when identifying improvements. With the help of TPI a limited assessment took place to give indications about the test maturity for three of The Company’s products where two of the products had low maturity. Results of the improvement measures can be summed up with the need to harmonize the documents, standardize and document the various processes.</p><p>As a last part of the thesis the possibility to automate testing of two of the products graphical user interfaces with the program Test Complete were investigated. For one of the products the result was that it worked satisfactorily and for the other product it did not work at all. This resulted in recommendations for how The Company should proceed with automated testing of the graphical user interface.</p> / <p>De produkter som företaget tillverkar används i huvudsak inom ett område av branschen där fel som leder till stopp i produktionen kan vara ganska dyrt. Detta gör testning av produkterna viktiga och tester kan också ge indikationer om kvaliteten på produkterna.</p><p>Företaget är i en fas där man utvecklar en ny produktlinje som ska stödja alla befintliga och framtida produkter. I denna fas har man beslutat att alla produkterna ska använda ett gemensant ramverk för enhetstestning och även använda ett gemensamt byggsystem för samtliga produkter. En del av examensarbetet var att undersöka och utvärdera olika ramverk för enhets testning och verktyg för byggsystem. De ramverk som utvärderades var CppUnit, cfix, NUnit, Boost test library, unitTest++ och CxxTest. Utvärderingen ledde fram till att CppUnit rekommenderades till företaget. Verktyg som utvärderades för byggsystem var MSBuild, NAnt, Automated Build Studio och Cruise Control .Net. För byggsystem rekommenderas MSBuild i kombination med Cruise Control .Net ifall företaget är intresserade av den extra funktionalitet som Cruise Control .Net har att erbjuda.</p><p>Företaget har även ett intresse av att utvärdera den nuvarande testprocessen och identifiera förbättringar som ett led i att befintliga produkter skall följa en gemensam testprocess. För att kunna identifiera dessa förbättringar utfördes en litteraturstudie över fyra stycken test process förbättrings ramverk (Test Process Improvent, Test Maturity Model integrated, Minimal Test Practice Framework och Test Improvement Model). Utav dessa fyra ramverk så valdes Test Process Improvement (TPI) ut som en hjälp för att identifiera förbättringar. Med hjälp av TPI utfördes en begränsad bedömning av företagets mogenhetsgrad på tre produkter, där två av produkterna har en låg mogenhetsgrad. Resultat av förbättringsåtgärderna kan sammanfattas med att man bör harmonisera dokument, standardisera och dokumentera olika processer.</p><p>Som en sista del i examensarbetet så utvärderades möjligheten att automatisera testning på två av produkternas grafiska användargränssnitt med programmet TestComplete. För en av produkterna blev resultatet att det fungerade tillfredställande och för den andra produkten så fungerade det inte alls. Resultatet blev rekommendationer för hur företaget borde gå vidare med automatisering av testnig på det grafiska användargränssnittet.</p>

The products The Company manufactures are used in an area of the industry where errors leading to a stop in production can be quite expensive. Therefore are testing of the products important and the tests can also give indications about the quality of the products. The Company is in a phase where they are developing a new product line to support all existing and future products. In this phase, it was decided that all products will use a common framework for unit testing and a common build system for all products. One part of the thesis was to investigate and evaluate different frameworks for unit testing and tools for a build system. The unit test framework that were evaluated are Cppunit, cfix, NUnit, Boost test library, Unit Testing++ and CxxTest. The result of the evaluation was that CppUnit were recommended. For the build system MSBuild, NAnt, Automated Build Studio and Cruise Control .NET were evaluated. The recommended tools for a build system is MSBuild in combination with Cruise Control .Net if The Company is interested in the functionality Cruise Control .Net has to offer. The Company also has an interest in evaluating the current test processes and identify improvements as a part of The Company’ s objective were all products should follow a common test process. In order to identify these improvements a literature study of four test process improvement frameworks (Test Process Improvement, Test Maturity Model Integrated, Minimal Test Practice Framework and Test Improvement Model) were carried out. Out of these four frameworks Test Process Improvement (TPI) were chosen to assist when identifying improvements. With the help of TPI a limited assessment took place to give indications about the test maturity for three of The Company’s products where two of the products had low maturity. Results of the improvement measures can be summed up with the need to harmonize the documents, standardize and document the various processes. As a last part of the thesis the possibility to automate testing of two of the products graphical user interfaces with the program Test Complete were investigated. For one of the products the result was that it worked satisfactorily and for the other product it did not work at all. This resulted in recommendations for how The Company should proceed with automated testing of the graphical user interface. / De produkter som företaget tillverkar används i huvudsak inom ett område av branschen där fel som leder till stopp i produktionen kan vara ganska dyrt. Detta gör testning av produkterna viktiga och tester kan också ge indikationer om kvaliteten på produkterna. Företaget är i en fas där man utvecklar en ny produktlinje som ska stödja alla befintliga och framtida produkter. I denna fas har man beslutat att alla produkterna ska använda ett gemensant ramverk för enhetstestning och även använda ett gemensamt byggsystem för samtliga produkter. En del av examensarbetet var att undersöka och utvärdera olika ramverk för enhets testning och verktyg för byggsystem. De ramverk som utvärderades var CppUnit, cfix, NUnit, Boost test library, unitTest++ och CxxTest. Utvärderingen ledde fram till att CppUnit rekommenderades till företaget. Verktyg som utvärderades för byggsystem var MSBuild, NAnt, Automated Build Studio och Cruise Control .Net. För byggsystem rekommenderas MSBuild i kombination med Cruise Control .Net ifall företaget är intresserade av den extra funktionalitet som Cruise Control .Net har att erbjuda. Företaget har även ett intresse av att utvärdera den nuvarande testprocessen och identifiera förbättringar som ett led i att befintliga produkter skall följa en gemensam testprocess. För att kunna identifiera dessa förbättringar utfördes en litteraturstudie över fyra stycken test process förbättrings ramverk (Test Process Improvent, Test Maturity Model integrated, Minimal Test Practice Framework och Test Improvement Model). Utav dessa fyra ramverk så valdes Test Process Improvement (TPI) ut som en hjälp för att identifiera förbättringar. Med hjälp av TPI utfördes en begränsad bedömning av företagets mogenhetsgrad på tre produkter, där två av produkterna har en låg mogenhetsgrad. Resultat av förbättringsåtgärderna kan sammanfattas med att man bör harmonisera dokument, standardisera och dokumentera olika processer. Som en sista del i examensarbetet så utvärderades möjligheten att automatisera testning på två av produkternas grafiska användargränssnitt med programmet TestComplete. För en av produkterna blev resultatet att det fungerade tillfredställande och för den andra produkten så fungerade det inte alls. Resultatet blev rekommendationer för hur företaget borde gå vidare med automatisering av testnig på det grafiska användargränssnittet.

When developing HTML5 applications for TV platforms, the TV platforms provide, in addition to standardHTML5 functionality, also extra APIs for TV-specific features. These extra APIs differ between TVplatforms, and that is a problem when developing an application targeting several platforms. This thesis hasexamined if it is possible to design a framework which provides the developer with one API that works formany platforms by wrapping their platform-specific code. The answer is yes. With success, platform-specificfeatures including: TV remote control input, video, volume, Internet connection status, TV channel streamsand EPG data have been harmonised under an API in a JavaScript library. Furthermore, a build systempackages the code in the way the platforms expect. The framework eases the development of TV platformHTML5 applications. At the moment, the framework supports the Pace, PC and Samsung Smart TVplatforms, but it can be extended with more TV platform back-ends. / Lorsque l’on développe des applications HTML5 pour des plateformes TV, les plateformes TV fournissent,en plus de la fonctionnalité standard d'HTML5, des APIs supplémentaires pour les particularités d'une TV.Ces APIs supplémentaires diffèrent entre les plateformes TV, et ceci cause un problème lors dudéveloppement d’une application pour plusieurs plateformes. Cette thèse a fait l’examen de la possibilité deconcevoir un cadre d'applications qui fournit au concepteur une API qui peut servir à plusieurs plateformes,cachant le code spécifique de celles-ci. La réponse est oui. On a réussi à harmoniser : l’entrée de latélécommande, le lecteur vidéos, le volume, la connexion Internet, le flux TV et leurs données GPE, dans uneAPI qui réside dans une bibliothèque JavaScript. En outre, un système de compilation met le code d’unemanière dont la plateforme peut comprendre. Le cadre d'applications facilite le développement d'applicationsHTML5 des plateformes TV. Pour le moment, le cadre d'applications peut supporter la Pace, le PC et laplateforme de Samsung Smart TV, mais il peut également fonctionner avec d'autres plateformes TV. / Wenn man HTML5-Anwendungen für TV-Plattformen entwickelt, stellen die Plattformen neben denStandardfunktionalitäten von HTML5 auch extra APIs für TV spezifische Features zur verfügung. Diesezuzätzlichen APIs unterscheiden zwischen TV-Plattformen und das ist ein Problem bei der Entwicklung vonAnwendungen, die auf mehreren Plattformen laufen sollen. Diese These untersucht, ob es möglich ist, einFramework zu entwerfen, dass dem Entwickler eine API bereitstellt, welche für mehrere Plattformenfunktioniert, indem deren Plattform spezifischer Code verpackt wird. Die Antwort ist ja. Das Frameworkharmonisiert: Fernbedienungeingabe, Video, Volumen, Internet-Anschlussstatus, Fensehkanalstreams undelektronische Programmführer, zu einer gemeinsamen JavaScript-Bibliothek-API. Weiterhin verpackt einbuild system den Code so, wie es die Plattform erwartet. Das Framework erleichtert die Entwicklung vonHTML5-Applikationen für TV-Plattformen. Im Moment deckt das Framework: Pace-, PC- und SamsungSmart TV-Plattformen, aber es kann mit weiteren TV-Plattformen erweitert werden. / Quando si sviluppano delle applicazioni HTML5 per le piattaforme TV, quest'ustime offrono, oltre allafunzionalità comune di HTML5, anche APIs addizionali per funzionalità specifiche della TV. Queste APIsaddizionali differiscono tra le varie piattaforme TV e questo è un problema quando si sviluppaun'applicazione che funzioni per ciascuna piattaforma. Il presente lavoro esamina la possibilità di progettareun framework che fornisca allo sviluppatore una sola API, la quale sia funzionante per molte piattaforme esia idonea a nascondere il codice specifico di ciascuna di esse. La risposta è sì. Il framework fonde:l'immissione del telecomando, il video, il volume, lo stato della connessione Internet, i flussi dei canali TV edei dati della guida elettronica dei programmi, all'interno di una API secondo il modello di una libreriaJavaScript. Inoltre, il sistema di compilazione crea un pacchetto del codice nel modo in cui le piattaforme siaspettano. Il framework facilita lo sviluppo di applicazioni HTML5 per le piattaforme TV. Al momento, ilframework sostiene le seguenti piatteforme: Pace, PC e Samsung Smart TV, ma può essere esteso anche adaltre. / När man utvecklar HTML5-applikationer för TV-plattformar, finns utöver HTML5s standardfunktionalitet,även extra APIer för att komma åt TV-specifika funktioner. Dessa extra APIer skiljer sig åt mellan TV-plattformar, och det är ett problem när man utvecklar en applikation för många plattformar. Dettaexamensarbete har undersökt om det är möjligt att designa ett ramverk som förser utvecklaren med ett APIsom fungerar för många plattformar genom att wrappa deras plattformsspecifika kod. Svaret är ja. Ramverketharmoniserar: fjärrkontrollsindata, video, volym, internetförbindelse, TV-kanalströmmar och deras TV-tablåer, till ett gemensamt JavaScript-bibliotek-API. Vidare paketerar ett byggsystem koden på de sätt somplattformarna förväntar sig. Ramverket underlättar utveckling av HTML5-applikationer för TV-plattformar.För tillfället stöder ramverket plattformarna: Pace, PC och Samsung Smart TV, men det kan breddas med flerTV-plattformar.

This thesis deals with implementation of continuous integration for build system Copr. The implementation uses framework Citool and its modules, which are already used for continuous integration of build system Koji. The outcome system can run the tests for the new package from the build system Copr and test it on virtual machine. This thesis shows way how to implement continuous integration for build system Copr.

Modern build systems that build large software projects often utilize a distributed compiler, allowing the compilation of object files to be parallelized over multiple machines. These build systems are often not able to fully utilize all the resources available on all machines. As linking is not part of this distributed process, the unused resources could be used to perform linking instead, reducing the total build time. However, linking is often performed at the end of the build process, thus not being able to access the previously unused resources. In this thesis project, a linker that runs concurrently with the compilation process of the build system is designed, implemented, and evaluated . As the compilation process produces an object file, the linker performs a partial link using this file. The link is finalized at the end of the build, not unlike a traditional linker. The results show that the total build time is reduced when using the new linker in a build system utilizing a distributed compiler. In some cases, the time spent linking at the end of the build system is reduced over 50 percent when compared to the reference linker.