1,721,213 research outputs found
Cost Savings in Global Software Engineering. Where's the Evidence?
Researchers examined published studies of global software engineering to determine whether offshoring actually yielded cost savings. Not enough evidence existed to reach the verdict that offshoring reduced costs
Evidence-Based Timelines for Agile Project Retrospectives – A Method Proposal
Retrospective analysis of agile projects can support identification of issues through team reflection and may enable learning and process improvements. Basing retrospectives primarily on experiences poses a risk of memory bias as people may remember events differently, which can lead to incorrect conclusions. This bias is enhanced in project retrospectives which cover a longer period compared to iteration retrospectives. To support teams in recalling accurate and joint views of projects, we propose using an evidence-based timeline with historical data as input to project retrospectives. The proposed method was developed together with a large software development company in the telecommunications domain. This paper outlines a method for visualizing an evidence-based project timeline by illustrating aspects such as business priority, iterations and test activities. Our method complements an experience-based approach by providing objective data as a starting point for reflection and aims to support objective analysis of issues and root causes
Erratum to “A General Theory of Software Engineering: Balancing Human, Social and Organizational Capitals” [The Journal of Systems & Software 109c (2015) 229–242]
Inner Source Project Management
Software development organizations are continuously looking for better ways to manage their projects. An emerging approach to achieve this is Inner Source, which refers to the adoption of Open Source development practices within the confines of an organization. With an Inner Source approach, individuals, teams, and departments within an organization can start software projects, very similar to the Open Source model. This affects the way projects are managed in a variety of ways. Firstly, it will affect strategic aspects such as a software sourcing strategy that includes decisions on which software can be “Inner-Sourced.” Secondly, at the tactical level, organizations should choose an appropriate Inner Source adoption model that suits the goals and scope of the organization. Finally, it will affect the operational aspects of a project, for example, in the way different people across a whole organization can access the source code and make improvements. Furthermore, Inner Source makes communication much more transparent. While Inner Source offers a variety of potential benefits to an organization, there are also a number of challenges to address. This chapter discusses how the introduction of Inner Source may affect conventional software developing environments and especially how it affects software project management aspects. Based on our studies and those presented in the literature, it outlines a number of benefits of Inner Source as well as a number of challenges and some suggestions as to how they can be addressed
Improving the software inspection process with patterns
AbstractThe quality of a software product depends largely on the quality of the process that is used to develop it. In small software companies, the development process may be informal or even ad hoc, which causes uncertainty and variation in the product quality. However, quality issues are as important in small companies as in their larger counterparts. To sustain their dynamics and competitiveness, small organizations need to concentrate on the most effective quality assurance methods.Software inspection is a proven method for improving product quality and it provides a very cost-effective way for small companies to improve their development processes. This study introduces a framework for adjusting the inspection process for the organization’s specific needs and evaluating its capabilities. The main focus of this work, however, is on refining and improving the inspection process. The improvement is guided by concrete instructions that are documented as process patterns. The pattern approach has already been used successfully in several other areas of software engineering. Patterns aim at capturing the best practices of software development and transferring this knowledge between people or organizations.The framework for inspection process capability originates from the literature relating to different types of peer review methods and experiments with flexible and tool-supported inspections in small companies. Furthermore, generic process improvement models are studied to find a feasible structure for the framework. As a result of the analysis, the i3 capability model is introduced. The feasibility of the model has been investigated in real-life software organizations carrying out inspections.After the capability evaluation, the inspection process can be upgraded with the aid of improvement patterns, which provide structured and easy-to-follow guidelines for implementing improvements. An initial list of patterns, describing solutions to the most common problems confronted in the establishment of inspections, is extracted from related inspection research and an industrial experiment.The contributions of this study are, first, the new view of the inspection process, based on the fundamental activities that are performed during an inspection instead of a series of stages, as it is usually presented. An activity-based process description enables tailoring of the process for organization-specific needs and its targeted improvement. Second, the study introduces a practical, lightweight method for implementing the improvement. Patterns are especially suitable in companies where resources are limited and full-scale improvement programmes cannot be initiated. Furthermore, the generic process improvement models do not provide detailed information on how improvements should be carried out, and the pattern approach represents a promising method for that. Third, the inspection process currently does not have a very significant role in generic software process improvement models; this study helps in outlining the importance of inspections. A similar approach could be applied to other software subprocesses to enable their evaluation and improvement.Academic Dissertation to be presented with the assent of the Faculty of Science, University of Oulu, for public discussion in Auditorium IT115, Linnanmaa, on December 16th, 2005, at 12 noonAbstract
The quality of a software product depends largely on the quality of the process that is used to develop it. In small software companies, the development process may be informal or even ad hoc, which causes uncertainty and variation in the product quality. However, quality issues are as important in small companies as in their larger counterparts. To sustain their dynamics and competitiveness, small organizations need to concentrate on the most effective quality assurance methods.
Software inspection is a proven method for improving product quality and it provides a very cost-effective way for small companies to improve their development processes. This study introduces a framework for adjusting the inspection process for the organization’s specific needs and evaluating its capabilities. The main focus of this work, however, is on refining and improving the inspection process. The improvement is guided by concrete instructions that are documented as process patterns. The pattern approach has already been used successfully in several other areas of software engineering. Patterns aim at capturing the best practices of software development and transferring this knowledge between people or organizations.
The framework for inspection process capability originates from the literature relating to different types of peer review methods and experiments with flexible and tool-supported inspections in small companies. Furthermore, generic process improvement models are studied to find a feasible structure for the framework. As a result of the analysis, the i3 capability model is introduced. The feasibility of the model has been investigated in real-life software organizations carrying out inspections.
After the capability evaluation, the inspection process can be upgraded with the aid of improvement patterns, which provide structured and easy-to-follow guidelines for implementing improvements. An initial list of patterns, describing solutions to the most common problems confronted in the establishment of inspections, is extracted from related inspection research and an industrial experiment.
The contributions of this study are, first, the new view of the inspection process, based on the fundamental activities that are performed during an inspection instead of a series of stages, as it is usually presented. An activity-based process description enables tailoring of the process for organization-specific needs and its targeted improvement. Second, the study introduces a practical, lightweight method for implementing the improvement. Patterns are especially suitable in companies where resources are limited and full-scale improvement programmes cannot be initiated. Furthermore, the generic process improvement models do not provide detailed information on how improvements should be carried out, and the pattern approach represents a promising method for that. Third, the inspection process currently does not have a very significant role in generic software process improvement models; this study helps in outlining the importance of inspections. A similar approach could be applied to other software subprocesses to enable their evaluation and improvement
Case Study Research in Software Engineering : It is a Case, and it is a Study, but is it a Case Study?
Background: Case studies are regularly published in the software engineering literature, and guidelines for conducting case studies are available. Based on a perception that the label “case study” is assigned to studies that are not case studies, an investigation has been conducted. Objective: The aim was to investigate whether or not the label “case study” is correctly used in software engineering research. Method: To address the objective, 100 recent articles found through Scopus when searching for case studies in software engineering have been investigated and classified. Results: Unfortunately, the perception of misuse of the label “case study” is correct. Close to 50% of the articles investigated were judged as not being case studies according to the definition of a case study. Conclusions: We either need to ensure correct use of the label “case study”, or we need another label for its definition. Given that “case study” is a well-established label, it is probably impossible to change the label. Thus, we introduce an alternative definition of case study emphasising its real-life context, and urge researchers to carefully follow the definition of different research methods when presenting their research. © 2021 The Authoropen access</p
Engineering Software Qualities in Telecommunications : Three Cases from Industry
Software has become an integral part of telecommunication systems over the last 30 years. The relative cost for software in the systems has increased continuously over these years. This increase has meant that there has been a need to also focus on evaluation and prediction of different software qualities of the systems. This paper presents three studies evaluating software qualities in different ways. The firsts study focuses on performance and touches upon reliability. The reliability aspect is discussed in more detail in the second case study. Finally, the third study presents methods to estimate the fault content from software inspections. These studies are presented as representative examples of the work that resulted in that the author of this paper received the Telenor Nordic Research Award in 2004. Some ongoing research on engineering software qualities is also briefly presented.</p
- …
