Unlike the 1960s at the dawn of software development, in today’s world, there are various colorful projects with different needs. Some big projects require rapid changes, others have unclear requirements, or demand being extra careful during the development. Here we will take a look at some of the most popular SDLC frameworks used over the years.
Waterfall (Traditional) Model:
Nearly 50 years ago when SDLC was first introduced as the standardized procedure to develop software, the world of computing was still black and white. There were no dynamic development phases, crazy applications, and evil stakeholders that demand constant changes in their products. Due to that stability, the first widely accepted model was the good-ole “Waterfall Model”, also known as the “Traditional Approach”.
The reason we call it a waterfall is that once a phase is done, there is no going back to the previous stage, just like we cannot climb a waterfall back (Unless you’re a Koi fish desiring to become a dragon). So, one of the distinct features of this approach is the Requirement Freeze, which means once the requirements are set, they cannot be changed (In your face, clients!). Also, in some instances, the test execution team is hired towards the end. These aspects make this model a relatively cheap and arguably a less stressful one for developers as they do not need to do recording again and again.
Yet, the model has its downsides. It might get tiresome for the customer and the team to not be able to see the end-product for a long time. This approach is especially not preferred for projects where the requirements have a high possibility of changing.
Spiral Model
What if our product has plenty of modules and it has to keep growing as the new modules (features) are being added to the requirements? No worries, Spiral Model is our go-to model for highly modular systems, such as online games that are constantly updated with new patches.
It is also called the “Incremental Waterfall Model” since it can be thought of as multiple waterfall cycles. Unlike the Traditional Model where SDLC is done only once, in this model, it is done every time there will be a new big module added. So, the requirement changes are also allowed. Not to confuse though, requirement changes are allowed, only before each iteration starts, and are frozen during the development. Since there is a new version of the software released after every cycle, the client and the team have a better chance of getting used to the software.
The approach to testing also differs a bit, as the integration testing should be done in detail every new cycle. To illustrate, let’s think about a MOBA game that has an in-game map, store, characters, and items. In every release, whenever there is a new character is added to the game, the following tests should be done between the related modules to validate the integration of the newly added features:
- Character – Items
- Character – Other Characters
- Character – Store
At the end of every iteration, a new cycle’s planning starts, so that the development of the software keeps going till the stakeholders decide to have enough updates on the application. Although the model is great for big and complex projects, it has the disadvantage of increasing cost, complexity, and difficulty in time estimation as the application grows.
Verification and Validation (V) Model
We can call this one as “V for Verification and Validation” model as well. Before diving into this important approach, we need to clear up terminology confusion first. Spoiler alert, both of the following terms are checking the software according to the business requirements.
Verification: Asking the question, “Are we building the product rightly?”. It is about how to build the software and should be asked by the developers.
Validation: The question is, “Are we building the right product?”. So, it focuses on what is being built and done by the testing team.
During the SDLC, Verification and Validation are done in parallel to each other, thus it creates that beautiful V-shaped diagram. Let’s discover what’s going on in every step from the QA perspective.
- As soon as the Customer Requirement Specification (CRS) is set, the requirements are given to both the developers and the testers (Let the battle begin!).
- Testers write the Acceptance Plan and the cases. Defects (bugs) are tried to be predicted before the actual development. Then the plan is given to the developers, and finally to the client.
- After CRS is verified and validated, the same steps are done on Software Requirement Specification (SRS). Testers write the System Testing (Whole application’s end-to-end test) cases in this step.
- Then, the High-Level Design (HLD) verification and validation are done. Testers write the integration test cases during this step.
- You got it correct! Now is the time to verify and validate the Low-Level Design (LLD), and testers are supposed to write the functional test cases (unit testing).
- Now each and every step is verified and validated, and test cases are ready to fire. Time to wait for the developers to complete the coding as well as the white box testing (testing the code they write).
- Time to let the magic happen. Remember all the test cases the testing proletarians wrote? Now is the time to execute all of them from bottom-to-up: Functional > Integration > System > Acceptance.
- Your software is ready to serve. Put a pinch of thyme before serving and let your guests enjoy the meal!
As we can see, it is a lot of work. Therefore, the initial investment will naturally be more, and the documentation will be massive. But it is rewarding for whom has clear requirements and wants each and every step to be tested and proactively reduce the defect risk as much as possible.
Prototype Model
You are confused with all the different models and kumbaya, and even don’t know what to expect from your own product? Today’s problem eh, nobody knows what they really want. Fortunately, this is not an existential crisis blog, and we’re here to talk about software. Then, let us introduce the Prototype Model!
The prototype approach is suitable for clients, and also for developers who are new to the business and the domain. Since the customer does not have a clear idea of their needs, it is wise for the team to not lose time developing the whole product. In the end, if the customer is not satisfied with the end result and does not accept it, ugly things might happen. To prevent ugly things, the team should follow this approach to show the customer a prototype of the end product to see their reaction. The prototype is made by the content developers as the visual representation of the CRS. After the design is done, it is verified by the testers, and then given to the customer. If they are not happy with the prototype, another one is designed till it is finally accepted. After that, the actual product is developed and tested and given to the client.
Although this approach is well-suited for the unclear CRS and SRS, it’s better to watch out the time management as it might get pretty time-consuming to create prototypes.
Not happy with any of those frameworks above? There are indeed a lot of other SDLC models, such as the Rapid Development, or the Big Bang model (fancy names, huh?), but in the next tutorial we will take a look at the reigning king of the models. Meet with “Agile Method”.
SDLC?! < Previous – Next > Agile Handbook
Funky QA 