Iterative and incremental development

Iterative and Incremental development is any combination of both iterative design or iterative method and incremental build model for software development. The combination is of long standing[1] and has been widely suggested for large development efforts. For example, the 1985 DOD-STD-2167[2] mentions (in section 4.1.2): "During software development, more than one iteration of the software development cycle may be in progress at the same time." and "This process may be described as an 'evolutionary acquisition' or 'incremental build' approach." The relationship between iterations and increments is determined by the overall software development methodology and software development process. The exact number and nature of the particular incremental builds and what is iterated will be specific to each individual development effort.

Iterative development model
Software development process
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Tools
Standards and BOKs

Iterative and incremental development are essential parts of the Modified waterfall models, Rational Unified Process, Extreme Programming and generally the various agile software development frameworks.

It follows a similar process to the plan-do-check-act cycle of business process improvement.

Overview

A simplified version of a typical iteration cycle in agile project management

The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.

The procedure itself consists of the initialization step, the iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase.

The iteration involves the redesign and implementation of iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the iterative approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a critical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results.

Iterative development.

Phases

Incremental development slices the system functionality into increments (portions). In each increment, a slice of functionality is delivered through cross-discipline work, from the requirements to the deployment. The Unified Process groups increments/iterations into phases: inception, elaboration, construction, and transition.

Each of the phases may be divided into 1 or more iterations, which are usually time-boxed rather than feature-boxed. Architects and analysts work one iteration ahead of developers and testers to keep their work-product backlog full.

Usage

Many examples of early usage are provided in Craig Larman and Victor Basili's article "Iterative and Incremental Development: A Brief History",[3] with one of the earliest being NASA's 1960s Project Mercury.

Another is an "early and striking example of a major IID success is the very heart of NASA’s space shuttle software—the primary avionics software system, which FSD built from 1977 to 1980. The team applied IID in a series of 17 iterations over 31 months, averaging around eight weeks per iteration. Their motivation for avoiding the waterfall life cycle was that the shuttle program’s requirements changed during the software development process".

Some organizations, such as the US Department of Defense, have a preference for iterative methodologies, starting with MIL-STD-498 "clearly encouraging evolutionary acquisition and IID".

The current DoD Instruction 5000.2, released in 2000, states a clear preference for IID: "There are two approaches, evolutionary and single step [waterfall], to full capability. An evolutionary approach is preferred. … [In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability...software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development. It can also be done in phases .

Contrast with Waterfall development

Waterfall development completes the project-wide work-products of each discipline in one step before moving on to the next discipline in the next step. Business value is delivered all at once, and only at the very end of the project. Backtracking is possible in an iterative approach.

Implementation guidelines

Guidelines that drive the implementation and analysis include:

Use in hardware and embedded systems

While the term iterative and incremental development got started in the software industry, many hardware and embedded software development efforts are using iterative and incremental techniques. For example, the large US launch service provider United Launch Alliance (ULA) has undertaken a decade-long project to restructure its launch business—reducing two launch vehicles to one—using an iterative and incremental approach to get to a partially-reusable and much lower-cost launch system over the next decade.[4]

See also

Notes

  1. ↑ Larman, Craig (June 2003). "Iterative and Incremental Development: A Brief History" (PDF). Computer. 36 (6): 47–56. doi:10.1109/MC.2003.1204375. ISSN 0018-9162. We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM's ServiceBureau Corporation]. He was a colleague of John von Neumann, so perhaps he learned it there, or assumed it as totally natural. I do remember Herb Jacobs (primarily, though we all participated) developing a large simulation for Motorola, where the technique used was, as far as I can tell ...'
  2. ↑ DOD-STD-2167 Defense Systems Software Development (04 JUN 1985) on everyspec.com
  3. ↑ Iterative and Incremental Development: A Brief History, Craig Larman and Victor Basili, IEEE Computer, June 2003
  4. ↑ Gruss, Mike (2015-04-24). "Evolution of a Plan : ULA Execs Spell Out Logic Behind Vulcan Design Choices". Space News. Retrieved 25 April 2015.

References

This article is issued from Wikipedia - version of the 11/12/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.