Software development methodologies comparison

A software development methodology refers to the framework that is used to structure, plan, and control the process of developing a software system. A wide variety of such software development frameworks have evolved over the years, each with its own recognized strengths and weaknesses.

A software development methodology is a way of managing a software development project. A software development method typically address issues like selecting features for inclusion in the current version, when software will be released, who works on what, and what testing is done.

In practice, every organization implements their software development project management in different ways, which is often slightly different from one project to the next. Nonetheless, nearly all are using some subset or combination of the ones discussed here.

Most modern development processes can be vaguely described as agile. Other methodologies include waterfall, prototyping, iterative and incremental development, spiral development, rapid application development, and extreme programming.

Traditional software development methodologies such as “Waterfall” that have distinct phases are sometimes known as software development life cycle (SDLC) methodologies, though this term could also be used more generally to refer to any methodology.

A “life cycle” approach with distinct phases is in contrast to Agile software development approaches which define a process of iteration, but where design, construction, and deployment of different pieces can occur simultaneously.

One software development methodology is not necessarily suitable for use by all projects. Each of the available software development methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.

Here each of the major prescribed software development methodologies are considered in context with business, applications, organization, and technical environments.

Waterfall Software Development Method

The Waterfall software development method is a sequential development approach, in which development is seen as flowing steadily downwards (like a waterfall) through several phases, typically:

Requirements analysis resulting in a software requirements specification
Software design
Implementation
Testing
Integration, if there are multiple subsystems
Deployment (or Installation)
Maintenance

The waterfall model is a traditional engineering approach applied to software engineering. A strict waterfall approach discourages revisiting and revising any prior phase once it is complete. This “inflexibility” in a pure waterfall model has been a source of criticism by supporters of other more “flexible” models.

The Waterfall software development method has been widely blamed for several large-scale government projects running over budget, over time and sometimes failing to deliver on requirements due to the Big Design Up Front approach.

Except when contractually required, the waterfall model has been largely superseded by more flexible and versatile methodologies developed specifically for software development.

Software development framework type: Linear

Waterfall Software Development Method Basic Principles:

Project is divided into sequential phases, with some overlap and splashback acceptable between phases.
Emphasis is on planning, time schedules, target dates, budgets and implementation of an entire system at one time.
Tight control is maintained over the life of the project through the use of extensive written documentation, as well as through formal reviews and approval/signoff by the user and information technology management occurring at the end of most phases before beginning the next phase.

Waterfall Software Development Method Strengths:

Ideal for supporting less experienced project teams and project managers, or project teams whose composition fluctuates.
The orderly sequence of development steps and strict controls for ensuring the adequacy of documentation and design reviews helps ensure the quality, reliability, and maintainability of the developed software.
Progress of system development is measurable.
Conserves resources.

Waterfall Software Development Method Weaknesses:

Inflexible, slow, costly and cumbersome due to significant structure and tight controls.
Project progresses forward, with only slight movement backward.
Little room for use of iteration, which can reduce manageability if used.
Depends upon early identification and specification of requirements, yet users may not be able to clearly define what they need early in the project.
Requirements inconsistencies, missing system components, and unexpected development needs are often discovered during design and coding.
Problems are often not discovered until system testing.
System performance cannot be tested until the system is almost fully coded, and under capacity may be difficult to correct.
Difficult to respond to changes. Changes that occur later in the life cycle are more costly and are thus discouraged.
Produces excessive documentation and keeping it updated as the project progresses is time-consuming.
Written specifications are often difficult for users to read and thoroughly appreciate.
Promotes the gap between users and developers with clear division of responsibility.

Situations where the Waterfall Software Development Method is most appropriate:

Project is for development of a mainframe-based or transaction-oriented batch system.
Project is large, expensive, and complicated.
Project has clear objectives and solution.
Pressure does not exist for immediate implementation.
Project requirements can be stated unambiguously and comprehensively.
Project requirements are stable or unchanging during the system development life cycle.
User community is fully knowledgeable in the business and application.
Team members may be inexperienced.
Team composition is unstable and expected to fluctuate.
Project manager may not be fully experienced.
Resources need to be conserved.
Strict requirement exists for formal approvals at designated milestones.

Situations where the Waterfall Software Development Method is least appropriate:

Large projects where the requirements are not well understood or are changing for any reasons such as external changes, changing expectations, budget changes or rapidly changing technology.
Web Information Systems (WIS) primarily due to the pressure of implementing a WIS project quickly; the continual evolution of the project requirements; the need for experienced, flexible team members drawn from multiple disciplines; and the inability to make assumptions regarding the users’ knowledge level.
Real-time systems
Event-driven systems
Leading-edge applications

Prototyping Software Development Method

Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed.

The process of prototyping software involves the following steps:

Identify basic requirements -
Determine basic requirements including the input and output information desired. Details, such as security, can typically be ignored.
Develop initial prototype - The initial prototype is developed that includes only user interfaces.
Review the prototype - The customers, including end-users, examine the prototype and provide feedback on potential additions or changes.
Revise and enhance the prototype - Using the feedback both the specifications and the prototype can be improved. Negotiation about what is within the scope of the contract/product may be necessary. If changes are introduced then a repeat of steps #3 and #4 may be needed.

Software development framework type: Iterative

Prototyping Software Development Method Basic Principles:

Not a standalone, complete development methodology, but rather an approach to handling selected portions of a larger, more traditional development methodology (i.e., Incremental, Spiral, or Rapid Application Development (RAD)).
Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
User is involved throughout the process, which increases the likelihood of user acceptance of the final implementation.
Small-scale mock-ups of the system are developed following an iterative modification process until the prototype evolves to meet the users’ requirements.
While most prototypes are developed with the expectation that they will be discarded, it is possible in some cases to evolve from prototype to working system.
A basic understanding of the fundamental business problem is necessary to avoid solving the wrong problem.

Prototyping Software Development Method Strengths:

“Addresses the inability of many users to specify their information needs, and the difficulty of systems analysts to understand the user’s environment, by providing the user with a tentative system for experimental purposes at the earliest possible time.” (Janson and Smith, 1985)
“Can be used to realistically model important aspects of a system during each phase of the traditional life cycle.” (Huffaker, 1986)
Improves both user participation in system development and communication among project stakeholders.
Especially useful for resolving unclear objectives; developing and validating user requirements; experimenting with or comparing various design solutions; or investigating both performance and the human computer interface.
Potential exists for exploiting knowledge gained in an early iteration as later iterations are developed.
Helps to easily identify confusing or difficult functions and missing functionality.
May generate specifications for a production application.
Encourages innovation and flexible designs.
Provides quick implementation of an incomplete, but functional, application.

Prototyping Software Development Method Weaknesses:

Approval process and control is not strict.
Incomplete or inadequate problem analysis may occur whereby only the most obvious and superficial needs will be addressed, resulting in current inefficient practices being easily built into the new system.
Requirements may frequently change significantly.
Identification of non-functional elements is difficult to document.
Designers may prototype too quickly, without sufficient up-front user needs analysis, resulting in an inflexible design with narrow focus that limits future system potential.
Designers may neglect documentation, resulting in insufficient justification for the final product and inadequate records for the future.
Can lead to poorly designed systems. Unskilled designers may substitute prototyping for sound design, which can lead to a “quick and dirty system” without global consideration of the integration of all other components. While initial software development is often built to be a “throwaway”, attempting to retroactively produce a solid system design can sometimes be problematic.
Can lead to false expectations, where the customer mistakenly believes that the system is “finished” when in fact it is not; the system looks good and has adequate user interfaces, but is not truly functional.
Iterations add to project budgets and schedules, thus the added costs must be weighed against the potential benefits. Very small projects may not be able to justify the added time and money, while only the high-risk portions of very large, complex projects may gain benefit from prototyping.
Prototype may not have sufficient checks and balances incorporated.

Situations where most the Prototyping Software Development Method is appropriate:

Project is for development of an online system requiring extensive user dialog, or for a less well-defined expert and decision support system.
Project is large with many users, interrelationships, and functions, where project risk relating to requirements definition needs to be reduced.
Project objectives are unclear.
Pressure exists for immediate implementation of something.
Functional requirements may change frequently and significantly.
User is not fully knowledgeable.
Team members are experienced (particularly if the prototype is not a throw-away).
Team composition is stable.
Project manager is experienced.
No need exists to absolutely minimize resource consumption.
No strict requirement exists for approvals at designated milestones.
Analysts/users appreciate the business problems involved, before they begin the project.
Innovative, flexible designs that will accommodate future changes are not critical.

Situations where the Prototyping Software Development Method is least appropriate:

Mainframe-based or transaction-oriented batch systems.
Web-enabled e-business systems.
Project team composition is unstable.
Future scalability of design is critical.
Project objectives are very clear; project risk regarding requirements definition is low.

Incremental / Interative Software Development Method

The basic idea behind the Incremental Software Development Method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system.

Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added

With the incremental software development method the product is designed, implemented and tested incrementally (a little more is added each time) until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping.

Software development framework type: Combination Linear and Iterative

Incremental Software Development Method Basic Principles:

Various methods are acceptable for combining linear and iterative system development methodologies, with the primary objective of each being to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process:

A series of mini-Waterfalls are performed, where all phases of the Waterfall development model are completed for a small part of the system, before proceeding to the next increment; OR
Overall requirements are defined before proceeding to evolutionary, mini-Waterfall development of individual increments of the system, OR
The initial software concept, requirements analysis, and design of architecture and system core are defined using the Waterfall approach, followed by iterative Prototyping, which culminates in installation of the final prototype (i.e., working system).

Incremental Software Development Method Strengths:

Potential exists for exploiting knowledge gained in an early increment as later increments are developed.
Moderate control is maintained over the life of the project through the use of written documentation and the formal review and approval/signoff by the user and information technology management at designated major milestones.
Stakeholders can be given concrete evidence of project status throughout the life cycle.
Helps to mitigate integration and architectural risks earlier in the project.
Allows delivery of a series of implementations that are gradually more complete and can go into production more quickly as incremental releases.
Gradual implementation provides the ability to monitor the effect of incremental changes, isolate issues and make adjustments before the organization is negatively impacted.

Incremental Software Development Method Weaknesses:

When utilizing a series of mini-Waterfalls for a small part of the system before moving on to the next increment, there is usually a lack of overall consideration of the business problem and technical requirements for the overall system.
Since some modules will be completed much earlier than others, well-defined interfaces are required.
Difficult problems tend to be pushed to the future to demonstrate early success to management.

Situations where the Incremental Software Development Method is most appropriate:

Large projects where requirements are not well understood or are changing due to external changes, changing expectations, budget changes or rapidly changing technology.
Web Information Systems (WIS) and event-driven systems.
Leading-edge applications.

Situations where the Incremental Software Development Method least appropriate:

Very small projects of very short duration.
Integration and architectural risks are very low.
Highly interactive applications where the data for the project already exists (completely or in part), and the project largely comprises analysis or reporting of the data.

Spiral Software Development Method

In 1988, Barry Boehm published a formal software system development “spiral model,” which combines some key aspect of the waterfall model and rapid prototyping methodologies, in an effort to combine advantages of top-down and bottom-up concepts. It provided emphasis in a key area many felt had been neglected by other software development methodologies: deliberate iterative risk analysis, particularly suited to large-scale complex systems.

In the Spiral Software development method focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle.

Each trip around the spiral traverses four basic quadrants:

Determine objectives, alternatives, and constraints of the iteration
Evaluate alternatives; Identify and resolve risks
Develop and verify deliverables from the iteration
Plan the next iteration

Software development framework type: Combination Linear and Iterative

Spiral Software Development Method Basic Principles:

Focus is on risk assessment and on minimizing project risk by breaking a project into smaller segments and providing more ease-of-change during the development process, as well as providing the opportunity to evaluate risks and weigh consideration of project continuation throughout the life cycle.
Each cycle involves a progression through the same sequence of steps, for each portion of the product and for each of its levels of elaboration, from an overall concept of operation document down to the coding of each individual program.
Each trip around the spiral traverses four basic quadrants: (1) determine objectives, alternatives, and constraints of the iteration; (2) evaluate alternatives; identify and resolve risks; (3) develop and verify deliverables from the iteration; and (4) plan the next iteration.
Begin each cycle with an identification of stakeholders and their win conditions, and end each cycle with review and commitment.

Spiral Software Development Method Strengths:

Enhances risk avoidance.
Useful in helping to select the best methodology to follow for development of a given software iteration, based on project risk.
Can incorporate Waterfall, Prototyping, and Incremental methodologies as special cases in the framework, and provide guidance as to which combination of these models best fits a given software iteration, based upon the type of project risk. For example, a project with low risk of not meeting user requirements, but high risk of missing budget or schedule targets would essentially follow a linear Waterfall approach for a given software iteration. Conversely, if the risk factors were reversed, the Spiral methodology could yield an iterative Prototyping approach.

Spiral Software Development Method Weaknesses:

Challenging to determine the exact composition of development methodologies to use for each iteration around the Spiral.
Highly customized to each project, and thus is quite complex, limiting reusability.
A skilled and experienced project manager is required to determine how to apply it to any given project.
There are no established controls for moving from one cycle to another cycle. Without controls, each cycle may generate more work for the next cycle.
There are no firm deadlines. Cycles continue with no clear termination condition, so there is an inherent risk of not meeting budget or schedule.
Possibility exists that project ends up implemented following a Waterfall framework.

Situations where the Spiral Software Development Method is most appropriate:

Real-time or safety-critical systems.
Risk avoidance is a high priority.
Minimizing resource consumption is not an absolute priority.
Project manager is highly skilled and experienced.
Requirement exists for strong approval and documentation control.
Project might benefit from a mix of other development methodologies.
A high degree of accuracy is essential.
Implementation has priority over functionality, which can be added in later versions.

Situations where the Spiral Software Development Method is least appropriate:

Risk avoidance is a low priority.
A high degree of accuracy is not essential.
Functionality has priority over implementation.
Minimizing resource consumption is an absolute priority.

Rapid Application Development (RAD) Software Development Method

Rapid application development (RAD) is a software development methodology, which favors iterative development and the rapid construction of prototypes instead of large amounts of up-front planning. The “planning” of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

The rapid development process starts with the development of preliminary data models and business process models using structured techniques. In the next stage, requirements are verified using prototyping, eventually to refine the data and process models. These stages are repeated iteratively; further development results in “a combined business requirements and technical design statement to be used for constructing new systems

Software development framework type: Iterative

Rapid Application Development (RAD) Software Development Method Basic Principles:

Key objective is for fast development and delivery of a high quality system at a relatively low investment cost.
Attempts to reduce inherent project risk by breaking a project into smaller segments and providing more ease-of-change during the development process.
Aims to produce high quality systems quickly, primarily through the use of iterative Prototyping (at any stage of development), active user involvement, and computerized development tools. These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-generation programming languages, code generators, and object-oriented techniques.
Key emphasis is on fulfilling the business need, while technological or engineering excellence is of lesser importance.
Project control involves prioritizing development and defining delivery deadlines or “timeboxes”. If the project starts to slip, emphasis is on reducing requirements to fit the timebox, not in increasing the deadline.
Generally includes Joint Application Development (JAD), where users are intensely involved in system design, either through consensus building in structured workshops, or through electronically facilitated interaction.
Active user involvement is imperative.
Iteratively produces production software, as opposed to a throwaway prototype.
Produces documentation necessary to facilitate future development and maintenance.
Standard systems analysis and design techniques can be fitted into this framework.

Rapid Application Development Method Strengths:

The operational version of an application is available much earlier than with Waterfall, Incremental, or Spiral frameworks.
Because RAD produces systems more quickly and to a business focus, this approach tends to produce systems at a lower cost.
Engenders a greater level of commitment from stakeholders, both business and technical, than Waterfall, Incremental, or Spiral frameworks. Users are seen as gaining more of a sense of ownership of a system, while developers are seen as gaining more satisfaction from producing successful systems quickly.
Concentrates on essential system elements from user viewpoint.
Provides the ability to rapidly change system design as demanded by users.
Produces a tighter fit between user requirements and system specifications.
Generally produces a dramatic savings in time, money, and human effort.

Rapid Application Development Method Weaknesses:

More speed and lower cost may lead to lower overall system quality.
Danger of misalignment of developed system with the business due to missing information.
Project may end up with more requirements than needed (gold-plating).
Potential for feature creep where more and more features are added to the system over the course of development.
Potential for inconsistent designs within and across systems.
Potential for violation of programming standards related to inconsistent naming conventions and inconsistent documentation.
Difficulty with module reuse for future systems.
Potential for designed system to lack scalability.
Potential for lack of attention to later system administration needs built into system.
High cost of commitment on the part of key user personnel.
Formal reviews and audits are more difficult to implement than for a complete system.
Tendency for difficult problems to be pushed to the future to demonstrate early success to management.
Since some modules will be completed much earlier than others, well-defined interfaces are required.

Situations where Rapid Application Development is most appropriate:

Project is of small-to-medium scale and of short duration (no more than 6 man-years of development effort).
Project scope is focused, such that the business objectives are well defined and narrow.
Application is highly interactive, has a clearly defined user group, and is not computationally complex.
Functionality of the system is clearly visible at the user interface.
Users possess detailed knowledge of the application area.
Senior management commitment exists to ensure end-user involvement.
Requirements of the system are unknown or uncertain.
It is not possible to define requirements accurately ahead of time because the situation is new or the system being employed is highly innovative.
Team members are skilled both socially and in terms of business.
Team composition is stable; continuity of core development team can be maintained.
Effective project control is definitely available.
Developers are skilled in the use of advanced tools.
Data for the project already exists (completely or in part), and the project largely comprises analysis or reporting of the data.
Technical architecture is clearly defined.
Key technical components are in place and tested.
Technical requirements (e.g., response times, throughput, database sizes, etc.) are reasonable and well within the capabilities of the technology being used. Targeted performance should be less than 70% of the published limits of the technology.
Development team is empowered to make design decisions on a day-to-day basis without the need for consultation with their superiors, and decisions can be made by a small number of people who are available and preferably co-located.

Situations where Rapid Application Development is least appropriate:

Very large, infrastructure projects; particularly large, distributed information systems such as corporate-wide databases.
Real-time or safety-critical systems.
Computationally complex systems, where complex and voluminous data must be analyzed, designed, and created within the scope of the project.
Project scope is broad and the business objectives are obscure.
Applications in which the functional requirements have to be fully specified before any programs are written.
Many people must be involved in the decisions on the project, and the decision makers are not available on a timely basis or they are geographically dispersed.
The project team is large or there are multiple teams whose work needs to be coordinated.
When user resource and/or commitment is lacking.
There is no project champion at the required level to make things happen.
Many new technologies are to be introduced within the scope of the project, or the technical architecture is unclear and much of the technology will be used for the first time within the project.
Technical requirements (e.g., response times, throughput, database sizes, etc.) are tight for the equipment that is to be used.

Learn more about choosing a software development method

References:

Software development process

Software Development Methodologies by Marcel Douwe Dekker, CC BY-SA 3.0 https://creativecommons.org/licenses/by-sa/3.0, based on Selecting a development approach at cms.hhs.gov.

How to Choose a Software Development Methodology