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.

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.

Understanding Waterfall Model from a tester's perspective

      In this article, I will describe the waterfall model and understand it in a better way myself too.

      Waterfall Model is a sequential process model used in SDLC in which sequence of activities flows from top to bottom in a linear manner with next activity starting once previous activity is completed. Normally, The Output of the first activity acts as an input to the subsequent phase in waterfall model, also changes in the analysis can be traced back to previous phases if any change is identified in later phases of SDLC.

      Waterfall model can also be described as a document driven approach as communication depends on the quality and quantity of documentation.

This was first of the models used in Software Engineering provided by Winston W. Royce in an article published in 1970. Since the Software Industry evolved a lot in the past 40 years, new models and methodologies have also evolved which covers the shortcoming of Traditional waterfall model, but some or other features of waterfall Model are used in various other software methodologies. Therefore it is useful to understand the waterfall model before discussing other models.

Different Phases in Waterfall Model are described in the section below:

a. Requirement Analysis: 

In this phase, the requirements are understood from the client and analyzed. To Understand requirement , customer are consulted, the feasibility of the requirements are understood and based on all the inputs, business requirement specification is developed and is signed off by client as an agreement between client and supplier on the agreed functionality.

b. System Design: 

Before starting with system design, all the requirements are freeze in the requirement phase. The requirement documents acts as an input to this phase and based on this a system design is prepared in this phase.

c. Architecture Design:

  The system design is analysed and an architecture design dividing requirement into module based on functionality is developed. The input for this phase is the system requirement documents and output helps in preparation of low level design for the projects.

d. Low Level Design: 

In this phase, low level design at module level is developed which acts as input to coding phase. The high level design or Architecture design acts as input to this phase.

e. Coding: 

The Low level design is implemented to code. All the code is merged together and various modules are integrated together to form a system as defined in System design.

f. Testing:  

When Coding is completed, the code is passed on for testing and various testing types are conducted on the code and the defects are passed on to development team . Based on the defect impact, there needs to be changes implemented at code level or can impact the previous levels. The more the impacted phases, more will be the cost of fix.

g. Operations and Maintenance:

 Once testing is completed, the system goes to Production. Support and maintenance team helps in maintenance of the product.

Waterfall Model

Where to Use Waterfall Model: 

Waterfall model is most useful to be followed in projects where:

a.  Requirement is very well documented and probability of requirement changes is low.

b.  Expertise of resources is available to ensure each phase is completed with minimum gaps and rework.

c.  The time span of the project is short.

d.  The Project is stable with minimal requirement changes 

 Waterfall Model Positives:

a. Easy to understand and manage as the milestones in project are defined and mostly at a time only one phase is active, so needs to manage one phase only at times.

b. Processes are well defined.

c. Documentation is done properly for each of the stages in the life cycle.

d. Developing a culture of analysis before coding as there is thorough analysis from requirement to design to coding.

  

Waterfall Model Negatives:

a. The major negative of the model is the risk and uncertainty associated with the model which can arise due to below reason:
        a. Requirement change at a later stage.
        b. Since the application is not developed till a major part of life cycle, Actual feedback on functionality happens late in the life cycle

        c. The cost of fixes is high if uncovered late in the life cycle

b. Most of the defects are uncovered in system testing phase which results in a lot of rework and at times changes in the design, which can impact the timeline and acts as major threat to the success of the project.

c. At times, the testing time shrinks in the waterfall model due to delay in earlier stages of model. This can led to defects escaping the testing phase, which if uncovered in production can result in higher costs and can impact business too.

 Conclusion: 

Waterfall model was first of the model to be used in Software development model and acted as a basic framework to track and relate various phases of development. With time, various new models of Software development life cycle evolved, for e.g. V-Model, Iterative model, agile Model and so on, but somewhere we can see glimpses of waterfall in each of the models. Hence Understanding the most basic of models is highly useful before going to understand newer model that evolved over the years in SDLC.

Testing Models - Understanding V-Model from testing perspective

V-Model is a software development  Model which shows software development life cycle to follow a V shape. V-Model was developed with the intention to cover some of the problems found in waterfall Model with one of the main issue as defect uncovered late in the Software development life cycle.

The main purpose of representing in a V is to show the relationship between each phase of development life cycle with its associated phase in testing. The execution of processes happens in a sequential manner in this model. This is also sometimes called as Verification and Validation Model

During the initial stage, i.e. from requirement to Coding and Implementation are verification phase and then from Coding and Implementation to User Acceptance testing are Validation phases in the model.

Before continuing with understanding the responsibility of testing in various phases of a V-Model, we must distinguish between Verification and Validation.

Objective of Verification is to ensure the product is being built according to requirement .Walk-through, reviews, inspection are some of the activities, whereas objective of Validation is to ensure the product build meets the user requirement. Whereas Verification activities are mostly done during product building process, Validation is done post product is build

Below are the activities performed by testing team during various stages of V-Model.

a. Requirement Analysis

 Testing tasks includes preparation of User Acceptance testing plan to be followed during UAT testing during the first phase of V-Model. Involvement of testing team early in the requirement help understanding the requirement and analyzing gaps and refining requirements based on scenarios identified for User Acceptance testing.   

b. System Design

 Once we have the requirement signed off by the customer, the developer and testers in parallel starts to work on system development design and system test design respectively.

c. Architecture Design

In this phase, test and plans related to integration testing of different modules are created. From development point of view, In this phase, high level design of the system is created starting from dividing requirement into different modules based on functionality and the interaction of modules defined with each other , external world as well as existing modules if the new functionality is an added functionality in the existing system.

d. Module Design

This phase from development point of view defines the low level design of each of the modules.  To ensure each module is working correctly, to test the internal structure of the module, we need to create unit test cases to test units in the module. Unit testing is mostly performed by developers as is mostly related to internal structure and design of modules.
   

e. Coding and Implementation

Next Phase in the V-model is implementation of low level design into code. So in all the above phases of the V-Model, similar to developers, testing phases occurs in parallel and does verification and analysis at each phase and prepares for testing.

f. Unit Testing 

 Once Coding and Implementation is completed, we need to execute unit test to verify the designed has been coded and implemented properly. Units are tested as they are developed. Unit tests prepared during Module designed are executed to unit test the modules individually

g. Integration Testing

Once the modules are unit tested individually, it is the time to test integration of modules with other modules and external systems. Integration test prepared during Architecture design are executed in this phase.

h. System Testing

 Once we have tested the modules followed by Integration of modules and external systems. Next step is to verify whether the system is working properly and as defined in the requirements
    

i. Acceptance Testing

 Once the system is tested properly by QA Team, it is passed on to customer to perform User acceptance test. This can be performed by client or UAT Team designated by client.Please note from  step f. on wards, we started in step a. to e., the necessary test preparation and analysis tasks.
  

Conclusion  On a whole, V-Model is a much disciplined Model with salient feature including testing starting as early as possible from requirement phase. Requirements are clear and properly analyzed by different perspective, i.e. business analysts, testers and developers. This model has shortcomings in case of some requirement changes in between the software development life cycle