Incremental Development

 

Software development projects of any size are always implemented in a progressive and incremental manner. It is never the case that all of the code is written before any of it is tested, evaluated, and possibly modified to remove errors or to change parts of the overall design. The many, small progressive tasks, that define the incremental strategy for a given system, are usually planned in advance.

Each step in the incremental development is carefully selected so that:

Testable: a step results in the addition of some functionality that can be tested to gain confidence that it was implemented correctly and that it operates correctly with the code that was added in previous steps. There is little point in adding a small bit of code if is so incomplete that there is no way to test it to determine these properties.

Minimal: a step represents the smallest incremental addition that can be made that is still testable. If the steps are too large (i.e., introduce too much new functionality and code), it becomes difficult to test it as completely as would be desired. Some experience is usually required to gain proficiency with identifying a good set of incremental steps. This project is a good place to start in developing this skill.

Incremental development is critical to developing software for the following reasons:

Easier testing/debugging: at each step there is less new code that is introduced, lessening the number of possible bugs that are introduced and lessening the interactions of the new code with the code already in the system. Since less code is introduced, it is easier to discover where mistakes in the code have been made - there are simply fewer places to look. Lessening the interactions between new and old code is important because problems with the code from previous steps may only be revealed by the introduction of code in later steps. While this detracts somewhat from the "ideal" of progressive development, because backtracking to a previous step may be needed, it still enormously better than the alternative method of dealing with all of the code (and all of the bugs and interactions) in one huge, and usually unsuccessful, step.

Better risk control: a project may present unusual requirements or involve the use of existing services not previously used by members of the development team. In this case, there is a certain amount of "risk" involved in those parts of the system. By identifying those parts of the system, the developer can decide where best to tackle the high risk parts. In some cases it may be better to get some of the well understood parts working and in place first. In other cases, the developer might decide to master the high risk parts first to gain confidence that unknown difficulties in these parts will arise late in the project when changes to large parts of the already developed code might have to be made to accommodate the components that involve the high risk.

Better team organization: In a team project, team members have a better understanding of how their work relates to the work of other team members. In some cases, there may be several independent steps that can be taken, allowing the team members to work in parallel. As team members have different skills and interests, it is more likely that a given team member can be assigned tasks for which that team member is particularly skilled.

Concrete measurability: the set of completed steps (often termed "milestones") can be shown to project managers as concrete evidence of progress. It is far better to have completed half of the steps and be able to demonstrate a partially functional system than to have half of the code written but not integrated or visibly working.
 

Psychological effects: team members have a better mental attitude toward the project resulting from the satisfaction that comes with the completion of individual steps or tasks. These small intermediate "rewards" help to sustain the energy and enthusiasm of the members of the team. A real sense of progress and direction results from the incremental approach.

Your are strongly encouraged to spend some time developing and following an incremental strategy. Even if done very informally, experience has shown that this is a more certain path to success. Remember, this project is not a team project; therefore, all the work for the project must be done by you alone.

  


Back to cs2704 Main Page

Please send comments and suggestions to Ron Arrivillaga: rarrivil@vt.edu