When restoring a test environment, the key to success is that the process is fast and automatic. The goal is to have as little user interaction as possible. This master thesis evaluates solutions for handling the restoration of the test environments and investigates a couple of possible approaches. It turns out that the most effective way of solving the problem is to elaborate a customized software. The interface and workflow of this software is described in the thesis. Testing of the new software is performed and the thesis ends with some conclusions regarding the new solution and proposals for future development.

Context. Software systems, becoming larger and more complex day-by-day, have resulted in software development processes to become more complex to understand and manage. Many companies have started to adapt distributed software engineering practices that would allow them to work in distributed teams at different organizations and/or geographical locations. For example, model-driven engineering methods are being used in such global software engineering projects. Among the activities in model-based software development, consistency checking is one of the widely known ones. Consistency checking is concerned with consistent models; in particular, having a consistent group of multiple models for a whole system, e.g., multiple models produced by distributed teams. Objectives. This thesis aims to find out how ‘Global Consistency Checking (GCC)’ can be utilized for exploring inconsistency problems between distributed models; particularly among UML class diagram relationships (in terms of consistency), as well as how GCC can be scaled with large number of models and relationships. Thereby, these inconsistencies are also aimed to incrementally resolve in our approach. Methods. We made a review in distributed software development domain and model management, in particular, methods of consistency checking between ‘Distributed Models (DM)’. Next, we conducted two case studies in two problem domains in order to apply our ‘consistency checking methodology’. We concurrently constructed and implemented new consistency rules, most of which are gathered from literatures and brainstorming with our coordinators. Generally, the method contains implementing different models of the case studies with a tool support and trying to figure out overlaps, merging models and checking the merged model against the consistency rules, and evaluating the results of GCC. We mainly addressed issues focused on consistency checking of individual models and the mapping between them e.g., pair-wise consistency checking (PCC), which are incapable of fully addressing problems against any consistency rules encountered in distributed environments. Results. We have identified seven types of inconsistency, which are divided in two groups named ‘Global inconsistency’ and ‘Pair-wise inconsistency’. In the first case study, we have 94 global inconsistencies and 73 pair-wise. In the second one, 14 global and 25 pair-wise inconsistencies are resulted. During ‘Resolution approach’, we followed six steps as a ‘systematic procedure’ for resolving these inconsistencies and constructed new merged model in each iteration. The initial merged model (inconsistent model) as an input for the first step has 1267 elements, and the consistent merged model (the output) from the sixth step has 686 elements. ‘time duration’ and ‘required effort’ for checking consistency against each ‘consistency rule’ were recorded, analyzed and illustrated in Sections 4.1.5 and 4.2.4. Conclusions. We concluded that GCC enables us to explore the inconsistencies, inclusive of resolving them and therefore, refining the relationships between different models, which are difficult to detect by e.g., a pair-wise method. The most important issues are: The number of model comparisons conducted by PCC, The inability of PCC for identifying some inconsistencies, Model relationships refinement and classification based on PCC approach will not lead to a final consistent DM, whereas, GCC guarantees it. Consistency rules application, inconsistency identification and resolving them could be generalized to any UML class diagram model representing a problem domain within the fields of consistency checking in software engineering. / 0046760850792, 0046737749752

Global software development is more challenging than the collocated software development. It requires extra effort to provide necessary information for coordinating the tasks activities which is natural in a collocated environment. Regardless of the task domain, team awareness (task awareness and presence awareness) is essential for coordinating the task activities both in collocated and distributed teams. As distance between the teams grows it requires disseminating the awareness information among team members to support coordination. In this study, we investigate how does the team awareness interact with other team cognition mechanisms like familiarity (i.e. task familiarity and team familiarity) and shared mental models (i.e. shared mental models of the task and shared mental models of the team). We also see how familiarity and shared mental models interact with each other. Then, we conjure its implications on coordination and team performance. Further, we investigate the level of team awareness on four segments of distance which are defined based on the distance between the pairs of teams (i.e. from collocated teams to the teams that are distributed across different time-zones). We used snowballing technique (i.e. forward snowballing and backward snowballing) for the literature review and conducted survey and semi-structures interviews for data collection. We found that team awareness has a positive effect on team cognition mechanisms (familiarity and shared mental models) and consequently has positive implications on coordination. Therefore, we postulate that team performance improves by providing the necessary awareness information to the software development teams. We found that, in addition to distance, there are other factors like task size, team size, team type and communication that also affect the team awareness in collocated and distributed collaborative software development teams. Finally, we presented a list of factors that can be incorporated in collaborative learning and development tools. / +46 455 38 50 00

This thesis describes Scrum and with a feasibility study tests if Scrum can be applied in a project with two developers at T-systems Sweden. Key issues regarding the development process are pointed out from a baseline project. The influence of the issues in the project is later tested in the new project at the same organization. New issues were identified and studied and corrected. Interviews and literature study are used to gather information of what issues do occur and may occur. The results and analysis lead to a conclusion on what changes that should be done and what strength and weaknesses Scrum has when implemented at T-systems Sweden.

The term “Globalization” brought many challenges with itself in the field of software development. The challenge of accurate effort estimation in GSD is one among them. When talking about effort estimation, the discussion starts for effort estimation methods. There are a number of effort estimation methods available. Existing effort estimation methods used for co-located projects are might not enough capable to estimate effort for distributed projects. This is why; ratio of failure of GSD projects is high. It is important to calibrate existing methods or invent new with respect to GSD environment. This thesis is an attempt to explore the accuracy of effort estimation methods for distributed projects. For this purpose, the authors selected three estimation approaches: COCOMO II, SLIM and ISBSG. COCOMO II and SLIM are two well known effort estimation methods, whereas, ISBSG is used to check the trend of a project depending upon its (ISBSG’s) repository. The selection of the methods and approaches was based on their popularity and advantages over other methods/approaches. Two finished projects from two different organizations were selected and analyzed as case studies. The results indicated that effort estimation with COCOMO II deviated 15.97 % for project A and 9.71% for project B. Whereas, SLIM showed the deviation of 4.17% for project A and 10.86 % for project B. Thus, the authors concluded that both methods underestimated the effort in the studied cases. Furthermore, factors that might cause deviation are discussed and several solutions are recommended. Particularly, the authors state that existing effort estimation methods can be used for GSD projects but they need calibration by considering GSD factors to achieve accurate results. This calibration will help in process improvement of effort estimation.

Today’s software companies face the challenges of highly distributed development projects and constant changing requirements. To be competitive, the software time to market has to be reduced as much as possible while keeping the expected quality. Development methodologies try to address this challenges by introducing new practices, techniques and methods for communication, requirements management, quality assurance, etc. This thesis proposes the adoption of relevant Free/Libre/Open Source Software practices to improve industrial developments. Many FLOSS projects have proven very successful, producing high quality products with steady frequent releases. The selection of the FLOSS best practices that would benefit industrial developments, and its adaptation for a corporate environment is the aim of this study. To achieve this goal, a framework to compare FLOSS and industrial development methodologies has been created and executed. Three successful FLOSS projects where selected as study targets, as well as two Ericsson’s projects. The framework served to identify FLOSS methodology strengths and compare them with the Ericsson projects. Analysing the significant differences resulting from this comparison, FLOSS best practices were tailored to fit industrial development environments. The final results of the thesis are six adoption opportunities that aim to improve software quality and overall development productivity while increasing practitioners’ motivation and commitment.

Context: Removal of wastes is a crucial area in lean software development. It has been found that there was little evidence on root causes of wastes in lean software development. Root causes from the state of practice had not being investigated. Furthermore, relations between wastes were now successfully exposed through root cause identifications process. Objectives: The objective of this study was to perform an in-depth investigation to identify causes which lead to wastes in Lean software development process in the context of medium to large software development. To this end, researcher also identified relationships that exist between wastes. Methods: The researcher conducted Literature review to look for evidence on waste related activities offered in peer-reviewed literature. Furthermore, the author conducted seven semi-structured interviews and used Grounded Theory method for both literature and interview data analysis. Results: The researcher identified three categories of factors of wastes. Namely, Technical, Non-technical and Global software product development. In the technical category, factors relating to different technical aspects to build a product such as required resource issues, solving complexity issues among others were identified. Similarly, factors relating to people knowledge, management issues as well as factors that bothered on communication, coordination and temporal distance were identified as non-technical and global software product development respectively. For all seven kinds of wastes the root causes were identified. / 0046734784551

Context. The quality of business process models is important in the area of model-based software development. The overall goal of this study was to develop and evaluate a model for assessing the quality of models (Process Diagrams) in Business Process Model and Notation (BPMN). The model was an instantiation of the developed metamodel that adopt ISO/IEC 1926. Objectives. The objectives of the thesis were to propose, implement and evaluate a model for quality assessment of business process models in BPMN. The model was intended to help practitioners to check the quality of their BPMN models and provide meaningful feedback on whether the business process models are of good or bad quality. First objective was to develop a metamodel of models for quality assessment of business process models in BPMN, and later the model that in an instantiation of the metamodel. Within the model, the objectives were to propose the relevant quality characteristics, quality metrics, quality criteria and quality functions. Finally, usefulness of model for quality assessment of business process models in BPMN was to be evaluated. Methods. The methodology was driven by essential elements of the model for quality assessment of business process models in BPMN. This is: quality characteristics, quality metrics, quality criteria and quality functions. In the beginning the metamodel of the model was developed based on the ISO/IEC 1926 standard. Later, in order to identify quality characteristics of models existing in the literature, a systematic literature review was conducted. Quality characteristics explicitly relevant to BPMN were compared against each other and selected. Overlapping quality characteristics relevant to BPMN were merged. Next, in order to obtain quality metrics that measure aspects of models of business processes, a literature review was carried out. The literature review was restricted by a proposed set of selection criteria. The criteria were questions that every relevant literature describing quality metrics must affirmatively answer in order to identify only metrics that were able to be assigned to identify quality characteristics. If the chosen quality metrics needed to be changed or adjusted for the sake of better results, the author added changes or adjustments and provided rationale for them. Next, in order to obtain quality criteria, values of the quality metrics were gathered through measuring a repository of BPMN models. The repository was gathered as a preparatory work for the thesis and it consisted of models of varying quality. Manual measurement of quality metrics for each BPMN model from the repository could not be done within a reasonable amount of time. Therefore, a tool to automatically calculate metrics for BPMN models was implemented. The quality criteria were proposed based on the results from interpretation of the values using statistical analysis. Later, quality functions that aggregate values of the metrics were proposed. The complete model was next integrated into the tool so that it could assess a quality of real BPMN models. Finally, the model for assessing the quality of business process models in BPMN was evaluated for usefulness through a survey and survey-based experiment. Results. A metamodel of models for quality assessment of business process models in BPMN was proposed. A model for the quality assessment of models in BPMN was proposed and evaluated for usefulness. Initial sets of quality characteristics of models were found in the literature and quality characteristics that were relevant to BPMN were extracted. Quality metrics that measure aspects of models were found and adjusted to the BPMN notation. Quality criteria that state how values of quality metrics can be classified as good or bad were provided. Quality functions that state if quality characteristics are good or bad for a chosen BPMN model were provided. Finally, a tool that implements the model for quality assessment of models in BPMN was created. Conclusions. The results of the survey and survey-based experiment showed that the proposed model for quality assessment of models in BPMN works in most cases and is needed in general. Additionally, the elements of the model which should be corrected were identified. Contacted users of BPMN expressed a will to use the suggested tool associated with the model for quality assessment of business process models in BPMN.

In the software industry a number of different software processes has been used throughout the years to address known problems with software development, despite their intention complains has been raised that some of these are too bureaucratic. The Agile Alliance was formed in 2001 and aimed to solve this problem, they developed a manifesto and twelve principles which are supported by all Agile software processes. The purpose with the manifesto and its principles is to uncover better ways of developing software and these are by many intercessors of Agile seen as common sense and not completely new ideas. The aim with this master thesis is to answer the question if companies that explicitly claim that they do not use any Agile software process are already applying some of these ideas since they are thought of as obvious and common sense. The comparison in this thesis is performed between the project lifecycles used in specific projects by five non-Agile software companies and four identified lifecycle characteristics and two more general characteristics of the Agile software processes Extreme Programming (XP) and Dynamic Systems Development Method (DSDM). The result from the analysis of these interviews has shown that it is very difficult to decide if a software company really is working as described by XP or DSDM, this is due to that many different factors affect the final outcome. For example type of project and is the software company using different software processes for different kinds of projects. Since we just covered specific projects we were only able to conclude with absolute certainty actions that really were performed in just these projects. The project lifecycles of these software companies had some similarities with the above mentioned Agile software processes, but as a whole the analysis showed that they are quite different due to that two very important characteristics according to us, namely iterative development and frequent releases, were not applied by any of the software companies and that their project phases differed tremendously compared to XP and DSDM. Our common sense hypothesis for Agile software development was shown in this investigation to be incorrect since important activities were not performed by any of the software companies. Instead of using an iterative approach with frequent releases they all followed sequential waterfall like software processes.

Context: In the last decade, Agile software development methods were proposed as a response to plan-driven methods. The main aim for this paradigm shift was to cope up with constant changes. Core values that are central to agile methods are described in Agile Manifesto. Agile practices define how agile methods are implemented in practice. Objectives: This study aims to investigate what practices were considered and adopted as part of agile philosophy, and identify evidence on the use of agile practices in reference to what defines agile. Methods: We conducted a systematic literature review. The review includes 186 primary studies published between 2000 and 2010. Quality assessment based on rigor and relevance as identified in the selected papers has been conducted. Non-empirical papers were classified based on themes they addressed. Empirical papers were analyzed based on two factors: 1. if they described the use of agile practices for a software project/product in general, 2. if they described the use of agile practices for a specific purpose/activity Application type, team size and experience of subjects in the primary studies were extracted. The alignment between practices reported in the studies with the core agile values is analyzed. Results: A total of 119 studies were conducted in industry and 67 in academia. Nearly half the papers published by researchers are non-empirical and present analysis of agile practices in various topics. Over half of the empirical papers were focused on evaluation/assessment of a specific aspect of agile. ‘Pair programming’ received most attention in this direction. Among the empirical studies that described agile practices for academic projects, ‘Pair programming’ and ‘Test driven development’ were the most considered practices. Among the 119 studies conducted in industry, 93 studies described the use of agile practices for the overall project/product development while the remaining studies described experiences of single practices like Pair Programming or the modification/adoption of agile for non-software aspects in software projects. Practices adopted have been ranked based on team size, practitioners’ experience and application type. A method for agile assessment based on core agile values is developed and exemplified. Conclusions: Practices that are considered agile vary with context although ‘Pair programming’, ‘Continuous integration’, ‘Refactoring and Testing continuous throughout the project are the most common practices used. ‘Test driven development’ was not highly adopted by practitioners. But it was not clear if test cases were written before code construction in projects where continuous testing was performed. However, this was completely opposite in academic projects. Practices ‘On-site frequently modified. In many of the studies inspected, practices adopted were not aligned with agile values. Although practices related to technical aspects of software development are in place, agile practices that focus aspects like ‘working together’ and ‘motivated individuals’ are often not used in practice. Moreover, many of the studies were not reported to an extent that it was possible to draw any inferences on the usability/applicability, benefits and limitations of the agile practices. To this end, a major implication is to improve the quality of the studies and a need for a common framework to report the results of agile practices’ adoption.