The development or spiral model it is a software development approach that can be considered as an answer to the drawbacks of cascade development. He spiral pattern describes the life cycle of a software through spirals, which are repeated until the finished product can be delivered. Spiral development is also known as incremental development or model. The product is worked on continuously and improvements often take place in very small steps.
A key feature of the spiral development is the minimization of risks in software development, which could result in increased total costs, more effort, and a delayed release. These risks are offset by the incremental approach, first making prototypes, which then go through the software development phases at least once. The spiral development it is generic and can be combined with other classic and agile development methods, which is why it is also called a second-order model or development.
General information
The spiral development It was proposed by Barry W. Boehm in his essay "A Spiral Model of Software Development and Enhancement." At that time, the waterfall development model prevailed, so the associated drawbacks were often discussed. Unlike other models such as "code and fix" or the "waterfall model", spiral development is based on risk. The identification and resolution of risks plays an important role in the different spirals of the project once the objectives and conditions have been defined. The focus is on possible factors that can cause uncertainties for the software or for the entire project. Under the assumption, if risks can be controlled in a profitable manner, there is nothing to prevent the successful completion of the project. Approaches to minimize these risks are, for example, prototypes, simulations, benchmarks or interviews with users. For certain types of risks, the whole process can even be reviewed and structured differently. Management intervention is feasible at each stage of the project and other development approaches can be adapted.
How does it work
The kind of spiral development It is characterized by the following cycles (also quadrants):[1]
- Objective and alternative determination: The objectives are determined jointly with the client. At the same time, possible alternatives are discussed and the framework conditions are specified (for example, operating systems, environments and programming languages).
- Analysis and evaluation of risks: Potential risks are identified and evaluated. In addition, existing options are evaluated. Risks are recorded, evaluated and subsequently reduced using prototypes, simulations and analysis software. In this cycle, there are several prototypes as design templates or functional components
- Development and testing: Prototypes are expanded and functionalities are added. The actual code is written, tested, and migrated to a test environment multiple times until the software can be implemented in a productive environment.
- Planning the next cycle: The next cycle is planned at the end of each phase. If errors occur, solutions are sought, and if an alternative is a better solution, it is preferred in the next cycle.
The most important driving force behind spiral development is risk assessment and analysis. Any risks that threaten the project must be identified up front. The progress of the project depends critically on how the risks can be erased. The project is considered successful only when there are no risks. The objective of the cycle is to produce a product in continuous improvement. The software or app is constantly being refined. The spiral model is incremental, but not necessarily repetitive. Repetitions occur only when risks, mistakes, or conflicts threaten the project. Then the product has to go through a cycle again, called an iteration or repetition.
Benefits / Disadvantages
- The spiral development model is used many times for larger projects that are subject to risk. Since these risks have a direct monetary impact, the control of the budgets of the clients and the promoter companies is essential. The spiral model is mostly used in new technical environments, as these pose a risk.[2]
- Conflicts between the requirements of a software and its design are effectively avoided through the cyclical approach, since the requirements can be constantly checked and, if necessary, modified.[3]
- Feedback from users, developers and customers can be obtained in the early stages of the project. However, this structure also requires management that is mindful of product cycles and can respond quickly to risks. The control of such projects is therefore relatively complex and also requires good documentation so that all changes are recorded.
- Even when software is tested under various aspects throughout the development and testing cycle (unit, acceptance test, and onboarding), it often happens that prototypes are transferred to the production system. In this way, there is a risk of other conceptual errors and inconsistencies being introduced into the subsequent final product.
- In places where decisions are made about subsequent cycles, there is a risk that loops will form and the project will take longer if wrong decisions are made. For this reason, the options and their evaluation are important.
Relevance for programming
Unlike a sequential model (for example, the cascade model) arranged in successive phases, the spiral model outlines the life cycle of a software through spirals that exist to go through. In this way, this approach is more like prototyping than classical approaches. The spiral model is supposed to avoid the disadvantages of other models and emphasize the advantages. By focusing on risk minimization, this model has a financial component that may be relevant to decision makers. Through discussions with clients, analysis and feasibility studies, large-scale projects can be implemented and their economic impact monitored. The extent to which agile methods like scrum, extreme scheduling, or DevOps are better alternatives depends on many different factors such as project scope, budget, or the required level of support and maintenance. The more flexibility required, the more agile methods will be considered.
