In my thesis I focus on providing a foundation of data on whichdecision makers can base refactoring decisions. For this, I examine therelationship between software complexity and maintenance eort. Tomake the data a stronger basis for refactoring decisions, I present anew approach of correlating le metrics to maintenance eort, whereI look at the relation between changes in le metrics over multiplereleases and changes in the maintenance eort spent on these les. Ido this using a broadened and, more complete notion of maintenanceeort. I measure maintenance eort in 4 ways: the amount of lines ofcode that had to be changed to resolve tasks, the amount of discus-sion that tasks generated, the amount of atomic changes to a le thatwere required to resolve a task, and the amount of bugs per month.To test this framework, I extracted data from 3 open source projects,where I measured the variation of both complexity and maintenanceeort, using this new notion of eort, over multiple releases, and in-vestigated their correlation. I found that 21 of the tested metrics weresignicantly correlated to the eort measures, where complexity basedmetrics and incoming propagation cost show the highest correlation.Of the proposed measures for maintenance eort, the amount of dis-cussion to resolve an issue shows the highest correlation to the chosenmetrics.

This thesis provides insight in the further development of an application for managing speed skating events, based on the previous developed application by a group of students in fall 2010. The application was implemented for the Karlstad Speed Skating Club, which before used a program from the 90's. After finishing the implementation, all basic functionality requested by the Karlstad Speed Skating Club can be used for managing speed skating events. The first part of the thesis presents a short summary of our work, comparing what we wanted to implement and what we achieved. A short background on speed skating, the old system, developed by a group of students, and the project requirements are presented. An introduction to the used tools, languages, techniques and development processes is given along with details concerning the implementation of the requirements. Finally, the design of the new user interface is explained and the results are presented, containing an evaluation of the implementation, occured problems and what could be added in the future.

Noways the majority of all trading with financial assets are committed via electronictrading platforms (ETP). Nasdaq is a major ETP provider and powers over 100markets worldwide. Because operational disruptions and software bugs can causesignificant economic losses, software testing is a key part of Nasdaqs operations. Thefirst part of this project was to analyze how Nasdaq works with software testing of itsETP called Genium Inet Trading. Based on this analysis a system aimed at simplifyingand streamlining the process of automating functional tests was developed. Functionaltests are a vital part of Nasdaqs quality assurance efforts. The project resulted in a overall conceptual model and a ”proof of concept”implementation called Scenario Runner. The conceptual model describes howfunctional tests specifications can be represented in an abstract level that isindependent of which techniques that are used for implementation. Scenario Runnerwas developed as a plugin to Nasdaqs internal ETP testing software called NeXTWorkstation and uses MS Excel as input format for the functional test specifications.Scenario Runner reads and executes tests in the MS Excel document and presents theresults both in the NeXT Workstation GUI and as an output MS Excel file. Theproject was successful and Scenario Runner can be used to run simple functionaltests, but more importantly, to demonstrate how the conceptual model can be usedfor automating functional tests in practice.

M.Sc. / The following questions led to this study: Why are there still so many approaches to the software generation process without one single approach taking the lead? Not only are there several methodologies available for the software generation process, but a methodology is not in use for long before it is replaced by an improved version or even another methodology. This is as a result of continuing further development and research. Sometimes the new methodology is not necessarily an improvement, but a paradigm shift. An example of this is object-orientation which followed shortly after the introduction of CASE as an alternative to software generation. Why are users to a large extent still dissatisfied and disillusioned with the software generation process even though they are more involved with it than before? User are more involved in the software generation process as a result of the availability of sophisticated tools, as well as joint sessions with the developer during the analysis and design stages of the software generation process. Yet, despite this, software systems in most cases still do not perform according to users' expectations. Why did the use of formal methodologies, based on successful techniques of the engineering field, only result in a limited improvement of the quality, control and operationalization of the software system? The cost of maintenance is still very high in relation to the total cost of generating a software system. The same degree of success attained in, say, the engineering field, could not be achieved [AND I]. Why is there a simultaneous movement towards incremental approaches and formal methods although these approaches are really moving in opposite directions? The incremental approach is based on obtaining quick results through prototyping without necessarily following a formal methodology [AND2]. Formal methods, on the other hand, attempt to formalize the software generation process through mathematical transformations. The advantage of using these mathematical transformations is that automation and verification of processes can be achieved [McC1]. Both these approaches show promising results, but the incremental approach might suit the developer better and is already used widely by practitioners. Why is it so difficult to find the correct methodology for generating a software system? The selection of an appropriate methodology is extremely difficult because of the variety of methodologies, technologies and hardware available. Some methodologies are also used for only a limited period because of rapid advances in technology. Why do sophisticated and user-friendly tools not succeed in simplifying the software generation process? Despite sophisticated tools such as CASE, where the user of these tools is guided through the different steps of the methodology, these tools have not succeeded in delivering the results expected by industry. The problems experienced during the software generation process are investigated. In order to distinguish between different approaches to software generation, is it necessary to place different approaches in relation to one another by considering the different elements of each. The characteristics and constraints of the software generation process must also be considered. All the issues pertaining to the software generation process will be discussed in terms of the problem statement.

The concept of software craftsmanship has roots in the earliest days of computing but has received comparably little attention from the research community.As a reaction to how Agile methods were practiced and taught in industry, in 2009, the Manifesto for Software Craftsmanship was formulated and published, drawing attention to the concept. Subsequent books and research papers have also elaborated on the concept. With this dissertation, we aim to study the software craftsmanship phenomenon using empirical software engineering methods.We developed an anatomy of software craftsmanship through a systematic literature study and a longitudinal case study, following a project consisting of multiple teams over several years.We also illustrate some consequences of not following through on the espoused craftsmanship practice of managing and account for technical debt. We find that some areas exhibited high growth in technical debt, while others remained comparably idle. This indicates that it is important to keep track of existing technical debt, but repayment should consider the distribution of each kind of technical debt in the codebase. Our studies are empirical, using mixed methods, analyzing quantitative as well as qualitative data.We used thematic coding to structure the qualitative data into themes, principles, and practices. We provide our systematically derived anatomy of the principles and practices of software craftsmanship and discuss how these relate to other principles within software engineering in general.

This thesis presents a tool for the mechanical validation of formal software specifications. The tool is based on a novel approach to incremental validation. In this approach, small-scale aspects of a specification are validated, as part of the stepwise refinement of a formal model. The incremental validation technique can be considered a form of "lightweight" model checking. This is in contrast to a "heavyweight" approach, wherein an entire large-scale model is validated en masse. The validation tool is part of a formal modeling and specification language (FMSL), used in software engineering instruction. A lightweight, incremental approach to validation is beneficial in this context. Such an approach can be used to elucidate specification concepts in a step-by-step manner. A heavy-weight approach to model checking is more difficult to use in this way. The FMSL model checker has itself been validated by evaluating portions of a medium-scale specification example. The example has been used in software engineering courses for a number of years, but has heretofore been validated only by human inspection. Evidence for the utility of the validation tool is provided by its performance during the example validation. In particular, use of the tool led to the discovery of a specification flaw that had gone undiscovered by manual validation alone.

Embedded computer systems are all around us. We find them in everything, from dishwashers to cars and airplanes. They must always work correctly and moreover, often within certain time constraints. The software of such a system can be very large and complex, e.g. in the case of a car or a train. Hence, we develop the software for embedded systems in smaller, manageable, parts. These parts can be successively integrated, until they form the complete software for the embedded system, possibly at different levels. This phase of the development process is called the system integration phase and is one of the most critical phases in the development of embedded systems. In this phase, substantial effort is spent on testing activities. Studies have found that a considerable amount of test effort is wasteful due to people, unknowingly or by necessity, performing similar (or even overlapping) test activities. Consequently, test cases may end up to be similar, partially or wholly. We identified such test similarities in a case study of 2500 test cases, written in natural language, from four different projects in the embedded vehicular domain. Such information can be used for reducing effort when maintaining or automating similar test cases. In another case study in the same domain, we investigated several approaches for prioritizing test cases to automate with the objective to reduce manual test effort as quick as possible given that similar automated tests could be reused (similarity-based reuse). We analyzed how the automation order affects the test effort for four projects with a total of 3919 integration test cases, written in natural language. The results showed that similarity-based reuse of automated test case script code, and the best-performing automation order can reduce the expected manual test effort with 20 percentage points. Another way of reducing test effort is to reuse test artifacts from one level of integration to another, instead of duplicating them. We studied such reuse methods, that we denote vertical reuse, in a systematic mapping study. While the results from of our systematic mapping study showed the viability of vertical test reuse methods, our industrial case studies showed that keeping track of similarities and test overlaps is both possible and feasible for test effort reduction. We further conclude that the test case automation order affects the manual test execution effort when there exist similar steps that cannot be removed, but are possible to reuse with respect to test script code. / Inbyggda datorsystem finns överallt omkring oss idag; i allt från diskmaskiner till bilar och flygplan. Ofta finns det stränga krav på såväl korrekt funktion som svarstider. Eftersom programvaran i det inbyggda systemet i till exempel en bil är väldigt stor och komplex, utvecklar man programvaran i mindre delar som sedan successivt integreras till det färdiga datorsystemet. Denna del av utvecklingsprocessen kallas systemintegrationsfasen och är en av de största och mest kritiska faserna när man utvecklar inbyggda system. Integrationen kan utföras i ett antal nivåer med utförliga tester av mjukvaran på varje nivå. Detta innebär att det krävs ett avsevärt arbete för att testa mjukvaran. Om man kan minska detta arbete, givetvis utan att ge avkall på testningens kvalitet, förväntas det få en stor effekt på det totala utvecklingsarbetet. Studier har visat att en icke försumbar del av testarbetet är slöseri på grund av att människor, omedvetet eller av nödvändighet, utför likartade (eller till och med överlappande) testaktiviteter. En konsekvens är att testfall riskerar att bli helt eller delvis lika. Vi identifierade sådana likheter i en fallstudie med 2500 manuella testfall, skrivna på vanligt språk, från fyra projekt inom fordonsindustrin. Information om likheter och överlapp kan användas för att, till exempel, minska arbetsåtgången vid underhåll eller när man översätter testfall till kod så att de kan utföras automatiskt av en dator (automatisering). I en annan studie inom samma domän, undersökte vi flera metoder för att prioritera arbetsordningen vid automatisering av testfall där liknande testfall kunde återanvändas. I studien analyserade vi hur denna ordning påverkar arbetsmängden för fyra industriprojekt med totalt 3919 integrationstestfall skrivna på vanligt språk. Resultaten visar att den bästa ordningen kan minska testarbetet avsevärt. En förutsättning för detta är att redan översatta delar av testfall kan återanvändas för att slippa översätta liknande testfall igen. En annan väg för att minska testarbetet är att återanvända testfall och information mellan integrationsnivåer. Vi har kartlagt metoder och motiv kring sådan återanvändning i en systematisk mappningsstudie. Våra fallstudier visar vidare att det både är genomförbart och lönsamt att hålla reda på likheter i testfallen. Slutligen konstaterar vi att arbetsinsatsen för manuell testning påverkas av automationsordningen när det är möjligt att återanvända redan översatta delar av liknande testfall. / IMPRINT

Development of a software system from existing components can surely have various benefits, but can also entail a series of problems. One type of problems is caused by a limited exchange of information between the developer and user of a component, i.e. the developer of a componentbased system. A limited exchange of information cannot only require the testing by the user but it can also complicate this tasks, since vital artifacts, source code in particular, might not be available. Self-testing components can be one response in such situation. This paper describes an enhancement of the Self-Testing COTS Components (STECC) Method so that an appropriately enabled component is not only capable of white-box testing its methods but also capable of black-box testing.

A research report submitted to the Faculty of Engineering and The Built Environment of the University of Witwatersrand, Johannesburg In partial fulfilment of the requirements for the Degree of Master of Science in Engineering September 2015 / In recent years, software has become the cornerstone of banking and new business products are directly dependant on software. The delivery cycles for new features is now related to market share. This drive to use software as a vehicle for competitive advantage has created an environment in which software development of new business systems are increasingly on the critical path of many projects. An organisation’s portfolio of software intensive projects is situated within this complexity and organisations attempt to mitigate the risks associated with these complexities by implementing software development processes and practices. A key problem facing the modern bank is how to define and build a software development process that caters for both the traditional and increasingly agile genres of software development characteristics in a consistent and manageable way. The banks attempt to address this problem through continuous methodology and process improvements. Comparing and assessing non-standardised software engineering lifecycle models without a common framework is a complex and subjective task. A standardised language is important for simplifying the task for developing new methods and practices or for analysing and documenting existing practices. The Software Engineering Methods and Theory (SEMAT) initiative has developed a standardised kernel of essential concepts, together with a language that describes the essence of software engineering. This kernel, called the Essence, has recently become an Object Management Group (OMG) standard. The Essence kernel, together with its language, can be used as the underpinning theory to analyse an existing method and help provide insights that can drive method enhancements. The research report proposes a simple, actionable analysis framework to assist organisations to assess, review and develop their software engineering methods. The core concepts of the methodology are identified and mapped to the Essence concepts. The governance model of the Essence is mapped to the governance model of the industry model and a set of practices is identified and documented in the Essence language. The mapping and resulting analysis can be used to test the validity of the Essence theory in practice and identify areas for improvement in both the method and the Essence standard. The analysis framework has been applied to an operational software development lifecycle of a large South African bank. A mapping of the Essence concepts to the governance model and method documented in the lifecycle was completed. This mapping revealed that the Essence is a valid tool and can be used to describe a method in practice. Furthermore it is useful as an analysis framework to assess the governance model that manages and measures the progress of an endeavour in the Bank. The case study and resulting analysis demonstrate that the Essence standard can be used to analyse a methodology and identify areas for improvement. The analysis also identified areas for improvement in the Essence specification.

Denna rapport beskriver arbetet med implementeringen av Drone Interactive Map som gjordes på uppdrag av RISE, Research Institutes of Sweden AB. Projektets mål är att göra det lättare att få en överblick över ett händelseförlopp med hjälp av drönare försedda med kameror som dokumenterar händelseförloppet. Projektet kan användas av till exempel räddningstjänstpersonal för att få en överblick över en skogsbrand eller industribrand.Projektet behandlar huvudsakligen automatisk styrning och dynamisk omfördelning av en svärm drönare som styrs genom en webbapplikation. Resultatet blev en produkt som har ett användarvänligt gränssnitt som i genomsnitt fick 78,3 poäng vid användbarhetstester enligt SUS-metoden.Produkten kan dela in ett område i mindre delområden och genererar sedan rutter för enskilda drönare i en drönarsvärm. Projektarbetet utfördes av en grupp på tio personer i kursen TDDD96 Kandidatprojekt i programvaruutveckling vid Linköpings universitet.