Effort Estimation in Incremental Software Development - CiteSeerX

Prepublication issue - Accepted for publication in IEE Proceedings – Software due in 2004.

1

Effort Estimation in Incremental Software Development Oddur Benediktsson and Darren Dalcher Software Forensics Centre, Middlesex University Trent Park, Bramley Road, London N14 4YZ Incremental software development offers many benefits compared with more traditional development approaches. Indeed, incremental approaches have been utilised for many years due to the involvement of users, the early demonstration of capability and the potential for risk reduction that they offer. However, there appears to have been little work on modelling, planning and controlling incremental development. This paper attempts to introduce a quantitative analytical framework for evaluating such approaches and their impacts on the development effort. Models that predict development effort as an exponential function of product size are used in the paper to explore some of the relationships between effort and the number of increments, thereby providing new insights into the economic impact of incremental approaches to software projects.

1. INTRODUCTION Estimating the development effort for a software system is a long standing problem in software project management. It has generally been noted that the effort is strongly correlated to the program size. A great deal of research has been carried out to relate the effort (E) empirically to the product size, with the effort being commonly expressed in project months and the size in Kilo Lines of Code (KLOC) or in Functions Points (FP). Typical models used to express this relationship are of the form: b

E = c + a Size (1) where a, b, and c are determined by regression analysis using a collection of project outcomes. Some of the better known empirical models are highlighted in Table 1 [1-4]: Table 1: Effort estimation models Author Halstead Boehm – Basic COCOMO - organic Boehm – Basic COCOMO – semidetached Boehm – Basic COCOMO - embedded Boehm et al – COCOMO II.2000 postarchitectural with all parameters set Nominal Walston-Felix Bailey-Basili Doty (for KLOC > 9) Albrecht and Gaffney Kemerer Matson, Barnett and Mellichamp

Base formula E = 0.7 KLOC 1.50 E = 2.4 KLOC 1.05 E = 3.0 KLOC 1.12 E = 3.6 KLOC 1.20 E = 2.9 KLOC 1.10 E = 5.2 KLOC 0.91 E = 5.5 + 0.73 KLOC 1.16 E = 5.288 KLOC 1.047 E = −13.39 + 0.0545 FP E = 60.62 ∗ 7.728 ∗10 −8 FP 3 E = 585.7 + 15.12 FP

The models are seen to vary considerably and can be expected to give different results in individual estimation cases. The estimation accuracy is improved for example in

IEE_Finito_OBDDPostSub.doc


2

COCOMO II [2] by setting a number of parameters to reflect the situation at hand regarding the product, process, platform, and people involved. Note that the effort is an exponential function of the size of the project (KLOC or FP) with the exponent being greater or equal to one in all but the Walston-Felix model. Note further that the above empirical relations are found by taking the outcome of a number of development projects and estimating the parameters. Incremental software development entails the planning, development and release of software products in a sequence of increments or stages, where each additional increment adds operational functionality, or capability, not available in previous releases. Incremental software development is iterative in nature (much like prototyping, using the spiral model, or other evolutionary approach [2, 3]). A note about terminology: The term incremental development as used here embraces the spectrum of iterative development, and incremental development and delivery (ranging from the full product architecting and design being performed up front, to the evolutionary and agile methods with little or no a priory product design). The essence of incremental development relates to the 1930s work of Walter Shewhart on iterative improvement cycles [5]. The X-15 hypersonic jet was developed using incremental ideas which were then in NASA’s Project Mercury (probably the first incremental project involving software development [ibid.]. In the early 1970s, Mills contended that the best way to produce software was to design a main program and to gradually develop the rest of the sub-programs level by level [6], with each module added progressively while paying attention to testing and integration [7]. In 1980, Mills reported the successful completion of the US Navy LAMPS project using incremental development to deliver seven million lines of code in 45 increments [8]. The 200 person-year project was completed in four years with monthly deliveries finalised on time and within budget. The work described by Mills offers a good exemplar of incremental development projects. Incremental approaches emphasise phased development and gradual build-up of functionality by offering a series of linked mini-projects [9]. The approach is underpinned by the assumption that it is possible to isolate meaningful subsets that can be developed, tested and implemented independently. Delivery of increments can thus be staggered as calendar time progresses. Incremental development has long been recognized as an effective way to get the user interested and actively involved in the development of the system in order to ensure a closer fit to real needs and a greater level of user satisfaction [7, 8, 10-12]. Indeed, the staggered release policy allows for learning and feedback to alter some of the customer requirements in subsequent versions thus incorporating user experience into the refined product. The gradual introduction provides time for the client to adjust to the system while also allowing for adjustment of expectations and responsiveness to change. It is also seen as one of the basic ways to enhance risk management and reduce the risk loss potential [1, 2, 13]. Moreover, in keeping with the philosophy of risk reduction, the exposure to risk is limited to shorter time intervals (during which additional knowledge and confidence are gained, thereby reducing the inherent uncertainty) [9]. Technical benefits from the adoption of incremental development are likely to include earlier resolution of implementation problems and design errors, reduced rework, inIEE_Finito_OBDDPostSub.doc


3

creased reliability and easier maintenance [14]. From the client perspective, benefits may also encompass early (and on-going) delivery of functionality, enhanced confidence in the developers’ ability to deliver the right system and greater involvement leading to enhanced familiarity. Additional benefits come from the improved mode of management. These were summarised in [9] and include the controlled release of funds (i.e. responsive cost management), early return on investment, improved resource loading (scheduling) profiles, smaller reliance on external and specialist personnel, stagelimited commitment, lower dependency on external events and deliverables, enhanced visibility, improved feedback, reduced uncertainty, better-informed decision making, better-understood trade-offs and the achievement of warranted performance levels. More crucially, perhaps, incremental approaches offer the potential for countering the diseconomics of scale, not least in terms of addressing the inherent complexity. Whilst incremental development approaches would appear to solve many problems and simplify some management tasks, they also introduce new issues that need to be addressed by project managers and developers, particularly in terms of planning and controlling the effort. For example, within this context, the following questions are likely to arise: • • •

How does the total development effort of incremental development relate to a similar, yet one-off development effort? In what way does the total effort depend on the number of increments? Is there an optimal number of increments?

Project managers may wish to pose more specific questions related to the individual characteristics of a project they are dealing with. Such a scenario may take the following format: •

Suppose that a software package of one million lines is to be developed and incremental development has been specified. The alternatives of using 10, 20, and 40 increments are being evaluated. Is there a difference in the total development effort in the different cases? b

This paper utilises the effort estimation model of the form E = a Size as the basis for exploring some of these questions. The terminology used is that of the COCOMO II model [2]. COCOMO II represents an update to the original COCOMO 81 [1] to account for contemporary development practices and provides a quantitative analytic framework for evaluating software technologies and their economic impacts [15, 16]. The rest of the paper will focus on providing a framework for answering this type of question. The framework will then be populated with a range of values to provide a sampling of scenarios for different project environments. These scenarios offer an insight into the behaviour patterns expected under different conditions. The paper concludes by drawing a set of observations from our results, commenting about the implications of the results and about the advantages of incremental approaches, before finally re-visiting the questions posed in this section in order to provide practical answers.



4

2. INCREMENTAL DEVELOPMENT EFFORT The effort estimation model used here relates the development effort y (in project person-months, PM) to software size x (in thousands of delivered source lines of code or in number of function points) as ( 2) y = a xb where a is termed the effort adjustment factor and b the scale factor. The parameters a and b depend on the product being developed and the project context. Most of the effort estimation models (see table 1 above) have b>1 giving “diseconomies of scale” i.e. project effort increases exponentially with size so that with increasing product size the overall productivity goes down. However note that, this is one place where utilising incremental approaches may impact the overall effort. In incremental development the target system S is delivered in n stages. The development is seen as a sequence of sub-systems S1, S2… Sn where each sub-system is a functioning system delivered to a customer and the functionality increases with each delivery. S1 is considered to be the start of a new system so that S0 can be seen as empty. Each additional delivery enhances the functionality of the system. At end of the development Sn is equivalent to S - the target system. The size of the target system S is represented by x. In a one-off (non-incremental) development this effort is estimated with expression (2). A nominal size of increment i (i.e. the additional functionality, or code, needed to move from Si-1 to Si) is represented by ui and the totality of the increments make up the target system so that x = ∑ ui (3) i

The effective size, xi, of each increment for effort estimation purposes is expressed as x i = u i + ci u i −1 ( 4) where the parameter c reflects the incremental breakage (or overhead) associated with the previous increment. The added work due to breakage reflects the fact that as a new increment is added to a release then some glue-code will be needed, some features and design may be amended, and some code altered. If c has a value of 0.15, it corresponds to 15% breakage. In order to simplify the discussion, it is assumed that all of the code of ui needs to be written from scratch (i.e. reuse is not taken into consideration). Boehm et al give an example of estimating effort in incremental development in Appendix B of their text [2]. The example introduces the possibility of letting the breakage term act on all of the previous code in the system. This paper assumes that the breakage will mainly act on the previous increment as shown in expression (4). The development effort in enhancing system from stage Si-1 to Si involves developing an increment of effective size xi and the effort is thus estimated by using expression (2): b y i = ai x i i (5) giving

∑a x i

bi i

(5.1)

i

as the summary over the given increments. IEE_Finito_OBDDPostSub.doc


5

In incremental development (except for agile development) significant one-time tasks need to be undertaken up front: product design for incremental systems must be well thought out and open-ended so that each additional increment can be incorporated into the architecture defined initially for the whole product. The architecture of the solution needs to allow for breakdown into increments thereby enabling staged development. This requires an upfront effort (encompassing core capability and overall architecture included in the first release) which is over and above the effort needed to develop each increment. The initial effort can be of considerable magnitude, especially if domain architecting and reuse considerations are taken into account. The initial effort is assumed to depend on the one-off effort for developing the target system S as well as n, the number of increments and is expressed as: d n a xb (5.2) where the parameter dn gives the fraction of the one-off effort needed for the initial work. So if dn has a value of 0.1, then 10% of the total one-off effort is needed for the initial tasks. The total incremental development effort is taken to be the sum of the initial effort expressed by (5.2) and the effort of developing the n increments as expressed by (5.1). The total effort, designated z, is then expressed as b z = d n a x b + ∑ a i xi i ( 6) i

The example of Boehm et al [ibid] shows system development in three increments. The product design work for the system as a whole is taken to occur up front and corresponds to the factor dn in expression (6). The factor is set at 24% and the effort is added to the first increment while the design work in the subsequent increments is discounted. Expression (6) is seen to give a high level view of the computations as carried out in the example. Expressions (4) and (6) give z = d n a x b + ∑ ai (u i + ci u i −1 ) bi

(7 )

i

Expression (7) represents a generalised formulation for effort estimation in incremental development: Once the size of the individual increments has been estimated and the parameters set (i.e. the a’s, b’s, c’s and dn), the effort can be computed. It is to be noted that empirical validation has not been carried out for expression (7) as fitting experimental results are not available to the authors. It is hoped that future research will be directed to this area. The nature of expression (7) can be illuminated by computing the ratio r of the incremental effort to the one-off effort i.e. r = z/y with z given by expression (7) and y by (2). This normalisation yields: r = d n + ∑ (ai / a ) (u i + ci u i −1 ) bi / x b (8) i

The ratio r is termed the incremental effort ratio and offers a fundamental mechanism for investigating the residual impact of incremental development. In order to investigate the effect of incremental development two simplifying assumptions will now be made: In the first place all the increments are taken to be of equal size i.e. ui=x/n. Then expression (8) simplifies to IEE_Finito_OBDDPostSub.doc


s = d n + 1/ nb

∑ (a

i

/ a ) (1 + ci ) bi

6

(9)

i

Note that the so-called “time-boxed” incremental development (see for example [17]) centres on constant time frame for each incremental delivery; say twenty working days. In this case it is fair to assume that the increments are of equal size and that the development context is uniform. The effort ratio in expression (9) is labelled s (for equally sized increments.) Note that s is independent of x, the size of the target system. So for the case of equally sized increments the expression gives a general way of exploring how the various parameters (other than the target size) influence the effort. In particular the effect of varying n, the number of increments, can be investigated. Secondly a uniform development situation is assumed so the a’s, b’s, and c’s parameters are all identical. Expression (9) then becomes:

u = d n + (1 + c ) / n b−1 b

(10)

As can be seen, in this case, the incremental effort ratio u is independent of a (the effort adjustment factor) as well as x (the product size). The first term in expression (10) will be referred to as the architectural term and the second term as the incremental term. The following section explores some of the implications of this formulation through the tabulation of sample effort calculations.

3. SAMPLE EFFORT COMPUTATION Expression (10) will now be explored as a function of n, the number of increments. In order to investigate the behaviour implied by the formulation the parameters in the equation i.e. dn, b, and c, will be assigned a range of numerical values thought to represent typical values in praxis. The incremental term by itself will be treated in Section 3.1 and the whole expression in Section 3.2.

3.1 The Benefit from Small Increments Examination of the incremental term in expression (10) reveals the following behaviour with respect to b as n increases: b b1

(1 + c )b / n b−1

as n increases increasing without bounds constant; 1 + c decreasing approaches 0

The case b > 1 is of primary interest. In this case the incremental term is a monotonic decreasing function of n and approaches zero as n increases. So the higher the number of increments the better, or in other words “the smaller the increments the better”! This supports the basic claim of the agile programming community regarding the benefits in working with very small increments. Note that an underlying assumption here is that the basic expression (2) holds for small increments. Note furthermore that dn, the architecIEE_Finito_OBDDPostSub.doc


7

tural term in expression (10) may counteract this by increasing in n, which will indeed be the stand taken in Section 3.3. The linear case b = 1 is strikingly simple as the incremental term reduces to 1 + c and expression (10) becomes u = 1+ d n + c (11) Expression (11) gives a convenient way of approximating the incremental effort ratio when b is close to 1. In the original COCOMO model, Boehm used three classes of project contexts [1]. They were termed organic, semidetached, and embedded and related respectively to the corresponding b scale factors of 1.05, 1.12, and 1.20 (as shown in table 1.) Each of the tables below focuses on one of these classes as representative scale factors. Published values for a breakage (c) are difficult to find. Walker Royce reports a re-work factor of between 0.05 and 0.15 in a study of Ada evolutionary projects [18]. While his Rework Ratio is not identical in concept to breakage, put forward in this paper, it can be argued that it provides an indication of the maximum amount of inflation that should be expected, or tolerated, in such a case. To ensure that worst-case analysis can be carried out, figures covering the full range between 5% and 30% for the breakage value c (i.e. 0.05 ≤ c ≤ 0.3) are included. Note that Cusumano and Selby reported that features may change by over 30% as a direct result of learning during a single iteration [19], thus justifying a higher breakage value, as used below. In the tables below the range of values of n is taken to lie between 2 and 100. This range is considered to be representative of a wide variety of project environments anchored around the number used in the LAMPS project [8]. Note that there is a practical upper bound on n in a given development case, because there is a limit to how small an increment developers want to work with. For example COCOMO II stipulates that a module should be at least 2000 lines of code in size for the given calibration of the effort adjustment and scale factors to hold. If 2 KLOC is taken as minimum size of an increment then a project of say 120 KLOC has n=60 as the maximum value for the number of increments. Tables 2-4 show the computed values for the incremental term for the selected values of b, c, and n. Table 2: The incremental term for b=1.05 n\c 0.05 0.10 0.15 0.20 1.02 1.07 1.12 1.17 2 0.91 0.95 1.00 1.04 20 0.88 0.92 0.96 1.01 40 0.86 0.90 0.94 0.99 60 0.85 0.89 0.93 0.97 80 0.84 0.88 0.92 0.96 100

0.25 1.22 1.09 1.05 1.03 1.02 1.00

0.30 1.27 1.13 1.10 1.07 1.06 1.05

Table 3: The incremental term for b=1.12 n\c 0.05 0.10 0.15 0.20 0.97 1.02 1.08 1.13 2 0.74 0.78 0.82 0.86 20 0.68 0.71 0.75 0.79 40 0.65 0.68 0.72 0.75 60

0.25 1.18 0.90 0.82 0.79

0.30 1.23 0.94 0.86 0.82 IEE_Finito_OBDDPostSub.doc

Prepublication issue - Accepted for publication in IEE Proceedings – Software due in 2004. 80 100

0.62 0.61

0.66 0.64

0.69 0.67

0.72 0.71

Table 4: The incremental term for b=1.20 n\c 0.05 0.10 0.15 0.20 0.92 0.98 1.03 1.08 2 0.58 0.62 0.65 0.68 20 0.51 0.54 0.57 0.60 40 0.47 0.49 0.52 0.55 60 0.44 0.47 0.49 0.52 80 0.42 0.45 0.47 0.50 100

0.76 0.74

0.79 0.77

0.25 1.14 0.72 0.63 0.58 0.54 0.52

0.30 1.19 0.75 0.66 0.60 0.57 0.55

8

Tables 2-4 demonstrate that the total effort decreases as the number of increments increases, as can be foreseen from nature of expression (10) for b > 1. This behaviour is the key economic benefit from the adoption of the incremental approach. 3.2 The Added Cost of Complexity In general, the effort spent up front (represented by dn) can be expected to increase as the number of increments planned increases. This effect will now be modelled in a simple way assuming a linear dependency on n. As discussed in previous section n is taken in the interval n = 2 to n = 100. dn can then be expressed as d n = [( f − e) (n − 2) / 98] + e (12) where dn assumes the value e for n = 2 and f for n = 100. In order to be able to carry out the numerical computations, the architectural effort ratio is anchored at 5% for n = 2 and 15% for n = 100 i.e. e = 0.05 and f = 0.15. This model is taken to be reasonable for demonstrating the behaviour of effort estimation in incremental development. As mentioned earlier additional empirical work is called for to verify the models presented here. The total effort ratio u in expression (10) can now be computed. Tables 5-7 show the results. Table 5: Total effort as a ratio for b=1.05 n\c dn 0.05 0.10 0.15 1.07 1.12 1.17 2 0.05 0.97 1.02 1.07 20 0.07 0.96 1.01 1.05 40 0.09 0.97 1.01 1.05 60 0.11 0.98 1.02 1.06 80 0.13 0.99 1.03 1.07 100 0.15

0.20 1.22 1.11 1.10 1.10 1.10 1.11

0.25 1.27 1.16 1.14 1.14 1.14 1.15

0.30 1.32 1.20 1.18 1.18 1.19 1.20

Table 6: Total effort as a ratio for b=1.12 0.05 0.10 0.15 n\c dn 1.02 1.07 1.13 2 0.05 0.81 0.85 0.88 20 0.07 0.77 0.80 0.84 40 0.09 0.76 0.79 0.82 60 0.11 0.75 0.79 0.82 80 0.13 0.76 0.79 0.82 100 0.15

0.20 1.18 0.92 0.88 0.86 0.85 0.86

0.25 1.23 0.96 0.91 0.89 0.89 0.89

0.30 1.28 1.00 0.95 0.93 0.92 0.92


Prepublication issue - Accepted for publication in IEE Proceedings – Software due in 2004. Table 7: Total effort as a ratio for b=1.20 n\c dn 0.05 0.10 0.15 0.97 1.03 1.08 2 0.05 0.65 0.68 0.72 20 0.07 0.60 0.62 0.65 40 0.09 0.58 0.60 0.63 60 0.11 0.57 0.60 0.62 80 0.13 0.57 0.60 0.62 100 0.15

0.20 1.13 0.75 0.68 0.66 0.65 0.65

0.25 1.19 0.79 0.71 0.69 0.67 0.67

9

0.30 1.24 0.82 0.74 0.71 0.70 0.70

Keep in mind that for u >1, the effort in incremental development projects is larger than the one-off effort, whilst for u 1, for incremental development as compared with the one-off major development effort (this is prevalent for a low value of b and high breakage). However, the tables show that in most cases there is a gain in effort ratio compared to the one-off project (when there is a higher value of b). The behaviour would appear to be dominated by b, thereby suggesting that the greater the scale factor, the higher the need for increments. •

In what way does the total effort depend on the number of increments?

Answer: This question is really a different way of asking the previous question. The ratio of work (and hence the overall work) decreases as the number of increments increases. This is most dramatic for low values of n. Conversely, if one were to reduce the number of increments, it would result in increasing the effort ratio. •

Is there an optimal number of increments?

Answer: The case for 20 increments rather than 2 appears to be persuasive. Obtaining a finer degree of granularity to determine an exact number would depend on the quality of the data and the parameters of the model. •

Finally, if we were to divide a large project into, say twenty equally sized increments, will the total effort level remain constant, increase or decrease as compared to the one-off project effort?

Answer: Table 4, showing the scenario of a lower scale factor, b, suggests that there may be an increase in the total effort. However, table 5 shows that when the level of b rises to 1.12, there is a decrease in effort, thereby providing a clear benefit. When the IEE_Finito_OBDDPostSub.doc


10

scale factor is increased further (table 6), this becomes more pronounced, showing an incremental effort in the range of 60-74% of the one-off effort. Therefore, it would appear that the higher the level of the scale factor, the greater the benefit from adopting incremental development.

4. Conclusion In the sample computations in tables 2-7, the work relies on two important but rather simple assumptions relating to the impact of incremental development. The first asserts that the additional design overhead is linear with the number of iterations. The second posits that breakage can be treated as a constant, independent of the number of iterations. To the extent that the two assumptions are essential simplification, they highlight some of the conditions that lead to significant gains through the adoption of incremental approaches. This offers an incentive to project managers to investigate the effects of making adjustments. In the original COCOMO model [1] under “Component Level Estimation”, a software project is divided into “components” (modules) that are sized separately. The over all project size (the sum of the size of the components) is used to compute the over all productivity that is used as nominal productivity to estimate the effort for the individual components. The gain in productivity derived from working with smaller components is not explicitly realised in this model. In the COCOMO II work [2] appendix B is devoted to estimating for incremental development. Sample computations are given for a 100 KLOC project developed in three increments of size 50, 30, and 20 KLOC. In the computations the scale factor is b = 1.15. The effect of integrating an increment into a previously existing system is accounted for by employing “Adaptation Adjustment Modifier” in the COCOMO II model. The total effort in the worked example is found to be 14% higher than the one-off effort. Consider now that the three increments are equally sized and set the breakage c at 20%. Expressions (10) and (12) above then yield u = 1.10 i.e. 10% above the one-off effort which is not far off from the 14% predicted by COCOMO II. Switching to 20 equally sized increments (of 5 KLOC each) gives u = 0.86 indicating considerable savings as compared to the on-off effort or indeed that of three increments. Looking at tables 2-4, the biggest gain in terms of the reduction of effort appears to come from increasing the number of increments from 2 to 20. Any further increases do not appear to have as dramatic an effect. Looking at tables 5-7, reveals a similar effect for the total effort, including the up-front architectural term dn, as one would expect. This supports the notion of increasing the number of increments, but also shows that there is a limit in terms of differential gain. The framework presented in this paper is not sensitive enough to provide absolute results in terms of identifying exact minima, but it does point to behavioural trends. The following conclusions about the incremental effort ratio u for the simple case presented in expression (10) may de drawn as a result of investigating tables 5-7: • For the low value of the scale factor b=1.01 in table 5, r>1 in most cases showing an increase in the development effort as compared to the one-off case. Increasing the number of increments from n=2 to n=20 shows a decrease in effort of about 10%. • For the medium value of b=1.12, r is down to 80%-90% at around n=40 thus indicating a considerable reduction of effort. • For the large value of b=1.20, the effort ratio is down to 60%-70% at n=60 giving quite significant reduction in effort. IEE_Finito_OBDDPostSub.doc


11

While these results are predicated on a simple case (with equally sized increments etc.) they can taken to be indicative of the behaviour in the general case as indicated by work on size of relative size of successive releases. The results of the paper were brought forth by working with normalised efforts. The normalising factor used was the one-off effort ( y = a x b ) . The normalisation, as exemplified in this paper appears to be of fundamental importance in managing projects and understanding the issues involved in determining the balance between effort and the number of increments. It is notable that this work focused on the effort side of development, in isolation. Additional benefits such as getting the user actively involved, ensuring a closer fit to real needs, allowing for adaptation to changing conditions or enabling the user to adjust to a new technology in increments cannot be easily quantified. Indeed, adopting an incremental approach allows for crucial feedback and learning which add value to the build cycles by improving stakeholder experience, designer knowledge and confidence, and thereby improving the overall fit between need and provision. Incremental development reduces the costs incurred before an initial deliverable capability is achieved (enabling cancellation and adjustment). As a result of utilising incremental approaches, understanding the requirements becomes clearer as users react to earlier increments. The accrued benefits are not limited to the technical side. Risk management practice is improved as a result of the reduction in risk exposure, the spreading of risk across several increments and the opportunity to revisit and readjust risk exposures. Project managers benefit from a reduction in uncertainty, from visible and controllable tangible progress, from maintaining the project momentum and from obtaining smoother staffing profiles. Moreover, the business perspective gains additional leverage from the fact that funds need not be expended upfront, from the earlier utilisation of deliverables, from earlier release (and presence) in volatile and change-intensive markets, and more crucially, from reducing the likelihood of project failures that may damage a brand image. One should consider adopting incremental development when one can avoid major leaps, as it is particularly suitable for situations with evolving requirements or where early presence is needed in the marketplace. It is also useful when it is too risky to develop the whole system at once and acceptable to deliver the system in regular intervals. Thus while the technical benefits explored in this paper can offer a major reason for adopting incremental approaches, additional considerations may make it the preferred way of developing software. The work reported in this paper can be extended in a number of directions to explore a range of potential avenues. In particular, the authors are interested in addressing a number of emerging challenges that include: • • • • •

Collecting empirical data on incremental development to validate the postulated formulation Extending the work to investigate the schedule impact of incremental delivery (which could mean critical effect on market opportunity) Analysing the relationship between incremental delivery and team size Relating the findings to factors expressed in alternative estimation models Utilising a richer estimation model to conduct deeper analysis of the cost/duration implications of incremental development IEE_Finito_OBDDPostSub.doc


• • • • • •

12

Investigating the relationship between incremental development and the ‘evolvability’ of systems Finding ways of reasoning about and quantifying non-technical factors to obtain a more balanced set of project values Developing an earned-value type of method to account for the ‘salvageable value’ (value that can be rescued prior to cancellation) of a project, especially in relation to given increments Evaluating the utility of adopting a long-term strategic perspective that stretches beyond single projects and enhances reuse Increasing the scope of the work discussed here to assess the impact of agile development processes and propose agile estimation models Providing a basis for reasoning about continuation and cancellation of projects (or deliverables) and conducting trade-offs between time, effort and increments in dynamic projects

It is therefore hoped that the work put forward in this paper will serve as an opening for further discussion and investigation. The opening of a new perspective can also stimulate additional insights needed to bridge the gap in the analysis of the economic impact of non-conventional development approaches on the product, process and project.

5. REFERENCES 1. 2.

3. 4. 5. 6.

7. 8. 9.

10. 11. 12. 13.

Boehm, B.W., Software Engineering Economics. 1981, Englewood Cliffs: Prentice Hall. Boehm, B. W., Abts, C., Brown, A. W., Chulani, S., Clark, B. K., Horowitz, E., Madachy, R., Reifer, D., and Steece, B., Software Cost Estimation with COCOMO II. 2000: Prentice-Hall. Pressman, R.S. and D. Ince, Software Engineering: A Practitioner's Approach. 5 ed. 2000, Maidenhead: McGraw-Hill. Vliet, H.V., Software Engineering: Principles and Practice. 2 ed. 2000, Chichester: John Wiley. Laraman, C. and V.R. Basili, Iterative and Incremental Development: A Brief History. IEEE Computer, 2003. 36(6): p. 47-56. Mills, H.D., Top-Down Programming in Large Systems, in Debugging techniques in Large Systems, R. Ruskin, Editor. 1971, Prentice-Hall: Englewood Cliffs, New Jersey. p. 41-55. Mills, H.D., Software Development. IEEE Transactions on Software Engineering, 1976. SE-2(6): p. 265-273. Mills, H.D., Incremental Software Development. IBM Systems Journal, 1980. 19(4): p. 415-420. Dalcher, D., Life Cycle Design and Management, in Project Management Pathways: A Practitioner's Guide, M. Stevens, Editor. 2002, APM Press: High Wycombe. Berrisford, T. and J. Wetherbe, Heuristic Development: A Redesign of Systems Design. MIS Quarterly, 1979. 3(1): p. 11-19. Brooks, F.P.J. No Silver Bullet: Essence and Accident in Software Engineering,. in Information Processing 86,. 1986: Elsevier science. Gilb, T., Principles of Software Engineering Management. 1988, Wokingham: Addison Wesley. Krutchen, P., The Rational Unified Process. 2000: Longman. IEE_Finito_OBDDPostSub.doc


14. 15. 16. 17. 18. 19.

13

Graham, D.R., Incremental Development and Delivery for Large Software Systems. IEEE Computer, 1992: p. 1-9. Clark, B., S. Devnani-Chulani, and B.W. Boehm. Calibrating the COCOMO II Post-Architecture Model. in Proceedings of ICSE 1998. 1998: IEEE Press. Royce, W., Software Project Management: A Unified Framework. 1998: Addison Wesley. Stapleton, J., DSDM Dynamic Systems Development Method. 1997: AddisonWesley. Royce, W.E. TRW's Ada Process Model for Incremental Development of Large Software Systems. in Proceedings, ICSE 12. 1990: IEEE/ACM. Cusumano, M.A. and R.W. Selby, Microsoft Secrets: How the World's Most Powerful Company Creates Technology, Shapes Markets, And Manages People. 1995, New York: Free Press.
