Denna studie presenterar en jämförelse mellan KL-trä och olika former av betong (armerad/oarmerad och platsgjuten/prefabricerad) som väggmaterial i byggnadskonstruktioner. Syftet är att analysera deras respektive miljöpåverkan och kostnadseffektivitet. Trots en initialt högre kostnad per kvadratmeter, har KL-trä en betydligt lägre miljöpåverkan, vilket medför en nettovinst för miljön jämfört med betongväggarna. Bland betongalternativen uppvisar oarmerad platsgjuten betong en balans mellan lägre kostnader och mindre CO2-utsläpp. Studien lyfter fram behovet av standardiserade, pålitliga data om miljöpåverkan inom byggindustrin för att stödja hållbara beslut. Den pekar på potentialen i ytterligare forskning som syftar till att reducera både kostnader och miljöpåverkan för KL-trä, för att främja dess bredare användning i byggsektorn. Studien erbjuder därmed viktiga insikter för att driva en mer hållbar och ekonomiskt lönsam byggindustri. / This study presents a comparison between CLT and various kinds of concrete (reinforced/unreinforced and cast in place versus prefabricated) as wall material in building constructions. The purpose is to analyse their respective environmental impact and cost efficiency. Despite an initially higher cost per square meter CLT has a considerably lower environmental impact, which entails a net profit for the environment compared to the concrete walls. Among the concrete options, walls without rebar and cast in place exhibits a balance between lower costs and CO2eemissions. This study highlights the need of standardized, trustworthy data of the environmental impact in the construction industry to support sustainable decisions. It points to the potential in further research which intends to reduce both cost and environmental impact for CLT, to further promote its use in the construction industry. The study thus offers important insights for driving a more sustainable and economically profitable construction industry.

När en grupp utvecklare jobbar med samma kodbas kan konflikter uppstå med avseende på implementationen av moduler eller delsystem som varje utvecklare individuellt jobbar på. Dessa konflikter måste snabbt lösas för att projektet ska fortskrida och inte stagnera. Utvecklare som sällan kommunicerar framför ofta okompatibla moduler eller delsystem som kan vara svåra eller omöjliga att integrera i kodbasen, detta leder ofta till s.k. “integration hell” där det kan ta väldigt lång tid att anpassa ny kod till en befintlig kodbas.En strategi som man kan ta till är “continuous integration”, ett arbetssätt som erbjuder en rad fördelar när man jobbar i grupp på en gemensam kodbas. Continuous integration är möjligt att tillämpa utan verktyg eftersom detta är ett arbetssätt. Däremot kan processen stödjas av ett s.k. “CI-system” som är något av en teknisk implementation eller påtagligt införlivande och stöd för arbetsmetoden “continuous integration”.Denna rapport syftar till att ge en inblick i vad ett CI-system är och vad den principiellt består av. Vi undersöker vad ett CI-system absolut måste bestå av genom en litteraturundersökning och en marknadsundersökning. Vi ställer upp dessa beståndsdelar som “funktionella” och “icke-funktionella” krav för ett typiskt CI-system. Vi kan på så vis kvantifiera och kategorisera olika komponenter och funktionaliteter som bör innefattas i ett typiskt CI-system. I denna rapport finns även ett bihang som visar hur man kommer igång med att bygga en egen CI-server mha. CI-systemmjukvaran “TeamCity”.Slutsatsen av vår rapport är att CI-system är ett viktigt redskap som kan underlätta mjukvaruutveckling. Med hjälp av CI-system kan man stödja utvecklingsprocessen genom att bl.a. förhindra integrationsproblem, automatisera vissa delar av arbetsprocessen (kompilering av källkod, testning av mjukvara, notifikation om stabilitet av kodbas och distribution av färdig mjukvara) samt snabbt hitta och lösa integrationsfel. / When a group of developers work on the same code base, conflicts may arise regarding the implementation of modules or subsystems that developers individually work on. These conflicts have to be resolved quickly in order for the project to advance at a steady pace. Developers who do not communicate changes or other necessary deviations may find themselves in a situation where new or modified modules or subsystems are impossible or very difficult to integrate into the mainline code-base. This often leads to so called “integration hell” where it could take huge amounts of time to adapt new code into the current state of the code-base. One strategy, which can be deployed to counteract this trend is called “continuous integration”. This practice offers a wide range of advantages when a group of developers collaborates on writing clean and stable code. Continuous integration can be put into practice without the use of any tools as it is a “way to do things” rather than an actual tool. With that said, it is possible to support the practice with a tangible tool called a CI-system.This study aims to give insight into the makings of a CI-system and what it fundamentally consists of and has to be able to do. A study of contemporary research reports regarding the subject and a survey was performed in order to substantiate claims and conclusions. Core characteristics of CI-systems are grouped into “functional requirements” and “non-functional requirements (quality attributes)”. By doing this, it is possible to quantify and categorize various core components and functionalities of a typical CI-system. This study also contains an attachment which provides instructions of how to get started with implementing your own CI-server using the CI-system software ”TeamCity”. The conclusion of this study is that a CI-system is an important tool that enables a more efficient software development process. By making use of CI-systems developers can refine the development process by preventing integration problems, automating some parts of the work process (build, test, feedback, deployment) and quickly finding and solving integration issues.

The growing need for computer software in different sectors of activity, (health, agriculture, industries, education, aeronautic, science and telecommunication) together with the increasing reliance of the society as a whole on information technology, is placing a heavy and fast growing demand on complex and high quality software systems. In this regard, the anticipation has been on non-functional requirements (NFRs) engineering and formal methods. Despite their common objective, these techniques have in most cases evolved separately. NFRs engineering proceeds firstly, by deriving measures to evaluate the quality of the constructed software (product-oriented approach), and secondarily by improving the engineering process (process-oriented approach). With the ability to combine the analysis of both functional and non-functional requirements, Goal-Oriented Requirements Engineering (GORE) approaches have become de facto leading requirements engineering methods. They propose through refinement/operationalisation, means to satisfy NFRs encoded in softgoals at an early phase of software development. On the other side, formal methods have kept, so far, their promise to eliminate errors in software artefacts to produce high quality software products and are therefore particularly solicited for safety and mission critical systems for which a single error may cause great loss including human life. This thesis introduces the concept of Complementary Non-functional action (CNF-action) to extend the analysis and development of NFRs beyond the traditional goals/softgoals analysis, based on refinement/operationalisation, and to propagate the influence of NFRs to other software construction phases. Mechanisms are also developed to integrate the formal technique Z/Object-Z into the standardised User Requirements Notation (URN) to formalise GRL models describing functional and non-functional requirements, to propagate CNF-actions of the formalised NFRs to UCMs maps, to facilitate URN construction process and the quality of URN models. / School of Computing / D. Phil (Computer Science)

Denna studie problematiserar icke-funktionella krav (IF krav), även benämnt kvalitetskrav, i svenska mjukvaruutvecklingsprojekt. Kravhantering anses vara den mest avgörande delen i mjukvaruutveckling för att lyckas, vilket än idag är en utmaning i majoriteten av projekten. Särskilt svårt är det att lyckas med IF krav, då tvetydigheter leder till brist på dokumentation och slutligen bortprioriteras de. För att adressera dessa problem syftade denna studie att besvara hur väl de IF kraven dokumenteras inom svenska mjukvaruutvecklingsprojekt samt vem som kan ansvara för att kvalitetssäkra de IF kraven. En mixed-method har genomförts med både en kvalitativ litteraturstudie av tidigare forskning samt en kvantitativ studie. Datainsamlingen i den kvantitativa studien har skett med webbaserad enkätundersökning med 24 frågor. Enkäten skickades ut till 72 företag i Sverige vars huvudsyssla var mjukvaruutveckling. Sammanlagt samlades 43 svar in och en univariat analys genomfördes. Enkätundersökningen indikerade att respondenterna är positivt inställda till dokumentation av IF krav. De flesta saknar dessutom gedigen kunskap om IF krav. Vidare saknas tydliga ansvarsroller för dokumentationen av IF krav. En lösnings- eller mjukvaruarkitekt är bäst lämpad för att kvalitetssäkra de IF kraven. Denna studie är skriven på svenska och kan främja studenter, forskare och yrkesverksamma då den nyanserar vikten av IF krav och hur existerande brister kan förbättras. / This study examines non-functional requirements (NFRs), also known as quality requirements, in Swedish software development projects. Requirements engineering is considered the most crucial part of software development, which is still a challenge in the majority of projects today. In particular, the NFRs are the most challenging seeing as there are ambiguities concerning their definition. This in turn leads to lack of documentation and, ultimately, their deprioritization. To address these issues, this study aimed to answer how well NFRs are documented in Swedish software development projects and who can be responsible for ensuring the quality of these NFRs. A mixed-method was conducted with both a qualitative literature review of previous research and a quantitative study. The data collection in the quantitative study was conducted using a web-based survey with 24 questions. The survey was sent to 72 software development companies in Sweden. A total of 43 responses were collected, and a univariate analysis was performed. The survey indicated that respondents have a positive attitude towards documenting. Additionally, most respondents lack comprehensive knowledge about NFRs and clear roles for the NFRs are missing. Standardization, better guidelines, and clear roles are needed to ensure the quality of NFRs, which are currently lacking. A solution or software architect is best suited to ensure the quality of NFRs. This study, written in Swedish, can benefit students, researchers, and professionals as it highlights the importance of NFRs and suggests improvements for existing deficiencies.