Software Development Methodologies Timeline

Updated on July 15, 2022

Throughout the years, various software development methodologies have been introduced with the intention to help professionals capitalize on the available technologies and resources. Based on a blend of design philosophies and pragmatism that stems back to the early days of computing, each methodology aims at providing a systematic approach to software development in order to carry out better related projects.

In today’s dynamic IT environment, most companies agree that employing a software development methodology is crucial as it clearly establishes how information is shared within a team and enables developers to work together more efficiently.

To help you get a better understanding of how the most significant methods emerged in software development, we’ve created the present blog post, which includes a visual timeline that illustrates the evolution of the field from the 1960s. The timeline categorizes each software methodology into a primary class that includes Agile, Structured Programming, Object Oriented, Waterfall, Engineering and Team paradigms.

History of Software Development Methodologies: a timeline

• 1968: Structured Programming Paradigm
• 1974: Cap Gemini System Development Methodology (SDM)
• 1980: Structured Systems Analysis and Design Method (SSADM)
• 1985: Soft Systems Methodology (SSM)
• 1990: Rapid Application Development (RAD)
• 1992: Object-Oriented Programming (OOP)
• 1994: Dynamic Systems Development Method (DSDM)
• 1995: SCRUM Methodology
• 1998: Team Software Process (TSP)
• 1998: Rational Unified Process (RUP)
• 1999: Extreme Programming (XP)
• 1999: Unified Software Development Process (USDP)
• 2005: Agile Unified Process (AUP)
• 2008: Disciplined Agile Delivery (DAD)
• 2011: Scaled Agile Framework (SAFe)
• 2013: Large-Scale-Scrum (LeSS)

Before we take a look at the main software development paradigms and models, let’s see why it is important to apply a chosen methodology.

Why use and adhere to software development methodology?

Simply put, a software development methodology provides a guided approach to building software and apps and ensures discipline when dealing with a project’s workload. Without a well-defined direction, developers risk being exposed to a customer’s ever-changing requests, which might involve frequent revision of work without consideration to the overall implications of the project. This, in turn, can lead to a waste of time, money, and effort with a high likelihood of yielding a subpar result.

Developed to help both the development team and customers, a clear software development methodology will make sure that:

• discussions are conducted on the appropriate channels;
• decisions are made after assessing all relevant factors;
• inefficiencies are identified and cut down;
• the delivery timeline is more accurate;
• development teams react to spontaneous changes in an organized and structured manner.

Types of software development methodologies

Here is a chronological overview of the best-known software development methodologies employed since the 1960s.

1968: Structured Programming

Emerged in the late 1950s, structured programming is a paradigm developed to improve the clarity, quality, and delivery time of a computer program. At its core, it relies on the use of block structures, subroutines, and structured control flow constructs of selection (if/then/else) and repetition (while and for).

Based on the ALGOL 58 and ALGOL 60 programming languages, the structured programming methodology gained widespread acceptance in 1968, after the publication of the “Go To Statement Considered Harmful” open letter written by Dutch computer scientist Edsger W. Dijkstra, who also coined the term “structured programming.”

1974: Cap Gemini System Development Methodology (SDM)

Introduced by the software company Pandata in the Netherlands in the 1970s, Cap Gemini SDM is a waterfall top-down model based on the works of Steven Ward, Tom Demarco, Larry Constantine, Ken Orr, Ed Yourdon, Michael A. Jackson, as well as data modeling techniques developed by Thomas Bachmann and Peter Chen.

The method uses 7 successively executed phases:

1. Information planning – problem definition and initial plan;
2. Definition study – analysis of requirements and revised plan;
3. Basic design – high-level technical design and revised plan;
4. Detailed design – building the system and revised plan;
5. Realization – testing and acceptance;
6. Implementation – installation, data conversion, and cut-over production;
7. Operation and support – delivery to ICT support department.

1980: Structured Systems Analysis and Design Method (SSADM)

Produced for the UK government office of Central Computer and Telecommunications Agency in the 1980s, the Structured Systems Analysis and Design Method is a waterfall methodology for the analysis and design of information systems.

It uses the following main techniques:

• Logical data modelling – the process of identifying, modelling, and documenting the data requirements of the system being designed. The output of this technique is a data model that contains entities, attributes, and relationships.
• Data flow modelling – the process of defining and documenting how data moves around an information system. It examines processes, data stores, external entities, and data flows.
• Entity event modelling – the process of identifying, modelling, and documenting the events that affect each entity in their sequential order, as well as designing a process for each of the identified events.

1985: Soft Systems Methodology (SSM)

Developed in England by academics at the Lancaster University Systems Department within a 10-year action research program, the Soft Systems Methodology (SSM) is an approach to organizational process modelling. It is primarily used in the analysis of complex situations (“soft problems”) where there are differing views about the definition of a problem.

An example of a soft problem where SSM proves useful is “How to manage disaster planning?” or “How to improve health services delivery?” To manage such an instance, the soft system approach uses the concept of a “system” as an interrogative element that enables debate among the involved parties.

When first presented, the SSM was described as a cluster of 7 activities in a circular learning process called the seven-stage model. The 7 stages are:

1. Enter problematic situation.
2. Define the problem situation.
3. Express root definition of relevant systems of purposeful activity.
4. Build conceptual model of the systems defined above.
5. Compare models with real-world situations.
6. Identify changes that are feasible.
7. Take action to implement changes.

1990: Rapid Application Development (RAD)

Created as an alternative to the more rigid, plan-driven waterfall processes such as the Structured Systems Analysis and Design Method, the Rapid Application Development model encompasses a variety of approaches that focus less on planning and more on creating adaptive processes. Developed by James Martin in the 1980s at IBM, RAD was finally formalized with the publication of his book “Rapid Application Development” in 1991.

A 4-step framework that includes defining project requirements, prototyping, testing, and implementation, RAD is particularly well-suited for developing software that is driven by user interface requirements. Unlike linear models where an initial plan is rigidly followed and change is discouraged, Rapid Application Development emphasizes building prototypes with the given requirements and testing them out with the customer. This is done through several iterations until the client is happy with the results.

1992: Object-Oriented Programming (OOP)

Although developed in the early 1960s, object-oriented programming became a dominant programming approach in the early 1990s. It is based on the concepts of objects, which can refer to:

• data in the form of fields (also known as attributes or properties);
• or code in the form of procedures (also known as methods).

The basic feature of the OOP paradigm is that computer programs are made out of objects that interact with one another through procedures that are attached to them so that they can modify an object’s data fields.

Among the best-known object-oriented programming languages are Java, C++, Python, PHP, VisualBasic.NET, Perl, MATLAB, and Smalltalk.

1994: Dynamic Systems Development Method (DSDM)

First released in 1994, the dynamic systems development method (DDSM) is an agile project delivery framework that was initially used as a software development method. The DSDM model inherits many of its principles from the Rapid Application Development framework and aims to ensure the prompt delivery and efficient alignment of project goals to the business needs.

Featuring four iterative phases of feasibility and business study, functional model, design & build, and implementation, DSDM relies on:

• processes where end users are greatly involved in providing feedback,
• and also on detailed documentation, which is lacking from most Agile frameworks.

1995: SCRUM Methodology

Arguably one of the most flexible software development methodologies available, SCRUM is based on the Agile philosophy of breaking tasks into short sprints that take about 1 to 4 weeks to complete. The main agents in a SCRUM environment are the Product Owner, the SCRUM Master, and the Development Team.

The product owner is responsible with taking input from the client and ensuring the team is on track in fulfilling the client’s requirements. The Scrum Master acts as a mediator and familiarizes the team members with the SCRUM processes, while the team takes charge of executing the actual development work.

Due to its incremental and iterative execution cycles, the SCRUM methodology allows teams to identify issues, introduce solutions, test, and act on feedback in a speedy manner that favors fast-paced projects.

1998: Team Software Process Methodology (TSP)

Piloted by Watts Humphrey in the late 1990s, the team software process (TSP) proposes a defined operational process framework designed to help software development teams organize work and produce results for projects that range from small to very large ones. Focusing on methods of how to better meet costs and schedule commitments of developing a software system, TSP is intended to improve a team’s levels of quality and productivity within any related project.

The Technical Report for TSP was sponsored by the U.S. Department of Defense and was published in November 2000. A comprehensive overview of this methodology is presented in Watts Humphrey’s book “Introduction to Team Software Process” and its main tenets are:

• effectively building a software production team;
• establishing team goals;
• distributing team roles and other teamwork-related activities.

1998: Rational Unified Process (RUP)

Created by IBM’s division called Rational Software Corporation in 2003, the Rational Unified Process (RUP) is an iterative software development process framework designed to be tailored by development organizations and software teams to fit a specific set of needs by selecting only certain elements of the process.

RUP includes a hyperlinked knowledge base with sample artifacts and detailed descriptions for a variety of different activities that users can selectively customize to suit their requirements. The original versions of this framework were refined by Phillippe Kruchten, an experienced technical representative from Rational Software Corporation. The resulting model was based on a strategic tripod:

• a tailorable process that guides development;
• tools that automate the application of the process;
• services that enhance and accelerate the adoption of both the process and the tools.

1999: Extreme Programming (XP)

A software development methodology aimed at improving software quality and responsiveness to changing customer requirements, the extreme programming method uses frequent releases in short developmental cycles so that new customer requirements can be regularly adopted.

Here are some other characteristics of extreme programming:

• programming in pairs or doing extensive code review;
• unit testing of all code;
• programming features only when they are needed;
• a flat management structure;
• code simplicity and clarity;
• frequent communication with the customer and among programmers.

1999: Unified Software Development Process (USDP)

The Unified Software Development Process, also known as the Unified Process, is an iterative and incremental process framework for software development teams. The most extensively documented refinement of the Unified Process is the Rational Unified Process (RUP).

Unified Process characteristics:

• Iterative and incremental process with elaboration, construction, and transition as its three main phases. All phases are divided into a series of timeboxed iterations, with each iteration resulting in an increment. The increment represents a release of the system that boasts added or improved functionality compared with the previous release.
• Architecture-centric – placing architecture at the heart of a project team’s efforts to shape a system, USDP supports multiple architectural models and views rather than championing a single one to cover all aspects of the system.
• Risk-focused – the USDP framework requires that the most critical risks be addressed as early as possible in the project’s life cycle. This is why the deliverables of each iteration (especially those belonging to the Elaboration phase) have to be carefully selected to ensure that the greatest threats to a successful outcome are dealt with first.

2005: Agile Unified Process (AUP)

Developed by Scott Ambler as a simplified version of the Rational Unified Process, the Agile Unified Process methodology advocates a simple approach to developing business software applications using agile techniques such as:

• Test-driven development (TDD);
• Agile modelling (AM);
• Agile change management;
• Database refactoring.

AUP has seven core disciplines:

1. Model – the purpose of a project is to address an organization’s specific problem domain and to identify a viable solution to it.
2. Implementation – models are transformed into executable code which then needs to be subjects to a basic level of testing, in particular unit testing.
3. Test – performing an objective quality assessment to ensure that potential defects are identified, the system’s overall performance is verified and that requirements are validated.
4. Deployment – planning and executing the delivery of the system so that it becomes available to end users.
5. Configuration Management – managing access to the project’s artifacts, which involves tracking all artifact versions and controlling any changes brought to them.
6. Project Management – scheduling and directing the underlying activities that take place within the project to ensure its successful delivery.
7. Environment – ensuring that the proper support, guidance, and resources are available for the team as needed.

2008: Disciplined Agile Delivery (DAD)

Developed to provide a more cohesive approach to agile software development, Disciplined Agile Delivery (DAD) builds on practices such as SCRUM, agile modeling, lean software development and others. Designed to streamline IT work and to enable scaling, DAD helps teams make simplified decisions around incremental and iterative solution delivery.

Aiming to move beyond the SCRUM methodology, DAD attempts to address the challenges that arise from the latter’s use by using a people-first, learning-oriented, hybrid approach to IT delivery.

2011: Scaled Agile Framework (SAFe)

A set of organization and workflow patterns designed to guide companies in scaling lean and agile practices, the Scaled Agile Framework (SAFe) seeks to address the challenges that occur when scaling beyond a single team.

Developed by and for practitioners by leveraging the main bodies of knowledge from agile software development, lean product development and systems thinking, SAFe promotes:

• alignment;
• collaboration;
• and delivery across large numbers of agile teams.

Originally created to show the big picture of how work flowed from product management out to customers through governance, program, and development teams, SAFe was first released in 2011, with 5 more refined versions later added (the latest edition available since February 2021).

2013: Large-Scale-Scrum (LeSS)

One of today’s leading frameworks for agile software development, Large-Scale-Scrum (abbreviated LeSS) is a multi-team scrum methodology that can be applied to work groups consisting of dozens, hundreds or even thousands of members.

The LeSS framework evolved from Bas Vodde and Craig Larman’s experience working in large-scale product development projects in the telecoms and finance industries. The main purpose of LeSS is to reduce organization complexity and solve problems in simpler ways through less hierarchy, less management and less organizational structure.

FAQs about Software Development Methodologies

Here are the brief answers to the most frequently asked question about software development methodologies.

About the Software Development Methodologies History Timeline

To quickly create similar PowerPoint timelines for personal, academic or business communications, we recommend using the free Office Timeline add-in which can also be used to edit and update the Software Development Methodologies timeline PowerPoint slide.

---