Like other sciences and engineering disciplines, software engineering requires a cycle of model building, experimentation, and learning. Experiments are valuable tools for all software engineers who are involved in evaluating and choosing between different methods, techniques, languages and tools. The purpose of Experimentation in Software Engineering is to introduce students, teachers, researchers, and practitioners to empirical studies in software engineering, using controlled experiments. The introduction to experimentation is provided through a process perspective, and the focus is on the steps that we have to go through to perform an experiment. The book is divided into three parts. The first part provides a background of theories and methods used in experimentation. Part II then devotes one chapter to each of the five experiment steps: scoping, planning, execution, analysis, and result presentation. Part III completes the presentation with two examples. Assignments and statistical material are provided in appendixes. Overall the book provides indispensable information regarding empirical studies in particular for experiments, but also for case studies, systematic literature reviews, and surveys. It is a revision of the authors book, which was published in 2000. In addition, substantial new material, e.g. concerning systematic literature reviews and case study research, is introduced. The book is self-contained and it is suitable as a course book in undergraduate or graduate studies where the need for empirical studies in software engineering is stressed. Exercises and assignments are included to combine the more theoretical material with practical aspects. Researchers will also benefit from the book, learning more about how to conduct empirical studies, and likewise practitioners may use it as a cookbook when evaluating new methods or techniques before implementing them in their organization.

Experimentation in Software Engineering

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.

Guidelines for conducting systematic mapping studies in software engineering : An update

Everybody knows that digital technology has revolutionized our economy and our lifestyles. But how many of us really understand the drivers behind the technology – the significance of going digital; the miniaturization of electronic devices; the role of venture capital in financing the revolution; the importance of research and development? How many of us understand what it takes to make money from innovative technologies? Should we worry about manufacturing going offshore? What is the role of India and China in the digital economy? Drawing on a lifetime’s experience in the industry, as an engineer, a senior manager, and as a partner in a global venture capital firm, Henry Kressel offers an expert personalized answer to all these questions. He explains how the technology works, why it matters, how it is financed, and what the key lessons are for public policy.

Competing for the Future

We provide a review of the alignment literature in IT, addressing questions such as: What have we learned? What is disputed? Who are contributors to the debate? The article is intended to be useful to faculty and graduate students considering conducting research on alignment, instructors preparing lectures, and practitioners seeking to assess the ‘state-of-play’. It is both informational and provocative. Challenges to the value of alignment research, divergent views, and new perspectives on alignment are presented. It is hoped that the article will spark helpful conversation on the merits of continued investigation of IT alignment.

/pdf/it-alignment-what-have-we-learned-nxwe0wokck.pdf

IT alignment: what have we learned?

Although business process management (‘BPM’) is a popular concept, it has not yet been properly theoretically grounded. This leads to problems in identifying both generic and case specific critical success factors of BPM programs. The paper proposes an underlying theoretical framework with the utilization of three theories: contingency, dynamic capabilities and task technology fit. The main premise is that primarily the fit between the business environment and business processes is needed. Then both continuous improvement and the proper fit between business process tasks and information systems must exist. The underlying theory is used to identify critical success factors on a case study from the banking sector.

https://papers.ssrn.com/sol3/Delivery.cfm/SSRN_ID1611789_code1485980.pdf?abstractid=1611789&mirid=5&type=2

The Critical Success Factors of Business Process Management

IntroductionWe have been developing software since the 1960s but still have not learned enough to ensure that our software development projects are successful. Boehm2 suggested that realistic schedule and budgets together with a continuing steam of requirements changes are high risk factors. The Standish Group in 1994 noted that approximately 31% of corporate software development projects were cancelled before completion and 53% were challenged and cost 180% above their original estimate.13 Glass discussed 16 project disasters.5 He found that the failed projects he reviewed were mostly huge and that the failure factors were not just management factors but also included technical factors. Linberg in 1999 found that 20% of software projects failed, and that 46% experienced cost and schedule overruns or significantly reduced functionality.8 Later, Glass revisited failed projects and found that poor estimation was high on his list of failure factors.6In 2007 the Standish Group reported that 35% of software projects started in 2006 were successful compared with only 16% in the corresponding 1994 report; however, the 2007 CHAOS report still identifies 46% (53% in 1994) of software projects as challenged (having cost or time overruns or not fully meeting user's requirements) and 19% (31% in 1994) as outright failures.12 The validity of the Standish Group findings has been questioned as not consistent with cost overrun results of other surveys.7 Jorgensen and Molokken-Ostvold suggested that there are serious problems with the way the Standish Group conducted their research and that the findings were biased toward reports of failure because a random sample of top IT executives was asked to share failure stories when mailed confidential surveys.Recently Charette4 commented that "billions of dollars are wasted each year on failed software projects" and that "we have a dismal history of projects that have gone awry."4 Charette suggests that from 5%-15% of projects will be abandoned before or shortly after delivery as hopelessly inadequate.4 Other recent studies, suggest various failure rates for software development projects up to 85%.7 Stories of software failure capture public attention and in general there is a perception that software quality is not improving but getting worse.Developing software systems is an expensive, and often a difficult process. Although there are many guidelines for successful software development,9,11 few project post-mortems are conducted, and little understanding is gained from the results of past projects. The project manager (PM) and the development team must deal with many pressures from project stakeholders (for example, upper level management, marketing, accounting, customers, and users) during the software development process. These pressures impact both the cost and the quality of the software produced. There are generally more than one or two reasons for a software project to fail, and it usually is a combination of technical, project management and business decisions. Many software project failure factors have been described in the literature.1-13 However, most organizations do not see preventing failure as an urgent matter. It is not understood why this attitude persists.4Because most of the literature is based on a handful of failed project case studies, in our research we analyze 70 failed software projects to determine those practices that affected project outcome. We are interested in providing, from the perspective of software practitioners, quantitative evidence targeting those aspects of the development process that contribute to project failure. Essentially, we are interested in updating the results of prior studies and testing the validity of previously reported anecdotal evidence. To date, no one has taken a set of project data and teased it out to identify, for a whole group of such projects, the most common failure factors. We are interested in everyday projects that are not high profile enough to be reported in the literature. Our work builds on that previously reported by Boehm,2 Charette,4 Glass,5,6 Jorgensen and Molokken,7 Linberg,8 and the Standish Group,12,13 among others.

Why did your project fail

Establishing and maintaining trust in software outsourcing relationships: An empirical investigation

Ensuring that organizational IT is in alignment with and provides support for an organization's business strategy is critical to business success. Despite this, business strategy and strategic alignment issues are all but ignored in the requirements engineering research literature. We present B-SCP, a requirements engineering framework for organizational IT that directly addresses an organization's business strategy and the alignment of IT requirements with that strategy. B-SCP integrates the three themes of strategy, context, and process using a requirements engineering notation for each theme. We demonstrate a means of cross-referencing and integrating the notations with each other, enabling explicit traceability between business processes and business strategy. In addition, we show a means of defining requirements problem scope as a Jackson problem diagram by applying a business modeling framework. Our approach is illustrated via application to an exemplar. The case example demonstrates the feasibility of B-SCP, and we present a comparison with other approaches.

B-SCP: A requirements analysis framework for validating strategic alignment of organizational IT based on strategy, context, and process

Agile methods may produce software faster but we also need to know how they meet our quality requirements. In this paper we compare the waterfall model with agile processes to show how agile methods achieve software quality under time pressure and in an unstable requirements environment, i.e. we analyze agile software quality assurance. We present a detailed waterfall model showing its software quality support processes. We then show the quality practices that agile methods have integrated into their processes. This allows us to answer the question "can agile methods ensure quality even though they develop software faster and can handle unstable requirements?".

https://ulir.ul.ie/bitstream/handle/10344/2144/2004_huo,m.pdf?sequence=2

June M. Verner

Papers

Why did your project fail

Establishing and maintaining trust in software outsourcing relationships: An empirical investigation

B-SCP: A requirements analysis framework for validating strategic alignment of organizational IT based on strategy, context, and process

Software quality and agile methods

Validating strategic alignment of organizational IT requirements using goal modeling and problem diagrams