Introduction to Iterative Model
In this model, iterative process starts with a small set of software requirements being simply implanted and increases the evolving versions iteratively, up to and including the complete system. Designs changes are produced and fresh functional skills are added to each iteration. The fundamental concept behind the techniques is to build a system over iteration and in smaller portion at a time (incremental). An iterative lifecycle model doesn’t begin with a complete requirement specification. Development instead starts with only part of the software specified and implemented, which is then checked to determine additional demands. This process is repeated at the end of each model iteration and produces a fresh version of the software.
More than one iteration of the software development cycle may be in progress at the same time. A strict validation of the requirements, verification and testing of each software version against those requirements within each model cycle is essential for the effective use of an iterative software development cycle. The software needs to be tested again and further to check each version of the software as it evolves over a number of cycles.
Types of Iterative Model
Following are two iterative models:
Rapid Application Development (RAD)
RAD model is a model for the rapid development of applications. It’s an iterative model form. The components and functions in RAD are developed in parallel as if they are mini-projects. RAD’s workshop or focus groups concentrate on meeting client demands, early prototype proofing by customers using the iterative idea, reuse of current prototype models, continuous integration and speedy delivery. As the pre-planning is not detailed, it is simpler for the design method to integrate modifications. RAD projects follow iterative and incremental model and have small teams comprising of developers, domain experts, customer representatives and other IT resources working progressively on their component or prototype (TutorialsPoint, 2019). There are mainly three phases in RAD:
- Business Modeling
- Data Modeling
- Process Modeling
- Application Generation
- Testing and Turnover
In terms of data flow and distribution of data between various business channels, the business model for the product under development has been built. A full business analysis is conducted to discover the vital information, how and when it can be acquired, and what variables drive effective dataflows.
The information collected in the business modelling stage is evaluated and analyzed for data objects that are essential to the business. The attributes of all data sets are identified and defined. In accordance with the business model, the relationship between these information objects is described and detailed.
The data objects defined in the data modelling stage are converted to provide the flow of business information required for the attainment of business objectives in accordance with the business model. The process model is described in this stage for modifications or improvements to the information item sets. Process descriptions are given for the add, removal, recovery or modifications of a data object.
The real system is constructed and coded using automation instruments, processes and information models are transformed into real prototypes.
Testing and Turnover
In the RAD model, the overall testing time is reduced, as prototypes are autonomously tested each time. However, it is necessary to carefully test the information flow and interfaces between all the parts with a full test coverage. As most programming parts were already tested, the risk of significant problems has been reduced.
Benefits of RAD Model
The RAD model allows fast shipment as the general design period is reduced by offering prototype and simultaneous production features. RAD initiatives adopt a routine and progressive model and include tiny groups of designers, field specialists, client agents and other IT sources operating on their components or prototypes increasingly. RAD decreases component creation time by reusability and helps to speed up development.
Constraints of RAD Model
The RAD model operates well if highly qualified technicians, designers and scheme analyst are only accessible. In this model the client undertakes in a specified time period to accomplish the specific prototype. This model can collapse if there is a lack of engagement on either hand. Progress and issues are difficult to monitor as there is no documentation available to show what has been accomplished. RAD initiatives collapse if developers are not promised to deliver software in due course.
Spiral model is an iterative model blended with waterfall model. Each spiral model stage starts with a design objective and finishes with the customer reviewing advancement. The spiral-SDLC model development team begins with a tiny set of needs and goes through every stage of growth. The software engineering team provides extra features in increasing spirals until the application is prepared for manufacturing. Spiral model allows incremental releases of the product through each iteration around the spiral. There are four phases on spiral model:
- Construct or Build
- Evaluation and Risk Analysis
This stage begins with the collection of business requirements in the spiral’s baseline. As the item matures, the system specifications, subsystem and unit specifications are all identified during the subsequent spirals during this stage. In this stage the system requirements are also understand through ongoing communication between the client and the system analyst. The item will be used in the identified market at the end of the spiral.
Starting with the conceptual design in the baseline spiral, the design stage includes architectural design, logical modular design, physical product design and the final design in subsequent spirals.
Construct or Build
The construction stage relates to the manufacturing at each spiral of the real software product. In the spiral baseline, a POC (Proof of Concept) will be developed for customer feedback when the product is just being thought of and the design developed during this stage. A working model of the software called construct is then generated with a version number in the subsequent spirals with a greater clarity on demands and design information. These components are sent for feedback to the client.
Evaluation and Risk Analysis
Risk analysis involves the identification, estimation and tracking of the technical and managed hazards such as slippage schedules and excess costs. After testing build, the client assesses the software and gives feedback at the end of the first iteration.
Benefits of spiral model
Spiral model is one of the versatile models for software development. Development stages depending on design difficulty can be determined by the project managers. Monitoring of projects is very simple and efficient. In addition to each circuit, each stage needs an examination by the individuals involved. This increases the transparency in the model. Risk management is one of the integrated characteristics of the model, making it more appealing than other designs. This can be used to develop an extremely tailored item.
Constraints of spiral model
The spiral model is an unavoidable complex planning methodology, particularly for initiatives with clear and definite software requirements. Many low-risk initiatives are also not viable. Appropriate compliance to layout provisions and protocols is essential is this model is to be implemented which is very difficult to do during the full development period. Cannot operate for initiatives with tiny or low risks and increase the price. Execution costs are significantly high as this model includes loops.