balancing software project drivers a rational quantitative approach

of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting

Balancing Software Project Drivers - A Rational Quantitative Approach


Introduction

The increasing role of mission critical software products and a highly competitive software market leaves little room for poorly

managed software projects with unclear development processes [Yourdon, 1997].

Decision Support Systems (DSS) are valuable tools that can help software project managers model their decision problems. A DSS can

also provide great value in assessing the potential impact of alternative course of actions [Sage, 1991].

From a global perspective on software projects, Grady Booch [1998] defines several “Artifacts” as being byproducts of development

processes or aids to development processes. These artifacts are classified according to their principle users or according to the clients

that they serve: the development team itself, end users, and software management teams.

The development team artifacts are:

The software’s architecture

Design specifications

Code

The end users’ artifacts are:

The software requirements

Data i.e. raw information that may be used within or across applications inside the end users’ organization

Human interfaces i.e. general look and feel of a family of programs

The software project management team artifacts are:

Estimates (costs, development time, quality level)

Project plans (staffing and scheduling )

Documentation

The Decision Support System (DSS) presented in this document is a tool that facilitates the definition and production of project estimates

and project plans focused on the design and implementation phases of the software development life cycle.

Booch also suggests that every well-define process has four roles:

Provide guidance as to the order of a team’s activities


Specify what artifacts should be developed

Direct the tasks of individual developers and the team as a whole

Offer criteria for monitoring and measuring the project’s products and activities

He then respectively relates these four roles to the purpose, products, activities, and measures of goodness of each phase of a software

development life cycle.

The DSS presented in this document is a tool that improves the effectiveness of the decision making process that results in estimating,

planning, and adapting:

the products (software architecture, design specifications and code ),

the activities (designing architecture, defining design specifications, and producing code)

and the measures of goodness (number of known requirements met, degree of resilience to new requirements, and degree of

reusability) of the design and implementation phases of a software development life cycle.

1-System Scope

The general architecture of the DSS is presented in figure 1. It contains the following subsystems:

User Interface that permits the dialog between the DSS and its users.

Database that provides persistent storage of the data manipulated by the DSS.

ModelBase that is the representation of the mathematical models used by the DSS.

Database Management System.

Modelbase Management System.

Management Software that integrates the communications among the User Interface, the Database Management System, and the

ModelBase Management System.


2-Project Scope

To the best of my knowledge, the DSS described in this project does not refer to an existing system utilized by a commercial or

government software development organization. Furthermore, this DSS is not tailored to any specific software development

organization. The project findings and results although substantial are kept generic enough to be utilized by an existing organization or

become part of the foundation of a new business.

Figure 1: DSS High Level Architecture


MODELBASE ANALYSIS

1-Overview

1.1-Single software project management policies

Software management teams continuously strive to achieve balance in fulfilling stakeholders’ expectations. Attaining such a balance

frequently involves conducting a continuous trade off of the software feature set, cost, schedule, and degree of reusability [Rico 2004].

Taken individually, each one of the figures being traded off has associated with it a specific optimal achievement direction that defines

its management policy. They are summarized in the following table:

Objective or Management Policy Object

Deliver software that has as many requirements met as

possible

Software features set

Do not exceed budgeted costs Software development effort cost

Deliver software on schedule Software delivery schedule

Produce software with as many reusable features as possible Software degree of reusability.

We have related the individual objectives mentioned previously to quantitative expressions that capture their essence.

Several software management objectives compete to be totally fulfilled. Software development managers are faced with the challenge

of finding the optimal balance of these objectives. A useful approach is to prioritize these objectives according to what the Decision

Maker judges as the most important objectives to achieve.

Once the objectives have been ranked, the optimal balance of fulfilled objectives can be derived by several techniques. Goal

Programming techniques fit well the problem at hand. The achievement function of the goal programming problem expresses the

optimal balance in achieving the various stated goals.

http://en.wikipedia.org/wiki/Goal_programming

http://en.wikipedia.org/wiki/Goal_programming


1.2-Multiple related software projects management

Beyond managing a single software project, software development management teams have to address management decisions that

involve several related successive or concurrent software projects. Here the focus is mainly on the design and implementation phases

of successive software products that share to varying degrees commonalties in terms of architecture, detail design specifications, and

types of implemented functionalities.

The set of related software projects has the following characteristic: each software project covers activities that are initiated by the

definition of a specific set of software requirements; they include the production of design artifacts and the implementation and testing

of software code prior to being packaged as releasable software product.

Two planning approaches that respond to two kinds of planning strategies are presented. Both approaches try to match future project

characteristics to development effort capability:

The first strategy is to find the kind of software projects that match the current profile of the organization software development

capability.

The second strategy is to define the organization software development capability that will match a given set of future software

projects.

1.3-Model elements

A software product development effort conducted by an organization generates two major artifacts:

Design Specifications (Software Architecture and Detail Design Specifications)

Software Code.

We define three types of software development efforts for the production of design specifications and the implementation of software

Code:

Efforts that require “no real effort” (indexed O),

Efforts that produced partially or totally reusable features (indexed N),

Efforts that produced non-reusable features (indexed W).

Software Architects and software abstractionists are most often in charge of producing the software architecture and design

specifications while Application Engineers are responsible for implementing the software Code [Grady Booch, 1998].


Compared to the production of non-reusable features, the production of reusable features requires more experience and more advanced

skills from the team assigned to it. Therefore, there is a high probability that team members assigned to the production of reusable

features will sell their experience and skills at a higher price than those assigned to the production of non-reusable features.

Our discussion introduces the design of the software architecture as a major driver for the remaining detail design and code

implementation activities [Rosenberg, Stephens, Collins-Cope; 2005].

Reusable features of the software as well as features of the software that were produced with little or no efforts are also introduced as

having a strategic value in terms of custom development time saving. The use and production of these types of features relate to

Walker Royce’s [1998] component-based development that defines a component as “a cohesive set of preexisting lines of code, either

in source or executable format, with a defined interface and behavior”.

Our model uses ratios that define the mean rate at which design specifications are produced and the mean rate at which software code

is implemented. The values of these rates depend on various factors such as:

Skill level of the development team,

Size of the development team,

Development tools,

Development methodology or paradigm,

These factors strongly vary from one organization to the next.

Our model also includes development cost figures that relate to the 3 types of development efforts previously defined [Bohem and

Papaccio, 1988]. Cost figures are related to the production rates previously discussed, the mean time required for producing design

specifications, and the mean time required for implementing software code. These cost figures also strongly depend on the:

Skill level of the development team,

Size of the development team,

Development tools,

Development methodology or paradigm,

Once again, these factors will likely vary from one organization to the next.

The degree to which software features can be reused to develop multiple software products depends mainly on:

The similarity between the initial software and the other ones in terms of problem domain, requirements set, programming

language, notations, machine architecture, development tool, and standards.


The actual occurrence of identical software components across several projects.

Reusable software components could be source code libraries or software design frameworks with multiple classes, interfaces, or

functions.

2-Model Details

2.1-Single software project management policies

Software Feature Set

The software feature set needs to be complete in order to meet the software requirements. But it is a moving target since several

requirements are at first unknown and are discovered only during the development phase.

Software development effort cost

The software cost needs to be minimized and needs to be lower than a given budgeted cost. As often noticed, several software projects

are above expected cost therefore the actual incurred cost needs to be as close as possible to the budgeted cost if it exceeds it.

Software delivery schedule

Any planned deadline of a software release needs ideally to be exactly met. Software projects are known to be delivered late therefore

the actual incurred development time needs to be as close as possible to the planned time if it exceeds it.

Software degree of reusability

With respect to the two sets of development efforts (specifying Architecture/Design and Implementing Code) software development

teams need to yield the best balance of skills and size that allows the completion of the software within the planned schedule and at the

budgeted cost while taking advantage of as many reusable software components as possible.

2.2-Multiple related software projects management policies

Related projects could be about different software products or they could be about several releases or versions of a same software

product. The analysis approach that is presented in this section tries to offer a generic enough framework that applies to both types of

software products.


In the case of successive releases of the same software product, the most recent set of software requirements may vary due to the

following reasons:

in response to feedback from users who expect more or different software features.

in response to the discovery by the development team of major overseen software requirements.

In the case of different successive software products, a new set of software requirements is usually determine in response to the

identification of new markets to conquer.

2.3-Further definition of development efforts

We are postulating that a software product development effort conducted by an organization generates 2 major artifacts: a set of design

specifications and a set of implemented software code.

Any design specification or implemented software code can be decomposed into 3 distinct subsets:

The first subset is characterized by the fact that its production requires little or no consumption of development efforts in order to

become part of the software product; it is either directly taken from a previous software development effort within the same

organization or it is bought from a third party vendor.

The second subset is characterized by the fact that its production is the result of a new development effort conducted within the

organization and it has the properties of being totally or partially reusable for other software development efforts.

The third subset is characterized by the fact that it is also the result of a new development effort but it is very unlikely to be reused

for another software development effort.

Let introduce the following convention:

The software is represented as a first set of D design specifications and a second set of C implemented software code.

O Index represents the first subset of the software that does not require new development efforts.

N Index represents the second subset of the software that requires new development efforts and is partially or totally reusable.

W Index represents the third subset of the software that requires new development efforts and is not reusable.

The following variables are introduced:

PDO and PCO: are respectively the mean proportions of total software Design Specifications and Software Code that do not

require new development efforts.


PDN and PCN: are respectively the mean proportions of total Software Design Specifications and Software Code that require new

development efforts and that are partially or totally reusable.

PDW and PCW: are respectively the mean proportions of total Software Design Specifications and Software Code that require

new development efforts and that are not reusable.

With the following relation holding:

PDO+PDN+PDW = 1 [E1]

PCO+PCN+PCW = 1 [E2]

Let D represent the total amount of Design Specifications. D’s unit could be for example the number of classes and interfaces or any

other metric that is be suitable to size the set of Design Specifications. It is possible to derive the following variables from (E1):

DO = PDO x D : the mean amount of design specifications of the software that do not require new development efforts.

DN = PDN x D : the mean amount of design specifications of the software that require new development efforts and that are

totally or partially reusable.

DW = PDW x D : the mean amount of design specifications of the software that require new development efforts and that are not

reusable.

Let C represent a measure of the total size of implemented Software Code. C’s unit could be for example in Software Lines of Code or

any other metric that is appropriate to size the set of implemented Software Code. By analogy, the following variables can be identified

for the software code:

CO = PCO x C : the mean amount of Software Code that do not require new development efforts.

CN = PCN x C : the mean amount of Software Code that requires new development efforts and that is totally or partially

reusable.

CW = PCW x C : the mean amount of Software Code that requires new development efforts and that is not reusable.

The magnitudes of DO and CO are especially useful to the development effort since they require no development time. DN and CN

represent a substantial development efforts “investment” for the current software project but they have the potential to fully or partially

become the “DO” and “CO” of other software development efforts. DW and CW are “one time use” development efforts with no or

very little chance of ever being reuse in another software development projects.

In summary, three types of software development efforts have been defined for the production of design specifications and the

implementation of software code:

those that require “no real effort” (indexed O),


those that produced partially or totally reusable features (indexed N),

those that produced non-reusable features (indexed W).

2.4-Allocation of resources to development efforts

Software development efforts can be viewed as the production of design specifications and the implementation of software code. From

the previous paragraph, we have defined three groups of such efforts among which only two really require new consumption of staff

resources in order to take place: the production of reusable features and the production of non-reusable features.

Software architects and software abstractionists are most often in charge of producing the software architecture and design

specifications. Application engineers are responsible for the implementation of software code [Grady Booch, 1998]. According to our

definition of software effort types, both the production of design specifications and the implementation of software code need to cover

two activities: the first one resulting in the production of reusable features and the second one resulting in the production of non-

reusable features. Compared to the production of non-reusable features, the production of reusable features requires more experience

and more advanced skills from the team assigned to it. Therefore, there is a high probability that team members assigned to the

production of reusable features sell their experience and skills at a higher price than those assigned to the production of non-reusable

features. In addition, software architects and software abstractionists cost more than application engineers but they are in much lesser

number than the application engineers in most software development projects.

2.5- Relationship with 2 major principles of modern software development management.

In 1998 Walker Royce presents 10 principles of modern software management. The first one and the third one are quoted next.

First -Base the process on an architecture-first approach.

Third -Transition design methods to emphasize component-based development.

Our discussion has introduced the design of the software architecture as a major driver of both the remaining design and

implementation activities.

Reusable features of the software as well as features of the software that were produced with little or no efforts were also presented as

having a strategic value in terms of custom development time saving. The use and production of these types of features relate to

Royce’s component-based development that defines a component as “a cohesive set of preexisting lines of code, either in source or

executable format, with a defined interface and behavior”.


2.6- Rates of production

In this section, we are interested in establishing a relationship between time and the variables expressing the mean amount of design

specifications and the mean amount of implemented software code. We introduce the following variables:

TDN: mean time required to produce DN amount of design specifications

TDW: mean time required to produce DW amount of design specifications

TDO: mean time required to produce DO amount of design specifications. TDO by definition is equal to 0 units of time

TCN: mean time required to implement CN amount of software code

TCW: mean time required to implement CW amount of software code

TCO: mean time required to implement CO amount of software code. TCO by definition is equal to 0 units of time.

The following ratios define the mean rate at which design specifications are produced and the mean rate at which software code is

implemented.

CDN = DN/TDN : mean production rate of DN amount of design specifications.

CDW = DW/TDW : mean production rate of DW amount of design specifications.

CCN = CN/TCN : mean implementation rate of CN amount of software code.

CCW = CW/TCW : mean implementation rate of CW amount of software code.

The following relations can be derived:

DN = CDN x TDN [E10]: the mean amount of design specifications that require new development efforts and that are totally or

partially reusable.

DW = CDW x TDW [E11]: the mean amount of design specifications that require new development efforts and that are not

reusable.

CN = CCN x TCN [E12]: the mean amount of Software Code that requires new development efforts and that is totally or

partially reusable.

CW = CCW x TCW [E13]: the mean amount of Software Code that requires new development efforts and that is not reusable.

The values of the above variables depend on various factors such as:

the skill level of the development team,

the size of the development team,


the development tools,

the development methodology or paradigm,

These factors strongly vary from one organization or project to the next.

2.7- Development efforts cost figures

An important aspect of project management responsibilities is planning and measuring cost expenditures throughout the project life

cycle. Such an activity is performed differently from one organization to the next therefore it may take many forms. In this project,

development efforts have been classified in three generic groups that remain valid regardless of organization specific practices and

policies. More specifically cost figures are related to both the production rates previously introduced and the mean time required to

produce design specifications and the mean time required to implement software code.

The following variables are introduced:

MDN: mean cost of producing one unit of design specifications.

MDW: mean cost of producing one unit of design specifications.

MCN: mean cost of implementing one unit of software code.

MCW: mean cost of implementing one unit of software code.

The cost of producing DN amount of design specifications is:

MDN x DN = MDN x CDN x TDN [E14]

The cost of producing DW amount of design specifications is:

MDW x DW = MDW x CDW x TDW [E15]

The cost of implementing CN amount of software code is:

MCN x CN = MCN x CCN x TCN [E16]

The cost of implementing CW amount of software code is:

MCW x CW = MCW x CCW x TCW [E17]

The values of the above variables depend on various factors such as:

the skill level of the development team,

the size of the development team,

the development tools,


the development methodology or paradigm,

These factors strongly vary from one organization or project to the next.

2.8- Development effort reuse

As mentioned before, among the three types of development efforts, one does not really require any development effort. It is expressed

by the variables DO and CO. The DO design specifications and CO implemented software code are either directly taken from a

previous software development effort within the same organization or are bought from a third party vendor. In this section we focus on

the process by which DO and CO are taken from a previous software development effort conducted by the same organization.

Using the three types of development efforts mentioned in this project, the reusable portion of any software can be expressed as

follow:

KDO x DO for reuse of the “non-effort consuming” part of design specifications.

KCO x CO for reuse of the “non-effort consuming” part of implemented software code.

KDN x DN for reuse of the “design for reuse” part of design specifications.

KCN x CN for reuse of the “implemented for reuse” part of implemented software code.

Where KDO, KCO, KDN and KCN are adjustment factors that express what fraction of the software project under consideration is

transferred to another given software project. KDO, KCO, KDN and KCN are by definition between 0 % and 100%.

The magnitudes of KDO, KCO, KDN and KCN depend mainly on:

The similarity between the initial software and the new one to develop in terms of problem domain, requirements set,

programming language, notations, machine architecture, development tool, and standards.

The effective reuse of software components in terms of occurrences of identical components across several projects.

Reusable software components could be source code libraries or software design frameworks with multiple classes, interfaces, or

functions. The important fact is that whatever the sources of reuse, the reused components become for the current project its set of

“Non-effort consuming” design specifications and implemented software code. The more “non-effort consuming” design

specifications and implemented software code used, the less “effort-consuming” design specifications and implemented software code

needed to complete the project. The ultimate outcome yields a substantial reduction of the software custom development time and

effort.


3- Using software development effort models in managerial decisions

Software development management teams would like to find ways to answer the following questions regarding given software

projects:

What amount of software features will likely be produced?

What amount of reusable features will likely be produced?

What amount of non-reusable features will likely be produced?

How long will it take to complete the production of the software features?

How much time needs to be dedicated the production of reusable features?

How much time needs to be dedicated to the production of non-reusable features?

How much will the development effort cost?

What will be the cost of the reusable features produced?

What will be the cost of the non-reusable features produced?

While knowing the following development capability parameters:

Mean cost of producing 1 unit of reusable design specification

Mean cost of producing 1 unit of non-reusable design specification

Mean cost of implementing 1 unit of reusable software code

Mean cost of implementing 1 unit of non-reusable software code

Mean production rate of 1 unit of reusable design specification

Mean production rate of 1 unit of non-reusable design specification

Mean implementation rate of 1 unit of reusable software code

Mean implementation rate of 1 unit of non-reusable software code

And knowing the following project constraints:

The expected amount of design specifications

The expected amount of implemented software code

The expected development effort budgeted cost

The planned time for producing design specifications

The planned time for implementing software code


3.1 Optimal single software project management policies.

In this section we will relate the individual software policies mentioned previously under section 2.1 to quantitative expressions that

capture their essence.

Software Feature Set

The software feature set consists of D amount of design specifications and C amount of implemented software code.

Using the three types of development efforts, the following relations are presented:

D = DO + DN + DW [E20]

C = CO + CN + CW [E21]

By substituting [E10] to [E13] in [E20] and [E21]:

D = DO + (CDN x TDN) + (CDW x TDW) [E30.1]

C = CO + (CCN x TCN) + (CCW x TCW) [E30.2]

Software development effort cost

Development effort costs are incurred as design specifications are produced and software code is implemented. The development cost

budgeted figures are MD for design specifications production and MC for software code implementation. The following relations

translate the policy that relates budgeted costs to incurred costs:

MD > (MDN x DN) + (MDW x DW)

Which is the same as:

MD > ( MDN x CDN x TDN) + (MDW x CDW x TDW) [E31.1]

MC > (MCN x CN) + (MCW x CW)

Which is the same as:

MC > (MCN x CCN x TCN) + (MCW x CCW x TCW) [E31.2]


Software delivery schedule

Let TD and TC be respectively the planned time for producing design specifications and the planned time for implementing software

code.

The actual time spent for the production of design specifications and the actual time spent for the implementation of software code

must be equal to the planned development times. The following equations capture these relations:

TD = TDN + TDW [E32.1]

TC = TCN + TCW [E32.2]

Software degree of reusability

From a global perspective, the development team is composed of software architects and software abstractionists who are in charge of

producing the software architecture and detail design specifications. Application engineers are responsible for implementing software

code. Within each one of these groups two skills level are defined. The first one is capable of producing reusable features and the

second one is mainly capable of producing non-reusable features. The strategic interest of reusable features has been presented several

times in this presentation. It is then desirable that as many as possible software features exhibit this property. This fact can be

translated by the following equations:

TDN > 0 [E33.1] and CDN > 0 [E34.1]

TCN > 0 [E33.2] and CCN > 0 [E34.2]

3.2 Optimal set of single software project management policies.

From the previous discussion, it appears that several software management objectives compete to be totally fulfilled. Software

development managers are faced with the challenge of finding the optimal balance of these objectives. A useful approach is to

prioritize these objectives according to what the Decision Maker judges as the most important objectives to achieve. These objectives

are listed below with no implications about their relative importance.


Objective or Management Policy Object

Deliver software that has as many requirements met as

possible

Software features set

Do not exceed budgeted costs Software development effort cost

Deliver software on schedule Software delivery schedule

Produce software with as many reusable features as possible Software degree of reusability.

Once the objectives have been ranked, the optimal balance of fulfilled objectives can be derived by several techniques. Next we

present how Goal Programming fits well the problem at hand.

Two similar goal programming problems can be formulated: the first one is about design specifications while the other one is about

implemented software code. The formulation that follows addresses implemented software code.

Optimize: the achievement of ranked project development objectives

Given: the following aspiration levels:

C – CO : Amount of software code to implement

MC : Software code implementation budgeted cost

TC : Software code implementation planned time

And given: the following production parameters:

CCN : Mean production rate of reusable software code

CCW : Mean production rate of non-reusable software code

MCN : Mean cost of producing one unit of reusable software code

MCW : Mean cost of producing one unit of non-reusable software code

The following relations constitute the Goal Programming constraints:

(CCN x TCN) + (CCW x TCW) = C - CO [E30.2]

(MCN x CCN x TCN) + (MCW x CCW x TCW) < MC [E31.2]

TCN + TCW = TC [E32.2]

TCN > 0 [E33.2]


The decision variables in the above relations are TCN and TCW. Each relation has an aspiration level and a direction of preference

that are summarized below with additional goal programming deviation variables.

Right Hand Side Deviation Variables Aspiration

Level

Achievement function Goal

(CCN x TCN) + (CCW x TCW) dC-, dC+ C - CO minimize deviation: (dC- + dC+)

(MCN x CCN x TCN) + (MCW x CCW x TCW) dM-, dM+ MC minimize over achievement :(dM+)

TCN + TCW dT-, dT+ TC minimize deviation : (dT- + dT+)

TCN dN-, dN+ 0 minimize under achievement: (dN-)

The achievement function of the goal programming problem expresses the optimal balance in achieving the various stated goals. It can

be expressed as any of the following:

Minimize the weighted sum of the goal deviations where weights are representative of priorities among the objectives.

Minimize some function of the goal deviations.

Minimize the worst deviation of the goal deviations.

Lexicographic minimization of an ordered set of goal deviations.

3.3 Post optimal analysis of a set of single software project management

The solution to the goal programming problem described previously provides the following information with respect to the priorities

defined by the decision maker:

How long it takes to complete the production of the software features

How much time is dedicated the production of reusable software features

How much time is dedicated to the production of non-reusable software features

What amount of software features have been produced

What amount of reusable software features has been produced

What amount of non-reusable software features has been produced

How much it costs to produce the software features

What is the total cost of the reusable software features

What is the total cost of the non-reusable software features


Post optimality analysis is useful to respond to the following questions:

How do modifications in the stated priorities influence the optimal solution proposed? This question addresses concerns such as:

if cost becomes the biggest priority instead of feature set, is the solution still valid?

Within what range can the aspiration levels on desired feature set, cost, and schedule vary without making proposed solution non-

feasible?

3.4 Multiple related software projects management.

Next, is presented an analysis procedure that allows planning a series of successive software projects. The three types of development

efforts (non-effort consuming, effort consuming with reusable property, effort consuming with non-reusable property) and the 2 types

development activities (producing design specifications, implementing software code) previously presented are taken into account.

For each project under consideration, the following software development effort parameters are defined:

D: the amount of design specifications

C: the amount of software code to implement

TD: the planned time for producing design specifications

TC: the planned time for implementing software code

TDN: the mean time needed to produce DN amount of reusable design specifications

TDW: the mean time needed to produce DW amount of non reusable design specifications

TCN: the mean time needed to implement CN amount of reusable software code

TCW: the mean time needed to implement CW amount of non-reusable software code

M: the development effort budgeted cost

MD : budgeted cost to produce D amount of design specifications

MC : budgeted cost to implement C amount of software code

MDN : mean cost of producing 1 unit of reusable design specification

MDW : mean cost of producing 1 unit non-reusable design specification

MCN : mean cost of implementing 1 unit of reusable software code


MCW: mean cost of implementing 1 unit of non-reusable software code

CDN: the mean production rate of 1 unit of reusable design specification

CDW: the mean production rate of 1 unit of non-reusable design specification

CCN: the mean implementation rate of 1unit of reusable software code

CCW: the mean implementation rate of 1unit of non-reusable software code

KDN: the reusability degree of DN amount of reusable design specifications

KCN: the reusability degree of CN amount of reusable software code

The strategies presented address a set of N successive related software projects. The organization objective is to develop the Nth

project with the following forecasted characteristics:

Dn amount of design specifications

Cn amount of software code

TDn planned time for producing design specifications

TCn planned time for implementing software code

Mn budgeted development cost

PD0n proportion of non-effort consuming design specifications

PC0n proportion of non-effort consuming implemented software code

The strategic variables are PD0n and PC0n since they reflect the portion of the software project that does not need to consume

development efforts therefore they are strong indicators of development effort cost savings. A natural procedure is to gradually

increase PD0 and PF0 from one project to the next by making sure that each software produces features that possess an effective

degree of reusability for subsequent projects.

Next we present two planning approaches that respond to two kinds of planning strategies. Both approaches try to match future project

characteristics to development effort capability.

3.4.1 First approach –marketing strategy


The first strategy is a marketing one and it consists of finding the kind of software projects that match the current profile of the

organization software development capability.

This approach can be modeled as follow using the software development effort parameters previously introduced:

Given the following characteristics of the Nth project:


Cn amount of implemented software code

TDn planned time for producing Dn amount of design specifications

TCn planned time for implementing Cn amount of software code




And given the forecasted values for each one of the (N-1) projects:

MDN : mean cost of producing 1unit of reusable design specification

MDW : mean cost of producing 1 unit of non-reusable design specification

MCN : mean cost of implementing 1unit of reusable software code

MCW: mean cost of implementing 1unit of non-reusable software code

CDN: the mean production rate of 1 unit of reusable design specification

CDW: the mean production rate of 1 unit if non-reusable design specification

CCN: the mean implementation rate of 1unit of reusable software code

CCW: the mean implementation rate of 1 unit if non-reusable software code

Find the values of the following parameters for each one of the (N-1) projects:

-D: the amount of design specifications

-C: the amount of software code to implement

-M: the development effort budgeted cost

-TD: the planned time for producing design specifications

-TC: the planned time for implementing software code

-KDN: the reusability degree of DN amount of reusable design specifications

-KCN: the reusability degree of CCN amount of reusable implemented software code.


3.4.2 Second approach – workforce development strategy

The second strategy is a workforce development one that defines the organization software development capability that will match a

given set of future software projects.

Given the following characteristics of the Nth project:


Cn amount of implemented software code

TDn planned time for producing Dn amount of design specifications

TCn planned time for implementing Cn amount of software code




And the forested values for each one of the (N-1) projects:

D: amount of design specifications

C: amount of software code to implement

M: the development effort budgeted cost

TD: the planned time for producing design specifications

TC: the planned time for implementing software code

Find the values of the following parameters for each one of the (N-1) projects:

-MDN: mean cost of producing 1unit of reusable design specification

-MDW: mean cost of producing 1unit of non-reusable design specification

-MCN: mean cost of implementing 1 unit of reusable software code

-MCW: mean cost of implementing 1 unit of non-reusable software code

-CDN: the mean production rate of 1unit of reusable design specification

-CDW: the mean production rate of 1unit of non-reusable design specification

-CCN: the mean implementation rate of 1unit if reusable software code

-CCW: the mean implementation rate of 1unit of non-reusable software code


-KDN: the reusability degree of DN amount of reusable design specifications

-KCN: the reusability degree of CN amount of reusable software code


References:

-Bohem B.W. and Papaccio P.N. 1988, Understanding and controlling software cost, IEEE Transactions on Software Engineering

14(10)

-Booch G. (1998), Object Solutions: Managing the Object-Oriented Project, Addison-Wesley, Menlo Park, CA

-Rico D.F (2004), ROI of software process improvement: Metrics for project managers and software engineers, J. Ross, Boca Raton,

FL.

-Rosenberg D., Stephens M., and Collins-Cope M. (2005), Agile Development with ICONIX Process-People, Process and

Pragmatism, Apress.

-Royce W. (1998), Software Project Management a Unified Framework, Reading, MA

-Sage A. P. (1991) Decision Support Systems Engineering. Wiley Series in Systems Engineering, New York.

-Yourdon E. (1997), Death march: The complete software developer’s guide to surviving “Mission Impossible” projects, Prentice Hall,

Upper Saddle River, NJ.

balancing software project drivers a rational quantitative approach

Technology

management software

software features

software management

software project managers

software development

products software architecture

software requirements

software feature set