Iterative Incremental Model in Software Engineering

Iterative Incremental Model in Software Engineering: A software development model in which requirements and solutions evolve through a series of 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 I-I 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 I-I method encourages early and frequent feedback so that high-level requirements can be adjusted to reflect the fact that they are not feasible. This is a significant advantage over the waterfall method when it comes to 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.

To obtain the most benefit from this method it is necessary to use techniques that provide appropriate feedback; for example:

I-I (Iterative Incremental) can be organized at three different levels of granularity:

• Phase 0 – Discovery Phase – One or more iterations that may include:
• Phase 1 – Inception Phase – One or more iterations that may include:
• Phase 2 – Elaboration Phase – One or more iterations that may include:

The evolution of the software to implement these requirements is represented by the I-I diagram.

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 down the line.

The model also allows for changes in scope during development by avoiding expensive rework later on into the project cycle which is often required with traditional waterfall lifecycles.

To facilitate the gathering of early feedback, frequent iteration cycles may be necessary if there are many unknowns about the solution to implement. For software developers who are working on a project where they have little or no knowledge about the system and its requirements, it is often possible to complete an entire development cycle over one or two days.

Iterative Incremental Model in Software Engineering

Minimizing the iteration cycles will minimize the number of new 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 a more efficient way to develop and evolve 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 is suitable for many projects that have changeable requirements or start out 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 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 that is clearly 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.

Phases in IID spiral lifecycles

The I-I method has a number of phases. They are:

• Define the business goals and objectives.
• Develop functional requirements, taking into consideration any functional prototypes that have been developed up to this point.
• Implementation – Defines the overall product architecture and its internal structure . This is where details will be included to ensure that the system will function 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 of the product components, from all versions are integrated into a single deployment package that forms part of an integrated solution.
• Maintenance – Maintenance is stage where fixes are made for a production system, or the development of product enhancements and features . At this phase we need to be sure that all possible errors have been found and dealt with .
• Retire – This is the final stage of software life cycle. At this stage project is declared as completed, no additional changes will be done .

Advantages of IID  spiral lifecycles :

As previously mentioned, I-I development methodologies are much less prescriptive than more 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 adopted to projects in a number of different ways.

In order 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 a number of advantages over more traditional methods because:

• It will suit businesses that have a constantly evolving business—If a business is constantly changing, or has a potentially changing functional area that they want to address, an iterative methodology will allow the software solutions created 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 takes into consideration 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 with rapidity, but still ensures that any testing can be done as efficiently as possible.

Limitations of IID  spiral lifecycles :

There are some limitations to the use of 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 any established guidelines on how designs should be created, or how to plan a project. For this reason, it is necessary for software engineers to ensure that they are very clear on what the goals of the project are, and how these can be best achieved while still keeping an eye on budgetary requirements.

Another challenge is that this development method may not be ideal for large complex projects because it is not clear 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 are able to 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 that are very focused on deadline compliance. For these businesses, having no pre-determined schedule for a project and not being able to estimate how much 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 that is best suited for 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 an important consideration 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 are going to be in place during development so that the software solution can be implemented 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 was needed, how easily this can be accessed by users, how easy the program is to navigate, and whether or not the application is secure. After testing one should be able to understand where any 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 that is unlike anything else on the market.

I-I methodologies also offer an excellent way to test a product for its 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 on how to develop an application. This leaves software engineers with levels of uncertainty when planning projects because they are never sure if what they are doing will be in compliance with the method.

Another disadvantage of this approach is that it usually requires a highly skilled project manager who is 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, this can lead to a loss of motivation and ultimately slow 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. This is because software engineers will not know how long it is going to 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 an increase in 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.