«ABSTRACT The purpose of this research study is to perform a comparison and contrast analysis on three F. Davis Cardwell published longitudinal case ...»
• In August 2003, significant areas of North America suffered a blackout of electrical power; an estimated 50 million people were affected. Ultimately, the blackout was caused by a cascade of failures; one of the critical initial events was a race condition in the monitoring and reporting software used to manage power distribution. A race condition can occur when two or more processes attempt to access the same shared data. In this particular instance, the race condition caused the monitoring and reporting software to “hang,” i.e., it stopped responding to ongoing events. (Race condition, 2012) As a result of this failure, critical events failed to trigger associated alarms and operators were unaware that anything was amiss until the entire management system crashed. (U.S. – Canada Power System Outage Task Force, 2004, pp. 60 – 63) At least 11 deaths were attributed either directly or indirectly to the blackout. Combined cost estimates for recovery and opportunity lost due to the blackout range between $4 billion and $13 billion.
Clearly, software systems can have a great impact on human life, and on the quality of human life. In this light, it is ethically appropriate that an emphasis be placed on the holistic view whenever software solutions to problems are developed, especially when the software product is critical to safety.
Generally, software can be divided into three criticality categories:
THE PERFORMANCE OF AGILE METHODS:
COMPARISON TO TRADITIONAL DEVELOPMENT METHODS
1. Non-critical systems are software systems whose failure does not affect lives, health, or business; an example is an office productivity tool, such as a word processor. In non-critical systems, failure is more properly an annoyance than a hazard.
2. Business-critical systems are systems whose failure would significantly affect business operations. The impact of a failure is described in terms of a loss of revenue or employee productivity.
3. Safety-critical systems are systems whose failure could significantly affect lives and health.
With safety-critical systems, ethics demand that all potential safety aspects of the system be considered and incorporated into the final product, despite potential negative effects on business priorities; anything less is ethically unjustifiable. (Pfleeger & Atlee, 2010, pp. 413 – 415) This study is significant, because it is important to determine the most effective way to develop software from both a business viewpoint and an ethical viewpoint. If a particular type of software development method shows evidence of being more effective at developing software products, then it is incumbent on us, as leaders in the field, to use it. Likewise, if it can be shown that a particular type of development method enables developers to more effectively evaluate the big picture and successfully mitigate potential failures, it is therefore ethically irresponsible to use anything else.
Finally, if it can be shown that the use of a particular development method results in a more positive stakeholder experience, then the use of that method is preferred over other, less satisfactory methods.
Some advantages that may be realized as a result of this research include a better understanding of various development methods, understanding of how agile methods differ from traditional methods, and an understanding of if and why one development method is superior to another. If we have a clear understanding of why a particular method is more effective than another, we can use this understanding to help business succeed in its implementation. If we discover new methods to improve the development of successful and useful software products, we can integrate these methods into our operations, thereby reaping all of the rewards associated with increased efficiency. Finally, if we can discover ways to demonstrate the effectiveness of a particular development method, it is highly likely that all affected stakeholders can be brought into accord with the method, which greatly increases the likelihood of successful software development projects. Project management experience has shown that an effective development methodology is a critical factor in the success of a project, regardless of the specific methodology used. (Schwalbe, 2011, p. 81) If the potential discoveries described in this research are explored and a more effective method for developing software is identified, it represents a win-win situation; businesses will be able to operate using processes which if properly implemented, can produce high-quality software, happy developers, and methods that are better able to predict and prevent failures. If the potential discoveries described in this research are not explored, it is certain that software will continue to be developed using less effective methods, with continuing potential for inefficient processes, wasted resources, employee burnout, environmental damage, and loss of life.
RESEARCH DESIGN AND METHODOLOGYThe data is presented in the qualitative and quantitative formats listed in the respective research questions section, using secondary data gathered from publically available sources, including such data as project summaries and published expenditure statements, industrial averages, professional journals, preexisting interviews pertaining to software development methods, and Internet sources pertaining to the use of traditional and agile software development processes.
The first section of the research study compares agile software development methods to traditional development methods, primarily using longitudinal case studies between software development projects of similar size and complexity, with additional supporting data from other sources incorporated as relevant to the topic at hand. Comparison and contrast of costs between the projects provide insights into how the methods used affect development costs.
The null-hypothesis of this
THE PERFORMANCE OF AGILE METHODS:
COMPARISON TO TRADITIONAL DEVELOPMENT METHODSsection is that there are no significant differences between development costs of traditionally developed software projects and projects developed using agile methods.
The second section of the research study compares agile software development methods to traditional development methods, using the same case study material as the first section along with additional data relevant to the problem at hand. Comparison and contrast of schedule performance between the projects provide insights into how the methods used affect the project schedule. The nullhypothesis of this section is that there are no significant differences between the schedule performance of traditionally developed software projects and projects developed using agile methods.
The third section of the research study compares agile software development methods to traditional development methods, using the same case study material as the first section along with additional data relevant to the problem at hand. Comparison and contrast of product quality between the projects will provide insights into how the methods used affect product quality. The null-hypothesis of this section is that there are no significant differences between product quality of traditionally developed software projects and projects developed using agile methods.
The fourth section of the research study compares agile software development methods to traditional development methods, using the same case study material as the first section along with additional data relevant to the problem at hand. Comparison and contrast of stakeholder satisfaction between the projects will provide insights into how the methods used affect stakeholder satisfaction. The nullhypothesis of this section is that there are no significant differences between stakeholder satisfaction of traditionally developed software projects and projects developed using agile methods.
Each section of the research study targets a specific research sub-problem. The data in each section, after exploration, should provide evidence either for or against the associated null-hypothesis. Taken together, the data should be able to illuminate the central research question; specifically, are there significant measurable differences in performance between agile development methods and traditional development methods?
ORGANIZATION OF THE STUDYChapter one, Introduction, includes the context of the problem, the statement of the problem, research questions, the significance of the study, research design and methodology, and the organization of the study. Chapter one includes all of the elements required for a Directed Research Project proposal, as delineated and required by Strayer University. (Strayer University, 2009) Chapter two, Review of the Literature, provides an overview and summary of the literature used in the research project, including government statistics, company presentations and data, and articles from peer-reviewed managerial, professional, and business journals. It explores both agile and traditional development methods, and introduces the case studies used in the research chapters to explore the research questions.
Chapter three, Research Findings, introduces the comparison framework, presents the research findings, and compares the performance of agile projects and traditional projects using development costs, schedule performance, product quality, and stakeholder satisfaction as the comparison factors.
Chapter four, Conclusion, interprets the data covered in the research project, and summarizes findings and conclusions as they relate to the research problems and sub-problems. (Leedy & Ormond, 2010, p. 297) This chapter will determine if the research answers the research questions and will explore the answers provided. It also presents suggested directions for future research, in order to increase the body of knowledge concerning agile and traditional development performance.
THE PERFORMANCE OF AGILE METHODS:COMPARISON TO TRADITIONAL DEVELOPMENT METHODS
CHAPTER 2: REVIEW OF RELATED LITERATURE
INTRODUCTION TO THE REVIEWTo provide a framework for understanding the research that follows, the chapter begins by examining the origins of software development methods, and how they have evolved as software development experience has winnowed viable methods from methods that present too many drawbacks to be practically useful. It then explores the origins and history of agile development, explores the differences between agile and traditional software development methods, describes the different types of agile methods that have emerged in response to the agile movement, and describes the reaction of the software development community to the advent of agile methods. Finally, the chapter presents the case studies used to explore the research questions.
HISTORY OF SOFTWARE DEVELOPMENT METHODSConcurrent with the advent of computers and digitally controlled systems was the birth of software development; after all, computers are not useful without software to control their functioning. (Burd, 2010, p. 44) The first software was developed using ad hoc software development methods, also known as “code and fix.” (Fowler, 2005, p. 2) In other words, the developer would develop the solution to the problem as the code was being written, without any overarching plan. This method is effective for developing solutions to simple problems, but quickly breaks down once a certain level of complexity is reached. The result of attempting to develop software solutions to complex problems using this method is often a “big ball of mud;” code components are highly coupled, lack cohesion, and are difficult or impossible to trace, troubleshoot, and modify. (Foote & Yoder, 1999, p. 2) In response to the inadequacy of ad hoc development, engineering, or plan-driven, software methodologies were developed; these methods attempted to impose the same type of discipline as that required for engineering projects, such as building a bridge, upon the software development process. (Fowler, 2005, p. 3) For the purposes of this paper, plan-driven methodologies will be referred to herein as “traditional” methods of software development.
The first of the traditional development methods was the “Waterfall” method. With the Waterfall method, the development process is divided into a series of sequential steps: Scope, requirements analysis, design, development, test, implementation, and operation & maintenance. The foundation of all the traditional software development methods is the Waterfall. (Dillman, 2003, p. 3)
Figure 1. The Waterfall Method (Dillman, 2003, p. 3)
An assumption of the Waterfall method is that the entire software development project can be planned at the beginning of development, and that each phase begins where the previous phase ends; a result of this assumption is that the Waterfall method does not support changes to the software requirements. (Dillman, 2003, p. 11) As change is inevitable in any practical project, the Waterfall method is not considered to be practically useful in its pure form.
THE PERFORMANCE OF AGILE METHODS:COMPARISON TO TRADITIONAL DEVELOPMENT METHODS
An improvement to the Waterfall method is the “V” method. The assumption of the V method is that testing activities performed after coding can be used to validate the correctness of the planning activities performed prior to coding. Any problems found during testing can be resolved by repeating the linked preceding activity; thus problems found during unit and integration testing can be resolved by returning to the program design phase, and so forth. The V method acknowledges that change will occur during software development, and provides feedback paths to make change possible. (Pfleeger & Atlee, 2010, pp. 52 – 53)
Figure 2. The V Method (Pfleeger & Atlee, 2010, p. 52)
The “Incremental” method is a variation of the Waterfall method, designed to minimize some of its drawbacks. With the Incremental method, development is divided into a series of increments, which can then be developed in parallel. The focus of each increment is in developing only a subset of the desired requirements; the process is then repeated until all of the desired functionality is in place.