Comparing Software Development Methodologies: A SWOT Analysis

Introduction and Problem Statement

This paper examines three different software processing methodologies: the Waterfall model, the Iterative model, and the V-Model. Each methodology is discussed at length to develop a clear understanding of its similarities and differences with the others. The paper focuses on gaining a solid understanding of each methodology and identifying when it is best to utilize each one. Each serves a special purpose, and the process of understanding the problem one must solve remains as complicated as actually solving the problem itself. This work investigates the intricacies required to formulate the problem while also selecting the appropriate methodology, analyzing the pros and cons of each in relation to the problem being solved. The pure nature of the problem will not only dictate which methodology to use, but also clarify why — and the "why" is critical to providing a sound response.

This work also provides an analysis of historical projects and examines their chosen methodology, offering a complete breakdown of the thought process for entering a methodology as well as an examination and summary of the life cycle model based on the chosen approach. Each methodology section concludes with a summary of possible different outcomes had another methodology been selected to solve the same problem.

The end goal of this work is to provide new entrance criteria for selecting a software processing methodology based on the nature of the problem. Given the breadth of available software processing methodologies, this work focuses specifically on the requirements element of each model.

The central question is: how does one determine which software processing methodology provides the optimal delivery of a complex solution with regard to functionality, cost, schedule, and quality — collectively known as the quad constraint (PMI, 2007)? The quad constraint, also known as the triple constraint, is one of the most important concepts in project management. Reis (2008) noted that executing a given project involves altering three or four legs of a "stool" comprising cost, time, functionality, and quality. A change in functionality leads to an increase in project cost and time — an alteration in one leg necessarily changes the others. This paper examines three different software processing methodologies with the end goal of developing a model that predicts which methodology should be used to deliver a given solution.

Deploying a solution that optimizes the quad constraint is crucial to the survival of all companies. The quantitative portion of this work focuses on the requirements aspects of each model, though a full understanding of each model is required. Requirements are the cornerstones of a successful project. Failure to produce and deliver accurate, high-quality requirements is the primary cause of project failure with respect to the quad constraint. This work will not attempt to reprove the value of software processes but will instead rely on already established findings, examining the various models to build background understanding and setting the stage for a final selection model.

The extended technical question that drives the overall thought process centers on what solution works best in the current customer environment to deliver and support the end solution within the overall strategic business case. Companies struggle with understanding the multitude of approaches available for delivering a complex technical solution. When choosing a methodology, organizations must consider available resources — people, processes, and technology — within a given environment. The combination of building and maintaining a solution within cost and revenue guidelines causes most IT leaders to proceed with caution on any technical decision, let alone the choice of methodology. The focus of this paper is to help those leaders choose the best methodology to ensure success.

The importance of this problem lies in improving the number of successful project deliveries within the quad constraint. Projects always deliver; that is not the concern. Optimizing delivery and reducing overall costs to improve revenue are the motivating factors behind selecting the best-fit methodology. The goal is to help organizations select the right methodology and ramp up resources to drive the requirements phase of the project. Focusing delivery using the best-fit methodology has proven to reduce costs and provide a higher-quality solution.

This work utilizes both academic and corporate theory to define a new set of entrance criteria for selecting the model best suited to solve a given problem. The approach of the paper is organized as follows:

Introduction and Setup the Problem (Theory): Provided in Section I, this sets the stage for the problem being solved and includes the rationale behind the work.

Analysis of Three Software Methodologies (Theory): Provided in Section II, this section defines the three methodologies along with a SWOT analysis for each. It concludes with recommendations for beginning the definition of data points required to build the predictive model for methodology selection.

Software Processing Methodologies Overview

Define Measurement Data Points for Test Case Analysis (Theory plus Practical): Provided in Section III, this section evaluates six completed complex technical solutions using each of the models. The solutions are similar in nature for a more comprehensive result and define the data points for the predictive model.

Creation and Validation of the Predictive Model (Practical): Provided in Section IV, this is the mathematical representation — implemented in Excel — that provides a methodology recommendation based on the input parameters and data points defined in Section III. The model will review and determine whether to use semantic modeling, UML, SysML, or a combination.

Waterfall Methodology

Conclusion: This section provides a summary analysis of the findings as they relate to the research and discusses practical usage of the model in both corporate and academic environments.

Textbooks, internet articles, current and past work experience, interviews with colleagues, and discussions with industry experts will guide and shape the outcome of this work. The plan includes working with corporations, universities, and government agencies to acquire completed projects for analysis against each methodology.

The predictive model will also be applied within the author's current company and tested against new projects on the horizon. The goal is to have three small projects created from start to finish using each of the three methodologies and to determine whether the predictive model can be validated in a controlled sample.

Developing a system development methodology means structuring, controlling, and planning the development of an information system (CMS, 2005). Numerous frameworks have been developed over the years, each exhibiting unique recognized strengths and weaknesses. Not all system processing methodologies are equally good fits for all projects. The real focus, therefore, is not which methodology fails to fit, but rather which is the most optimal fit. This section explores the Waterfall, Iterative, and V-Model methodologies, with the end goal of identifying the data points required in Section III.

The Waterfall methodology is a sequential software development model for the entire solution (SBS, 2011). It requires significant upfront activity and clearly defined requirements. While some software development teams criticize the Waterfall methodology as cumbersome and slow, it provides an orderly sequence of developmental steps that ensure design, reviews, and documentation meet standards of quality, reliability, and maintainability (Chapman, 1997). Key factors in the Waterfall methodology are products and processes (MIT, 2002).

All projects are better managed when broken down into a hierarchy of phases, with some overlap permitted between them. Other divisions of project work include stages, tasks, activities, and steps. The simplistic rendition used in system development projects — the Waterfall methodology — focuses on time schedules, planning, budgeting, and full-system implementation at a single time. Extensive written documentation is used to maintain tight control over the project throughout its entire lifespan. The Waterfall methodology has seven products: communicated requirements, requirements specification document, design specification document, executable software models, integrated software product, delivered software product, and changed requirements (QTP Blog, 2009). This also includes approvals or sign-offs at the beginning of each new project phase.

It is important to note that the Waterfall model embodies several crucial principles of a sound methodology: working in stages, conducting content reviews between stages, reviewing decision points, and establishing quality gates for continuation. In terms of modeling, input and output parameters for each phase are assigned a numerical value as they relate to the final data points.

The Waterfall methodology is suitable for applications with inexperienced project teams or management with less experience, or in situations where the composition of the project team fluctuates. In such scenarios, it supports continuity of software development effectively. When strict controls are combined with an orderly sequence and design reviews, the maintainability, quality, and reliability of the developed software are assured. In addition to conserving resources, the Waterfall methodology ensures that every stage of system development progress is measurable by the team or managers. It requires that the problem be well understood and that requirements be well defined before work begins.

Due to its tight controls and significant structure, the Waterfall methodology is rigid, cumbersome, costly, and slow as a method of system development. As development progresses, there are usually very few opportunities to step backward. Because users may not be able to clearly articulate what they need in the initial stages of a project, this methodology may be unsuitable due to its dependence on early specification and identification of requirements.

This methodology is often characterized by missing components, unexpected development needs, and inconsistencies that are only discovered during system design and coding. Most problems go undetected until the system testing stage, which may be too late to address efficiently. System performance cannot be tested until completion, and underperformance may be difficult to correct; any changes that are made occur very late in the life cycle and are therefore more costly. The methodology also involves numerous documentation steps, which makes it difficult to update as development continues. Finally, the Waterfall methodology widens the gap between developers and users through a clear division of responsibilities.

One of the widespread uses of this methodology is in the development of transaction-oriented batch systems or mainframe-based systems (CMS, 2008). It also finds application where a large, complicated, and expensive program is to be developed with clear solutions and objectives. The methodology is a good fit in situations where there is no pressure for immediate implementation of the developed software and where project requirements are stable and do not change throughout development. Its applicability is also valued when the user community is fully knowledgeable about the application and business domain of the developed program. Similarly, it is appropriate when team members are inexperienced with software development or when the development team is expected to fluctuate due to labor mobility.

This methodology is not appropriate for large projects where requirements are not well understood or are subject to change — whether due to shifting expectations, external factors, budget changes, or rapid technological advancement — since it is a less flexible process that does not accommodate dynamism (CMS, 2008). The Waterfall methodology also struggles when applied to Web Information Systems, which are typically characterized by pressure for quick implementation, the need for a flexible and experienced cross-disciplinary team, and constantly evolving requirements. The methodology cannot be readily applied to real-time, event-driven systems or applications requiring leading-edge technology. A further challenge lies in partially implementing the rigor required for Waterfall, which causes an immediate departure from the process without a clean way to recover.