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 Software features set
possible
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.


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 Software features set
possible
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 Achievement function Goal
Level
(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

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (6)

Similar to Balancing software project drivers a rational quantitative approach

Similar to Balancing software project drivers a rational quantitative approach (20)

More from Pragmatic Cohesion Consulting, LLC

More from Pragmatic Cohesion Consulting, LLC (20)

Recently uploaded

Recently uploaded (20)

Balancing software project drivers a rational quantitative approach