Conventional Software Development Strategies
In a previous article basic concepts of SDLC (Software Development Life Cycle) were introduced. Now we're going to examine some of the most conventional strategies for applying this life cycle.
Waterfall
The name speaks for what it entails. In this model, each step needs to be finished before the next one begins, there's no overlap.
When to Use it
The product requirements are somewhat clear and well-defined.
The technology being used is clearly understood.
The project is short.
Advantages
Simple and easy to understand and use.
Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
Clearly defined stages.
Well understood milestones.
Easy to arrange tasks.
Process and results are well documented.
(Source)
Disadvantages
No working software is produced until late during the life cycle.
High amounts of risk and uncertainty.
Not a good model for complex and object-oriented projects.
Poor model for long and ongoing projects.
Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty is high with this process model.
It is difficult to measure progress within stages.
Cannot accommodate changing requirements.
Adjusting scope during the life cycle can end a project.
Integration is done as a "big-bang". at the very end, which doesn't allow identifying any technological or business bottleneck or challenges early.
(Source)
Iterative
In this model, the project is broken down into smaller semi-independent phases and the SDLC steps are taken for each phase, on each iteration.
Also known as the incremental build approach, this model allows for the parallel working of independent modules, and at the end of each phase, new functionalities are added to the product.
When to Use it
Requirement analysis for major features is done but not everything can be assessed at the moment. This could be due to "the unpredictable nature of the target market", "the difficulty of choosing the right path with limited infrastructure", or many other reasons.
Competition is high in the target market, so the product has to be introduced to the market as the user base grows, and new features are added as updates.
New resources (technologies, experts, etc.) are needed for this project and the development team is learning them as they go by.
Advantages
Software is broken down into smaller components/projects, which increases flexibility, reduces risk, and helps adhere much easier to the iterative approach of Agile methodologies.
Parallel development is possible.
Time and cost estimations are much more accurate and the Project/Product Managers can monitor the progress much more closely.
Changing some and adding new requirements, especially those that need a basis (= earlier stages) first, is achievable.
Customer evaluation can be done periodically to make sure that the design and development are going according to their vision.
Disadvantages
More expert managerial skills are needed to handle the complexities.
Not all the requirements are gathered carefully at the beginning of the project and unforeseen issues may arise later down the way.
Risk analysis cannot be done for the whole project from the start. So later down the road, as the risk assessment is done, the management might decide to cancel the project.
Spiral
A spiral model is a type of iterative model combined with waterfall model where the project goes through 4 phases in each iteration:
Planning
Requirement analysis of the next phase of the project is done. Collaboration between the business analysts and the customers is highly essential at this phase, for the identification of a target market.
Design
Conceptual and practical designs are discussed and reviewed by the technical team, and architectural design, technologies, feature list, etc. are planned for the coming phase only.
Development
In each iteration, a build of the software with a version number is produced and is then released to the customers to gain their feedback.
At earlier stages, a Proof of Concept is created instead of an actual working build.
Evaluation
Two major analysis takes place at this phase: hindsight review and foresight risk assessment. The former is about monitoring the user satisfaction rate, the company's KPIs, the reported issues, etc. for the currently released build. The latter is about making sure that the project is worth it, by performing risk analysis and trying to estimate the application growth, the company revenue, and the expected market engagement rate.
When to Use it
Projects that involve significant technical, operational, or business risks can benefit from the risk-driven nature of the Spiral Model. It allows for early identification, analysis, and mitigation of risks through multiple iterations.
When certain aspects of the project are uncertain or unknown, such as new technologies, market conditions, or user needs, the Spiral Model helps in progressively exploring and addressing these uncertainties through iterative cycles.
If the project has strict compliance requirements, such as regulatory standards or quality certifications, the Spiral Model's emphasis on documentation, reviews, and risk management aligns well with these needs.
Advantages
Strong focus on risk management. It allows for early identification, analysis, and mitigation of risks through iterative cycles.
Flexibility in accommodating changes and evolving requirements.
The Spiral Model emphasizes extensive documentation and formal reviews at each phase. This ensures that the project's progress, risks, and requirements are well-documented and reviewed by stakeholders, leading to better transparency and understanding.
Disadvantages
The Spiral Model can be complex to manage and implement, especially for small or straightforward projects. It requires careful planning, risk analysis, and coordination across multiple iterations, which may increase project overhead.
The increased time and resources associated with the Spiral Model can lead to higher project financial and temporal costs.
The success of the Spiral Model relies heavily on accurate risk analysis and management. If risk identification or mitigation strategies are inadequate or overlooked, it can lead to project issues or failures.
What's the difference with the Iterative Model?
| Attribute | Iterative | Spiral |
| Phases | Each iteration delivers a working increment of the software. | Every 4 phase, delivers a working software |
| Focus | The Iterative Model emphasizes obtaining feedback from stakeholders and end-users during each iteration. | Each spiral includes risk analysis, assessment, and mitigation activities. It allows for early identification and mitigation of high-risk areas. |
| Applicability | Suitable for projects where requirements may evolve or change over time, and there is a need for early and frequent delivery of working software. | Often used for large, complex projects where risks need to be carefully managed, and frequent feedback loops are crucial. |
V
The "V" model emphasizes a systematic and structured approach to software development, where each phase of the development process is aligned with its corresponding testing phase. The model highlights the importance of early planning and involvement in testing activities throughout the entire development life cycle.
Level 1: Requirements Gathering and Analysis
This phase involves gathering and documenting user requirements, understanding business needs, and defining the scope of the project.
The requirements are analyzed, validated, and prioritized to create a clear and comprehensive set of specifications.
Level 2: System Design
In this phase, the system architecture and high-level design are established based on the gathered requirements.
The design includes defining components, modules, interfaces, and the overall structure of the software system.
Level 3: Subsystem/Component Design
This phase focuses on designing the individual subsystems or components of the software.
Detailed designs are created for each component, specifying their functionalities, interfaces, data structures, and algorithms.
Last Level: Implementation/Coding
The actual coding and development of the software occur in this phase.
Developers write the source code based on the design specifications, following coding standards and best practices.
Code quality tests are also included and practiced in this phase.
Level 3 Tests: Unit Testing
Unit testing is performed on the individual units or components of the software.
Each unit is tested in isolation to ensure that it functions correctly and meets its specifications.
Level 2 Tests: Integration and System Testing
In this phase, the different components or subsystems are integrated and tested together as a complete system.
Integration testing verifies the interactions and interfaces between components, while system testing validates the system as a whole.
Level 1 Tests: Acceptance Testing
Acceptance testing is performed to ensure that the software meets the specified requirements and is ready for deployment.
Users or stakeholders validate the software's functionality, usability, and overall compliance with their needs.
When to Use it
The V Model is most effective when the project requirements are well-defined and stable from the beginning, and will not significantly change during the development process.
The V Model is often suitable for projects that follow a sequential or phased approach similar to the waterfall model. It provides a visual representation of the testing activities corresponding to each development phase, ensuring a systematic approach to quality assurance.
Advantages
The V Model provides clear traceability between each stage of the development process and ensures that requirements are aligned with the corresponding design and that test cases are derived from the requirements. This traceability helps in validating that the implemented system meets the specified requirements.
Since testing activities are planned and executed from the early stages of the project, defects and issues can be identified and addressed sooner. This leads to early bug detection and allows for timely corrective actions.
The V Model provides a structured and visual representation of the development and testing activities, making it easier to understand and follow. It also encourages the documentation of requirements, design, and test artifacts, which aids in maintaining project documentation for future reference.
Disadvantages
A sequential and phased approach makes this model rigid and inflexible. It may not be suitable for projects with rapidly changing requirements or where an agile and iterative approach is needed.
The V Model's structured approach requires extensive documentation at each stage of development. This can lead to increased documentation overhead, which may be time-consuming and resource-intensive.
The testing activities in the V Model are primarily focused on validating against design specifications. It may not fully cover aspects such as usability, user experience, and real-world scenarios, which may require additional testing approaches.
Final Word
In conclusion, understanding different software development strategies is crucial for successful project execution. In this article, we explored several conventional software development strategies. Each approach has its advantages and disadvantages, and the choice depends on factors such as project requirements, flexibility needs, and client engagement. By carefully selecting and implementing the right strategy, software development teams can enhance efficiency, improve software quality, and meet project objectives. Remember, no single model fits all scenarios, so it's important to evaluate and tailor the chosen approach to the specific project context.