Agile software development represents a major departure from traditional, plan-based approaches to software engineering. A systematic review of empirical studies of agile software development up to and including 2005 was conducted. The search strategy identified 1996 studies, of which 36 were identified as empirical studies. The studies were grouped into four themes: introduction and adoption, human and social factors, perceptions on agile methods, and comparative studies. The review investigates what is currently known about the benefits and limitations of, and the strength of evidence for, agile methods. Implications for research and practice are presented. The main implication for research is a need for more and better empirical studies of agile software development within a common research agenda. For the industrial readership, the review provides a map of findings, according to topic, that can be compared for relevance to their own settings and situations.

/pdf/empirical-studies-of-agile-software-development-a-systematic-4kky3l7vnd.pdf

Empirical studies of agile software development: A systematic review

Software development paradigms are shifting. The development group's "team" ability, and the effects of the individual developer, become more important as organizations recognize that the traditional approach of increasing process pressure and overworking team members is not getting the job done. The pioneers of Agile methodologies question the preconceived processes within which development teams work. Rather than adding to the burden of the individual developer, Agile asks "how can we change the process so that the team is more productive, while also improving quality?" The answer is in learning to play the "game." Written for developers and project managers, Agile Software Development compares software development to a game. Team members play the game knowing that the ultimate goal is to win---always remembering what they have learned along the way, and always keeping in mind that they will never play the same way twice. Players must keep an open mind to different methodologies, and focus on the goal of developing quality software in a short cycle time.

/pdf/agile-software-development-2i0f3sexmc.pdf

Agile Software Development

Enterprise resource planning (ERP) systems and other complex information systems represent critical organizational resources. For such systems, firms typically use consultants to aid in the implementation process. Client firms expect consultants to transfer their implementation knowledge to their employees so that they can contribute to successful implementations and learn to maintain the systems independent of the consultants. This study examines the antecedents of knowledge transfer in the context of such an interfirm complex information systems implementation environment. Drawing from the knowledge transfer, information systems, and communication literatures, an integrated theoretical model is developed that posits that knowledge transfer is influenced by knowledge-related, motivational, and communication-related factors. Data were collected from consultant-and-client matched-pair samples from 96 ERP implementation projects. Unlike most prior studies, a behavioral measure of knowledge transfer that incorporates the application of knowledge was used. The analysis suggests that all three groups of factors influence knowledge transfer, and provides support for 9 of the 13 hypotheses. The analysis also confirms two mediating relationships. These results (1) adapt prior research, primarily done in non-IS contexts, to the ERP implementation context, (2) enhance prior findings by confirming the significance of an antecedent that has previously shown mixed results, and (3) incorporate new IS-related constructs and measures in developing an integrated model that should be broadly applicable to the interfirm IS implementation context and other IS situations. Managerial and research implications are discussed.

https://www.jstor.org/stable/pdfplus/25148668.pdf

Antecedents of knowledge transfer from consultants to clients in enterprise system implementations

The value of using static code attributes to learn defect predictors has been widely debated. Prior work has explored issues like the merits of "McCabes versus Halstead versus lines of code counts" for generating defect predictors. We show here that such debates are irrelevant since how the attributes are used to build predictors is much more important than which particular attributes are used. Also, contrary to prior pessimism, we show that such defect predictors are demonstrably useful and, on the data studied here, yield predictors with a mean probability of detection of 71 percent and mean false alarms rates of 25 percent. These predictors would be useful for prioritizing a resource-bound exploration of code that has yet to be inspected

/pdf/data-mining-static-code-attributes-to-learn-defect-2iiikp0sat.pdf

Data Mining Static Code Attributes to Learn Defect Predictors

Technical foundations introduction software reliability and system reliability the operational profile software reliability modelling survey model evaluation and recalibration techniques practices and experiences best current practice of SRE software reliability measurement experience measurement-based analysis of software reliability software fault and failure classification techniques trend analysis in validation and maintenance software reliability and field data analysis software reliability process assessment emerging techniques software reliability prediction metrics software reliability and testing fault-tolerant SRE software reliability using fault trees software reliability process simulation neural networks and software reliability. Appendices: software reliability tools software failure data set repository.

/pdf/handbook-of-software-reliability-engineering-32dwvaljmm.pdf

Handbook of software reliability engineering

Software organizations' main assets are not plants, buildings, or expensive machines. A software organization's main asset is its intellectual capital, as it is in sectors such asconsulting, law, investment banking, and advertising. The major problem with intellectual capital is that it has legs and walks home every day. At the same rate experience walks out the door, inexperience walks in the door. Whether or not many software organizations admit it, they face the challenge ofsustaining the level of competence needed to win contracts and fulfill undertakings.

Knowledge management in software engineering

Agile Methods are creating a buzz in the software development community, drawing their fair share of advocates and opponents. While some people consider agile methods the best thing that has happened to software development in recent years, other people view them as a backlash to software engineering and compare them to hacking. The aim of this chapter is to introduce the reader to agile methods allowing him/her to judge whether or not agile methods could be useful in modern software development. The chapter discusses the history behind agile methods as well as the agile manifesto, a statement from the leaders of the agile movement. It looks at what it means to be agile, discusses the role of management, describes and compares some of the more popular agile methods, provides a guide for deciding where an agile approach is applicable, and lists common criticisms. It summarizes empirical studies, anecdotal reports, and lessons learned from applying agile methods and concludes with an analysis of various agile methods. The target audiences for this chapter include practitioners, who will be interested in the discussion of the different methods and their applications, researchers who may want to focus on the empirical studies and lessons learned, and educators looking to teach and learn more about agile methods.

/pdf/an-introduction-to-agile-methods-5ey1qwrqde.pdf

An Introduction to Agile Methods

In recent years, the use of, interest in, and controversy about Agile methodologies have realized dramatic growth. Anecdotal evidence is rising regarding the effectiveness of agile methodologies in certain environments and for specified projects. However, collection and analysis of empirical evidence of this effectiveness and classification of appropriate environments for Agile projects has not been conducted. Researchers from four institutions organized an eWorkshop to synchronously and virtually discuss and gather experiences and knowledge from eighteen Agile experts spread across the globe. These experts characterized Agile Methods and communicated experiences using these methods on small to very large teams. They discussed the importance of staffing Agile teams with highly skilled developers. They shared common success factors and identified warning signs of problems in Agile projects. These and other findings and heuristics gathered through this valuable exchange can be useful to researchers and to practitioners as they establish an experience base for better decision making.

/pdf/empirical-findings-in-agile-methods-4rx33uzu6w.pdf

Empirical Findings in Agile Methods

The Center for Empirically Based Software Engineering helps improve software development by providing guidelines for selecting development techniques, recommending areas for further research, and supporting software engineering education. A central activity toward achieving this goal has been the running of "e- Workshops" that capture expert knowledge with a minimum of overhead effort to formulate heuristics on a particular topic. The resulting heuristics are a useful summary of the current state of knowledge in an area based on expert opinion. This paper discusses the results to date of a series of e-Workshops on software defect reduction. The original discussion items are presented along with an encapsulated summary of the expert discussion. The reformulated heuristics can be useful both to researchers (for pointing out gaps in the current state of the knowledge requiring further investigation) and to practitioners (for benchmarking or setting expectations about development practices).

/pdf/what-we-have-learned-about-fighting-defects-15zx5yxhav.pdf

What we have learned about fighting defects

As software systems become increasingly complex, the need to investigate and evaluate them at high levels of abstraction becomes more important. When systems are very complex, evaluating the system from an architectural level is necessary in order to understand the structure and interrelationships among the components of the system. There are several existing approaches available for software architecture evaluation. Some of these techniques, pre-implementation software architectural evaluations, are performed before the system is implemented. Others, implementation-oriented software architectural evaluations, are performed after a version of the system has been implemented. This chapter briefly describes the concepts of software architecture and software architectural evaluations, describes a new process for software architectural evaluation, provides results from two case studies where this process was applied, and presents areas for future work.

Mikael Lindvall

Papers

Knowledge management in software engineering

An Introduction to Agile Methods

Empirical Findings in Agile Methods

What we have learned about fighting defects

Evaluating Software Architectures