Iterative Incremental Model in Software Engineering: A software development model in which requirements and solutions evolve through progressive build cycles. Models are written to implement the current best understanding of system requirements; they are implemented (written), and then subjected to testing and evaluation.
Changes are made to improve the model or solution based on this experimental feedback loop until the stakeholders agree that requirements have been met. The iterative, incremental method is a Software Development Strategy. It generally starts with high-level requirements and evolves towards the implementation details.
This model allows software designers to implement more of their ideas in each iteration rather than deferring decisions about lower levels until a later phase of the lifecycle when it is too late to change them (a common pitfall in the Waterfall development model).
The iterative, incremental method encourages early and frequent feedback so that high-level requirements can be adjusted to reflect that they are not feasible. This is a significant advantage over the waterfall method for software projects (at least during the first iteration cycle). In some cases, it may not be feasible to follow the model exactly despite its power.
This model uses Lifecycle integration and Rapid Application Development techniques to facilitate the implementation of large or complex systems. I-I enables critical information to be obtained early in the software lifecycle so that decisions will not have to be made in a vacuum months later.
The model also allows for changes in scope during development by avoiding expensive rework later in the project cycle, which is often required with traditional waterfall lifecycles.
Frequent iteration cycles may be necessary to gather early feedback if there are many unknowns about the solution to implement. Completing an entire development cycle over one or two days is often possible for software developers working on a project with little or no knowledge about the system and its requirements.
Iterative Incremental Model in Software Engineering
Minimizing the iteration cycles will minimize the number of discoveries and feedback received, which may require a change in direction or strategy. This method can be used to provide rapid development feedback on any system that is being designed: servers, operating systems, network software such as routers and firewalls, messaging and transaction systems; application software such as an electronic payment system or a stock trading systems; even embedded software for mobile phones or network routers.
For most companies, the I-I method is more efficient for developing and evolving business requirements than Waterfall development methods. It also allows more opportunities for feedback before major rework has to be done on the project.
The problem is that the I-I method and its concepts can be difficult to understand and articulate, so it can be improved by linking this concept with more commonly used development models, such as a spiral model.
The spiral suits many projects with changeable requirements or starting life as a prototype or research application. It has a similar aim to the I-I model: to evolve the software through a series of iterations that provide feedback information. However, unlike I-I development lifecycles, it is not designed to have a clear end-state (which could be said to be one of the shortcomings of using Waterfall methods); rather, each iteration should contain significant new functionality and functionality linked to the next iteration.
The Spiral model and I-I method share many of the same practices, such as:
Take a user story that needs to be developed: “As a project manager, I need functionality X to manage my projects.” The project manager defines some initial requirements for this requirement; for example:
It is then the job of the project manager and software engineer to gather feedback about these requirements and evaluate them objectively. They may have opinions about the features they need, but it is essential that they can identify which features are critical for their business. After many discussions with stakeholders, a new set of requirements would emerge, perhaps like this:
The output of one iteration is used as the input for the next iteration. This means that requirements change over time to reflect feedback from stakeholders. This process repeats until the system meets all business goals and objectives.
Incremental Model Phases
The I-I method has many phases. They are:
- Define the business goals and objectives.
- Develop functional requirements, considering any functional prototypes developed up to this point.
- Implementation – Defines the overall product architecture and its internal structure. This is where details will be included to ensure the system functions correctly.
- Test – The tests for each release are defined. This phase may also consider future releases (milestones) and the test cases associated with these milestones.
- Deployment – All product components from all versions are integrated into a single deployment package that forms part of an integrated solution.
- Maintenance is the stage where fixes are made for a production system or the development of product enhancements and features. We must ensure all possible errors have been found and dealt with at this phase.
- Retire – This is the final stage of the software life cycle. The project is completed at this stage, and no additional changes will be made.
Advantages of IID spiral lifecycles :
As previously mentioned, I-I development methodologies are much less prescriptive than traditional software development methods. However, because they do not have a centralized driving force at the start of the project, such as a requirements document or functional specification, IID spiral lifecycles can be adapted to projects in several different ways.
To account for this, project managers and software engineers should discuss how each piece should work together, what the various components mean, and how they will function as part of the overall system. This approach has many advantages over more traditional methods because:
- It will suit businesses with a constantly evolving business—If a business is constantly changing or has a potentially changing functional area that it wants to address, an iterative methodology will allow the software solutions to be tailored to these changes.
- It is flexible – The I-I method allows for more flexibility than other methods because it does not require any particular development strategy or set process. This means that, depending on the business software needs of a particular project, any number of different work strategies may be utilized.
- It is efficient – I-I lifecycles provide an efficient way to plan and create software solutions within reason. They can also be used for agile projects because they allow short iterations for testing and feedback.
- It is cost-effective – I-I methodology can be executed more economically because no project manager or software engineer, when creating the project plan, considers what the final product will look like before it has been thoroughly tested for its functionality and usability. This allows developers to build up a system rapidly but ensures that testing can be done as efficiently as possible.
Limitations of IID spiral lifecycles :
There are some limitations to using I-I development methods, but these can be overcome by a good software engineer who is experienced in building applications. The main challenge with this method is that it does not provide established guidelines on how designs should be created or how to plan a project. For this reason, software engineers must ensure they are very clear on the project’s goals and how they can be best achieved while keeping an eye on budgetary requirements.
Another challenge is that this development method may not be ideal for large, complex projects because it is unclear how a project should be structured. It may also not be suitable for large teams of software engineers and those with little to no experience in project management.
When this method is used to create applications containing many security features, it can become difficult to find experienced testers who can identify exploits or vulnerabilities within an application. This is because a lack of a centralized design can make it more difficult for testers to interpret the overall functionality of complex systems and, therefore, be able to identify where security flaws may lie.
Finally, I-I software development methodologies may not work well in industries focusing on deadline compliance. For these businesses, having no pre-determined schedule for a project and not being able to estimate how many resources will be needed may lead to a lack of trust in the software engineering process.
Because IID lifecycles are very flexible, project managers should ensure they choose a development approach best suited to their business needs. To determine which technology solution is best suited, the business needs of the project must be clearly defined so that they can then be matched to a particular software solution.
Choosing the right development strategy for a project is important because it will dictate how easily and cheaply a company can build its required systems. Particular attention must also be given to what type of processes will be in place during development to implement the software solution as efficiently and economically as possible.
Once a project has been designed, it must then undergo usability testing. This is where there will be an opportunity to assess whether or not the solution provides everything that is needed, how easily users can access this, how easy the program is to navigate, and whether or not the application is secure. After testing, one should understand where flaws are within the software before these have been made public.
Summary of I-I process lifecycles: The advantages of I-I development methodologies include flexibility, the ability to plan in short iterations that can easily be changed if necessary, and fast development. It is also very good for innovation because programs can be developed unlike anything else on the market.
I-I methodologies also offer an excellent way to test a product’s usability before it has been thoroughly tested for functionality. This overcomes the limitation of other lifecycles that may force software engineers to undertake tests in the wrong order, which can lead to costly mistakes.
The main disadvantage of this method is that it does not have a structure like other methodologies do, and therefore, there are no guidelines for developing an application. This leaves software engineers uncertain when planning projects because they are unsure if their actions will comply with the method.
Another disadvantage of this approach is that it usually requires a highly skilled project manager capable enough to organize and direct a large team of developers. This can be problematic because software engineers may not want to work for someone who does not have experience in this field. They are also more likely to get bored by repetitive tasks, leading to a loss of motivation and ultimately slowing down the development process.
In some situations, I-I methodologies may not be as suitable for businesses that are focused on deadlines and have an estimated completion time for a project. Software engineers will not know how long it will take them to complete the program until they have programmed it. It is also unsuitable for businesses that want to see how the software performs before they commit to buying it.
A final disadvantage of this approach is that if not properly managed, the absence of a strict structure can lead to increased costs and time taken to develop a program. However, since I-I methodologies have a small amount of focus on security, this is not as much of an issue if the developer has experience with software development.
