Wheel and spoke model

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The Wheel And Spoke Model is a sequentially parallel software development model. It is essentially a modification of the spiral model that is designed to work with smaller initial teams, which then scale upwards and build value faster. It is best used during the design and prototyping stages of development. It is a bottom-up methodology.

The unmodified "wheel and spoke model". Programs both contribute to, and receive products from, the core group.
Software development process
Coding Shots Annual Plan high res-5.jpg
Core activities
Supporting disciplines

The Wheel And Spoke Model[edit]

The wheel and spoke model retains most of the elements of the spiral model, on which it is based. As in the spiral model, it consists of multiple iterations of repeating activities:

  1. New system requirements are defined in as much detail as possible from several different programs.
  2. A preliminary common API is generated that is the greatest common denominator across all the projects.
  3. Implementation stage of a first prototype.
  4. The prototype is given to the first program where it is integrated into their needs. This forms the first spoke of the wheel and spoke model
  5. Feedback is gathered from the first program and changes propagated back to the prototype.
  6. The next program can now use the common prototype, with the additional changes and added value from the first integration effort. Another spoke is formed.
  7. The final system is the amalgamation of common features used by the different programs – forming the wheel, and testing/bug-fixes that were fed back into the code-base - forming the spokes.

Routine changes and additions are eventually seen by every program that uses the common code, and the experience gained by developing the prototype for the first program is shared by each successive program using the prototype.


The wheel and spoke is best used in an environment where several projects have common architecture or feature-set that can be abstracted by an API.


  1. Low initial risk. Since one is developing a small-scale prototype instead of a full-blown development effort, much fewer programmers are needed initially. If the effort is deemed successful, the model scale very well by adding new people as the scope of the prototype is expanded
  2. Gained expertise applicable across different programs. The core team developing the prototype gains experience from each successful program that adapts the prototype and sees an increasing number of bug fixes and a general rise in code quality. This knowledge is directly transferable to the next program since the core code remains mostly similar.

See also[edit]


External links[edit]