Balancing software project drivers a rational quantitative approach
-
Upload
pragmatic-cohesion-consulting -
Category
Technology
-
view
294 -
download
1
description
Transcript of Balancing software project drivers a rational quantitative approach
Page 1 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
Balancing Software Project Drivers - A Rational Quantitative Approach
Page 2 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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
Page 3 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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.
Page 4 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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
Page 5 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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.
Page 6 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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].
Page 7 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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.
Page 8 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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.
Page 9 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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.
Page 10 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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),
Page 11 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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”.
Page 12 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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,
Page 13 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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,
Page 14 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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.
Page 15 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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
Page 16 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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]
Page 17 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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.
Page 18 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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]
Page 19 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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
Page 20 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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
Page 21 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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
Page 22 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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:
Dn amount of design specifications
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
Mn budgeted development cost
PD0n proportion of non-effort consuming design specifications
PC0n proportion of non-effort consuming implemented 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.
Page 23 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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:
Dn amount of design specifications
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
Mn budgeted development cost
PD0n proportion of non-effort consuming design specifications
PC0n proportion of non-effort consuming implemented 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
Page 24 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
-KDN: the reusability degree of DN amount of reusable design specifications
-KCN: the reusability degree of CN amount of reusable software code
Page 25 of 25 Copyright © 2010-2013 Pragmatic Cohesion Consulting
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.