One of the first decisions we face for each of our project implementations at Segue is “Which development methodology should we use. From Waterfall,V- model or Agile, there are a variety of different models for Software development. Some, like Waterfall, follow a more rigid, structured methodology others might prefer Agile. In this post I would like to explain the differences between Waterfall, V-model and Agile.
Lets first have an overview on these models:
The Waterfall method is the traditional approach to software development where a project is broken up into distinct stages that must be completed in sequence. It’s simple, elegant and makes sense. A project using this model moves down a series of steps starting from requirement/idea to final product. In Waterfall implementation, returning to a previous phase is prohibited—you can only travel downstream and must complete a full development cycle before returning to the top. Also, there’s typically a review of requirements at the end of each stage.
The different phases of the waterfall model are as follows:
- Requirement Gathering and Analysis:In this phase the requirements of the client are gathered, and an analysis of the same conducted, using which requirement specification document is created. This document is used as the base for creating the system.
- Design:This is an important phase, where the entire software is designed, taking the software requirement specifications into consideration. The system architecture along with the hardware and software specifications required are worked upon.
- Implementation:After the design stage comes the implementation stage, where the code for the software is written. When the modules are ready, unit tests are carried out on them, which helps in checking, if there are problems with the software. In case of defects, the code is fixed, before proceeding to the next stage.
- Testing :After the software has been developed completely, it is passed onto the testers. They run different tests on the software and the defects, if any are fixed.
- Deployment:Once the software has been passed forward, after debugging, starts the implementation of the software at the client side. The client is given a thorough insight into the software, so he can use the software.
- Maintenance:After the software has been installed, the client uses the software and may ask for changes. The changes and general maintenance of the software are taken care of in this phase.
3 important things about Waterfall:
- There’s large emphasis on specifying what the product will be.
- The steps are discrete and there no overlaps.
- There’s no way to backup. As soon as you’re on step, you need to complete the task for that step and then move on.
When should you use waterfall methodology?
1.When there is a clear picture of what the final product should be. The requirements are precisely documented
2.When clients won’t have the ability to change the scope of the project once it has begun.
3.When definition, not speed, is key to success.
4.No ambiguous requirements and Product definition is stable.
5.The project is short and simple.
V Model is an enhanced version of the classic waterfall model whereby each level of the development life-cycle is verified before moving on to the next level. The activities in this model are vent into a ‘V’ shape, with coding at the lower tip of the ‘V’. The main idea in the V-Model is that development tasks and testing tasks are corresponding activities of equal importance, which is symbolised by the two sides of the “V”.
V- model means Verification and Validation.
Here, by testing we mean verification by means of reviews and inspections, i.e. static testing. This helps in identifying errors very early in the life-cycle and minimizes potential future defects appearing in the code later in the life-cycle.
Validation means test execution which is also known as Dynamic Testing.
The activities which fall under the verification side are as follows:
- Requirement Analysis:Information about the proposed system is gathered from the end user, using which the software requirement specification document is prepared, that makes for the base of the software to be prepared.
- System Design:It is also known as functional design, the aim of which is to prepare functional design of the software. In case of any functionality, that is not feasible the same is intimated to the user.
- Architecture Design:Once the system design is in place, the architecture required for the system is made, which is often also referred to as high level design. It is here the interface relationship, database tables, their dependencies, etc. are all worked upon.
- Coding:After the system architecture is in place starts the coding stage. For coding, the entire system is broken up into small modules, which in turn are later integrated to form the entire system.
After the verification side comes the validation side of the V model. Let’s see the phases, which are a part of the validation side.
- Unit Testing:This is the first phase of the validation side, where small modules developed are tested, to check if they are fit for purpose.
- Integration Testing:Once the modules are ready, they are integrated upon which testing is carried out. It helps in determining faults in the interface and the interaction between two different modules.
- System Testing:It is in this phase, that the actual is tested against the system specification. In this phase the testing is carried out from the perspective of the end user. Also there are chances that some of the functionality are visible only after the entire system has been integrated completely.
- User Acceptance Testing:The aim of this testing is to check, if the system is in line with the software requirement specification. It helps in determining whether the developed software is according to the acceptance criteria and whether the system is to be accepted or not. Also, this phase of testing is carried out in simulated real time environment.
When V Model should be followed?
1.For the projects where an accurate product testing is required.
2.V Model should be followed for small project where requirements are clear and easy to understand at the beginning of development.
3.V Model should be followed for the project where very less probability to make the changes in the middle of testing or development phase which are unplanned.
4.The engineers of the required qualification, especially testers, are within easy reach.
Agile methodology follows an iterative and incremental process models and focuses upon adaptability to changing product requirements and enhancing customer satisfaction through rapid delivery of working product features and client participation.
Developers start off with a simplistic project design, and then begin to work on small modules. The work on these modules is done in weekly or monthly sprints.At the end of each sprint, project priorities are evaluated, and tests are run. These sprints allow for bugs to be discovered, and customer feedback to be incorporated into the design before the next sprint is run. Iterations are short time frames (time-boxed) that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders. This minimises overall risk and allows the project to adapt to changes quickly.
Team composition in an agile project is usually cross-functional and self-organising. Team members normally take responsibility for tasks that deliver the functionality an iteration requires. They decide individually how to meet an iteration’s requirements.
Agile methods emphasis face-to-face communication over written documents when the team is all in the same location. Most agile teams work in a single open office (called a bullpen), which facilitates such communication. Team size is typically small (5-9 people) to simplify team communication and team collaboration.
When should you use Agile methodology?
1.When rapid production is more important than the quality of the product.
2.When clients will be able to change the scope of the project.
3.When there isn’t a clear picture of what the final product should look like.
4.When you have skilled developers who are adaptable and able to think independently.
5.When the product is intended for an industry with rapidly changing standards.