Change search
Refine search result
12 51 - 98 of 98
CiteExportLink to result list
Permanent link
Cite
Citation style
  • apa
  • harvard1
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf
Rows per page
  • 5
  • 10
  • 20
  • 50
  • 100
  • 250
Sort
  • Standard (Relevance)
  • Author A-Ö
  • Author Ö-A
  • Title A-Ö
  • Title Ö-A
  • Publication type A-Ö
  • Publication type Ö-A
  • Issued (Oldest first)
  • Issued (Newest first)
  • Created (Oldest first)
  • Created (Newest first)
  • Last updated (Oldest first)
  • Last updated (Newest first)
  • Disputation date (earliest first)
  • Disputation date (latest first)
  • Standard (Relevance)
  • Author A-Ö
  • Author Ö-A
  • Title A-Ö
  • Title Ö-A
  • Publication type A-Ö
  • Publication type Ö-A
  • Issued (Oldest first)
  • Issued (Newest first)
  • Created (Oldest first)
  • Created (Newest first)
  • Last updated (Oldest first)
  • Last updated (Newest first)
  • Disputation date (earliest first)
  • Disputation date (latest first)
Select
The maximal number of hits you can export is 250. When you want to export more records please use the Create feeds function.
  • 51. Mujtaba, Shahid
    et al.
    Feldt, Robert
    Petersen, Kai
    Analyzing strategy and processes for product customization in large-scale industrial settings2011Conference paper (Refereed)
    Abstract [en]

    In practice companies face situations where many customization requests could not be foreseen. Thus, companies need to be able to rapidly develop customizations even after release. The objective of this study is to understand how industry handles the customization challenge with a focus on the strategy and processes used. Two cases have been studied (one telecom company located in Germany and one located in Sweden). For data collection purposes interviews(a total of 25) and process documentations were used. The result showed that the two companies have different product development strategies (compositional vs integration) and also follow different development processes for customizations, these being further elaborated in this paper.

  • 52. Mujtaba, Shahid
    et al.
    Feldt, Robert
    Petersen, Kai
    Waste and Lead Time Reduction in a Software Product Customization Process with Value Stream Maps2010Conference paper (Refereed)
    Abstract [en]

    Custom-developed adaptations of software products are increasingly important to meet different and changing customer needs and heterogeneous system environments. Efficient software customization processes with short lead times are thus a priority for companies to stay competitive. The purpose of this case study is to identify waste-related problems in a software product customization process by using value stream maps (VSM). The study was conducted at the telecom company Ericsson AB; the empirical data was collected using document analysis, extraction of phase times from a requirements tracking tool and interviews. It was used to construct a value stream map that showed the present state of the process. The map was then used in interviews with key stakeholders where they identified waste and proposed measures to avoid them. These solution proposals were subsequently used to construct a future value stream map showing a reduced lead time. Static validation showed that the VSM methodology was useful and that the identified solutions were of value. Our results have applicability for software engineering process improvement in general and for customization processes in particular.

  • 53. Munir, Hussan
    et al.
    Moayyed, Misagh
    Petersen, Kai
    Blekinge Institute of Technology, School of Computing.
    Considering rigor and relevance when evaluating test driven development: A systematic review2014In: Information and Software Technology, ISSN 0950-5849, E-ISSN 1873-6025, Vol. 56, no 4, p. 375-394Article in journal (Refereed)
    Abstract [en]

    Context Test driven development (TDD) has been extensively researched and compared to traditional approaches (test last development, TLD). Existing literature reviews show varying results for TDD. Objective This study investigates how the conclusions of existing literature reviews change when taking two study quality dimension into account, namely rigor and relevance. Method In this study a systematic literature review has been conducted and the results of the identified primary studies have been analyzed with respect to rigor and relevance scores using the assessment rubric proposed by Ivarsson and Gorschek 2011. Rigor and relevance are rated on a scale, which is explained in this paper. Four categories of studies were defined based on high/low rigor and relevance. Results We found that studies in the four categories come to different conclusions. In particular, studies with a high rigor and relevance scores show clear results for improvement in external quality, which seem to come with a loss of productivity. At the same time high rigor and relevance studies only investigate a small set of variables. Other categories contain many studies showing no difference, hence biasing the results negatively for the overall set of primary studies. Given the classification differences to previous literature reviews could be highlighted. Conclusion Strong indications are obtained that external quality is positively influenced, which has to be further substantiated by industry experiments and longitudinal case studies. Future studies in the high rigor and relevance category would contribute largely by focusing on a wider set of outcome variables (e.g. internal code quality). We also conclude that considering rigor and relevance in TDD evaluation is important given the differences in results between categories and in comparison to previous reviews.

  • 54. Munir, Hussan
    et al.
    Wnuk, Krzysztof
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Moayyed, Misagh
    An experimental evaluation of test driven development vs. test-last development with industry professionals2014Conference paper (Refereed)
    Abstract [en]

    Test-Driven Development (TDD) is a software development approach where test cases are written before actual development of the code in iterative cycles. Context: TDD has gained attention of many software practitioners during the last decade since it has contributed several benefits to the software development process. However, empirical evidence of its dominance in terms of internal code quality, external code quality and productivity is fairly limited. Objective: The aim behind conducting this controlled experiment with professional Java developers is to see the impact of Test-Driven Development (TDD) on internal code quality, external code quality and productivity compared to Test-Last Development (TLD). Results: Experiment results indicate that values found related to number of acceptance test cases passed, McCabe's Cyclomatic complexity, branch coverage, number of lines of code per person hours, number of user stories implemented per person hours are statistically insignificant. However, static code analysis results were found statistically significant in the favor of TDD. Moreover, the results of the survey revealed that the majority of developers in the experiment prefer TLD over TDD, given the lesser required level of learning curve as well as the minimum effort needed to understand and employ TLD compared to TDD.

  • 55. Mäntylä, Mika
    et al.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Lehtinen, Timo O. A.
    Lassenius, Casper
    Time pressure: a controlled experiment of test case development and requirements review2014In: 36TH INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING (ICSE 2014), Hyderabad: ACM , 2014Conference paper (Refereed)
    Abstract [en]

    Time pressure is prevalent in the software industry in which shorter and shorter deadlines and high customer demands lead to increasingly tight deadlines. However, the effects of time pressure have received little attention in software engineering research. We performed a controlled experiment on time pressure with 97 observations from 54 subjects. Using a two-by-two crossover design, our subjects performed requirements review and test case development tasks. We found statistically significant evidence that time pressure increases efficiency in test case development (high effect size Cohen’s d=1.279) and in requirements review (medium effect size Cohen’s d=0.650). However, we found no statistically significant evidence that time pressure would decrease effectiveness or cause adverse effects on motivation, frustration or perceived performance. We also investigated the role of knowledge but found no evidence of the mediating role of knowledge in time pressure as suggested by prior work, possibly due to our subjects. We conclude that applying moderate time pressure for limited periods could be used to increase efficiency in software engineering tasks that are well structured and straight forward.

  • 56. Mäntylä, Mika
    et al.
    Petersen, Kai
    Blekinge Institute of Technology, School of Computing.
    Pfahl, Dietmar
    How many individuals to use in a QA task with fixed total effort?2012Conference paper (Refereed)
    Abstract [en]

    Increasing the number of persons working on quality assurance (QA) tasks, e.g., reviews and testing, increases the number of defects detected - but it also increases the total effort unless effort is controlled with fixed effort budgets. Our research investigates how QA tasks should be configured regarding two parameters, i.e., time and number of people. We define an optimization problem to answer this question. As a core element of the optimization problem we discuss and describe how defect detection probability should be modeled as a function of time. We apply the formulas used in the definition of the optimization problem to empirical defect data of an experiment previously conducted with university students. The results show that the optimal choice of the number of persons depends on the actual defect detection probabilities of the individual defects over time, but also on the size of the effort budget. Future work will focus on generalizing the optimization problem to a larger set of parameters, including not only task time and number of persons but also experience and knowledge of the personnel involved, and methods and tools applied when performing a QA task.

  • 57. Mäntylä, M.V.
    et al.
    Adams, B.
    Khomh, F.
    Engström, E.
    Petersen, Kai
    Blekinge Institute of Technology, School of Computing.
    On rapid releases and software testing: a case study and a semi-systematic literature review2015In: Empirical Software Engineering, ISSN 1382-3256, Vol. 20, no 5, p. 1384-1425Article in journal (Refereed)
    Abstract [en]

    Large open and closed source organizations like Google, Facebook and Mozilla are migrating their products towards rapid releases. While this allows faster time-to-market and user feedback, it also implies less time for testing and bug fixing. Since initial research results indeed show that rapid releases fix proportionally less reported bugs than traditional releases, this paper investigates the changes in software testing effort after moving to rapid releases in the context of a case study on Mozilla Firefox, and performs a semi-systematic literature review. The case study analyzes the results of 312,502 execution runs of the 1,547 mostly manual system-level test cases of Mozilla Firefox from 2006 to 2012 (5 major traditional and 9 major rapid releases), and triangulates our findings with a Mozilla QA engineer. We find that rapid releases have a narrower test scope that enables a deeper investigation of the features and regressions with the highest risk. Furthermore, rapid releases make testing more continuous and have proportionally smaller spikes before the main release. However, rapid releases make it more difficult to build a large testing community , and they decrease test suite diversity and make testing more deadline oriented. In addition, our semi-systematic literature review presents the benefits, problems and enablers of rapid releases from 24 papers found using systematic search queries and a similar amount of papers found through other means. The literature review shows that rapid releases are a prevalent industrial practice that are utilized even in some highly critical domains of software engineering, and that rapid releases originated from several software development methodologies such as agile, open source, lean and internet-speed software development. However, empirical studies proving evidence of the claimed advantages and disadvantages of rapid releases are scarce.

  • 58.
    Nurdiani, Indira
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Börstler, Jürgen
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Fricker, Samuel
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    A Preliminary Checklist for Capturing Baseline Situations in Studying the Impacts of Agile Practices Introduction2018In: IEEE-ACM International Workshop on Conducting Empirical Studies in Industry CESI, IEEE Computer Society, 2018, p. 25-28Conference paper (Refereed)
    Abstract [en]

    To assess the benefits of introducing Agile practices, it is important to get a clear understanding of the baseline situation, i.e. the situation before their introduction. Without a clear baseline, we cannot properly assess the extent of impacts, both positive and negative, of introducing Agile practices. This paper provides a preliminary guideline to help researchers in capturing and reporting baseline situations. The guideline has been developed through the study of literature and interviews with industry practitioners, and validated by experts in academia.

  • 59.
    Nurdiani, Indira
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Börstler, Jürgen
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Fricker, Samuel
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Usage, Retention, and Abandonment of Agile Practices2019In: e-Informatica Software Engineering Journal, ISSN 1897-7979, E-ISSN 2084-4840, Vol. 13, no 1, p. 7-35Article in journal (Refereed)
    Abstract [en]

    Background: A number of Agile maturity models (AMMs) have been proposed to guide software organizations in their adoption of Agile practices. Typically the AMMs suggest that higher maturity levels are reached by gradually adding more practices. However, recent research indicates that certain Agile practices, like test-driven development and continuous integration are being abandoned. Little is known on the rationales for abandoning Agile practices. Aim: We aim to identify which Agile practices are abandoned in industry, as well as the reasons for abandoning them. Method: We conducted a web survey with 51 respondents and interviews with 11 industry practitioners with experience in Agile adoption to investigate why Agile practices are abandoned. Results: Of the 17 Agile practices that were included in the survey, all have been abandoned at some point. Nevertheless, respondents who retained all practices as well as those who abandoned one or more practices, perceived their overall adoption of Agile practices as successful. Conclusion: Going against the suggestions of the AMMs, i.e. abandoning Agile one or more practices, could still lead to successful outcomes. This indicates that introducing Agile practices gradually in a certain sequence, as the AMMs suggest, may not always be suitable in different contexts.

  • 60.
    Nurdiani, Indira
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Börstler, Jürgen
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Fricker, Samuel
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Chatzipetrou, Panagiota
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Understanding the order of agile practice introduction: Comparing agile maturity models and practitioners’ experience2019In: Journal of Systems and Software, ISSN 0164-1212, E-ISSN 1873-1228, Vol. 156, p. 1-20Article in journal (Refereed)
    Abstract [en]

    Context: Agile maturity models (AMMs) suggest that agile practices are introduced in a certain order. However, whether the order of agile practice introduction as suggested in the AMMs is relevant in industry has not been evaluated in an empirical study. Objectives: In this study, we want to investigate: (1) order of agile practice introduction mentioned in AMMs, (2) order of introducing agile practices in industry, and (3) similarities and differences between (1) and (2). Methods: We conducted a literature survey to identify strategies proposed by the AMMs. We then compared the AMMs’ suggestions to the strategies used by practitioners, which we elicited from a survey and a series of interviews from an earlier study. Results: The literature survey revealed 12 AMMs which provide explicit mappings of agile practices to maturity levels. These mappings showed little agreement on when practices should be introduced. Comparison of the AMMs’ suggestions and the empirical study revealed that the guidance suggested by AMMs are not aligned with industry practice. Conclusion: Currently, AMMs do not provide sufficient information to guide agile adoption in industry. Our results suggest that there might be no universal strategy for agile adoption that works better than others. © 2019 Elsevier Inc.

  • 61. Oliinyk, O.
    et al.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Schoelzke, M.
    Becker, M.
    Schneickert, S.
    Metrics for the evaluation of feature models in an industrial context: A case study at opel2015Conference paper (Refereed)
    Abstract [en]

    [Context & motivation] Feature models are used in product line engineering to document possible product configurations on the feature level. [Problem] In order to quantify the success of adopting feature modeling in practice, we need to understand the industry relevant metrics for feature model evaluation. [Solution] In order to identify the metrics a Goal-Question-Metric approach was used in the context of a case study conducted at Adam Opel AG. [Contribution:] We identified seven goals (quality criteria) we should strive for and evaluate when using feature models. Furthermore, we identified 18 sub-goals, 27 questions and corresponding metrics. The metrics were used to reflect on the feature modeling conducted at the company. © Springer International Publishing Switzerland 2015.

  • 62.
    Oliinyk, Olesia
    et al.
    Capgemini, DEU.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Schoelzke, Manfred
    Adam Opel AG, DEU.
    Becker, Martin
    Fraunhofer Inst Expt Software Engn, DEU.
    Schneickert, Soeren
    Fraunhofer Inst Expt Software Engn, DEU.
    Structuring automotive product lines and feature models: an exploratory study at Opel2017In: Requirements Engineering, ISSN 0947-3602, E-ISSN 1432-010X, Vol. 22, p. 105-135Article in journal (Refereed)
    Abstract [en]

    Automotive systems are highly complex and customized systems containing a vast amount of variability. Feature modeling plays a key role in customization. Empirical evidence through industry application, and in particular methodological guidance of how to structure automotive product lines and their feature models is needed. The overall aim of this work is to provide guidance to practitioners how to structure automotive product lines and their feature models, understanding strengths and weaknesses of alternative structures. The research was conducted in three phases. In the first phase, the context situation was understood using interviews and workshops. In the second phase, possible structures of product lines and feature models were evaluated based on industry feedback collected in workshops. In the third phase, the structures were implemented in the tool GEARS and practitioner feedback was collected. One key challenge was the unavailability of structuring guidelines, which was the focus of this research. The structures considered most suitable for the automotive product line were multiple product lines with modular decomposition. The structures most suitable for the feature model were functional decomposition, using context variability, models corresponding to assets, and feature categories. Other structures have been discarded, and the rationales have been presented. It was possible to support the most suitable structures with the commercial tool GEARS. The implementation in GEARS and the feedback from the practitioners provide early indications for the potential usefulness of the structures and the tool implementation.

  • 63.
    Papatheocharous, Efi
    et al.
    RISE SICS, SWE.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Cicchetti, Antonio
    Mälardalens University, SWE.
    Sentilles, Séverine
    Mälardalens University, SWE.
    Muhammad Ali Shah, Syed
    RISE SICS, SWE.
    Gorschek, Tony
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Decision support for choosing architectural assets in the development of software-intensive systems: The GRADE taxonomy2015In: ECSAW '15 Proceedings of the 2015 European Conference on Software Architecture Workshops / [ed] Matthias Galster, ACM Digital Library, 2015, article id 48Conference paper (Refereed)
    Abstract [en]

    Engineering software-intensive systems is a complex process that typically involves making many critical decisions. A continuous challenge during system design, analysis and development is deciding on the reference architecture that could reduce risks and deliver the expected functionality and quality of a product or a service to its users. The lack of evidence in documenting strategies supporting decision-making in the selection of architectural assets in systems and software engineering creates an impediment in learning, improving and also reducing the risks involved. In order to fill this gap, ten experienced researchers in the field of decision support for the selection of architectural assets in engineering software-intensive systems conducted a workshop to reduce traceability of strategies and define a dedicated taxonomy. The result was the GRADE taxonomy, whose key elements can be used to support decision-making as exemplified through a real case instantiation for validation purposes. The overall aim is to support future work of researchers and practitioners in decision-making in the context of architectural assets in the development of software-intensive systems. The taxonomy may be used in three ways: (i) identify new opportunities in structuring decisions; (ii) support the review of alternatives and enable informed decisions; and (iii) evaluate decisions by describing in a retrospective fashion decisions, factors impacting the decision and the outcome.

  • 64.
    Papatheocharous, Efi
    et al.
    Swedish Institute of Computer Science, SWE.
    Wnuk, Krzysztof
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Sentilles, Severine
    Mälardalens högskola, SWE.
    Cicchetti, Antonio
    Mälardalens högskola, SWE.
    Gorschek, Tony
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Shah, Syed Muhammad Ali
    Swedish Institute of Computer Science, SWE.
    The GRADE taxonomy for supporting decision making asset selection in software-intensive system development2018In: Information and Software Technology, ISSN 0950-5849, E-ISSN 1873-6025, Vol. 100, p. 1-17Article in journal (Refereed)
    Abstract [en]

    Context: The development of software-intensive systems includes many decisions involving various stakeholders with often conflicting interests and viewpoints. Objective: Decisions are rarely systematically documented and sporadically explored. This limits the opportunity for learning and improving on important decisions made in the development of software-intensive systems. Method: In this work, we enable support for the systematic documentation of decisions, improve their traceability and contribute to potentially improved decision-making in strategic, tactical and operational contexts. Results: We constructed a taxonomy for documentation supporting decision-making, called GRADE. GRADE was developed in a research project that required composition of a common dedicated language to make feasible the identification of new opportunities for better decision support and evaluation of multiple decision alternatives. The use of the taxonomy has been validated through thirty three decision cases from industry. Conclusion: This paper occupies this important yet greatly unexplored research gap by developing the GRADE taxonomy that serves as a common vocabulary to describe and classify decision-making with respect to architectural assets. © 2018 Elsevier B.V.

  • 65. Penzenstadler, Birgit
    et al.
    Khurum, Mahvish
    Blekinge Institute of Technology, School of Computing.
    Petersen, Kai
    Blekinge Institute of Technology, School of Computing.
    Towards Incorporating Sustainability while Taking Software Product Management Decisions2013Conference paper (Refereed)
    Abstract [en]

    Software product managers are missing guidelines on how to incorporate di erent dimensions of sustainability in software product management and requirements selection decision-making. This is a challenge because considering sustainability perspective while selecting requirements has become a major objective for software product development companies; however, it is unclear how to support it during complex product management decision-making. In this paper, we identify the value aspects related to sustainability for software requirements selection. An exemplary dialogue between a consultant and a product manager illustrates how the proposed approach can be used while taking product management and requirements selection decisions. Our contribution provides software product managers with guidance on how toincorporate value aspects related to sustainability while taking software product management and requirements selection decisions.

  • 66.
    Petersen, Kai
    Blekinge Institute of Technology, School of Computing.
    A palette of lean indicators to detect waste in software maintenance: A case study2012In: Lecture Notes in Business Information Processing, Malmö: Springer , 2012, Vol. 111, p. 108-122Conference paper (Refereed)
    Abstract [en]

    Software maintenance is a key activity in software development requiring considerable effort and time. Hence, it is important to increase the efficiency and effectiveness of the maintenance process. The objective of this article is to introduce a palette of indicators to assess the maintenance process based on indicators lean indicators. Four indicators aiming at detecting waste have been proposed, namely the inflow of maintenance requests, the flow of maintenance requests through the maintenance process with regard to continuous value creation and high throughput, the analysis of lead-times, and the analysis of workload. The research method is case study in which the proposed indicators were applied on the maintenance process of one case company (Ericsson AB).

  • 67. Petersen, Kai
    An Empirical Study of Lead-Times in Incremental and Agile Software Development2010Conference paper (Refereed)
    Abstract [en]

    Short lead-times are essential in order to have a first-move advantages and to be able to react on changes on a fast-paced market. Agile software development is a development paradigm that aims at being able to respond quickly to changes in customer needs. So far, to the best of our knowledge no empirical study has investigated lead-times with regard to different aspects (distribution between phases, difference of lead-time with regard to architecture dependencies, and size). However, in order to improve lead-times it is important to understand the behavior of lead-times. In this study the lead-times of a large-scale company employing incremental and agile practices are analyzed. The analysis focuses on 12 systems at Ericsson AB, Sweden.

  • 68. Petersen, Kai
    Implementing Lean and Agile Software Development in Industry2010Doctoral thesis, comprehensive summary (Other academic)
    Abstract [en]

    Background: The software market is becoming more dynamic which can be seen in frequently changing customer needs. Hence, software companies need to be able to quickly respond to these changes. For software companies this means that they have to become agile with the objective of developing features with very short lead-time and of high quality. A consequence of this challenge is the appearance of agile and lean software development. Practices and principles of agile software development aim at increasing flexibility with regard to changing requirements. Lean software development aims at systematically identifying waste to focus all resources on value adding activities. Objective: The objective of the thesis is to evaluate the usefulness of agile practices in a large-scale industrial setting. In particular, with regard to agile the goal is to understand the effect of migrating from a plan-driven to an agile development approach. A positive effect would underline the usefulness of agile practices. With regard to lean software development the goal is to propose novel solutions inspired by lean manufacturing and product development, and to evaluate their usefulness in further improving agile development. Method: The primary research method used throughout the thesis is case study. As secondary methods for data collection a variety of approaches have been used, such as semi-structured interviews, workshops, study of process documentation, and use of quantitative data. Results: The agile situation was investigated through a series of case studies. The baseline situation (plan-driven development) was evaluated and the effect of the introduction of agile practices was captured, followed by an in-depth analysis of the new situation. Finally, a novel approach, Software Process Improvement through the Lean Measurement (SPI-LEAM) method, was introduced providing a comprehensive measurement approach supporting the company to manage their work in process and capacity. SPI-LEAM focuses on the overall process integrating different dimensions (requirements, maintenance, testing, etc.). When undesired behavior is observed a drill-down analysis for the individual dimensions should be possible. Therefore, we provided solutions for the main product development flow and for software maintenance. The lean solutions were evaluated through case studies.

  • 69. Petersen, Kai
    Measuring and Predicting Software Productivity: A Systematic Map and Review2011In: Information and Software Technology, ISSN 0950-5849, E-ISSN 1873-6025, Vol. 53, no 4, p. 317-343Article in journal (Refereed)
    Abstract [en]

    Context: Software productivity measurement is essential in order to control and improve the performance of software development. For example, by identifying role models (e.g. projects, individuals, tasks) when comparing productivity data. The prediction is of relevance to determine whether corrective actions are needed, and to discover which alternative improvement action would yield the best results. Objectives: In this study we identify studies for software productivity prediction and measurement. Based on the identified studies we first create a classification scheme and map the studies into the scheme (systematic map). Thereafter, a detailed analysis and synthesis of the studies is conducted. Method: As a research method for systematically identifying and aggregating the evidence of productivity measurement and prediction approaches systematic mapping and systematic review have been used. Results: In total 38 studies have been identified, resulting in a classification scheme for empirical research on software productivity. The mapping allowed to identify the rigor of the evidence with respect to the different productivity approaches. In the detailed analysis the results were tabulated and synthesized to provide recommendations to practitioners. Conclusions: Risks with simple ratio-based measurement approaches were shown. In response to the problems data envelopment analysis seems to be a strong approach to capture multivariate productivity measures, and allows to identify reference projects to which inefficient projects should be compared. Regarding simulation no general prediction model can be identified. Simulation and statistical process control are promising methods for software productivity prediction. Overall, further evidence is needed to make stronger claims and recommendations. In particular, the discussion of validity threats should become standard, and models need to be compared with each other.

  • 70. Petersen, Kai
    et al.
    Ali, Nauman Bin
    Identifying Strategies for Study Selection in Systematic Reviews and Maps2011Conference paper (Refereed)
    Abstract [en]

    Study selection in systematic reviews is prone to bias and there exist no commonly defined strategies of how to reduce the bias and resolve disagreement between researchers. This study aims at identifying strategies for bias reduction and disagreement resolution. A review of existing systematic reviews is conducted for study selection strategy identification. In total 13 different strategies have been identified.

  • 71.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Badampudi, Deepika
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Ali Shah, Syed Muhammad
    SICS Swedish ICT AB, SWE.
    Wnuk, Krzysztof
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Gorschek, Tony
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Papatheocharous, Efi
    SICS Swedish ICT AB, SWE.
    Axelsson, Jakob
    SICS Swedish ICT AB, SWE.
    Sentilles, Séverine
    Mälardalens högskola, SWE.
    Crnkovic, Ivica
    Chalmers, Göteborg, SWE.
    Cicchetti, Antonio
    Mälardalens högskola, SWE.
    Choosing Component Origins for Software Intensive Systems In-house, COTS, OSS or Outsourcing?: A Case Survey2018In: IEEE Transactions on Software Engineering, ISSN 0098-5589, E-ISSN 1939-3520, Vol. 39, no 12, p. 237-261Article in journal (Refereed)
    Abstract [en]

    The choice of which software component to use influences the success of a software system. Only a few empirical studies investigate how the choice of components is conducted in industrial practice. This is important to understand to tailor research solutions to the needs of the industry. Existing studies focus on the choice for off-the-shelf (OTS) components. It is, however, also important to understand the implications of the choice of alternative component sourcing options (CSOs), such as outsourcing versus the use of OTS. Previous research has shown that the choice has major implications on the development process as well as on the ability to evolve the system. The objective of this study is to explore how decision making took place in industry to choose among CSOs. Overall, 22 industrial cases have been studied through a case survey. The results show that the solutions specifically for CSO decisions are deterministic and based on optimization approaches. The non-deterministic solutions proposed for architectural group decision making appear to suit the CSO decision making in industry better. Interestingly, the final decision was perceived negatively in nine cases and positively in seven cases, while in the remaining cases it was perceived as neither positive nor negative.

  • 72.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Engström, Emelie
    Finding relevant research solutions for practical problems: the serp taxonomy architecture2014Conference paper (Refereed)
    Abstract [en]

    Background: Experience and research indicates that there exist a communication gap between research and industry in software engineering. Objective: We propose the Software Engineering Research and Practice (SERP) taxonomy architecture to support communication between practitioners and researchers. The taxonomy architecture provides a basis for classifying research from a problem perspective which in turn supports the breaking down of complex practical challenges to researchable units. Thus such taxonomy may support the mapping of challenges in industry to research solutions in the software engineering context. Method: In this paper we present SERP and exemplifies its usage based on two literature studies in the field of software engineering. Further, we discuss how a taxonomy based on this architecture could have helped us in two past research projects that were conducted in close collaboration with industry. Finally we validate SERP by applying it to the area of software testing, developing SERP-test, and interviewing two industry practitioners and two researchers. Results: The taxonomy architecture has been applied to two problems in software testing, and has been assessed through interviews with practitioners and researchers. The interviews provided suggestions of how to improve the taxonomy architecture, which have been incorporated. With two examples, we demonstrated how the taxonomy architecture could be used to find solutions for industrial problems, and to find the problems addressed by a particular solution. Conclusion: SERP may be useful in multiple ways: (1) Given that SERP taxonomies are populated with industrial problems and scientific solutions, we could rapidly identify candidate research solutions for industrial practice. (2) Researchers could benefit from the taxonomy in the reporting of their research to ease the mapping to industrial challenges.

  • 73. Petersen, Kai
    et al.
    Feldt, Robert
    Mujtaba, Shahid
    Mattsson, Michael
    Systematic Mapping Studies in Software engineering2008Conference paper (Refereed)
  • 74.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, School of Computing.
    Gencel, Cigdem
    Worldviews, Research Methods, and their Relationship to Validity in Empirical Software Engineering Research2013Conference paper (Refereed)
    Abstract [en]

    Abstract—Background - Validity threats should be considered and consistently reported to judge the value of an empirical software engineering research study. The relevance of specific threats for a particular research study depends on the worldview or philosophical worldview of the researchers of the study. Problem/Gap - In software engineering, different categorizations exist, which leads to inconsistent reporting and consideration of threats. Contribution - In this paper, we relate different worldviews to software engineering research methods, identify generic categories for validity threats, and provide a categorization of validity threats with respect to their relevance for different world views. Thereafter, we provide a checklist aiding researchers in identifying relevant threats. Method - Different threat categorizations and threats have been identified in literature, and are reflected on in relation to software engineering research. Results - Software engineering is dominated by the pragmatist worldviews, and therefore use multiple methods in research. Maxwell’s categorization of validity threats has been chosen as very suitable for reporting validity threats in software engineering research. Conclusion - We recommend to follow a checklist approach, and reporting first the philosophical worldview of the researcher when doing the research, the research methods and all threats relevant, including open, reduced, and mitigated threats.

  • 75.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Gencel, Cigdem
    Asghari, Negin
    Baca, Dejan
    Betz, Stefanie
    Action research as a model for industry-academia collaboration in the software engineering context2014Conference paper (Refereed)
    Abstract [en]

    Background: Action research is a well-established research methodology. It is following a post-positivist research philosophy grounded in critical thinking. The methodology is driven by practical problems, emphasis participatory research, and develops practically useful solutions in an iterative manner. Objective: Two objectives are to be achieved: (1) Understanding the state of the art with respect to action research usage in the software engineering literature, and (2) reflecting and providing recommendations of how to foster industry-academia collaboration through action research. Method:} Based on our experience with two action research studies in close collaboration with Ericsson lessons learned and guidelines are presented. Results: In both cases presented action research led to multiple refinements in the interventions implemented. Furthermore, the close collaboration and co-production with the industry was essential to identify and describe the required refinements to provide an in-depth understanding. In comparison with previous studies, we required multiple iterations while previous software engineering studies reported mostly one iteration, or were not explicit regarding the number of iterations studied. Conclusion: We conclude that action research is a powerful tool for industry-academia collaboration. The success of the method highly depends on the researchers and practitioners working in a team. Future studies need to improve the reporting with respect to describing the type of action research used, the iterations, the model of collaboration, and the rationales for changes in each iteration.

  • 76.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Gencel, Cigdem
    Asghari, Negin
    Betz, Stefanie
    An Elicitation Instrument for Operationalising GQM+Strategies (GQM+S-EI)2015In: Journal of Empirical Software Engineering, ISSN 1382-3256, E-ISSN 1573-7616, Vol. 20, no 4, p. 968-1005Article in journal (Refereed)
    Abstract [en]

    Context: A recent approach for measurement program planning, GQM+Strategies, provides an important extension to existing approaches linking measurements and improvement activities to strategic goals and ways to achieve these goals. There is a need for instruments aiding in eliciting information from stakeholders to use GQM+Strategies. The success of GQM+Strategies highly depends on accurately identifying goals, strategies and information needs from stakeholders. Objective: The research aims at providing an instrument (called GQM+SEI), aiding practitioners to accurately elicit information needed by GQM+Strategies (capturing goals, strategies and information needs). Method: The research included two phases. In the first phase, using action research method, the GQM+S-EI was designed in three iterations in Ericsson AB. Thereafter, a case study was conducted to evaluate whether the information elicited with the designed instrument following the defined process was accurate and complete. Results: We identified that the industry requires elicitation instruments that are capable to elicit information from stakeholders, not having to know about the concepts (e.g. goals and strategies). The case study results showed that our proposed instrument is capable of accurately and completely capturing the needed information from the stakeholders. Conclusions: We conclude that GQM+S-EI can be used for accurately and completely eliciting the information needed by goal driven measurement frameworks. The instrument has been successfully transferred to Ericsson AB for measurement program planning.

  • 77.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Khurum, Mahvish
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Angelis, Lefteris
    Reasons for bottlenecks in very large-scale system of systems development2014In: Information and Software Technology, ISSN 0950-5849, E-ISSN 1873-6025, Vol. 56, no 10, p. 1403-1420Article in journal (Refereed)
    Abstract [en]

    Context: System of systems (SOS) is a set or arrangement of systems that results when independent and useful systems are to be incorporated into a larger system that delivers unique capabilities. Our investigation showed that the development life cycle (i.e. the activities transforming requirements into design, code, test cases, and releases) in SoS is more prone to bottlenecks in comparison to single systems. Objective: The objective of the research is to identify reasons for bottlenecks in SoS, prioritize their significance according to their effect on bottlenecks, and compare them with respect to different roles and different perspectives, i.e. SoS view (concerned with integration of systems), and systems view (concerned with system development and delivery). Method: The research method used is a case study at Ericsson AB. Results: Results show that the most significant reasons for bottlenecks are related to requirements engineering. All the different roles agree on the significance of requirements related factors. However, there are also disagreements between the roles, in particular with respect to quality related reasons. Quality related hinders are primarily observed and highly prioritized by quality assurance responsibles. Furthermore, SoS view and system view perceive different hinders, and prioritize them differently. Conclusion: We conclude that solutions for requirements engineering in SoS context are needed, quality awareness in the organization has to be achieved end to end, and views between SoS and system view need to be aligned to avoid sub optimization in improvements.

  • 78.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Nauman Bin, Ali
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Operationalizing the requirements selection process with study selection procedures from systematic literature reviews2015In: CEUR Workshop Proceedings, 2015, Vol. 1342, p. 102-113Conference paper (Refereed)
    Abstract [en]

    Context: Software organizations working in a market-driven environment have to select requirements from a large pool to be prioritized and put into backlogs for the development organization. Objective: This paper proposes an approach based on study selection in systematic literature reviews and translates the concept to requirements engineering. The rational for doing so is that the selection processes used there have been e?ective (selecting and finding relevant papers) and efficient (possible to use for a high number of studies, in some cases 10,000 research contributions had to be evaluated). Method: This paper can be classified as a solution proposal, and utilizes hypothetical examples to explain and argue for the method design decisions. Results: The process proposed consists of three main phases, namely establish selection criteria, evaluate selection criteria, and apply selection. On a more fine-grained level, nine activities are specified. Conclusion: Given that the process has been e?ective and efficient in a similar context, our proposition to be evaluated in future research contributions is that the process leads to e?ective and efficient decision making in requirements selection. © 2015 by the authors.

  • 79.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Roos, Peter
    Nyström, Staffan
    Runeson, Per
    Early identification of bottlenecks in very large scale system of systems software development2014In: Journal of Software Maintenance and Evolution: Research and Practice, ISSN 1532-060X, E-ISSN 1532-0618, Vol. 26, no 12, p. 1150-1171Article in journal (Refereed)
    Abstract [en]

    System of systems are of high complexity, and for each system, many different requirements are implemented in parallel. Systems are developed with some degree of managerial independence but later on have to work together. In this situation, many requirements are written, implemented, and tested in parallel for different systems that are to be integrated. This makes identifying bottlenecks challenging, and visualizations often used on project level (such as Kanban boards or burndown charts) have to be extended/complemented to cope with the increased complexity. In response to these challenges, the contributions of this study are to propose the following: (i) a visualization for early identification and proactive removal of bottlenecks; (ii) a visualization to check on the success of bottleneck resolution; and (iii) to provide an industry evaluation of the visualizations in a case study of a system of systems developed at Ericsson AB in Sweden. The feedback by the practitioners showed that the visualizations were perceived as useful in improving throughput and lead time. The quantitative analysis showed that the visualizations were able in identifying bottlenecks and showing improvements or the lack thereof. On the basis of the qualitative and quantitative data collected, we conclude that the visualizations are useful in bottleneck identification and resolution.

  • 80. Petersen, Kai
    et al.
    Rönkkö, Kari
    Wohlin, Claes
    The impact of time controlled reading on software inspection effectiveness and efficiency: a controlled experiment2008Conference paper (Refereed)
    Abstract [en]

    Reading techniques help to guide reviewers during individual software inspections. In this experiment, we completely transfer the principle of statistical usage testing to inspection reading techniques for the first time. Statistical usage testing relies on a usage profile to determine how intensively certain parts of the system shall be tested from the users' perspective. Usage-based reading applies statistical usage testing principles by utilizing prioritized use cases as a driver for inspecting software artifacts (e.g., design). In order to reflect how intensively certain use cases should be inspected, time budgets are introduced to usage-based reading where a maximum inspection time is assigned to each use case. High priority use cases receive more time than low priority use cases. A controlled experiment is conducted with 23 Software Engineering M.Sc. students inspecting a design document. In this experiment, usage-based reading without time budgets is compared with time controlled usage-based reading. The result of the experiment is that time budgets do not significantly improve inspection performance. In conclusion, it is sufficient to only use prioritized use cases to successfully transfer statistical usage testing to inspections.

  • 81. Petersen, Kai
    et al.
    Sundmark, Daniel
    Larsson, Stig
    An exploratory case study of testing in an automotive electrical system release process2011Conference paper (Refereed)
    Abstract [en]

    The release process is a crucial element in the development of software-intensive systems, as it bridges the gap between the development of a system and its operational use. A short release process enables a fast time to market, but also puts high demands on the efficiency of integration and testing, which typically constitue principal release process steps. This paper reports findings from an exploratory industrial case study focusing on system testing in an automotive electrical system release process. We provide a description of how system testing is performed and integrated in the release process in the automotive domain, and identify a set of challenges observed in the studied setting. The case being studied is Scania, a major Swedish automotive company.

  • 82.
    Petersen, Kai
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Vakkalanka, Sairam
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Kuzniarz, Ludwik
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Guidelines for conducting systematic mapping studies in software engineering: An update2015In: Information and Software Technology, ISSN 0950-5849, E-ISSN 1873-6025, Vol. 64, p. 1-18Article in journal (Refereed)
    Abstract [en]

    Context Systematic mapping studies are used to structure a research area, while systematic reviews are focused on gathering and synthesizing evidence. The most recent guidelines for systematic mapping are from 2008. Since that time, many suggestions have been made of how to improve systematic literature reviews (SLRs). There is a need to evaluate how researchers conduct the process of systematic mapping and identify how the guidelines should be updated based on the lessons learned from the existing systematic maps and SLR guidelines. Objective To identify how the systematic mapping process is conducted (including search, study selection, analysis and presentation of data, etc.); to identify improvement potentials in conducting the systematic mapping process and updating the guidelines accordingly. Method We conducted a systematic mapping study of systematic maps, considering some practices of systematic review guidelines as well (in particular in relation to defining the search and to conduct a quality assessment). Results In a large number of studies multiple guidelines are used and combined, which leads to different ways in conducting mapping studies. The reason for combining guidelines was that they differed in the recommendations given. Conclusion The most frequently followed guidelines are not sufficient alone. Hence, there was a need to provide an update of how to conduct systematic mapping studies. New guidelines have been proposed consolidating existing findings. © 2015 Elsevier B.V.

  • 83. Petersen, Kai
    et al.
    Wohlin, Claes
    A comparison of issues and advantages in agile and incremental development between state of the art and an industrial case2009In: Journal of Systems and Software, ISSN 0164-1212 , Vol. 82, no 9, p. 1479-1490Article in journal (Refereed)
    Abstract [en]

    Recent empirical studies have been conducted identifying a number of issues and advantages of incremental and agile methods. However, the majority of studies focused on one model (Extreme Programming) and small projects. To draw more general conclusions we conduct a case study in large-scale development identifying issues and advantages, and compare the results with previous empirical studies on the topic. The principle results are that (1) the case study and literature agree on the benefits while new issues arise when using agile in large-scale and (2) an empirical research framework is needed to 27 make agile studies comparable.

  • 84. Petersen, Kai
    et al.
    Wohlin, Claes
    Context in industrial software engineering research2009Conference paper (Refereed)
    Abstract [en]

    In order to draw valid conclusions when aggregating evidence it is important to describe the context in which industrial studies were conducted. This paper structures the context for empirical industrial studies and provides a checklist. The aim is to aid researchers in making informed decisions concerning which parts of the context to include in the descriptions. Furthermore, descriptions of industrial studies were surveyed.

  • 85. Petersen, Kai
    et al.
    Wohlin, Claes
    Issues and advantages of using agile and incremental practices2008Conference paper (Refereed)
    Abstract [en]

    The importance of agile methods increased in recent years due to the need of being more flexible due to unstable requirements and high competitive pressure. Therefore, recent empirical studies have been conducted identifying a number of issues and advantages of incremental and agile methods. However, the majority of studies focused on one model (Extreme Programming) and small projects. Thus, in order to draw more general conclusions there is a need to also study large scale implementations of agile and incremental practices. Therefore, this paper 1) investigates a large-scale implementation of agile and incremental practices and identified issues and advantages and 2) compares them with the findings of previous studies mainly focusing on small-scale agile implementations.

  • 86. Petersen, Kai
    et al.
    Wohlin, Claes
    Measuring the flow in lean software development2011In: Software, practice & experience, ISSN 0038-0644, E-ISSN 1097-024X, Vol. 41, no 9, p. 975-996Article in journal (Refereed)
    Abstract [en]

    Responsiveness to customer needs is an important goal in agile and lean software development. One major aspect is to have a continuous and smooth flow that quickly delivers value to the customer. In this paper we apply cumulative flow diagrams to visualize the flow of lean software development. The main contribution is the definition of novel measures connected to the diagrams to achieve the following goals: (1) increase throughput and reduce lead-time to achieve high responsiveness to customers' needs and (2) to provide a tracking system that shows the progress/status of software product development. An evaluation of the measures in an industrial case study showed that practitioners found them useful and identify improvements based on the measurements, which were in line with lean and agile principles. Furthermore, the practitioners found the measures useful in seeing the progress of development for complex products where many tasks are executed in parallel. The measures are now an integral part of the improvement work at the studied company.

  • 87. Petersen, Kai
    et al.
    Wohlin, Claes
    Software Process Improvement through the Lean Measurement (SPI-LEAM) Method2010In: Journal of Systems and Software, ISSN 0164-1212 , Vol. 8, no 7, p. 1275-1287Article in journal (Refereed)
    Abstract [en]

    Software process improvement methods help to continuously refine and adjust the software process to improve its performance (e.g., in terms of lead-time, quality of the software product, reduction of change requests, and so forth). Lean software development propagates two important principles that help process improvement, namely identification of waste in the process and considering interactions between the individual parts of the software process from an end-to-end perspective. A large shift of thinking about the own way of working is often required to adopt lean. One of the potential main sources of failure is to try to make a too large shift about the ways of working at once. Therefore, the change to lean has to be done in a continuous and incremental way. In response to this we propose a novel approach to bring together the quality improvement paradigm and lean software development practices, the approach being called Software Process Improvement through the Lean Measurement (SPI-LEAM) Method. The method allows to assess the performance of the development process and take continuous actions to arrive at a more lean software process over time. The method is under implementation in industry and an initial evaluation of the method has been performed.

  • 88. Petersen, Kai
    et al.
    Wohlin, Claes
    The Effect of Moving from a Plan-Driven to an Incremental and Agile Development Approach: An Industrial Case Study2010In: Journal of Empirical Software Engineering, ISSN 1382-3256, E-ISSN 1573-7616, Vol. 15, no 6, p. 654-693Article in journal (Refereed)
    Abstract [en]

    So far, only few in-depth studies focused on the direct comparison of process models in general, and between plan-driven and incremental/agile approaches in particular. That is, it is not made explicit what the effect is of moving from one model to another model. Furthermore, there is limited evidence on advantages and issues encountered in agile software development, this is specifically true in the context of large-scale development. The objective of the paper is to investigate how the perception of bottlenecks, unnecessary work, and rework (from hereon referred to as issues) changes when migrating from a plan-driven to an incremental software development approach with agile practices (flexible product backlog, face-to-face interaction, and frequent integration), and how commonly perceived these practices are across different systems and development roles. The context in which the objective should be achieved is large-scale development with a market-driven focus. The selection of the context was based on the observation in related work that mostly small software development projects were investigated and that the investigation was focused on one agile model (eXtreme programming). A case study was conducted at a development site of Ericsson AB, located in Sweden in the end of 2007. In total 33 interviews were conducted in order to investigate the perceived change when migrating from plan-driven to incremental and agile software development, the interviews being the primary source of evidence. For triangulation purposes measurements collected by Ericsson were considered, the measurements relating to unnecessary work (amount of discarded requirements) and rework (data on testing efficiency and maintenance effort). Triangulation in this context means that the measurements were used to confirm the perceived changes with an additional data source. In total 64 issues were identified, 24 being of general nature and the remaining 40 being local and therefore unique to individual’s opinions or a specific system. The most common ones were documented and analyzed in detail. The commonality refers to how many persons in different roles and across the systems studied have mentioned the issues for each of the process models. The majority of the most common issues relates to plan-driven development. We also identified common issues remaining for agile after the migration, which were related to testing lead-time, test coverage, software release, and coordination overhead. Improvements were identified as many issues commonly raised for the plan-driven approach were not raised anymore for the incremental and agile approach. It is concluded that the recent introduction (start in 2005 with the study being conducted in the end of 2007) of incremental and agile practices brings added values in comparison to the plan-driven approach, which is evident from the absence of critical issues that are encountered in plan-driven development.

  • 89. Petersen, Kai
    et al.
    Wohlin, Claes
    Baca, Dejan
    The waterfall model in large-scale development2009Conference paper (Refereed)
    Abstract [en]

    Waterfall development is still a widely used way of working in software development companies. Many problems have been reported related to the model. Commonly accepted problems are for example to cope with change and that defects all too often are detected too late in the software development process. However, many of the problems mentioned in literature are based on beliefs and experiences, and not on empirical evidence. To address this research gap, we compare the problems in literature with the results of a case study at Ericsson AB in Sweden, investigating issues in the waterfall model. The case study aims at validating or contradicting the beliefs of what the problems are in waterfall development through empirical research.

  • 90.
    Poulding, Simon
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Feldt, Robert
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Garousi, Vahid
    Using Citation Behavior to Rethink Academic Impact in Software Engineering2015In: ACM-IEEE International Symposium on Empirical Software Engineering and Measurement, 2015, p. 140-43Conference paper (Refereed)
    Abstract [en]

    Although citation counts are often considered a measure of academic impact, they are criticized for failing to evaluate impact as intended. In this paper we propose that software engineering citations may be classified according to how the citation is used by the author of the citing paper, and that through this classification of citation behaviour it is possible to achieve a more refined understanding of the cited paper’s impact. Our objective in this work is to conduct an initial evaluation using the citation behaviour taxonomy proposed by Bornmann and Daniel. We independently classified citations to ten highly-cited papers published at the International Symposium on Empirical Software Engineering and Measurement (ESEM). The degree to which classifications were consistent between researchers was analyzed in order to assess the clarity of Bornmann and Daniel’s taxonomy. We found poor to fair agreement between researchers even though the taxonomy was perceived as relatively easy to apply for the majority of citations. We were nevertheless able to identify clear differences in the profile of citation behaviors between the cited papers. We conclude that an improved taxonomy is required if classification is to be reliable, and that a degree of automation would improve reliability as well as reduce the time taken to make a classification.

  • 91.
    Rafi, Dudekula Mohammad
    et al.
    Blekinge Institute of Technology, School of Computing.
    Moses, Katam Reddy Kiran
    Blekinge Institute of Technology, School of Computing.
    Petersen, Kai
    Blekinge Institute of Technology, School of Computing.
    Mäntylä, Mika
    Benefits and limitations of automated software testing: Systematic literature review and practitioner survey2012Conference paper (Refereed)
    Abstract [en]

    There is a documented gap between academic and practitioner views on software testing. This paper tries to close the gap by investigating both views regarding the benefits and limits of test automation. The academic views are studied with a systematic literature review while the practitioners views are assessed with a survey, where we received responses from 115 software professionals. The results of the systematic literature review show that the source of evidence regarding benefits and limitations is quite shallow as only 25 papers provide the evidence. Furthermore, it was found that benefits often originated from stronger sources of evidence (experiments and case studies), while limitations often originated from experience reports. We believe that this is caused by publication bias of positive results. The survey showed that benefits of test automation were related to test reusability, repeatability, test coverage and effort saved in test executions. The limitations were high initial invests in automation setup, tool selection and training. Additionally, 45% of the respondents agreed that available tools in the market offer a poor fit for their needs. Finally, it was found that 80% of the practitioners disagreed with the vision that automated testing would fully replace manual testing.

  • 92.
    Sentilles, Severine
    et al.
    Malardalen Univ, SWE.
    Papatheocharous, Efi
    Swedish Inst Comp Sci, SWE.
    Ciccozzi, Federico
    Malardalen Univ, SWE.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    A Property Model Ontology2016In: 2016 42ND EUROMICRO CONFERENCE ON SOFTWARE ENGINEERING AND ADVANCED APPLICATIONS (SEAA), 2016, p. 165-172Conference paper (Refereed)
    Abstract [en]

    Efficient development of high quality software is tightly coupled to the ability of quickly taking complex decisions based on trustworthy facts. In component-based software engineering, the decisions related to selecting the most suitable component among functionally-equivalent ones are of paramount importance. Despite sharing the same functionality, components differ in terms of their extra-functional properties. Therefore, to make informed selections, it is crucial to evaluate extra-functional properties in a systematic way. To date, many properties and evaluation methods that are not necessarily compatible with each other exist. The property model ontology presented in this paper represents the first step towards providing a systematic way to describe extra-functional properties and their evaluation methods, and thus making them comparable. This is beneficial from two perspectives. First, it aids researchers in identifying comparable property models as a guide for empirical evaluations. Second, practitioners are supported in choosing among alternative evaluation methods for the properties of their interest. The use of the ontology is illustrated by instantiating a subset of property models relevant in the automotive domain.

  • 93. Shah, Syed Muhammad Ali
    et al.
    Alvi, Usman Sattar
    Gencel, Cigdem
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Comparing a Hybrid Testing Process with Scripted and Exploratory Testing: An Experimental Study with Practitioners2014Conference paper (Refereed)
    Abstract [en]

    This study presents an experimental study comparing the testing quality of a Hybrid Testing (HT) process with the commonly used approaches in industry: Scripted Testing (ST) and Exploratory Testing (ET). The study was conducted in an international IT service company in Sweden with the involvement of six experienced testers. Two measures were used for comparison: 1) defect detection effectiveness (DDE) and 2) functionality coverage (FC). The results indicated that HT performed better in terms of DDE than ST and worse than ET. In terms of FC, HT performed better than ET, while no significant differences were observed between the HT and ST. Furthermore, HT performed best for experienced testers, but worse with less experienced testers.

  • 94. Solinski, Adam
    et al.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Prioritizing agile benefits and limitations in relation to practice usage2016In: Software quality journal, ISSN 0963-9314, E-ISSN 1573-1367, Vol. 24, no 2, p. 447-482Article in journal (Refereed)
    Abstract [en]

    In recent years, there has been significant shift from rigid development (RD) toward agile. However, it has also been spotted that agile methodologies are hardly ever followed in their pure form. Hybrid processes as combinations of RD and agile practices emerge. In addition, agile adoption has been reported to result in both benefits and limitations. This exploratory study (a) identifies development models based on RD and agile practice usage by practitioners; (b) identifies agile practice adoption scenarios based on eliciting practice usage over time; (c) prioritizes agile benefits and limitations in relation to (a) and (b). Practitioners provided answers through a questionnaire. The development models are determined using hierarchical cluster analysis. The use of practices over time is captured through an interactive board with practices and time indication sliders. This study uses the extended hierarchical voting analysis framework to investigate benefit and limitation prioritization. Four types of development models and six adoption scenarios have been identified. Overall, 45 practitioners participated in the prioritization study. A common benefit among all models and adoption patterns is knowledge and learning, while high requirements on professional skills were perceived as the main limitation. Furthermore, significant variances in terms of benefits and limitations have been observed between models and adoption patterns. The most significant internal benefit categories from adopting agile are knowledge and learning, employee satisfaction, social skill development, and feedback and confidence. Professional skill-specific demands, scalability, and lack of suitability for specific product domains are the main limitations of agile practice usage. Having a balanced agile process allows to achieve a high number of benefits. With respect to adoption, a big bang transition from RD to agile leads to poor quality in comparison with the alternatives.

  • 95. Ulziit, B.a
    et al.
    Warraich, Z.A.b
    Gencel, Cigdem
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    A conceptual framework of challenges and solutions for managing global software maintenance2015In: Journal of Software: Evolution and Process, ISSN 2047-7473, E-ISSN 2047-7481, Vol. 27, no 10, p. 763-792Article in journal (Refereed)
    Abstract [en]

    Context Software maintenance process in globally distributed settings brings significant management challenges to software organizations. Objectives Investigate the factors specific to managing software maintenance process in globally distributed settings and best practices in software organizations. Method A systematic literature review and interviews with industry practitioners were conducted. For analysis and synthesis, the grounded theory method was used. Results We identified a number of management challenges and mitigation strategies and then classified them under people, process, product, and technology factors. Overall, a structure of challenges and solutions, the conceptual framework, has been developed that may be used to understand and classify global maintenance challenges. Conclusions Distributed software maintenance process has specific management challenges in relation to process, people, product, and technology. Therefore, companies performing maintenance in distributed settings should consider these factors, which are not present in the general global software development literature, although many lessons apply to both. © 2015 John Wiley and Sons, Ltd.

  • 96.
    Usman, Muhammad
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Börstler, Jürgen
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering. Blekinge Institute of Technology, School of Computing.
    An Effort Estimation Taxonomy for Agile Software Development2017In: International journal of software engineering and knowledge engineering, ISSN 0218-1940, Vol. 27, no 4, p. 641-674Article in journal (Refereed)
    Abstract [en]

    In Agile Software Development (ASD) effort estimation plays an important role during release and iteration planning. The state of the art and practice on effort estimation in ASD have been recently identified. However, this knowledge has not yet been organized. The aim of this study is twofold: (1) To organize the knowledge on effort estimation in ASD and (2) to use this organized knowledge to support practice and the future research on effort estimation in ASD. We applied a taxonomy design method to organize the identified knowledge as a taxonomy of effort estimation in ASD. The proposed taxonomy offers a faceted classification scheme to characterize estimation activities of agile projects. Our agile estimation taxonomy consists of four dimensions: estimation context, estimation technique, effort predictors and effort estimate. Each dimension in turn has several facets. We applied the taxonomy to characterize estimation activities of 10 agile projects identified from the literature to assess whether all important estimation-related aspects are reported. The results showed that studies do not report complete information related to estimation. The taxonomy was also used to characterize the estimation activities of four agile teams from three different software companies. The practitioners involved in the investigation found the taxonomy useful in characterizing and documenting the estimation sessions. © 2017 The Author(s).

  • 97.
    Usman, Muhammad
    et al.
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Petersen, Kai
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Börstler, Jürgen
    Blekinge Institute of Technology, Faculty of Computing, Department of Software Engineering.
    Neto, Pedro
    bFederal University of Piaui , BRA.
    Developing and Using Checklists to Improve Software Effort Estimation: a Multi-Case Study2018In: Journal of Systems and Software, ISSN 0164-1212, E-ISSN 1873-1228, Vol. 146, p. 286-309Article in journal (Refereed)
    Abstract [en]

    Expert judgment based effort estimation techniques are widely used for estimating software effort. In the absence of process support, experts may overlook important factors during estimation, leading to inconsistent estimates. This might cause underestimation, which is a common problem in software projects. This multi-case study aims to improve expert estimation of software development effort. Our goal is two-fold: 1) to propose a process to develop and evolve estimation checklists for agile teams, and 2) to evaluate the usefulness of the checklists in improving expert estimation processes. The use of checklists improved the accuracy of the estimates in two case companies. In particular, the underestimation bias was reduced to a large extent. For the third case, we could not perform a similar analysis, due to the unavailability of historical data. However, when checklist was used in two sprints, the estimates were quite accurate (median Balanced Relative Error (BRE) bias of -0.05 ). The study participants from the case companies observed several benefits of using the checklists during estimation, such as increased confidence in estimates, improved consistency due to help in recalling relevant factors, more objectivity in the process, improved understanding of the tasks being estimated, and reduced chances of missing tasks.

  • 98. V. Mäntylä, Mika
    et al.
    Khomh, Foutse
    Adams, Bram
    Engström, Emeilie
    Petersen, Kai
    Blekinge Institute of Technology, School of Computing.
    On Rapid Releases and Software Testing2013Conference paper (Refereed)
    Abstract [en]

    Abstract—Large open and closed source organizations like Google, Facebook and Mozilla are migrating their products towards rapid releases. While this allows faster time-to-market and user feedback, it also implies less time for testing and bug fixing. Since initial research results indeed show that rapid releases fix proportionally less reported bugs than traditional releases, this paper investigates the changes in software testing effort after moving to rapid releases. We analyze the results of 312,502 execution runs of the 1,547 mostly manual systemlevel test cases of Mozilla Firefox from 2006 to 2012 (5 major traditional and 9 major rapid releases), and triangulated our findings with a Mozilla QA engineer. In rapid releases, testing has a narrower scope that enables deeper investigation of the features and regressions with the highest risk, while traditional releases run the whole test suite. Furthermore, rapid releases make it more difficult to build a large testing community, forcing Mozilla to increase contractor resources in order to sustain testing for rapid releases.

12 51 - 98 of 98
CiteExportLink to result list
Permanent link
Cite
Citation style
  • apa
  • harvard1
  • ieee
  • modern-language-association-8th-edition
  • vancouver
  • Other style
More styles
Language
  • de-DE
  • en-GB
  • en-US
  • fi-FI
  • nn-NO
  • nn-NB
  • sv-SE
  • Other locale
More languages
Output format
  • html
  • text
  • asciidoc
  • rtf