incremental developmentÑterminology and guidelines · keywords: incremental development, iterative...

Handbook of Software Engieering and Knowledge EngineeringVol. 0, No. 0 (2000) 000-000© World Scientific Publishing Company

1

Incremental developmentÑterminology andguidelines

Even-Andr� KarlssonQ-Labs AB

Ideon Research ParkS-22 370 Lund, Sweden

Email: [email protected]

Many software producing organizations are using alternatives to thetraditional waterfall software development model, e.g. evolutionarydelivery, concurrent software engineering, time boxing, spiral model,iterative development, phased development, versioned implementa-tion, short interval scheduling, or as we prefer to call itÑincrementaldevelopment. The confusion of terminology in this area is large. Theproposed methods are also not very precise on how to apply them,i.e. providing practical guidelines and examples. This article tries tooutline the design space within incremental development, and pro-vide guidelines from our experience where we have worked with orstudied a dozen medium to large (20-1000 kilo man-hours) incre-mental development projects. We also relate this to MicrosoftÕs ap-proach to incremental development.

Keywords: incremental development, iterative development

1. Introduction

Many software producing organizations are using alternatives to the tradi-tional waterfall model to software development, e.g. evolutionary delivery[1] [12], concurrent software engineering, time boxing [2], spiral model [3],

2ÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊHandbook of Software Engineering and Knowledge Engineering

iterative development, phased development, versioned implementation, shortinterval scheduling [4], or as we prefer to call itÑincremental development[5]. These models are usually called life-cycle models.

The confusion of terminology in this area is large. This is confusing forpractitioners who want to compare and evaluate different approaches to de-cide how to implement it in their organization, as well as for researchers whowant to understand and compare what these companies are doing.

The proposed methods are also not very precise on how to apply them,i.e. they provide few practical guidelines and examples, e.g. when shouldyou do increments of this or that type, what are the pitfalls of these type ofincrements?

In this article we outline the design space within incremental develop-ment, and provide guidelines from our experience. This work is based on in-dustrial experience from consultancy and studies of over a dozen medium tolarge (20-1000 kilo man-hours) incremental development projects in thetelecommunication and other domains over the last 7 years, e.g. [18, 19, 20,21]. These guidelines and terminology are successfully applied in these pro-jects to structure their approach to incremental development, and evaluatetheir choice of increments.

In this article we do not go into the reasons that organizations have todepart from the waterfall model, as our aim is not to advocate incrementaldevelopment. The advantages promised by this and other alternatives areoften astonishingÑand are well covered in other sources, e.g. [1, 6, 13, 14,15, 16, 17]. We do also not cover the process of planning increments e.g.[22], nor the requirements on configuration management, build and test [20,23].

The essence of incremental development is illustrated in figure 1.

Fig. 1. Waterfall versus incremental development

analysis implementation test

time

waterfall

incremental

As we see here the idea is to divide the development into smaller incre-ments, which are gradually accumulated to become the complete system.

Incremental development - Terminology and GuidelinesÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊÊ3

The remaining sequential analysis and test activities are discussed in chapter4.

The concept of incremental development is independent of the develop-ment process, i.e. after the project it is not possible to see how many incre-ments the project used, if any. For this article we will use a simple threephase development process with analysis, implementation and test. The arti-facts produced to document the system during these phases we call designitems, e.g. specification, design, code and test cases. The plan of the incre-ments we call the construction plan.

Note that an increment is an abstract concept, and can have several in-stantiations within software development. Some examples are:

• For a product line each release of the product is an increment. Theproduct strategy (if any) is the construction plan. These incrementsare delivered to the customers.

• Within a project there can be several increments, each adding to thefunctionality of the earlier. These project level increments can besystem tested and demonstrated to customers. Larger systems areusually structured in subsystems, where a sub-project or team couldbe responsible for each subsystem. Thus each sub-project and sub-system has to participate in the delivery of the project level incre-ments.

• Each sub-project or team can divide their work within one projectlevel increment into several smaller increments, which could betested in a simulated environment.

One example of a possible situation is shown in figure 2. Here we havetwo releases of the product (1.0 and 2.0). Release 2.0 has two sub-systems(A and B) and is developed in 4 increments. Sub-system A contributes to allincrements (with A1 to A4), whereas sub-system B only contributes to sys-tem increment 1, 3 and 4 (with B1, B3 and B4). The second increment ofsub-system B (B3) contains 3 sequential increments (B3.1-B3.3). Withineach of B3.1-B3.3 there could be 2 different teams involved in deliveringfunctionality (shown with a dashed line inside increment B3).


Fig. 2. Increments on different levels

Release 1.0

Release 2.0Sub-system A

Sub-system B

A1A2

A3A4

B1

B3

B4B3.1 B3.2 B3.3

The parts from sub-system A and B which contribute to the system in-crements could be dependent or independent, e.g. either A3 and B3 are sepa-rately testable and are only delivered to integration at the same time for con-venience or they are functionally dependent on each other. Based on thisdistinction we have found it useful to distinguish between two differentkinds of increments:

• Integration increments are executable and testable. These are the realincrements.

• Design increments are parts of integration increments and are notexecutable and testable without other design increments. A designincrement can be seen as a projection of an integration incrementonto a subset of design items. A team or sub-project usually handlesthese design items.

Note that this distinction depends in which environment we want to exe-cute and test the increments (from simulated to customer environment). Wecould thus have an interleaved hierarchy and aggregation of increments. Re-ferring back to the example in figure 2, assuming we have two test environ-ments, simulated (for subsystems) and target (for system), we could get thefollowing:


• Each team contributes with a design increment to each of the threeintegration increments (B3.1 to B3.3) for simulated test of incrementB3 of sub-system B.

• Sub-system B contributes with three design increment (B1, B3 andB4) to integration increment 1, 3 and 4 for target test on systemlevel. Note that from the figure we can not see if there are any de-pendencies between A1 and B1 etc. If there are no dependenciesthey are integration increments by themselves, and are only synchro-nized for convenience.

Another very important fact about increments is that they are an accu-mulation of functionality, e.g. Release 2.0 builds on Release 1.0.

The terminology and guidelines we discuss here are equally applicableindependent of where one chooses to apply increments.

The rest of this article is organized as follows:

• Section 2 outlines the design alternatives when doing a project in in-crements and the terminology we use.

• Sections 3-6 discuss different alternatives within each of the areas,with advantages, disadvantages and examples.

• Section 7 contains a discussion of MicrosoftÕs approach to incre-mental development.

• Section 8 contains a conclusion and a comparison to related work.

2 Increment alternatives

In this section we introduce the four different but interrelated questionswhich have to be answered when one wants to apply incremental develop-ment. These four questions can be easily explained with the help of figure 3

Fig. 3. Incremental development alternatives


• What is the functionality of increments? The functionality of incre-ments is what is developed in each increment, i.e. what can the sys-tem do at the end of each of the 5 increments in figure 3.

• Which phases do the increments span? Thus how much of the devel-opment process is done in increments versus before the incrementsstart and after all increments are completed. In figure 3 the span isfrom the middle of analysis to the middle of test.

• What is the duration of increments and how are they scheduled? Theduration is the lead-time of each increment, and scheduling how theyare allocated in time. In figure 3 the duration is fixed and quite long,and the increments are partly overlapping.

• How is work allocated? Work allocation is how we organize thepeople, e.g. either per increment (horizontally in figure 3) or perphase (vertically in figure 3 with responsibility for specific develop-ment phases).

There is no right answer to any of these questions. It depends on thecontext of the project and the product to be developed. In section 3 to 6 wewill discuss some of the alternatives we have seen, and some advantages anddisadvantages of each.

3. What is the functionality of increments

This question concerns the type of functionality we develop in each incre-ment, i.e. the type of increment. For this question there are several differentpossibilities. Some of the ones that we have encountered are:

1. Separate user functions are added in different increments. The choiceof when to add which functions can be made based on e.g.:• basicÑadvanced (from a user point of view)• simpleÑcomplex (from a implementation point of view)• criticalÑnon-critical (from a safety point of view)• stability of requirements• cost benefit ratio for customer

Whatever choice is made the architecture and the interdepen-dency between the functions has to be taken into account.


For each function the complete function is implemented, i.e. eve-rything that is needed for the function to work, all error handling etc.We call this alternative feature increment. Note that several featurescan be developed in parallel for one increment.

2 . Simple normal cases, more complex normal cases, without errorhandling and then addition of error handling of different types. Wecall this alternative normal/error increment.

3. Separate system functionality, where for instance start, restart, dy-namic size alteration, commands and traffic handling are examplesfrom the telecommunication domain. We call this alternative systemfunction increment.

These three alternatives are not exclusive, as we can use a combinationof them, i.e. we can use feature increments on an overall level, within eachfeature we use normal/error increments, and within each normal/error incre-ment we use system function increments. In the example shown in figure 2,the top-level increments within Release 2.0 could be of feature type, whereasthe B3.1-B3.3 increments could be normal/error type.

There is some confusion about the difference between prototyping andincremental development. In our opinion there are two main differences:

• The increments are not to be thrown away, each increment providescode and documentation which is supposed to go as untouched aspossible into the complete system.

• Incremental development requires a thorough plan for what func-tionality to develop when, and how it fits together.

There are also similarities, e.g. both approaches have the ability to takeuser feedback into account.

When we select the increments we need to find a suitable balance be-tween several potentially conflicting factors as illustrated in figure 4


Fig. 4. Technical factors influencing the choice of increments

System components

Architecture

Requirements Integration/test

• Architecture means increments to ensure that we have the right ar-chitecture, thus we might want to select functionality, which estab-lishes the backbone of the architecture as soon as possible. The ar-chitecture is also usually the bearer of the non-functional require-ments of the system, e.g. performance, fault tolerance, and restart.We have found that a focus on non-functional requirements whendefining the increments is crucial. This is also a key point in GilbÕsmethod [1]. One practical example is to establish performance goalsfor each increment.

• System components mean increments to establish the usability ofcertain system components to reduce the risks with such compo-nents, e.g. hardware, reusable components, etc. In this case it can begood to integrate the risky component in an early increment wherewe only have made limited commitments to the component in thedesign. If the component is found useless, we can still switch to analternative solution without too much rework.

• Requirements mean increments to compensate for unstable or un-known requirements. It could also mean to choose the incrementsbased on customer priorities.

• Integration/test means increments to ensure the quality of the systemor to optimize the testing.

There are also other factors influencing the choice of increments, e.g.competence where we can use small and isolated early increments to buildup competence in the domain. All of these factors have to do with control-ling the risks in the project with an active use of incremental development.


Risk management is actually the main driver in one of the alternative incre-mental development models, the Spiral model [3].

In the case of development of a system from scratch a sufficiently smallfirst increment is usually difficult to find. In this case we can use a combina-tion of feature and normal/error increments, i.e. we select a minimal set offeatures and for these we implement the normal cases first. Other feature in-crements can then build on the normal cases in parallel with the addition oferror cases for the first feature increment. In the case of development fromscratch or large restructuring we have often seen design increments used.Another alternative when developing from scratch is to base the incrementson system functionality. These two alternatives are further elaborated inconnection with the anatomy and figure 6.

In most projects we have seen a combination of an inside out and outsidein approach to find the increments:

• Outside in: How far can the functionality be split and still be mean-ingful? If we can split the functionality in more pieces than the num-ber of increments which we want to end up with; it will be easier tofind suitable larger increments as combinations of these smallerfunctionalities. One example of this was a project where each re-quirement items, i.e. each paragraph in each requirements specifica-tion, was seen as a potential increment, with associated costs and de-pendencies on other requirement items.

• Inside out: For the complex part of the system, how is it possible tobreak up the implementation, and what is needed around this break-up to provide user functionality. Thus here we will look inside thesystem at the ÒkernelÓ part to see how it can be implemented in in-crements. Usually the key to the increments is in splitting the part,which seems the most monolithic.

This distinction relates to the two dimensions discussed in relation withfigure 4, i.e. Outside in is connected to Requirements and Integration/test,whereas Inside out is connected to architecture and system components.

A concept known as the system anatomy, or anatomy only, has provedhelpful in working out possible increments. The anatomy is a visualizationof the interconnection of the different functionality in the system, where themost basic functionality is shown at the bottom. A simplified example of ananatomy is shown in figure 5. Here each box represents some functionality


of a telecommunication system, e.g. phone traffic. The anatomy can help usto find increments by pointing out the dependencies between the functional-ity in the system. It also helps us to get a better understanding and visualiza-tion of the system. Note that the increments need not be chosen according tothe elements in the anatomy, we could as well provide a thread through theanatomy in the first increment, and then extending this thread in later incre-ments. These two alternatives are shown in figure 6. The left alternative ismore feature type increments or increments chosen from a requirementspoint of view (see figure 4), i.e. we will only build what is needed of thelower level boxes in the anatomy (support functions) for the user functional-ity we will provide. The alternative on the right is more system function typeincrements chosen from an integrat ion/ tes t point ofview.

Fig. 5. Example anatomy of telecom system

Load OS

HW initiation Load Appl

CommandsHW superv

Traffic

Charging SW superv Statistics

Fig. 6. Two alternatives for increments from an anatomy

increment 1

increment 2

increment 3increment 3increment 2increment 1


These two alternatives have different advantages and disadvantages:

• Feature increments tests all the parts of the system at an early stage,thus we can see if they really fit together. We also only construct thesupport functions that are really necessary for the user functionality.

• Feature increments can lead to reopening of the same design itemsseveral times to add new functionality. This is an advantage forlearning, but can lead to more regression testing and possibly un-structured design items.

Note that the anatomy is different from the product structure, i.e. the di-vision of the system into sub-systems and code modules (design items). Theanatomy provides a functional view, whereas the system structure is an im-plementation view.

The majority of software development is not development from scratchbut enhancements or restructuring of existing systems. In this case each en-hancement can form a natural feature increment. The remaining problem isto split large enhancements and restructuring into smaller parts. In our expe-rience large restructuring is the most difficult to do incrementally as we haveall the old code present.

For enhancement projects the total system anatomy can provide an un-derstanding of how the enhancements affect the existing system and gener-ally how they depend on each other. But an internal anatomy of each en-hancement, e.g. feature, is necessary to provide insight into possible incre-ments for the feature and detailed dependencies between features.

4. Which phases do the increments span

This question concerns which phases of the development process the incre-ments cover. Here we need to consider when the increments

• Split, i.e. when in the development process do we stop doing devel-opment breath first and start doing depth first.

• Merge, i.e. when in the development process do we end the incre-ments and deliver a whole product to the next phase.


We call the phases of the development process (from split to merge) thespan of the increment. Both the split and the merge can be at virtually anypoint in the development process, and we can even have several splitting andmerging points, either for the complete product or some increment.

Some of the most common splitting points that we have encountered are(referring to the development process depicted in figure 1):

• During analysis. Here only an overall understanding of the total re-quirements and architecture of the total system is developed beforethe first increments are defined. After each increment the overallplan and architecture is updated. This early split is also used for en-hancement projects where the features are grouped in increments ac-cording to customer priority.

• After analysis. Here the complete set of requirements and architec-ture are known, but the design is not started. It is not necessary thatall requirements are completely stable, but at least we know whichones are and which ones are not, and for the unstable requirementswe have some idea of the range of variation so that this can be takeninto account in the architecture.

• During implementation. Here the design of the system is more com-plete, but the detailed design and implementation is still to be com-pleted.

The decision when to do the splitting is naturally influenced by two fac-tors:

• Early splitting: Less is known about the total requirements and nec-essary architecture. There is an increased risk of wrong initial designdecisions that can lead to a badly structured system and considerablerework.

• Late splitting: Long time spent in the waterfall model reduces theadvantages that we want to achieve with increments.

As for most other choices regarding incremental development there is noright answer. It has to be considered for each project.

There is also some freedom in choosing the merging point:


• Before each separate test phase. This means that all testing after themerging point is executed when all increments are accumulated. Thetest phases could be module test, sub-system test or system test. Notethat we could even define a final review of the design items in a de-velopment phase as a test, and end the increments there.

• Before release to customer. Here the increments are tested to com-pletion as the final system, and the system can in principle be deliv-ered to the customer after each increment.

• Released to customer in increments. This is the most radical alterna-tive where the customer starts to use the earlier increments.

Here it is also a trade-off between early and late merging:

• Late merging: This requires more planning to ensure that the func-tionality of all increments can be effectively and completely tested inthe later test phases without writing a lot of dummy code. Thus thereis a natural latest possible merging point depending on the naturaltestability of the increments. Late merging also implies additionalsynchronization problems between error correction in one incrementand development of the next.

• Early merging. Long time spent at the later phases in a waterfallmode reduces the advantages that we wanted to achieve with incre-mental development, e.g. reduced lead-time by overlapping test andimplementation, early integration and feedback etc.

We can combine different alternatives for which phases each incrementspans with alternative types of functionality of each increment (discussed insection 3). If we continue the example from figure 2 where we had a projectwith a combination of increments we can have

• feature increments spanning from during analysis to delivery to cus-tomer,

• normal/error increments spanning from after analysis to functiontest, and

• finally system function increments spanning from during design tosome test phase (e.g. simulated testing).


The situation is shown in figure 7. Note that we here only show one incre-ment in each group. The existence of several increments means that the startand end of increments within each group is displaced. This is another viewof figure 2, which shows increments on different levels.

Fig. 7. Relation between different increment types

analysis implementation test

feature increment

normal/error increment

system functionality increment

mergesplit

5. How long are the increments and how are they scheduled

The third question concerns three aspects:

• The duration of increments, i.e. how long should an increment lastfrom start to completion

• Fixed or variable duration of increments.• The scheduling of increments, i.e. should they be done in sequence

with all personnel focused on one increment or should we allow par-allelism between the increments.

The duration of increments is connected to the type and span of incre-ments, but within a given type and span we have some freedom with regardsto the duration.

• Short increments keeps up the focus and pressure on the organiza-tion, but can result in a focus on code, and neglecting the otherdocumentation, i.e. developers can be tempted to wait with docu-mentation to the next increment as they are anyway extending thedocuments for that later increment.

• Too long increments bring us back to the problems of the waterfallmodel.


Some organizations have tried very short increments. In the case of HP[7] increments have been down to one week. Here there is one-day planning,two-three days implementation and one-two days test. Microsoft [8] is goingeven further with daily builds. These increments are in our opinion only fea-sible during the later stages of implementation. In extreme programming[15] the recommend increments should last for hours not days. Incrementsfrom three to six weeks spanning implementation and test and four to 20weeks spanning analysis to test are the most common in our experience, ourrecommendation is 8-10 weeks for feature like increments, but shorter forother types of increments. We have also experience from ÒincrementsÓwhich were longer, but they have seldom worked as well as the shorter ones.

Fixed or variable duration of increments also has advantages and disad-vantages:

• Fixed duration makes planning and follow up easier. The schedulesare fixed, and everyone knows what is the goal, e.g. integration thefirst working day of every month. Splitting the functionality intosuitable increments that make sense to integrate can however be aproblem.

• Variable duration increments require more planning and coordina-tion, but the splitting of increments can be done more based on natu-ral functionality.

The last part of this question concerns scheduling of increments. Herethere are in principle two different alternatives:

• Sequential, i.e. all resources are focused on one increment. The ad-vantages here are the focus and no need for coordination betweenparallel increments.

• Parallel, i.e. several partially overlapping increments. The advan-tages here are the longer continuous execution of all phases, the op-portunity to spend longer time with each increment which can benecessary to understand the functionality and the better utilization ofscarce resources, e.g. design items, test environments.

Often projects have chosen to do analysis and implementation in se-quence and in parallel with test.


Three schematic example projects both with fixed duration incrementsspanning analysis to test are shown in figure 8. The first project has 8 incre-ments that are 2 x 4 displaced parallel increments. The second has three dis-placed increments. Note that the project with 8 increments has more oppor-tunities for feedback and learning than the one with 3 increments. The totallead-time is also shorter since there is more overlap between the differentphases. The project with 8 increments will however require better planningand coordination to define and execute more and smaller increments. Thelast project has 4 increments. The overlap between the increments is lesscompared to the others. This has the advantage that more feedback from theprevious increment can be taken into account in the next, and there is lesssynchronization between parallel increments. The disadvantage is that thelead-time will be longer, but if we have only two types of competence, e.g.combined analysis and implementation versus test, and we can utilize allfully, this is a good alternative.

Fig. 8. Three example projects

8 increments

3 increments

4 increments

There is an intrinsic time that is needed to understand and make a goodsolution to a problem or function, and this needs to be taken into accountwhen we select the functionality, span and duration of the increments. Thisapplies for all phases of development (e.g. analysis of a function and specifi-cation of a solution, design and implementation of a central piece of thesystem or test of interacting functions). The strategy of incremental devel-opment for attacking a complex problem is to split the problem into a simpleversion that is gradually enhanced in later increments in parallel with theother activities for earlier and later increments. This would in practice mean:


• Split a complex feature into several increments so that a simple ver-sion can be analyzed in the first, and then extended.

• Split implementation of a complex design item over several incre-ments so that we can gradually enhance it by adding functionality.

• Split complex testing over several increments.

This does however require that we have a fairly good understanding ofthe totality of the problem, so that we choose suitable increments.

6. How is work allocated?

There are basically two different strategies for allocation of work in a projectusing increments:

• Design item responsibility. People are assigned to design items ordevelopment phases, and they deliver the functionality necessary foreach increment.

• Increment responsibility. People are assigned to increments, and theydo the necessary functionality in each design item affected by the in-crement.

The kind of responsibility used is connected to the type of increments(section 3), i.e.:

• Increment responsibility is most natural with feature increments.Here the responsibility is for complete user functionality, and the de-sign items are seen as means to achieve this goal. In particular forenhancement projects this is a natural choice [18, 21]; i.e. the projectis responsible for a new release (figure 2).

• Design item responsibility is more natural for normal/error incre-ments and some cases of system functionality. For normal/error in-crements it is not natural that different persons implement the simplenormal case and the error cases in a design item.

In the choice between design item or increment responsibility we musttake into account whether the complexity is in


• communication, i.e. the interaction between the design items partici-pating in the functionality of one increment is complex, or

• design items, i.e. the interaction of the impacts of different incre-ments on single design items are complex.

Complex communication points towards increment responsibilitywhereas complex design items point towards design item responsibility.

The advantages of design item responsibility are:

• Clear design item responsibility and ownership.• Better knowledge of the design item.• No cost to ÒopenÓ and understand the design item.• Specialist on design item and phase of the process.• May give better solution in design items as consistency between in-

crements can be maintained.• The advantages of increment responsibility are:

• Responsibility for some complete and understandable user function-ality that is usually more rewarding than being responsible for asmall piece which contributes to different functions. It is also easierfor customers and developers to keep in touch, as both are workingon the same level.

• System understanding, even if not an expert on any particular designitem.

• Improved overall solution, i.e. one understands the whole function-ality and can make global decisions.

• Understanding of the overall development process as one incrementis followed through different phases (the span of the increment).

• No hand over of intermediate results between different phases of thedevelopment process. No need to learn the functionality.

We have often used a role called design item coordinator in connectionwith increment responsibility to get the advantages of both worlds. The de-sign item coordinator is then responsible for following the design itemthrough the increments, e.g. participating in reviews, approving solutions,ensuring that it stays consistent and is not misused. The person doing themost work on the design item during the project or the maintenance respon-


sible usually fills this role. It is usually so that even if a design item by itselfis complex and affected by many increments, most of its complexity is allo-cated to one increment, and the other increments are only doing minor exten-sions. In this case the person working on the increment with the major im-pact is a natural choice for the design item coordinator.

Note that design item responsibility and increment responsibility are in-dependent of design and integration increments as described in section 1.The design increment is just the projection of one increment on a subset ofthe design items. These design items can be taken over by someone else inthe next increment, where they also can be split into other design increments.

In the following we discuss some examples of how work has been allo-cated in incremental projects.

One example is increment responsibility in connection with team work(teams of 4-5 persons) for feature type increments spanning from analysis totest [18, 21]. The team has a very concrete common goal (analyze, imple-ment and test the feature), they have different design items to work with(ability to split the work), but all design items must work together to achievethe goal.

Another example is a team of people doing analysis, implementation andtest in displaced parallelism. This can be exemplified by the two projectswith 3 and 8 increments in figure 8, assuming we have two separate imple-mentation phases, e.g. design and coding. Here the analysis people arehanding the analysis of the first increment over to implementation as theystart on the analysis of the next increment thus we have a pipeline. This ofcourse requires fixed duration for each increment as well as developmentphase.

It is possible to use a mix of responsibility in different stages, e.g. startthe project with design item responsibility to learn the design items and thenmove over to increment responsibility for later increments when the archi-tecture is more stable. In connection with teamwork this could mean teamsresponsible for design items in the first increment, then splitting these toteams responsible for increments so that competence from design items isproperly spread.

A mix of design item and increment responsibility can be used through-out the same project, e.g. a few central and complex design items can be de-veloped with design item responsibility whereas the majority of the func-tionality is developed with increment responsibility [21]. Thus the incrementresponsible can implement everything needed for the functionality except the


impacts on a few complex design items, where all impacts are handled bydesign item responsible.

7. Microsoft's approach to incremental development

Microsoft has been applying incremental development quite heavily andwith good results [8,11]. In this section we will briefly describe MicrosoftÕsapproach using the terminology introduced in this article.

Microsoft does incremental development on two levels. Each project is acollection of new features, which are organized into three groups of equalsize. Each group then becomes one top-level increment, which is completedbefore the next is started. The duration of each of these increments is 3-4months. On the lower level increments are on daily basis, i.e. the developeris coding something which is integrated every day to a complete executablesystem. The general idea is shown in figure 9.

Fig. 9. Incremental development at Microsoft

Planning Development Stabilization

Code completeFeature completeVisual freeze

3-12 months 3-46-12

3-8

6-10 weekscodesynchteststabilization

3-5 3-5Integr.test

Buffer

Thus using our terminology the top-level increments can be classified as:

• Feature type.• Rather short span (mainly coding and test), i.e. there is a quite sub-

stantial start-up (Planning) and completion (Stabilization) phasewhich is run waterfall.


• Fixed duration of 3-4 months, and increments are sequential, i.e. oneset of features is completed before the next is started.

• Increment responsibility, as each developer is responsible for one ormore features. Design items (code modules) are shared between de-velopers on an ad hoc basis with merging through the CM system.

The lower level increments can be classified as:

• Unidentified type, as it is up to each designer to develop the code inincrements, but a guess is that some form of normal/error case in-crements are used.

• Very short span, only coding. The reason that this short span can beused without having a lot of documentation that is not up to date isthat Microsoft does not use much design documentation apart fromthe code. Thus the developer is basing the development on the func-tional specification of the feature which is developed in the planningphase before the increments start.

• Fixed/variable duration, i.e. integration every day, but developerscan choose whether to check their code in or not. Since there is noplanned evolution of the design items, not checking in regularly is abig risk for the designer as the system might evolve so that he mustdo a large merge job to get the code in later. The increments areoverlapping as each developer has a buddy tester, which is doingtesting in parallel with new development on the feature the day aftersynchronization.

• Increment responsibility as each designer is doing the necessary up-dates to all code modules impacted by his feature.

As can be seen MicrosoftÕs approach to incremental development is quiteaggressive, but there is not that much structure in the selection and planningof increments. The grouping of features on the top level is rather easy for astable system with a set of relatively independent new functional features.The selection of features can mainly be done based on the requirementviewpoint (figure 4). The lower level increments can be developed rather in-dependently because of the frequent synchronization and that no change tothe system is so large that it can not be done within a couple of days. Theoperating system development in Microsoft is operating under totally differ-ent conditions with major reconstructions or new large subsystems in each


new release. To introduce incremental development in this environmentwould require a different approach with much better up front planing of in-crements.

8. Conclusion

In this article we have tried to provide some consistent terminology andpractical guidelines for incremental development. We have elaborated onfour fundamental questions:

• Type• Span• Duration and scheduling• Work allocation

Since there is a large freedom in implementing incremental developmentit is necessary that we get some more precision in the description of projectswhich have applied it. It is also important that we relate the chosen incre-ments to the development process, as well as the type of project, i.e. devel-opment from scratch, enhancements or restructuring. Thus when describingincremental development projects we recommend to use the followingstructure:

• Description of project (size, type, constraints).• Description of development process (major phases).• Description of increments, i.e. type, span, duration, scheduling and

work allocation.

There is limited related work in this area, most of the work only explainsthe advantages of incremental development, advocates one specific ap-proach, or is very generic, e.g. the Spiral model [3]. A good overview of in-cremental development from a Cleanroom Software Engineering point ofview is provided by Trammel et al. [13. They have the Cleanroom view ofincrements, i.e. increments spanning from a complete specification of thesystem to complete certification, and do not discuss different alternatives toincremental development. Tom Gilb [1] discuss evolutionary development,but also here the choices of increments are discussed very briefly. However


one main point in GilbÕs work is to focus on non-functional requirements inearly increments. Extreme Programming [15] applies extremely short incre-ments (or iterations), but also here there is a lack of guidelines for how tochoose the right increments. Redmill [14] provides a good book on manag-ing incremental software projects, but is also weak on the different choices.

In MIL-STD-498 [9] program strategies are explained in appendix G.The different approaches are shown in the table below.

Strategy Define all re-quirements first

Multiple devel-opment cycles

Filed interimsoftware

Grand design(waterfall)

Yes No No

Incremental(PreplannedProduct im-provements)

Yes Yes Maybe

Evolutionary No Yes Yes

This is a quite coarse classification, which mainly focus on the span ofthe increments.

Davis [10] describes a comparison based on how the development modelsatisfies the user needs illustrated with figure 10. The concepts in the figureare:

• Shortfall: Difference between user requirements and system capa-bilities at any time.

• Lateness is the lead-time of implementation of a requirement.• Adaptability is the rate at which we can incorporate new require-

ments.• Longevity is the time between replacements of systems (the vertical

line represents a replacement).• Inappropriateness is the integration of the shortfall.

This characterization focuses on the behavior of the development modeland is rather orthogonal to our discussion, which focuses more at the internalproperties, and how to apply them.

The concept of increments is related to configuration management con-cepts in the following way:


• An increment will constitute a release of the product.• A release consists of a version of each design item.• For parallel increments the need to handle variants during the project

arises.

References

1. Gilb, T., The principles of Software Engineering Management, Addison-Wesley, 1988

2. Martin, J., Information Engineering Book III, Prentice Hall, 19903. Boehm, B., ÒA Spiral Model of Software Development and Enhance-

mentÓ, IEEE Computer, May 19884. Navigator System Series Overview Monograph, Ernest & Young Inter-

national, LTD., 19915. Mills, H. D., Dyer M., and Linger, R. C., ÒCleanroom Software Engi-

neeringÓ, IEEE Software, September 1987, pp. 19-246. Hausler, P. A., Linger R. C., Trammel, C. J., Adopting Cleanroom soft-

ware engineering with a phased approach, IBM Systems Journal, Vol. 33,No. 1, 1994

7. Head, G., Can Cleanroom Thrive in a Chaotic World?, 2nd EuropeanIndustrial Symposium on Cleanroom Software Engineering, Berlin 1995

8. Anderson, C. ÒAn Operating System Development: Windows 3Ó, Indus-trial Experiences presentation at ICSE 18

9. MIL-STD-498 (Draft, 29 June 1994), Appendix G, Figure 710. Davis, A. M., Bersoff, E. H., Comer, E. R., A Strategy for Comparing

Alternative Software Development Life Cycle Models, IEEE Transac-tions on Software Engineering, Vol. 14, No. 10, October 1988

11. Cosumano and Selby, ÒMicrosoft SecretsÓ, Free Press 199512. McCracken, D. and Jackson, M., ÒLife-Cycle Concepts Considered

HarmfulÓ, ACM Software Engineering Notes, April 1982, pp. 29-3213. Trammel, C., Pleszkoch, M., Linger, R., and Hevner, A., ÒThe Incre-

mental Development Process in Cleanroom Software Engineering,Ó De-cision Support Systems, Vol. 17, No. 1, 1996, pp. 55-71.

14. Redmill, F., ÒSoftware ProjectsÑEvolutionary vs. Big-Bang DeliveryÓ,John Wiley, 1997

15. Beck, K, ÒExtreme Programming explained, Embrace ChangeÓ,Addison-Wesley, 2000


16. Department of Defense, ÒReport on the Defense Science Board TaskForce on Military SoftwareÓ, September 1987

17. Brooks, F., ÒNo Silver Bullet: essence and Accidents of Software Engi-neeringÓ, Computer, April 1987, pp. 10-19

18. Johansen, ¯., Karlsson, E.A., ÒExperiences from using Cleanroom atEricsson in Arendal, NorwayÓ, 2nd European Industrial Symposium onCleanroom Software Engineering, 27-29 Mar. 1995, Berlin

19. Allen, G., Davies, L., Lindmark, G., and Karlsson, E.A., ÒTTM15ÑAlarge multi-site improvement projectÓ, 6th European Software Engi-neering Conference, Sept. 1997, Zurich

20. Karlsson, E.A, and Taxen, L., ÒIncremental development for AXE 10Ó,6th European Software Engineering Conference, Sept. 1997, Zurich

21. Karlsson, E.A., Andersson L.G., Leion, P., ÒDaily build and feature de-velopment in large distributed projectsÓ, International Conference onSoftware Engineering, June 2000, Limerick, Ireland

22. Karlsson, E.A., ÒA construction planning processÓ, 3rd annual Interna-tional Conference on Cleanroom Software Engineering Practices, 9-11October 1996, College Park, Maryland, USA

23. Karlsson, E.A., Andersson, L.G., ÒXP and large distributed projectsÓ,XP 2000, June 2000, Calgari, Italy

incremental developmentÑterminology and guidelines · keywords: incremental development, iterative...

Documents