Agile, V Model, Waterfall, Spiral – a comprehensive guide to the development models.
Some days ago I was in a testing conference in Tel-Aviv. The subject of the conference was “QA & Development in Agile”.
Despite the fact that the main subject of the conference was the Agile method in the development process these days, during all lectures, the presenters compared the Agile model to traditional models, especially to the V-Model.
In this post, I am going to explain in depth the main differences between the different software development models and the advantages and disadvantages of each model.
In order to achieve structured and controllable software development efforts, several software development models are being used.
There are many accepted models in the development process. Such as the Spiral Model, the Waterfall-model, the V-Model, and the Agile Model, which are so popular today.
All these models define a systematic way to accomplish an orderly way of working during the project.
Testing appears in each of these lifecycle models, but with very different meanings and different extent.
Some methods work better for a specific type of project, but in the final result, the most important factor for the project success may be how closely a particular plan was followed.
Most of the projects work according to a specific software development model chosen by development but in some cases could be used some different models work in parallel.
For example, the V-Model or Waterfall model combined the Agile model.
For Instance, a project using V-Model, but during the developing process, it becomes clear that the project should update some of the requirements cause of the change of design by the customer.
In this example, we can see that the V-Model Model has interaction with some indications of the Agile Model.
Here is an in-Depth Guide to the Advantages and Disadvantages of Different Software Development Life Cycle Models: Agile, V Model, Waterfall, and Spiral.
The original SDLC model was the Waterfall model. This model is very simple to understand and very well known in the development process.
The main concept of this model is that only when one development level is completed will the next one be initiated.
At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.
– The Waterfall method is also well known amongst the software developers, therefore, it is easy to use
– Works well for smaller projects where requirements are very well understood
– Cost-effectiveness: Time spent early in the software production cycle can lead to the greater economy at later stages
– The crucial disadvantage of this model is that testing is understood as a “one-time” action at the end of the project just before the release of the operation.
The test is seen as a “final inspection”, an analogy to a manufacturing inspection before handing over the product to the customer.
– High amounts of risk and uncertainty
– Poor model for complex and object-oriented projects
In summary, the Waterfall Model should use in projects with a clear and deeply understood of project requirements, design, technical tools, and infrastructures.
The second model is the V-model.
This is the most familiar model in the development process. The model has the form of a “V”.
The main idea in the V-Model is that development tasks and testing tasks are corresponding activities of equal importance, which is symbolized by the two sides of the “V”.
The development process proceeds from the upper left point of the V toward the right, ending at the upper right point.
In the left-hand, downward-sloping branch of the V, development personnel define business requirements, application design parameters, and design processes.
At the base point of the V, the code is written. In the right-hand, upward-sloping branch of the V, testing and debugging is done.
The extreme upper right point of the V represents product release and ongoing support.
Like in Waterfall-Model each phase must be completed before the next phase begins, V-model actually is a modified version of a Waterfall-Model.
The V-model ordains that the code testing documentation is written in tandem with the development phases that means, for instance, the integration tests should be documented as and when the high-level design is finalized and the unit tests should be ready as and when the detailed specifications are laid down.
In this model, testers should be involved in reviewing development implementation as soon as possible.
Like the Waterfall-Model testing process and fixing faults can be done at any stage in the life cycle, but the cost of finding and fixing faults increases dramatically as development progresses.
The number and intensity of the test levels may be modified according to the specific needs of the project and for every development stage, there is a corresponding test level.
– Due to the fact that in the V-Model defects are being repaired a short time after they have been detected, it is cheaper to fix them.
– The model has a reputation for a very good base for the partitioning of testing.
All the participants in the development of a system have a responsibility for quality assurance and testing.
– Testing activities like requirements, test designing happens well before coding.
This fact saves a lot of time and also helps in developing a very good understanding of the project at the initial stage.
– The objectives of testing are changing, and specific for each test level
– The V-Model is very rigid and the least flexible, it means that if one of the requirements are changing, the tester should update the test documentation as a whole.
– This model applicable mostly to big companies because the model needs a lot of resources.
– The amount and the intensity of the test levels should be tailored according to the specific needs of the project.
In summary: In the V-Model the place of testing in the development process is critical. The fault-finding occurs in the early stage of the development process which provides the cheaper alternative for fixing it.
The Spiral model is mostly used in large projects.
For smaller projects, the Agile concept is more appropriate.
This model of development combines the features of the prototyping model and the waterfall model.
The spiral model was defined by Barry Boehm in his article “A Spiral Model of Software Development and Enhancement” (1985).
This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters.
The spiral model is an evolutionary version of incremental prototyping.
Incremental development means that the project is not done by (possibly large) pieces, but as a series of smaller developments and deliveries.
Incremental models try to reduce the risk of developing the wrong system by delivering useful parts of the system early and getting customer feedback.
System functionality and reliability requirements will grow over time, from an early version only for the development or for users, to a version released to final customers later.
What about testing in the spiral model?
In a spiral model, testing must be adapted to such development models, and continuous integration testing and regression testing are necessary.
The tests should be a reusable test case for every component and increment, and it should be reused and updated for every additional increment.
If this is not a case, the software reliability tends to decrease over time instead of increasing.
– Spiral Life Cycle Model is a very flexible model. Development phases can be determined by the project manager, according to the complexity of the project.
– Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses because important issues are discovered earlier.
– Good for large and mission-critical projects.
– The software is produced early in the software lifecycle.
– Doesn’t work well for smaller projects.
– Evaluating the risks involved in the project can shoot up the cost and it may be higher than the cost of building the system.
– The spiral model is much customized for every project.
– Risk analysis requires highly specific expertise.
In summary: It serves as the best option for businesses with volatile business goals but where there is a need for a prototype to handle the complexities of the business procedures.
This Agile Model of software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project.
The Agile approach meaning as the name refers implies something to do very quickly.
Hence, Agile Testing refers to validate client requirements as soon as possible and make it customer-friendly.
Agile practices are specially tailored to eliminate all kinds of waste manifesting in a product lifecycle, but more especially, improving the quality of the developed product is a major goal threaded into most of that practice.
There are many agile development methods; most minimize risk by developing software in short amounts of time.
Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks.
Each iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation.
In Agile testing as soon as the build is out, testing is expected to get started and report the bugs quickly if any found.
There are some accepted properties to Agile Development, for example:
-Short release cycles- agile development can’t be called agile unless it is done in short repetitive iterations.
-Customer involvement. The tester should provide his thoughts on the client’s requirements rather than just being the audience at the other end.
– Responding to change – agile development is focused on quick responses to change and continuous development.
– Individuals and interactions over processes and tools
– Saving time and money.
– Focus more on the application rather than documenting things.
– Daily meetings and discussions for the project following an Agile model can help to determine the issues well in advance and work on it accordingly.
– Requirements changing even in the late stage of development
– The end result is high-quality software in the least possible time duration and satisfied customer.
– The project can easily get taken off track if the customer representative is not clear what final outcome that they want.
– There is a lack of emphasis on necessary designing and documentation.
– User involvement is often a potential problem especially in big and complex projects
– Agile processes are really only applicable to products where reliability is not very critical.
I have come to the conclusion that with the quicker development, testing, and constant feedback from the user, the Agile methodology becomes the appropriate approach for the projects to be delivered in a short span of time.
Agile methods also emphasize working software as the primary measure of progress.
Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods.
Is this post helpful for you? Share your thoughts in comments on how it helped you.
Join to Productive Hut Family and be part of a testing community!