The iterative model involves splitting the life cycle project into a sequence of iterations, each of which resembles “mini-project”, including all phases of the life cycle as applied to creating smaller pieces of functionality, compared to the project as a whole. The goal of each iteration is to get a working version of the software system that includes the functionality, determined by the integrated content of all previous and current iteration. The result of the final iteration contains all desired functionality of the product. Thus, with the completion each iteration, the product develops incrementally.
The chances of successfully creating a complex system will be maximum if it is realized in a series of small steps and if each step contains a well-defined result, and the ability to return to the results of a previous successful iteration, in case of failure. Before putting all the resources into action, designed to create software, the developer has the opportunity receive feedback from the real world (customers, users) and correct possible errors in the project.
The iterative model implies the possibility not only building a working (in terms of test results) version system – a prototype, but also its deployment in real operating conditions with an analysis of user feedback to determine content and planning for the next iteration. Because on each step we have a working system, then we can:
* start user testing very early;
* adopt a development strategy in accordance with the budget, fully protecting against time or cost overruns (in in particular, by reducing the secondary functionality).
The idea behind the incremental model is that software system should be developed incrementally, so that the developer can use the data obtained from development of earlier versions of the software. New data is obtained as in during the development of the software, and during its use, where possible. The key steps in this process are the simple implementation of a subset requirements for the program and the improvement of the model in the series successive releases until the software is released during in its entirety. During each iteration, the organization of the model changes, and new functionality is added to it.
For the organization of incremental development is usually chosen a characteristic time interval, for example, a week. Then during this interval, the project is updated: a new one is added documentation, both textual and graphic, the set is expanding tests, new code is added, etc. Theoretically, the steps developments can be carried out in parallel, but such a process is very difficult to coordinate. Incremental Development Goes Better in total if the next iteration starts after the update of all artifacts in the previous iteration is finished, and significantly worse, if the time required to update the artifacts is significant exceeds the selected interval.
The result of each iteration is a working, but not full-featured software that is not yet software product and cannot be distributed. As a result of each iteration creates a version of some piece of software. It should be noted but as a rule, at each iteration, new requirements, some iterations may be entirely devoted to improvement of an existing program, for example, in order to improving its performance.
From the point of view of the structure of the life cycle, the evolutionary the model is called iterative. In terms of product development – incremental. Experience shows that it is impossible to consider each of these views is isolated. Most often, this mixed evolutionary model is called simply iterative (speaking of process) and / or incremental (speaking of building up product functionality). Significance of the evolutionary model on basis of the organization of iterations is especially manifested in the reduction uncertainty with the completion of each iteration. In its turn, reducing uncertainty reduces risks.
Spiral model as a kind of evolutionary models
In the mid-1980s, Barry Boehm proposed his own version iterative model an iterative model called “Spiral model”. When using the spiral model, application software is created in several iterations (helix turns) by the method prototyping. Prototyping is carried out in several iterations, or turns of the spiral. Each iteration corresponds to the creation fragment or version of the software, it specifies the goals and characteristics project, the quality of the results obtained is assessed and plans are work of the next iteration. At each iteration, careful assessment of the risk of exceeding the terms and cost of the project, to determine if another iteration is needed, the degree of completeness and accuracy in understanding the system requirements, and expediency of terminating the project.
A distinctive feature of this model is a special attention to risks affecting the organization of the life cycle. Boehm formulates the 10 most common (by priority) risks:
- lack of specialists;
- unrealistic deadlines and budget;
- implementation of inappropriate functionality;
- development of the wrong user interface;
- “golden serving”, perfectionism, unnecessary optimization and sharpening details;
- a never-ending stream of changes;
- lack of information about external components that determine environment of the system or those involved in the integration;
- deficiencies in the work performed by external (in relation to project) resources;
- insufficient performance of the resulting system;
- “gap” in the qualifications of specialists in different fields of knowledge.
The main problem of the spiral cycle is the determination of the moment transition to the next stage. To solve it, you need to enter time limits for each of the stages of the life cycle. Transition carried out according to plan, even if not all the planned work is completed. The plan is based on static data obtained in previous projects, and personal developer experience.
The advantages of the spiral model are: (previously getting results through prototyping), permanent participation of the customer in the development process, splitting a large volume work into small parts, risk reduction.
The natural development of the cascade and evolutionary model has led to their convergence and the emergence of modern approaches – methodologies, which is essentially a rational combination the models described above. Various variants of the evolutionary approach implemented in most modern technologies and methods: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), Agile and other.