Evolution of Software Process Models
From Waterfall to Agile model process
Just like the evolution of mankind took almost a period of six million years according to the scientific evidences, the software development evolution also started in 1970s and still evolving. It all started from WATERFALL evolved into an INCREMENTAL, ITERATIVE and AGILE Process models. This article briefly talks about the evolution and the need for the new process models starting from WATERFALL model to the current AGILE Process model.
Evolution:
Before we get into the topic of Software Development Process evolution, let’s understand the main elements of software development. Any software project / product development needs to have the following phases as a part of its Life Cycle, i.e., the Software Development Life Cycle (SDLC).
1. Understand what is Required Convert the End User Requirements into Software Requirements (Requirements Analysis)
2. Design an Architecture that would enable the realization of the Software Requirements (Architecture Design)
3. Design the function product feature to realize the solution (App Design)
4. Implement the Design (Coding)
5. Verification and Validation (Code reviews, Unit Testing, Integration and System Testing)
6. Deployment (Deploy at the End User Environment)
7. Operations - Monitoring / Maintenance and Support
To achieve the above, the IT industry has adopted multiple approaches. One has to remember, that early systems were monolithic apps running on a mainframe. This evolved into a Client-Server system and today it is all distributed and parallel computing. Hence in keeping with the architectural evolution, industry has strived to evolve the SDLC processes to best suit the development and improve the productivity.
The first article on the WATERFALL model was published by Royce, Winston in 1970. The WATERFALL model is a sequential software development process which is non-iterative. It starts from Requirement and ends at Maintenance / Support. Pictorially, we can visualize the WATERFALLMODEL as depicted below:
The term “WATERFALL” was coined to reflect the fact that every water particle in the waterfall falls to the same height. Likewise, in WATERFALL methodology, every module of an application is at the same stage of development. For example, if module A is at the design phase, then all other modules will also be at the design phase. Even if any one of the module has finished the work of a stage, it waits for all the other modules to complete and then they all move into the next phase. This means that there will never be a scenario in which the different modules are at different stages of development.The WATERFALL model originated from manufacturing and construction industries where we have highly structured physical environments. Here the “after-the-fact” changes are very high and since there was no formal Software Development process during those days, the same WATERFALL model was adapted for Software Development as well.
Royce agreed to the limitations of the WATERFALL model and suggested some steps to overcome them, which then evolved into SPIRAL Model, INCREMENTAL, ITERATIVE AND AGILE MODELS.
1: Preliminary Program Design:
Royce introduced a new term “Preliminary Program Design” which should be done before the Analysis phase. This is now referred as the POC / Proof of Concept. This is a miniature end expected software product which proves that there are no Technical Hurdles to reach the real end expected software product.
2: Document the design:
Royce believed that the only way to convey the program in the initial stage before the availability of some version of the end product is through Documentation. He insisted on documenting the architecture and design as a Specification.
3: Do it Twice:
The first iteration is covered as a part of Preliminary Based on the above tips, the WATERFALL model evolved into an “INCREMENTAL” model in which the requirements are divided into multiple builds / rather called as multiple incremental cycles. This can be visualized as “Multi WATERFALL” cycle model. Pictorially, we can visualize the INCREMENTAL MODEL as depicted below:
Program Design and it is designed to “THROW IT AWAY”. The biggest blunder a software team could do is to use the POC as the base version for the actual development of the software product. The POC is only to prove the concept and real development of the software should start from scratch as the design document is the reference.
4: Iterative Verification & Validation
Royce advocated that “every bit of analysis and every bit of code should be subjected to a second review / testing”. Bases on this concept the evolved processes introduced test driven programming, peer reviews, extreme programming (XP) and so on.
5.Involve the Customer
The idea of involving customer during the evolution of software product development in the current Agile Software Process was long advocated by Royce and recognized as a critical part for the success of the software product development.But here note that the Complete Requirement Specification should be frozen before the start of the Increment 1 for all the Increments. The further phases will be done in the Incremental / Multi WATERFALL cycle model. All the major requirements must be defined and only some details can evolve over time. As the evolution of software process models,
soon there was a need felt by the industry that the clients will be able to define / visualize the requirements as the product evolves. It was not possible for the customers to visualize the complete system in the beginning and define the same. These projects mainly fall in the Product / Solution development category. As the Product evolves, the customer is able to see where he is heading towards and refine the product. Hence the need for continuous evolution of requirements as the product development arose. This resulted in the “ITERATIVE MODEL”.
Unlike INCREMENTAL MODEL, the ITERATIVE MODEL does not mandate to have the Complete Requirement Specification to be frozen before starting the Iteration1. Rather, a subset or some parts of the software’s requirement specification is frozen and the implementation of this part is being done. This part is reviewed by the client / customer to further come up with the detailed requirements. As mentioned earlier, this approach is well suited for the product development with the features enhancements go in multiple iterations / refinements. Pictorially, Still a drawback of the ITERATIVE MODEL is the client feedback is not that frequent, hence there is a still a cost of rework involved when the client gets to see the deliverable of each iteration. This motivated the industry to come up with a more agile methodology in which we increase the frequency of the feedback from the clients.
Agile Model:
AGILE MODEL for software development is a combination of INCREMENTAL and ITERATIVE MODEL. The term “Agile” was coined in 2001, in the Manifesto for Agile Software Development. The heart principle of the AGILE MODEL is the “Customer Satisfaction by early and continuous delivery of valuable Software”. This principle is motivated by the need of industry to overcome the customer pain points of the duration between the client requirement phase and the first sight of the product to the customer. Hence by Agile, the project teams are encouraged to deliver frequently, get the early feedback from the clients, and adapt the feedback in the further development. Hence the client gets the complete visibility of how the product literally grows from inception to the mature end user stage.
Agile product developers are no more rigid as they welcome changing requirements, even in late development. The team regularly reflects on how to become more effective, and this promotes the spirit of teamwork. So, this model became a “WIN-WIN situation” to both the parties i.e. Development Team and the Clients. Eventually, many agile software development frameworks evolved. To name a few famous frameworks, there were SCRUM, KANBAN, XP, FEATURE DRIVEN DEVELOPMENT etc. Pictorally, we can visualize the AGILE MODEL (SCRUM) as depicted below:
Thus the Software Development Process Models evolved from WATERFALL to AGILE MODELS. But when we look into this evolution carefully, each of the evolved methods post Royce’s WATERFALL Model revolved around the basic 5 TIPS suggested by Royce i.e. Preliminary Program Design, Document the design, Do it Twice, Iterative Verification and Validation and Involve Customer as the improvements he suggested on his WATERFALL Model. Hats off to Royce!
