ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS

7/28/2019 ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS

1/41

ATHABASCA UNIVERSITY

ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE

FINANCIAL BENEFITS

BY

FRANCOIS NADEAU

An essay submitted in partial fulfilment

Of the requirements for the degree of

MASTER OF SCIENCE in INFORMATION SYSTEMS

Athabasca, Alberta

May, 2007

Francois Nadeau, 2007


2/41

DEDICATION

To Yoko who supported me during my studies and who has opened my eyes to the world, and to my

parents who sacrificed so much to raise me.

i


3/41

ABSTRACT

The use of the iterative delivery process has been popularized by the agile movement, and has now

become a well-understood and often used process for developing software. This thesis examines the

techniques for estimating the cost of software projects, and investigates whether projects which use the

iterative delivery process can be evaluated more favourably than projects which do not use this process.

For this purpose, expert-based estimation and formal mathematical model estimation techniques are

reviewed and discussed. Various mechanisms which can be employed to find an iteratively delivered

project's release plan are then reviewed, as well as the business models used by software vendors to

produce software for their customers. This thesis concludes that the use of the iterative delivery process

does not affect a project's estimated level of effort. Thus, knowing that this process will be used to

develop the project does not lower the estimated development cost. However, it is possible to demonstrate

that a project's return on investment (ROI) will be higher if the iterative delivery process is used instead of

a sequential delivery process such as the waterfall methodology. This occurs because software delivered

during iterations can generate income before the entire project has been completed. Furthermore, it is

argued that a higher ROI may be realized by combining the iterative delivery process with the service

oriented-business model.

Keywords: Iterative delivery process, software effort estimation, release planning, service-oriented

business model.

ii


4/41

Table of Contents

CHAPTER I.....................................................................................................................................................1INTRODUCTION......................................................................................................................................1

Introduction............................................................................................................................................1

Statement of Purpose.............................................................................................................................2Significance...........................................................................................................................................2Limitations.............................................................................................................................................3

Definition of Terms...............................................................................................................................4Organization of the Essay......................................................................................................................5

CHAPTER II...................................................................................................................................................6SOFTWARE COST ESTIMATES.............................................................................................................6

Introduction............................................................................................................................................6Quantifying effort..................................................................................................................................7

Line of code (LOC)..........................................................................................................................7Function Point (FP)...........................................................................................................................8

Expert judgement-based estimation......................................................................................................9Bottom-up.........................................................................................................................................9

Top-down..........................................................................................................................................9Formal Mathematical Models..............................................................................................................10

COCOMO.......................................................................................................................................11Conclusion...........................................................................................................................................13

CHAPTER III................................................................................................................................................15RELEASE PLANNING...........................................................................................................................15

Introduction..........................................................................................................................................15Ad hoc Approach.................................................................................................................................17

Planning Game.....................................................................................................................................17Optimization-Based.............................................................................................................................18Kano Model of Customer Satisfaction................................................................................................19

Incremental Funding Methodology (IFM)..........................................................................................20Conclusion...........................................................................................................................................22

CHAPTER IV................................................................................................................................................23BUSINESS MODELS..............................................................................................................................23

Introduction..........................................................................................................................................23Product Oriented (PO) Business Model..............................................................................................23

Service Oriented (SO) Business Model..............................................................................................24Hybrid Oriented (HO) Business Model..............................................................................................25

The Open Source Movement...............................................................................................................26Conclusion...........................................................................................................................................26

CHAPTER V.................................................................................................................................................28

CONCLUSION AND RECOMMENDATIONS.....................................................................................28Conclusion...........................................................................................................................................28

Product Quality....................................................................................................................................28Release Planning..................................................................................................................................29

iii


5/41

Business Model....................................................................................................................................30

Further Research Suggestions .............................................................................................................31

iv


6/41

LIST OF TABLES

Table 1: Function Point Types.........................................................................................................................8

Table 2: Effort Estimation Models................................................................................................................11Table 3: COCOMO Project Type..................................................................................................................12Table 4: COCOMO Coefficient Values........................................................................................................13

Table 5: Feature Categories for the Kano Model..........................................................................................19Table 6: Kano Categorization Matrix...........................................................................................................20

v


7/41

LIST OF FIGURES

Figure 1: Projected Cash Flow for the Sequential Life Cycle ......................................................................16

Figure 2: Projected Cash Flow for the Iterative Delivery Life Cycle...........................................................16Figure 3: Manipulating Financial Metrics through Resequencing MMFs...................................................21

vi


8/41

CHAPTER I

INTRODUCTION

Introduction

In today's aggressive business world, few executives are willing to bankroll large IT projects with

delivery dates in the far future. While some computer scientists may lament this change in business

vision, the fact is that today's business executives no longer see IT projects as soon-to-be-cash-cows,

but instead as investments to be analysed in the same manner as any other infrastructural investments. In

order to be financed in this environment, IT projects need to shorten their investment periods, quicken

their time-to-market, and respond quickly to internal or external events which may affect the project.

Some software practitioners have started to use the iterative delivery process to better handle these

difficulties.

Software development projects which use an iterative delivery process deliver their project's

features incrementally throughout the development life cycle. This is normally accomplished by

constructing a small part of the system, and then allowing a subset of the end users to either use the

software or to test it. In this way, each of the iterations are used to demonstrate that some features have

been adequately implemented, and allows for the collection of feedback from the end users. For example,

a development team could provide its users with the capability to enter data even though the system may

not yet allow them to retrieve and view this information.

The advantages of the iterative delivery process have been well documented[1]. They include:

lower production and maintenance costs, increase in product quality, and an increase in the product's

fitness of use. These advantages provide a competitive edge for companies which have successfully

implemented a methodology which uses the iterative delivery process.

1


9/41

The use of the iterative delivery process does, however, create some difficulties. For example, one

of the greatest advantages of the iterative delivery process is that it permits the development team to delay

making design decisions which need to be taken at an earlier stage with the use of other methodologies

[2]. This benefit results from the fact that the team will only work on the features which are to be released

on the next iteration. In this manner, the software's design is not restricted and new information can be

used to implement future features without, in theory, requiring that the team greatly modifies its previous

work. To allow this to happen, software requirements are not fully analysed, and the customer is not

locked into their requirements at the beginning of the development cycle. Overcoming the contractual

difficulties and evaluating the financial value of this feature during a project's bidding stage can be a

daunting task.

Statement of Purpose

This thesis will examine the techniques used to estimate the cost of software projects, and will

investigate whether projects which use the iterative delivery process can be financially more attractive

than projects which do not use this process. The author proposes to evaluate the potential financial

benefits of the iterative delivery process, and the possible manner in which a software company's

response to a request for proposal can be made so that it is financially appealing to the customer.

Significance

A great deal of research has been conducted about methodologies which uses the iterative delivery

process, such as Adaptive Software Development (ASD), Agile Modeling, Crystal Methods, Dynamic

System Development Methodology (DSDM), Extreme Programming (XP), Feature-Driven Development

(FDD), Lean Development, the Rational Unified Process (RUP), and Scrum. However, most of the

literature does not make a business case for the change, but instead focuses on the techniques which can

be applied to increase a software development team's agility.

2


10/41

Software effort estimation methods can be classified as belonging in one of two groups; expert

judgement-based, or formal mathematical models[3]. Expert judgement-based estimations methods rely

on an expert's judgement in order to evaluate and estimate a software project's effort cost. Methods in this

category include expert consulting, intuition based on experience, and analogy. These techniques have

been found to be the most commonly used estimation methods in the software industry[3].

Formal mathematical models, such as COCOMO, can be used to estimate a project's effort in

project months, kilo lines of code (KLOC) or function points (FP). Most of these models are based on the

assumption that the total effort required to complete a project will increase exponentially in relation to the

the project size[4]. Although a great deal of research has been conducted with regards to these models,

there is no evidence that their use will lead to more accurate estimates[5]. This reason, coupled with the

fact that the use of these models can be more complicated than using one's gut feelings, may be the

reason that the majority of the software industry has not adopted these models for cost estimation.

Limitations

Moving to an iteration delivery process can be difficult and costly for some organizations. This

thesis does not address these costs, and whether or not they will be recovered once the investment has

been made to change the development process. While these are important concerns for organizations

which have not yet moved to an agile methodology, the author believe that these changes will be forced

onto all software developers in the same manner as that by which just-in-time production was adopted by

the manufacturing industry; that is, organisations will either adapt or go out of business.

This thesis does not present any methodologies which use the iterative delivery process, but

instead builds on what has already been published. In other words, the findings in this thesis are expected

to be applicable to any methodology which uses the iterative delivery approach.

Another limitation of this thesis has to do with quality. Software products which are considered to

3


11/41


12/41


13/41


14/41


15/41

The use of expert judgement or Program Evaluation and Review Techniques (PERT) are common

techniques used to estimate a project's LOC. The former will be explained in more detail latter on in this

chapter. The latter uses expert judgement to evaluate the most optimistic LOC (O), the most likely LOC

and the pessimistic LOC (P). These values are then used in formula (1) to find the estimated LOC (E).

E=O4TeP

6(1)

Function Point (FP)

FP is a measurement method which is used to quantify a software project's functionality. This

method uses the sum of five distinct types, adjusted by their estimated level of complexity. Table 1

describes these types. An advantage of using FP, instead of LOC, is that they can be more accurately and

easily calculated before the project has been started.

Table 1: Function Point Types

FP type Description

User-input : user-entered inputs, e.g. inputs through a graphical user interface(GUI)

User-output : outputs which are required to be displayed by the system, or which

must leave the system, e.g. output filesInquiry : interactive inputs which produce a response from the system, e.g.

charts or reports which are viewed within the application

Internal file : logical groups of persistent data which are used exclusively by thesystem, e.g. a database columns, or configuration files

External file : logical groups of persistent data which are used by the system aswell as one or more external systems, e.g. columns in a database

which are shared by multiple applications

Value adjustment for each of the discovered FP Nij in the system is completed by estimating

the FP's level of difficulty Wij . These are classified as simple, medium, or complex, and are assigned

the value of 1, 2, or 3, respectively. Formula (2) describes how these values are compiled.

8


16/41

FP=i=1

5

j=1

3

NijWij (2)

For example, if a project's FPs are evaluated to be 1 simple inputs, 2 medium outputs, 3 complex

inquiries, 4 simple internal files, and 5 medium external files. Then the FP for the project is as

follows:

FP=1122334152=28

Expert judgement-based estimation

Expert estimation can be described as estimation conducted by persons recognised as experts, in

which important parts of the estimation process are based on non-explicit, non-recoverable reasoning

process such as intuition. Expert estimation strategies includes vague techniques such as gut-feeling, and

more structured techniques such as history-based expert estimation[12]. Expert estimates typically deal

better with vague requirements than mathematical models do. Expert estimation strategies can be

categorized as belonging to either the bottom-up or the top-down approach.

Bottom-up

Estimates which use a bottom-up approach typically divide the project into activities, and estimate

the effort required to complete each of these activities individually. The project's effort estimate is

evaluated as the sum of the effort required to complete each of the activities, with the possible addition of

a budget to cover unexpected activities or events. This is most often accomplished by developing a Work

Breakdown Structure (WBS)[8]. This approach can be more beneficial than the top-down one for re-

estimating the remaining activities required to complete a project.

Top-down

Estimates which follow a top-down approach estimate the total effort of a software project without

decomposing the project into activities or other types of project parts. For instance, an estimation strategy

9

Te,


17/41

may be to compare the entire project with previously completed projects which have similar

characteristics. This strategy has some advantages when estimates are needed for ROMs with vague

requirement specifications that don't enable the creation of a detailed WBS of the activities to be

developed.

Formal Mathematical Models

Formal estimation models, such as COCOMO, can be used to estimate a project's effort in project-

months, kilo LOC (KLOC) or FP. Although a great deal of research has been conducted with regards to

these models, there is no evidence that their use will lead to more accurate estimates[5]. This fact,

combined with the fact that the use of these models can be more complicated than the use of personal

experience, may be the reason for which these models are not used by the majority of the software

industry.

Formal models are typically expressed in the following form:

E=caSizeb (3)

where E represents the effort in man-month, c, a, b are determined by analysing historical data from

completed projects, and Size is measured either in KLOC or FP. Table 2 presents a short list of some of

the models which have been proposed.

10


18/41

Table 2: Effort Estimation Models[4]

Author Base formula

Halstead E=0.7KLOC1.50

Boehm Basic COCOMO organic E=2.4KLOC1.05

Boehm Basic COCOMO semi-detached E=3.0KLOC1.12

Boehm Basic COCOMO embedded E=3.6KLOC1.20

Boehm et al. COCOMO II.2000 post-architectural

with all parameters set Nominal E=2.9KLOC1.10

Walston Felix E=5.2KLOC0.91

Bailey Basili E=5.50.73KLOC1.16

Doty (forKLOC > 9) E=5.288KLOC1.047

Albrecht and Gaffney E=13.390.0545FP

Kemerer E=60.627.728108

FP3

Matson, Barnett and Mellichamp E=585.715.12FP

Most of these models are based on the assumption that the total effort required to complete a

project will increase exponentially in relation to the the project size. This implies that software projects

have a dis-economy of scale associated with their development.

The following section describes the COCOMO model, which is one of the most popular models

from Table 2.

COCOMO

The COnstructive COst MOdel (COCOMO) was original proposed by Barry Boehm in 1981. This

original model, often referred to as COCOMO 81, was upgraded during the 1990s to account for

technological novelties in the software industry. These revisions, named COCOMO II, still use the same

basic model presented in COCOMO, but now permit its users to enter additional input in order to increase

the result's accuracy.

COCOMO consists of three different levels; basic, intermediate and detailed. Each of these levels

require different amounts of data, and provide different levels of estimate accuracy. For the purpose of

this discussion, the basic level, which is also used by the other two levels, will be briefly described in this

11


19/41

section.

The first step in estimating a software project with COCOMO is to determine the type of project

which will be estimated. Table 3 describes the different types of projects which can be estimated with the

COCOMO model.

Table 3 : COCOMO project type[13]

Project Type Description

Organic relatively small, simple software projects in which small teamswith good application experience work to a set of less than rigid

requirements

Semi-detached intermediate (in size and complexity) software projects in whichteams with mixed experience levels must meet a mix of rigid and

less than rigid requirements

Embedded software projects that must be developed within a set of tighthardware, software, and operational constraints

Once the appropriate project type has been selected, the following equations are used to find the

effort (E) in man-months, development time (D) in chronological months, and the number of people (P)

required for the project's development:

E=aKLOCb (4)

D=c Ed (5)

P=E

D(6)

where the coefficients a, b, c and d are taken from Table 4.

12


20/41

Table 4 : COCOMO coefficient values[13]

Project type a b c d

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

For example, an organic project which is estimated to require 50 KLOC will require an effort of

146 E=2.4 501.05 man-months , will be developed over 17 D=2.5146

0.38 months, and will

require 9 P=146

17 developers.

Conclusion

Two key concerns emerged in this chapter: the accuracy of initial estimates is not very high

regardless of which estimation model is used, and the software industry seems to be plagued by a dis-

economy of scale. Fortunately, the problem of accuracy of estimation has been shown to diminish as the

project is developed. This implies that the development team is capable of accurately predicting the end

date and cost of a project before its completion. However, inaccurate estimates can cause contractual

problems, since either the customer or vendor must pay for the difference between the estimated cost and

the actual development cost.

Benediktsson and Dalcher suggest that the dis-economy of scales, demonstrated by the

exponential growth of required effort reported by models such as COCOMO, can be countered by the use

of the iterative delivery process[4]. They propose to estimate a project as a series of smaller projects

representing each of the iterations. By doing this, it is possible to show a linear relationship between the

effort required to complete a project and its size. This shows that it is theoretically possible to develop

software more cheaply with the iterative delivery process than with more traditional processes.

All of the estimation techniques discussed in this chapter generate effort estimates based on the

13


21/41

amount of work to be performed. In other words, estimates are based on the work to be completed, not on

the process that is to be used. Therefore, it is not possible to guarantee that a project will require less

effort if it is developed with the iterative delivery process instead of another process. This means that a

software vendor cannot offer to develop a project for a lower cost by assuming that the iterative delivery

process will reduce the development cost.

14


22/41

CHAPTER III

RELEASE PLANNING

Introduction

Release planning is the process of selecting the order in which features will be developed and

delivered. In other words, it is the process of determining which customer gets their features at which

time. The proper ordering of the requirements can provide financial advantages to projects which use the

iterative delivery process, since customers can benefit from the software delivered during each of the

iterations.

Figures 1 and 2 demonstrate the financial advantages of using the iterative delivery process

instead of a more traditional sequential process, such as the waterfall methodology, with which all of the

features are delivered at the end of the life cycle. The difference between the two charts is caused by the

assumption that ROI will begin after the first iteration has been delivered, and that it will increase after

each of the iterations. That is, it is expected that each of the iterations will cause an increase in income or

performance for the customer, and therefore financial benefits will be reaped at an earlier time than they

would be with the sequential process.

15


23/41


24/41

deterministic Polynomial-time hard (NP-hard) problem[14], and that the problem's complexity increases

the more it is explored.

The problem of optimizing a release plan is not new to software developers. For example, in 1978

Gilb wrote that each of the iterations have to either (a) give planned return on investment payback, or, if

impossible, then (b) give break-even (no loss); or, at least, (c) some positive user benefit measurably; or,

at least (d) some user environment feedback and learning[15]. Although there are many methods which

can be used to create release plans, none of them can be considered a silver bullet for the creation of an

optimal release plan. The next sections will discuss some of these methods.

Ad hoc Approach

Ad hoc release planning relies on a single individual's judgement, such as the project manager.

This approach typically produces release plans which are non-reproducible, and often focus solely on the

content to be delivered in the next release, giving preference to short-term gains over long-term ones.

These plans are most often completed by simply guessing the order in which the features should be

developed. The greatest advantage of this approach is that it requires less effort to complete than the other

approaches. The drawback of this approach is that it does not take into consideration all of the

stakeholders, and therefore runs the risk of not satisfying their needs. The ad hoc approach is most

suitable for small projects with few requirements and relaxed constraints.

Planning Game

The planning game is a process which has been defined as part of the extreme programming (XP)

methodology[16]. This process is first initiated by having the customer write storyboards which describe

the features which are required for the project. The software developers then estimate the time that will be

required to develop the features, and then the customer prioritizes the storyboards to match their own

preference. The customer is also responsible for setting the next iteration release date.

17


25/41


26/41

Kano Model of Customer Satisfaction

The Kano Model of Customer Satisfaction classifies requirements based on how they are

perceived by the end-users. These classifications can then be used for deciding the order in which

requirements should be developed. Table 5 defines and provides a short description of the three categories

in the Kano model.

Table 5: Feature Categories for the Kano Model

Feature Category Description

Threshold Must-have features which must be present in the product for it tosucceed. Improving the performance of these features is not typically

required. In other words, these features only need to be present andfunction properly.

E.g., the application must function with input and output devices.Linear Features which are correlated linearly with the end-user's satisfaction.

That is, the more of these features there are, the better it is for the end-

user.E.g., making the application support various export formats.

Exciters Features which provide a great deal of satisfaction for the end-user, but

which are not expected to be included. The lack of these features will notdecrease the end-user's satisfaction.

E.g., integrating email and voice-mail into the application.

The categorizing process first involves creating and administering a questionnaire to a subset of

end-users. The questionnaire is a collection of paired functional and dis-functional questions, the first

asking the user about their feelings if the feature is present, and the second asking about their feeling if it

is absent. The user answers each question by selecting one of the following five possible answers: I like

it that way, I expect it that way, I am neutral, I can live with it that way, or I dislike it that way.

The following provides an example of a functional and dis-functional question pair.

Functional form How do you feel if you can export xml files?

Dis-functional form How do you feel if you cannot export xml files?

19


27/41

Once the questionnaire has been answered by a satisfactory number of end-users, the matching

questions are compared in a matrix similar to Table 6.

Table 6: Kano Categorization Matrix[17]

Dis-functional

Question

Like

Expect

Neutral

Livewith

Dislike

FunctionalQuestion Like Q E E E L

Expect R I I I T

Neutral R I I I T

Like with R I I I T

Dislike R R R R Q

where Trepresents a threshold feature,L a linear feature,Ean exciter feature,R a reverse feature, Q a

questionable feature, andIuser's indifference to the feature.

The advantage of using the Kano model is that the end-user's preference is used to set the

priorities. By doing this, the software development team can prioritize the threshold requirements, and

therefore be sure to deliver a system which can solve the user's business problems. A disadvantage of the

Kano model is that since it prioritizes requirements solely on the end-user's view of importance, it does

not take the requirement's cost and projected ROI into consideration.

Incremental Funding Methodology (IFM)

The IFM is an approach to quantifying the financial benefits of individual features of a software

development project and optimizing the delivery sequence for maximum financial impact[18]. By using

this method, a project manager can prioritize the development of each feature to optimize the project's

overall net present value (NPV), which is a measurement of the overall value of the software development

over time.

20


28/41

The basic principle of the IFM is to quantify and then compare the financial benefits received

from software developed throughout the software development life cycle. To do this, a project's

requirements are first divided into minimum marketable features (MMF), which are requirement sets

capable of returning value to the customer when released as independent entities. By estimating the

expected financial benefits of each of the MMF, it becomes possible to apply various search algorithms to

prioritize the order in which the MMF should be developed.

One of the benefits of using IFM over the other methods explored in this paper is that IFM is

capable of handling requirement dependencies. For instance, MMF with high returns may have a

dependence on other MMF which may have low returns. In such cases, an approach which only compares

short-term profitability may delay the development of these more profitable MMF. This is demonstrated

in Figure 3, where the dotted line represents a release plan which only considers short term goals, while

the solid line represents a release plan which considers long-term goals.

Figure 3: Manipulating Financial Metrics through Resequencing MMFs[19].

By basing a project's release plan on the expected financial benefits of its features, IFM allows the

development team to optimise their release plans based on the expected financial benefits of each

requirement. This can make the plan more appealing to the customer and the management team. However,

21


29/41

a problem with the use of this methodology is that its performance is dependent on the accuracy of the

projected financial benefits of each of the requirements, which can be difficult to estimate. For example,

accurately estimating the financial value of a requirement which boosts the end-users' morale, and

therefore their productivity, can be a very difficult task.

Conclusion

The release planning techniques in this chapter suggest that projects developed with the iterative

delivery process are more financially attractive than projects developed with a sequential process. This

difference occurs because projects developed with the iterative delivery process can have a lower capital

requirement, and can provide a higher ROI on the project, since software can be used at an earlier stage

than sequential processes allow. Release plans can be optimized in order to further increase the value

gained from the project, but this task requires a level of effort from the development team.

An assumption shared by all of the release planning techniques defined in this paper is that it is

the development team's goal to satisfy their customers' needs, not simply to satisfy contractual

specifications. In other words, development teams that optimize their release plan do so by expanding

development resources for their customer's benefit. Doing so increases the development cost, and

therefore decreases the development team's short-term benefits. However, development teams which do

not make this assumption will have contracted the management disease of (supposing) that it is only

necessary to meet specifications[20] defined by Deming, and therefore may not provide a product which

satisfies their client's needs.

22


30/41

CHAPTER IV

BUSINESS MODELS

Introduction

Business models used by software companies can be grouped into three categories: Product

Oriented (PO), Service Oriented (SO), and Hybrid Oriented (HO)[21], where PO and SO represent

opposite ends of a spectrum, and HO refers to strategies between these two extremities. This section will

describe some of the advantages and disadvantages of these business models, and the skill sets required

for a company to be successful in each of the orientations. In conclusion, there will be a brief discussion

of the influence that the open source movement has had on these models.

Product Oriented (PO) Business Model

Companies which follow the PO business model generate income by selling packaged software

solutions which meet a set of generic computing requirements. Operating systems, enterprise resource

planning systems, software development tools, and personal-computing applications such as computer

games are all examples of software products.

The greatest appeal of the PO business model is its potentially high ROI. This can occur because

of the inexpensive cost of reproducing digital work, which allows companies to exercise large economies

of scale. An example of this is MS-DOS, which is believed to have been the greatest "cash cow" the world

has ever known. Purchased by Microsoft in 1981 for $50,000 US, MS-DOS came to dominate 80% to

90% of the PC market, making Microsoft a corporate giant, and one of the most influential companies in

the software industry.

Unfortunately, the ease with which software can be copied has also given birth to software

pirates. This term refers to users who use software products without paying the license fees. For

23


31/41

instance, in 2003 alone it has been estimated that companies in the United States were deprived of $6.5

billion US in unpaid licensing fees[22]. To prevent such losses, companies have been involved in legal

battles, have created large propaganda campaigns to intimidate and frighten their users, and have

intentionally crippled their products. All of these tactics have had the effect of increasing the development

cost of software, while not providing any additional business value to the customer.

Software users have also had to struggle with some of the methods used by software companies to

increase their customers' dependence on their products. One of these techniques is for the vendors to

prevent their clients from accessing their own data. The basic mechanism used to do this is to create and

patent a proprietary format for storing the product's digital data. This insures that the users cannot change

vendor without losing access to their own data, and therefore obliges the clients to remain loyal to the

same product vendor. Although this method has often favoured the vendors, some users have started to

fight the use of such strategies. For instance, the Peruvian government recently passed a legal bill

requiring all state departments to use software which does not limit access to information[23].

The reality of the PO business model is that it is very difficult to produce a best-seller product

from which a company can generate enough income to survive, and even more difficult to repeatedly

introduce new and successful products. Competitors also make it difficult to retain clients by copying the

product's features and offering them at a more attractive price.

Service Oriented (SO) Business Model

Businesses which follow the SO business model generate their income by selling software as

services. These include, but are not limited to: custom development, system implementation, system

integration, system upgrade, and maintenance[24]. SO companies create unique solutions for their clients'

needs, which typically cannot be packaged and sold "as is" to another client. PriceWaterhouseCoopers is

an example of an SO company which derives most of its revenues from its outsourcing and consulting

24


32/41


33/41

use the skills needed for both the PO and SO business models. Misbalancing the priorities of these two

strategies has caused failures[24]. An example of these conflicting priorities is that SO companies

typically focus on the technologies which are required to complete current contracts, while PO companies

are more concerned about long-term competitive implications of the technologies they decide to

specialize in. In other words, an SO company's skills are more often than not those which have been

acquired to complete contracts in the past, while PO companies need to acquire skills which will be in

demand once their product is deployed.

The Open Source Movement

The open source movement has had a great impact on the software industry. Open source software

developers, in contrast to proprietary software developers, allow their users to freely modify, copy, and

distribute the application's source code[25].

An example of the impact that open source has had on the software industry is the decreasing

demand for proprietary platforms such as operating systems, databases, and middle-ware applications. By

using open source solutions for their infrastructural needs, companies are able to lower their capital

investment, decrease the total cost of ownership, and decrease their reliance on specific vendors.

PO companies which have been forced to directly compete against open source software products

have had to adapt their business models. For instance, because of competition from open source operating

systems, Sun Microsystems has recently released the source code to its proprietary Solaris operating

system as an open source project. In other words, Sun now uses the SO business model for its operating

system, and generates income by offering support contracts to users of the Solaris operating system.

Conclusion

This section described and explained the different business models used by software companies.

Deciding which model to use depends on many factors, but recent events such as the open source

26


34/41

movement are forcing the industry to pursue an SO business model rather than a PO one. For instance, an

interesting aspect of the Peruvian open source bill, cited earlier in this section, is that government

officials felt that the bill needed to exist. A Peruvian congressman stated two reasons for this in an open

letter. The first is that the Peruvian government believes that the general public must be able to access all

public information. Proprietary software does not allow this, since it traditionally stores information in its

own formats, which are not public. The second reason for the bill is the fear that since each of the public

departments functions as an independent unit, it would be possible for some departments to accidentally

purchase proprietary software, and hence prevent the public from accessing the data[23].

27


35/41

CHAPTER V

CONCLUSION AND RECOMMENDATIONS

Conclusion

The estimated cost of creating a project cannot vary solely on the basis of development process

which will be used, as estimators generally only estimate the work that has been defined by the customer

in the contract. The fact that the iterative delivery process allows a more flexible approach, which in turn

permits the modification of requirements once the project has begun, does not lower the estimated effort,

since the modifications are unknown at the time. This means that, while estimating a project's cost, the

iterative delivery process may seem more attractive financially if it increases the final product's quality, or

if the customer benefits from the product earlier.

Product Quality

The product's quality is the first area in which the iterative delivery process may be financially

beneficial to the customer. However, although many claims have been made that the iterative delivery

process increases product quality, there is no conclusive proof that this is true for all projects. Just as

Brooks said in 1987, there is no silver bullet for software development[26]. It is also the author's belief

that processes do not produce software, but simply define the structure in which software developers

perform their duties. In other words, software is created by software developers, not by software

processes, and therefore the use of one process cannot guarantee higher levels of quality.

Claiming that the use of the iterative delivery process will increase quality can only be done as a

sales pitch, which unfortunately does not provide much financial information. In other words, a

company's claim that they will create a better product than their competitors is not a measurable variant.

28


36/41

Release Planning

The second area in which the iterative delivery process may produce benefits for the customer is

its ability of allowing the client to benefit from the software at an earlier stage. Working software can be

completed and deployed at each (or some) of the iterations, allowing the customer to use these

incremental deliveries. However, doing so creates two difficulties for the development team: estimating

benefits can be a difficult task, and finding the optimal release plan to maximize the benefits for a project

is a NP-hard problem.

In some cases, it may be a trivial task to estimate a feature's financial value. For instance,

developing software features to comply with newly enacted regulations prevents fines which are normally

well-defined by the enforcing party. In cases such as this one, the financial benefits of the features bear a

direct relation to the fines of not complying. On the other hand, estimating the financial benefits from

increasing customer loyalty, attracting new customers, decreasing product defects, and increasing

employees' productivity can be tricky at best. Estimating the value of these benefits can take a great deal

of effort and will typically be inaccurate, which further complicates the process of optimizing the release

plan.

Finding the optimal release plan can be a complicated task, though various methods and

techniques can be used to aid in its creation. However, development teams must not expend too much

effort on this activity, since finding the optimal solution can easily require more resources than it

warrants. Fortunately, it is not required to find the optimal release plan in order to benefit from multiple

deliveries.

The IFM, defined in chapter 3, provides a model to explain how financial benefits can accrue

from multiple deliveries. Although the IFM was defined as a tool for creating release plans, its basic

premise demonstrates how the iterative delivery process can be beneficial to the client. The premise that

29


37/41

software delivered at the end of an iteration can generate income for the client can be explained within a

project's request for proposal. Doing so can demonstrate to the client that they will be able to shorten their

investment periods, quicken their time-to-market, and increase their overall ROI on the project.

Business Model

The author began this thesis with the assumption that projects are to be developed as products.

That is, software development efforts have a beginning with its definition of requirements, and a definite

ending once the requirements have been satisfied. However, the research completed for this thesis has

suggested that the PO business model may not be well-suited to projects which are developed with the

iterative delivery process.

As stated before, one of the effects of the iterative delivery process is that it allows the client to

benefit from the development effort earlier. However, this short-term financial incentive is beneficial

exclusively to the client, while the software vendor will benefit only indirectly if the client provides them

with future work. Under the PO business model, conflicts between the client and the software vendor may

occur since both parties may decide to maximize their short-term profits. In practice, this often results in

a deteriorated relationship, and may even force one of the parties to seek another business partner. This in

turn affects the long-term profits for both the client and the vendor, since both will have to expend

resources searching for a new vendor or a new customer.

It is the author's belief that these problems could be minimized with the use of the SO business

model. By using this model, a vendor could respond to a request for proposal by sub-sectioning a project

into smaller parts, not contractually binding the client to all of the sections, and treating each of the

sections as service contracts to be agreed on sequentially. In this manner, the client and the vendor would

be able to begin a long-term relationship which would allow the vendor to acquire the business

knowledge required to better serve their clients, while the clients would become dependent on the service

30


38/41

solutions provided by the software vendor.

The author also believes that as the software industry matures, companies will no longer be able

to use a PO business model. The reason for this is that this model is not well-suited to developing digital

material which can be easily distributed via the Internet. Furthermore, this model requires that a great

deal of resources be wasted to prevent users from using the software illegally, and therefore has a higher

development cost than the SO business model.

Further Research Suggestions

Although software quality is an important concern, most of the literature about effort estimation

does not deal with this aspect of project management. Instead, the focus is most often placed exclusively

on estimating the total cost of producing the project without stating anything about the quality. This

obliges customers to compare project proposals solely on their estimated price tags, and in some cases

information about a vendor's past performance. Research in finding ways to quantify and estimate

software quality could provide decision makers with the information that they require to make better

business decisions.

In this thesis, it has been suggested that companies should shift to an SO business model.

However, this suggestion begets the question of how companies are to perform such a strategical change.

Obviously, established companies will want to continue collecting revenues from their products for as

long as they are able to do so, while also attempting to remain competitive. Further research needs to be

conducted to enable companies to make the decision of when and how quickly they should change their

business model.

Companies such as eBay, Youtube and Google have enjoyed extraordinary growth by using an SO

business model and the iterative delivery process over the Internet. Research on the impact of these

companies on the software industry may enable the prediction of upcoming business models trends. This

31


39/41

information could be used by educational institutions to offer courses to better assist their students.

32


40/41

REFERENCES

[1] P. Pande, R. Neuman, and R. Cavanagh, The Six Sigma Way, McGraw-Hill, 2000.

[2] M. Poppendieck and T. Poppendieck, Lean Software Development, Addison-Wesley, 2003.[3] K. Molkken-stvold, M. Jrgensen, S. Tanilkan, H.Gallis, and A. Lien, S. Hove, "A survey onsoftware estimation in the Norwegian industry", 10th International Symposium on Software Metrics, 14-

16 Sept., 2004, pp. 208- 219.[4] O. Benediktsson and D. Dalcher, "Effort estimation in incremental software development", Software,IEEE Proceedings, vol. 150, iss. 6, 2003, pp. 351 - 357.

[5] K. Molkken and M Jrgensen, "A review of software surveys on software effort estimation", isese,2003, p. 223.

[6] M. Cusumano, The Business of Software, FREE PRESS, 2004.[7] K. Schwalbe, Information Technology Projet Management, Thomson Course Technology, 2004.

[8] PMBOK Guide, Third Edition v1.2 CD-ROM, Project Management Institute, 2004.[9] E. Stensrud and I. Myrtveit, "Human performance estimating with analogy and regression models",

Fifth International Software Metrics Symposium, 1998, pp. 205-213.[10] M. Jrgensen, "A review of studies on expert estimation of software development effort", Journal of

Systems and Software, 2004, vol. 70, iss. 1-2, pp. 37-60.[11] H. Leung and Z. Fan, "Software Cost Estimation", Handbook of Software Engineer and Knowledge

Engineer, Vol. 2, 2002, .[12] M. Jrgensen, "Top-Down and Bottom-Up Expert Estimation of Software Development Effort",

Journal of Information and Software Technology, Vol. 46, Iss. 1, 2004, pp. 3-16.[13] "COCOMO", [Online document], Available at HTTP: http://en.wikipedia.org/wiki/COCOMO

[14] A. J. Bagnall, V. J. Rayward-Smith and I. M. Whittley, "The next release problem", Information and

Software Technology, 2001, Vol. 43, Iss. 14, pp. 883-890.[15] C. Larman and V.R. Basili, "Iterative and incremental developments: a brief history", Computer,2003, Vol. 36, Iss. 6, pp. 47-56.

[16] K. Beck and M. Fowler, Planning EXtreme Programming, Addison-Wesley, 2001.[17] M. Cohn, Agile Estimating and Planning, Prentice Hall Professional Technical Reference, 2006.

[18] "Software By Number: Frequently Asked Questions", [Online document], Available at HTTP:http://dactyl.cti.depaul.edu/ifm/faqs.html

[19] M. Denne and J. Cleland-Huang, "The Incremental Funding Method, A Data Driven Approach toSoftware", IEEE Software, 2004, Vol. 21, Iss. 3, pp. 39-47.

[20] W. Deming, Out of the crisis, First MIT Press edition, 2000.[21] M. Cusumano, The Business of Software, Free Press, 2004.

[22] "Software piracy losses 2003, by selected countries", [Online document], Available at HTTP:http://www.aic.gov.au/topics/cybercrime/

[23] "Peruvian Congressman refutes Microsoft's "Fear, Uncertainty and Doubt"", [Online document],Available at HTTP: http://www.opensource.org/docs/peru_and_ms.php

[24] S. Nambisan, "Why Service Businesses Are Not Product Businesses", MIT Sloan ManagementReview, 2001, vol. 4, iss. 42, pp. 72-80.

33


41/41

[25] "A Brief History of Free/Open Source Software Movement", [Online document], Available at HTTP:

http://www.openknowledge.org/writing/open-source/[26] F. Brooks, "No Silver Bullet Essence and Accidents of Software Engineering", Computer, 1987,

vol.20, iss.4, pp. 10-19.

Documents

ESTIMATING AND PLANNING ITERATIVELY DELIVERED PROJECTS TO MAXIMIZE FINANCIAL BENEFITS