Blog to understand automation concepts in QTP, Selenium Webdriver and Manual Testing concepts

Understand Iterative and Incremental Development Model

In Iterative and Incremental Model, the whole requirement is divided into various sub–requirements or builds. Each build in itself follows waterfall model, i.e. each build passes through requirement, design, implementation and coding. The need for incremental and iterative model arise and is very useful in scenario where requirement changes frequently or we are working on an idea and the detailed requirement may not be clear at the start of development but a high level vision of the end product is available to us.


As the name suggest, this model will consider both iterative and incremental development. Before we discuss this in detail, let us know what iterative and incremental means. Various parts of the system are developed at different time and are integrated into the existing developed work once they are completed. And iterative strategy assigns time for rework and improvement in the part of system developed, thus continuously working in iterations to rework and improve the system adding more features in an iterative manner.

Iterative and Incremental Model
IID Model
To start with this model, we divide the project in a number of modules or stories. Each module/story represents functionality or use case in the product. Stories should be created or planned in such a manner that each story covers a feature of product, has set of entry and acceptance criteria and needs to be of shorter span of time, may be few days to few weeks. 

This is the analysis phase where we have analyzed the various stories from the requirement based on the features expected from the product. With each story having its own story means features  which will have a short span of time to complete.


Now once we have analyzed all the stories in the requirement, how do we react to stories, Do we start working on all stories together in a bang bang manner or do we need to priority to the stories, We will start with the story with most risk and complexity, and before this will complete on other smaller stories on which the most complex and risk story is developed. Once the complex piece is selected, we work on following a small waterfall on the story, 


We start with analysis, then design, coding and then testing the code, but with regular feedback at each of the steps.


The first piece will take a longer time compared to next stories but will provide useful immense information on the feasibility of the project, Knowledge to team on the product and possible bottlenecks in the development of project. It is strictly advised not to set deadlines for the initial few pieces as it will act as guidance to rest of stories on how long it will take to develop another story in the project.

Once we develop another story, we add it to existing product thus increment the functionality added to existing product and at the same time, we do iteration to improve and rework to existing developed piece based on defects, feedback from various stakeholder. 

All the pieces are developed, integrated with existing developed functionality, once the piece is fitted with rest of the developed pieces, we can have feedback and testing on the incremented product so that we can do rework and review the product. The development happens in an incremental and iterative manner unless the completed product is developed.

Where to Use IID Model

  • Major functionality and goal of development are well defined, but features and enhancement mayevolve with time.
  • IID is very useful in case of development with new technologies to validate a prototype filling preparing the complete.
  • High Risk features which may change in future.


Positives in the Model

  • An initial working product is developed in the early stages quickly.
  • Developing the initial product early helps in getting feedback and defect Identification early in the lifecycle.
  • We can work on different stories/pieces at the same time.
  • Continuously improving the product by rework and review is possible based on iterative nature of development.
  • Risks are identified in a better manner and can be implemented in the remaining project development.


Negatives in the model

  • The timelines of the project are not fixed and can change drastically based on requirement change.
  • Sometimes incorrect implementation of model can lead of frequent requirement change and estimation of project.
  • Initial development which helps in identifying risks in the system required experienced risk analysts as incorrect risk analysis during initial phase may lead to failure of development.
  • Management complexity is higher.


No comments:

Post a Comment