Background: In current software development, agile development approaches are widely used. One of these methods is Test-driven development (TDD). TDD is said to be a perfect fit for development as it is highly collaborative and is said to improve productivity and accuracy in development. However, it is not a widely used process because people have different perceptions of TDD (mostly negative). In this study we will investigate the expectations about TDD and if these expectations are being met in practice and understand what makes TDD a not-so-usable process. Objectives: The objectives of this study include: To understand the expectations of practitioners about TDD. To investigate if the expectations for TDD are met in practice. To identify the factors that limit the use of TDD. Methods: We have performed a review of the state of the art, from where we have gathered the most common expectations about TDD. These expectations have been used in the survey to see if these expectations are met from the perspective of practitioners simultaneously, we have also conducted interviews. We have collected qualitative data and analyzed the data. Additionally, we have also conducted a sentiment analysis of Reddit comments. Results: From the survey and interviews, we found that the overall perception of TDD is positive and it can provide benefits in certain contexts, We also identified the factors like lack of knowledge or training, perceived difficulty, and resistance to change among others that limit the use of TDD in industry. In the sentiment analysis, we found that the overall sentiment of the comments is mostly neutral and some of them negative. Conclusions: In conclusion, from our study, we identified that TDD can provide benefits but organizations must be willing to invest the time and effort to train their people and see the results using TDD. There are examples of successful projects using TDD but it is not necessarily the best approach in all situations and should be used judiciously to match the specific needs of the project and the organization. Keywords: Agile, Software testing, Test Driven Development, Expectations, Limitations.

Agility is developing to a more and more central concept in the military domain and new war fare methods etc. is creating a greater demand on the Swedish Defence Agency to be more agile. The concept is very complex but could be described as the ability a command team has to discover threats and opportunities, and act with a response towards these to gain advantage in the situation. This report aims to develop an assessment tool for evaluating whether or not, or to which extent, a command team is agile. Discussions have been made in sessions with informants that somehow are connected to (working with or research about) agility in the Swedish Defence Agency to discuss the development of an assessment tool like this. Five sessions have been executed and after the first two respectively the last three, upgrades of the tool were made. The result of the study shows that it is not impossible to develop an assessment tool, but for a complex concept like agility, it is very hard. The conclusions drawn is that it might be possible to create a basic frame for a tool that further on can be shaped to fit the command team being evaluated.

More efficient and reliable High-Throughput Field Phenotyping (HTFP) approaches are essential for the development of plant breeding and carbon storage studies, as well as the improvement of yield estimation in the food production sector. The use of ground-based platforms in combination with other data sources such as UAVs and satellites addresses constraints related to payload capacity restrictions and reduced below-canopy data collection. This study describes an early approach to the deployment of agile robots for HTFP that aims to estimate height, diameter at breast height (DBH), and volume for forty-three unique trees corresponding to two different species (E. variegata and F. altissima) occupying an urban-park. The data acquisition system consists of an agile robot from Boston Dynamics and a navigation enhancer LiDAR module from the same company. In order to obtain a point cloud using this system, it is necessary to overcome two challenges: a reduced vertical FoV of the LiDAR and limited management of the LiDAR module. A multiway registration approach is implemented to reconstruct a low-density digital twin of the experiment site, which is later georeferenced using points surveyed with a GNSS system. Subsequently, the point cloud is manually segmented using CloudCompare software to obtain individual tree point clouds. Three different algorithms are implemented to obtain height, DBH, and tree volume estimates from the individual point clouds. The results are statistically analyzed by species in order to characterize sources of error. The height estimation method had a Median Percentage Error (MPE) of 1.4% for E. variegata and 1.2% for F. altissima. The DBH estimation had an MPE of 20.1% for E. variegata and 13% for F. altissima. The volume estimation model returned an R2 of 0.86 for E. variegata and 0.98 for F. altissima. Finally, all three feature estimations are mapped into a GEOJson file. These findings, combined with the numerous advantages of using agile robots as mobile platforms in HTFP, enable more efficient and reliable estimation of important parameters such as aboveground biomass and carbon storage sequestration, as well as delivery the potential for improvements in crop monitoring and yield estimation.

With the increasing popularity of Agile methods in software development projects, an emerging question is how Agile incorporates user needs to their process – which is the staple of User Centered Design (UCD). Existing reports indicate that integrating Agile and UCD has shown to improve the process and end product and that they are a natural fit. However, there is also a general lack of guidelines of how an effective integration may be done, and further research is requested. This study aims to provide that by portraying some aspects of how Agile and UCD may be integrated in practice, but also some factors that may affect such an integration. This is done through an empirical study, by gaining insights from the perspective of UX-designers who are part of Scrum teams. TenUX-designers took part in semi-structured interviews, and based on a thematic analysis, results are portrayed in terms of suggested factors to consider when integrating Agile and UCD methods. / Samtidigt som Agila metoder ökar i popularitet inom mjukvaruutvecklingsprojekt, så uppstår även frågan om hur Agilt arbete integrerar användarcentrerade krav i sin process ett område som är i fokus inom Användarcentrerad Design (ACD). Tillgängliga rapporter indikerar på att integrationen av Agilt och ACD har givit förbättrade processer och slutprodukt, samt att båda processer är kompatibla med varandra. Det anses dock finnas en brist på riktlinjer i hur man kan integrera båda processer, och det efterfrågas vidare studier i ämnet. Denna studie ämnar till att erbjuda just detta genom att presentera några faktorer av hur Agilt och ACD kan integreras i praktiken, men också exempel på faktorer som kan påverka hur väl integration lyckas. Detta tas fram genom en empirisk studie, genom att ta del av insikter från UX-designers som jobbar i olika Scrum projekt. Tio UX-designers deltog i semistrukturerade intervjuer, och baserat på en tematisk analys så presenteras resultat i form av föreslagna faktorer att ta del av när man vill integrera Agila och ACD metoder.

This report describes the work on automating the testing of nodes at CCS (Common Control System) in Ericsson. The goal was to every three hours configure nodes with the latest build and run the tests. This process is to be fully automatic without user in-put. The existing configuration tool CICC (Core Integration node Control Center) is to be used for configuration. Before work started fault reports were analyzed and creating a usecase for testing restarts should reduce some faults.The first step was to make the configuration tool CICC automated. To schedule the test-ing the continuous integration tool Jenkins was used. But Jenkins can’t by itself run CICC nor interpret the result. Therefore a wrapper layer was implemented. When the wrapper is finished it stores the results of the configuration run in a XML (eXtensible Markup Language) file, which Jenkins reads. Results can then be seen in Jenkins through web interface. If there were any failures during configuration or testing the failed step will have an error message.The project shows that automation is possible. Automating the testing reduce the time for correcting errors because they are more likely to be found early in the process. Be-fore implementing this project in production some improvements should be made. The most significant improvement is making the configuration and testing of each node par-allel with each other, in order to make the time limit for configuration and testing less of an issue. / Denna rapport beskriver arbetet med att automatisera testningen av noder hos CCS på Ericsson. Målet var att var tredje timma konfigurera noderna med binärfiler kompilerade från den senaste källkoden och sedan testa dem. Detta ska ske helt automatisk utan att användarens hjälp och konfigurationen ska använda det befintliga konfigurations verktyget CICC. Innan arbetet påbörjades skulle felrapporter analyseras för att se om det fanns något att tjäna på automaseringen.Uppgiften löstes genom att först titta på felrapporterna och konstatera att det fanns rum för förbättringar, främst gällande omstarter. Efter det automatiserades CICC som tidigare körts via en GUI. För att schemalägga konfiguration och testning användes testverktyget Jenkins. Jenkins använder sig av ett s.k. wrapperskript som kör CICC och testfallen. Wrapperskriptet sköter även felhanteringen och skriver sedan resultatet av körningen till en XML fil som läses av Jenkins.Resultaten av testen går sedan att se i Jenkins via ett webinterface. Där går det att se resultatet av wrapperskript körningen och testerna, om det blev några fel finns det felmeddelanden med anledningen till felet. Misslyckade tester visas också.Projektet visar att med automatisk testning som sker oftare kan fler fel hittas tidigare och därför åtgärdas snabbare. Innan arbetet används skarpt bör förbättringar ske som tillexempel att köra konfiguration och testning av olika noder parallellt med varandra i wrapperskriptet, för att klara tidsbegränsningen när det är flera noder.

Additive Manufacturing – AM – which is a part of a generic term, Rapid Prototyping, comprises a family of different techniques to build 3D physical objects sequentially stacking a series of layers over each other. These techniques have been evolving over three decades with more materials available, improving the techniques as well as generating new ones. However they are all based on the same explained idea. In this research the main AM methods followed with the opportunities of application and cost drivers is sought. For this purpose, after reviewing different processes and techniques, the application of them in diverse industry sectors is described. The influence of AM in production systems, so called Rapid Manufacturing (RM) is also discussed in terms of lean and agile concepts. Time and cost are the most important factors for the production systems to be responsive and productive respectively. Thus, case based application of RM is evaluated to clarify how AM acts in different production systems regarding these factors. To decide which method is the best, strongly depends on the case. But what has been derived from the analysis, is that however in comparison with traditional methods, AM applies more economically in one-off jobbing, yet the economy of scale exists to some extent. In fact it depends on the machine capacity utilization as well as batch size which indicates the machine volume usage. Despite all the improvements in the last three decades, the application of AM is still not widespread. Since the demand, use, applications and materials as well as its techniques are still in a growing phase, a brighter future is seen for the upcoming customer oriented market. / Additive Manufacturing – AM – som är del av en generell term, Rapid Prototyping, består av en familj olika tekniker för att bygga 3D fysiska objekt genom att sekventiellt lägga lager ovanpå varandra. Dessa tekniker har utvecklats över de senaste tre decennierna, där nya material blivit tillgängliga, teknikerna har förbättrats och nya har skapats, men i slutändan bygger de alla på en och samma idé. Det projekt undersöks de huvudsakliga AM -metoderna, deras applikationer och kostnadsdrivare. Här görs först en litteraturstudie av olika tekniker och processer varefter deras användning inom olika industrier undersöks. Den influens AM har i produktionssystem, s.k. Rapid Manufacturing (RM), diskuteras också i förhållande till lean och agila koncept. Eftersom tid och kostnad är de viktigaste faktorerna för tillgänglighet respektive produktivitet utvärderas case-baserad användning av RM utifrån dessa faktorer för att förklara hur AM fungerar i produktionssystem. Att besluta vilken metod som är bäst, är starkt case-baserad. Men det som framkommit från analysen är att i jämförelse med traditionella metoder, är AM mer ekonomiskt vid enstyckstillverkning, men stordriftsfördelar finns i någon utsträckning. Faktiskt det beror på maskinens kapacitetsanvändning och satsstorlek som indikerar maskinens volymanvändning. Trots alla förbättringar under de senaste tre decennierna är användandet av AM ännu inte utbrett. Eftersom efterfrågan, användning, tillämpning och material så väl som dess tekniker fortfarande befinner sig i en tillväxtfas spås en ljusare framtid för en växande kundorienterad marknad.

Software development is a growing part of many businesses today. The software development approach that is used to develop new software may have a positive or negative impact on the efficiency and quality of the final software product. The objective of this thesis was to propose a refined software development approach and to test it empirically. The software development approach is comprised of three main subcomponents: development style, development architecture, and technical documentation. The software development approach was applied in a case study in cooperation with Ericsson. At the completion of the case study, questionnaires were administered to Ericsson employees to evaluate the success of the software development approach. The results showed that the quality of the software product was high and Ericsson was pleased with the result. The results indicated that the development approach helped the case study be successful in some of the researched areas. The end results suggest that the proposed software process has the potential to be successful in other projects of a similar type and structure.

Distribuerade agila mjukvaruutvecklings-metoder har aldrig varit mer populärt. Att kunna arbeta hemifrån för att undvika den dagliga pendlingen eller för att samarbeta med utvecklare utomlands har aldrig varit enklare. Tredjepartsverktyg som Zoom och Google Meet förenklar kommunikationsprocessen, och med introduktionen av verktyg som Visual Studio’s “liveshare” som möjliggör realtids-kodning, har agila metoder verkligen flyttat ut från kontoren. Dock är en av de viktigaste komponenterna av att arbeta agilt att arbeta ansikte mot ansikte, vilket innebär att en av de effektivaste metoderna för kommunikation nu förloras när man flyttas till att arbeta med distribuerade metoder. Att övergå till nya metoder är aldrig enkelt, och när företag övergår till en distribuerad framtid kan mjukvaruutvecklare potentiellt drabbas av denna förändring i miljö och metod. Om företag har riktlinjer för övergången till distribuerade metoder kan det potentiellt göra förflyttninen enklare.Problemet är att det inte finns några sådana riktlinjer. Syftet med denna rapport är att skapa riktlinjer med målet att hjälpa organisationer övergå till distribuerade agila metoder från lokala agila metoder. Metoden i denna rapport är en kvalitativ utforskande litteraturstudie tillsammans med utforskande intervjuer som utforskar de positiva och negativa erfarenheterna utvecklare möter när de gör en övergång till distribuerade metoder. Litteraturstudien användes för att formulera forskningskriterierna och intervjufrågorna. Totalt tillfrågades åtta personer som hade erfarenheter av att göra en övergång till distribuerade agila metoder. Dessa intervjuer resulterade i tre generella riktlinjer som kan användas för att förenkla övergången mellan lokala-och distribuerade agila metoder. / Distributed agile software development has never been more popular. Being able to work at home to avoid the commute or simply collaborating with developers abroad has never been easier. Third party tools such as Zoom and Google Meet makes communication easier than ever, and with the introduction of Visual Studio’s live share that enables real-time collaborative coding, distributed agile development truly has moved out of the offices. Yet, one of the core components of the agile working method is working face to face, meaning that one of the most efficient methods of communication is lost upon moving development into a distributed setting. Transitions towards new methods and settings are never easy, and as companies transition towards a remote and distributed future, software developers are potentially burdened by this change in environment. If companies had access to guidelines they could potentially experience a smoother transition. The problem is that there currently do not exist such guidelines. The purpose of this report is to create such guidelines with the goal of helping organizations transition towards distributed agile methods. In this report, the method utilized is a qualitative and explorative literature study, coupled with interviews aimed to explore the positive and negative experiences developers face when transitioning towards distributed methods. A literature study was used to help formulate the research criteria and the interview questions. In total, eight people that had experienced a recent transition towards distributed agile methods were interviewed. These interviews resulted in three general guidelines that can be used to ease the transition between a local and distributed work environment.

The Agile method has since it got published, of many been regarded as the universal solution to increased flexibility in software development. Scrum is, without a doubt, the most widely used Agile method among software development teams. Nonetheless, there are many challenges with the Scrum method, and therefore, success factors need to be identified to make up for its weaknesses. Lack of enthusiasm or events being time-consuming is some of the challenges the team faces with the framework, which can result in its members only using Scrum partially. For that reason, the main objective of this thesis is to identify which parts of Scrum are most commonly skipped by the members of an Agile development team for software, and why. In the initial study, a content analysis was conducted to examine how people in forums and on social media express themselves regarding Scrum, to identify the most common objections to the framework. The conclusion of the work was that the sprint review was identified as the most common event to skip, and the number one reason for skipping an event was that it felt unnecessary. Sprint planning was the step seen as giving the most negative consequences when skipped, and some of the risks of skipping a step were that it could give less oversight, a low feedback cycle, and a lack of communication, and collaboration. A positive outcome of skipping an event was that it allowed for more time to work, to get an uninterrupted flow and less overhead. To get an even better insight into the Scrum team’s daily work, the future study would be to perform a case study for an in-depth, detailed examination of the challenges with Scrum.

Den agila arbetsmetoden har vuxit fram i takt med en volatil marknad som ställer krav på flexibilitet och innovation. Arbetsmetoden utmärker sig som en teamledningsmetod med ett dynamiskt och autonomt arbetssätt. Det råder ofullständig förståelse för vilka utmaningar arbetssättet medför. Syftet med denna studie är att bidra till en djupare förståelse för fenomenet och kunna bidra med insikter för hur organisationens val av styrmekanismer influerar medarbetare i det agila arbetssättet. Totalt genomfördes sju semistrukturerade intervjuer som analyserades med en tematisk analys vilket genererade tre teman: agilt mindset, teamwork och kultur som meningsskapande. Studien visar att de agila arbetsmetoderna och modellerna omfattar en bredare komplexitet än många tidigare forskare framställt. Företagskulturen visar kunna gagna arbetsmetoden när den upplevs meningsfull, transparent, inkluderande och stimulerar engagemang. En internaliserad företagskultur kan frigöra potential att stimulera arbetsmetodens fördelar. Vid implementering av en agil arbetsmetod bör organisationer beakta att det kan vara en tidskrävande process och följer av andra utmaningar än vid traditionella arbetsmetoder.