SOFTWARE ENGINEERING

S U S H R E E S ATA PAT H Y
D E PA RT M E N T O F C O M P U T E R S C I E N C E
S I L I C O N U N I V E R S I T Y, B H U B A N E S WA R
 Module 3
SOFTWARE PROJECT MANAGEMENT
 Syllabus
Module Topics
Module – 1 Software Engineering: Introduction, Evolving role of software, Legacy software, Software myths, Process
framework, CMM, Life-cycle models, Waterfall model, Incremental models, Evolutionary models,
Specialized models, Unified process, Agile Process Models (Extreme programming, Crystal, Scrum)
Module – 2 Requirements Engineering: Types of Requirements, Functional and non-functional requirements, The
software requirements document, Requirements - specification, engineering processes, elicitation &
analysis, validation, and management; Decision Trees and Decision Tables, Formal Specification
(Axiomatic specs for Stacks & Queues)
Module – 3 Software Project Management: Software project planning process, Project estimation (Cost, Time,
Effort), Decomposition techniques, Empirical estimation models, The Make/Buy decision, Project
scheduling, Task network, Critical Path method, PERT Scheduling, Earned Value analysis
Module – 4 Design Engineering: Function-oriented Software Design (DFD Structure charts), Object-oriented Design
using UML, User Interface design; Software Testing: Testing strategies, Types of testing, Black-Box testing ,
White-box testing, Basis Path testing, Control Structure testing, Reliability testing, Security testing.
Module – 5 Advanced Topics: Testing web-apps, Formal methods, Risk Management, Configuration Management, Re-
Engineering Security Engineering.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 3

Software Project Planning Process
•Several projects fail due to use of faulty project management practices.

•The main goal of software project management is to enable a group of

developers to work effectively towards the successful completion of a project.

•Management of software projects is much more complex than management of

many other types of projects.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 4

Software Project Planning Process
•The main factors contributing to the complexity of managing a software project,
as identified by [Brooks75], are the following:
• Invisibility – makes it difficult to assess the progress of a project
• Changeability – gets most frequently changed.
• Complexity – many types of risks are associated with its development
• Uniqueness – makes every project much different from the others
• Exactness of the solution – required to be in complete conformity with the
function definition
• Team-oriented and intellect-intensive work

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 5

 Responsibilities of a software project
manager
•Project planning - Project planning involves estimating several characteristics of
a project and then planning the project activities based on these estimates
made.
•Project monitoring and control - The focus of project monitoring and control
activities is to ensure that the software development proceeds as per plan.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 6

 Skills necessary for managing software
projects
•Three skills that are most critical to successful project management are the
following:
• Knowledge of project management techniques.
• Decision taking capabilities.
• Previous experience in managing similar projects.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 7

Project Planning
•Once a project has been found to be feasible, software project managers
undertake project planning.
•Project planning is undertaken and completed before any development activity
starts.
•During project planning, the project manager performs the following
•activities.
•Estimation: The following project attributes are estimated.
•Cost: How much is it going to cost to develop the software product?
•Duration: How long is it going to take to develop the product?
•Effort: How much effort would be necessary to develop the product?
•The effectiveness of all later planning activities such as scheduling and staffing
are dependent on the accuracy with which these three estimations have been
made.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 8
Project Planning
•Scheduling: After all the necessary project parameters have been estimated, the
schedules for manpower and other resources are developed.
•Staffing: Staff organisation and staffing plans are made.
•Risk management : This includes risk identification, analysis, and abatement
planning.
•Miscellaneous plans: This includes making several other plans such as quality
assurance plan, and configuration management plan, etc.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 9

Project Planning

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 10

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 11
Activities in step wise method
0 Select project
1 Identify project scope and objectives
1.1 Identify objectives and measures of effectiveness in meeting them
1.2 Establish a project authority
1.3 Identify stakeholders
1.4 Modify objectives in the light of stakeholder analysis
1.5 Establish methods of communication with all parties
2 Identify project infrastructure
2.1 Establish relationship between project and strategic planning
2.2 Identify installation standards and procedures
2.3 Identify project team organization

SUSHREE S., IIIT-BHUBANESWAR 12

Activities in step wise method
3 Analyse project characteristics
3.1 Distinguish the project as either objective- or product-driven
3.2 Analyze other project characteristics
3.3 Identify high-level project risks
3.4 Take into account user requirements concerning implementation
3.5 Select general life-cycle approach
3.6 Review overall resource estimates

4 Identify project products and activities

4.1 Identify and describe project products (including quality criteria)
4.2 Document generic product flows
4.3 Recognize product instances
4.4 Produce ideal activity network
4.5 Modify ideal to take into account need for stages and checkpoints

SUSHREE S., IIIT-BHUBANESWAR 13

Activities in step wise method
5 Estimate effort for each activity
5.1 Carry out bottom-up estimates
5.2 Revise plan to create controllable acclivities

6 Identify activity risks

6.1 identify and quantify activity-based risks
6.2 Plan risk reduction and contingency measures where appropriate
6.3 Adjust plans and estimates to take account of risks

7 Allocate resources
7.1 identify and allocate resources
7.2 Revise plans and estimates to take account of resource constraints

SUSHREE S., IIIT-BHUBANESWAR 14

Activities in step wise method
8 Review/publicize plan
8.1 Review quality aspects of project plan
8.2 Document plans and obtain agreement

9/10 Execute plan/lower levels of planning

This may require the reiteration of the planning process at a lower level

SUSHREE S., IIIT-BHUBANESWAR 15

Sliding window planning
•Large projects may take several years to complete.
•As a result, during the span of the project, the project parameters, scope of the
project, project staff, etc., often change drastically resulting in the initial plans
going haywire.
•It is usually very difficult to make accurate plans for large projects at project
[Link] order to overcome this problem, sometimes project managers
undertake project planning over several stages. That is, after the initial project
plans have been made, these are revised at frequent intervals.
•Planning a project over a number of stages protects managers from making big
commitments at the start of the project. This technique of staggered planning is
known as sliding window planning.
•In the sliding window planning technique, starting with an initial plan, the
project is planned more accurately over a number of stages.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 16

SPMP Document of Project Planning
•Once project planning is complete, project managers document their plans in a
software project management plan (SPMP) document.
•Organisation of the software project management plan
•(SPMP) document
•1. Introduction
•(a) Objectives
•(b) Major Functions
•(c) Performance Issues
•(d) Management and Technical Constraints

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 17

SPMP Document of Project Planning
2. Project estimates
(a) Historical Data Used
(b) Estimation Techniques Used
(c) Effort, Resource, Cost, and Project Duration Estimates
3. Schedule
(a) Work Breakdown Structure
(b) Task Network Representation
(c) Gantt Chart Representation
(d) PERT Chart Representation
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 18
SPMP Document of Project Planning
4. Project resources
(a) People
(b) Hardware and Software
(c) Special Resources
5. Staff organisation
(a) Team Structure
(b) Management Reporting

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 19

SPMP Document of Project Planning
6. Risk management plan
(a) Risk Analysis
(b) Risk Identification
(c) Risk Estimation
(d) Risk Abatement Procedures
7. Project tracking and control plan
(a) Metrics to be tracked
(b) Tracking plan
(c) Control plan
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 20
SPMP Document of Project Planning
8. Miscellaneous plans
(a) Process Tailoring
(b) Quality Assurance Plan
(c) Configuration Management Plan
(d) Validation and Verification
(e) System Testing Plan
(f ) Delivery, Installation, and Maintenance Plan

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 21

Metric for Project Size Estimation

•Lines of code
•Function point

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 22

Lines of Code(LOC)
•Counts the total number of lines of source code in the project
•Ignores the comments and header lines
•Determining at the end is easy
•Estimating at the beginning is difficult
•The project manager divides the problem into modules, and each module into
sub-modules and so on, until the LOC of the leaf-level modules are small enough
to be predicted. To be able to predict the LOC count for the various leaf-level
modules sufficiently accurately, past experience in developing similar modules is
very helpful. By adding the estimates for all leaf level modules together, project
managers arrive at the total size estimation.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 23

Lines of Code(LOC)
•Shortcomings
•LOC is a measure of coding activity alone. A good problem size measure should
consider the total effort needed to carry out various life cycle activities (i.e.
specification, design, code, test, etc.)
•LOC count depends on the choice of specific instructions: Different
programmers may lay out their code in very different ways. For example, one
programmer might write several source instructions on a single line, whereas
another might split a single instruction across several lines.
•LOC measure correlates poorly with the quality and efficiency of the code:
Larger code size does not necessarily imply better quality of code or higher
efficiency.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 24

Lines of Code(LOC)
•Shortcomings
•LOC metric penalises use of higher-level programming languages and code
reuse: A paradox is that if a programmer consciously uses several library
routines, then the LOC count will be lower. This would show up as smaller
program size, and in turn, would indicate lower effort!
•LOC metric measures the lexical complexity of a program and does not address
the more important issues of logical and structural complexities:
•It is very difficult to accurately estimate LOC of the final program from
problem specification:

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 25

Function Point(FP)
•Overcomes shortcomings of LOC and can be computed from program
specification
•Measures functionality from user’s point of view. It focuses on what
functionality is being delivered.
•Conceptually, the function point metric is based on the idea that a software
product supporting many features would certainly be of larger size than a
product with less number of features.
•Can be estimated during the requirement analysis stage.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 26

Function Point(FP)
•Though each feature takes some effort to develop, different features may take
very different amounts of efforts to develop.
•For example, in a banking software, a function to display a help message may be
much easier to develop compared to say the function that carries out the actual
banking transactions.
•This has been considered by the function point metric by counting the number
of input and output data items and the number of files accessed by the function.
The implicit assumption made is that the more the number of data items that a
function reads from the user and outputs and the more the number of files
accessed, the higher is the complexity of the function.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 27

Function Point(FP)
•Function point analysis (FPA) is a methodology for measuring software
productivity and the cost associated with the development and maintenance.
One function point (FP) is one end-user requested business function.
•It is the unit of measurement to express the amount of business functionality an
information system provides to a user.
•Using FP
• Estimate cost and effort to design, code and test software
• Predict number of errors that will be encountered during testing
• Forecast number of components or number of source line in implemented system

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 28

Function Point(FP)
•The basis of function point analysis is that information
systems comprise of five major components or
‘external user types’ that are of benefit to the users
• External input types(EI) – function relating to data
entering the system(logging in)
• External output types(EO) – functions relating to data
exiting the system(GUI display)
• External inquiry types(EQ) – functions that lead to data
retrieval from the system without changing the system
• Logical internal file types(ILF) – files maintained within
the system
• External interface file types(EIF) – files from other
application that allow for output and input (database
shared with other application)

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 29

Function Point(FP)
•FP = UFP X CAF
•where UFP = unadjusted functional point
•CAF = complexity adjustment factor
•Each FP is ranked according to complexity. There exists predefined weights for
each FP in each complexity category(simple, average or complex). We need to
determine the complexity of each of the FP which can be subjective.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 30

Function Point(FP)

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 31

Function Point(FP)

•where Fi is value adjustment factors based on responses to the following 14

questions

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 32

 Function Point(FP)
•Function Point Relative Complexity Adjustment Factors •Extent of online updating of master files
•Requirement for reliable backup and recovery •Extent of complex inputs, outputs, online queries and files
•Requirement for data communication •Extent of complex data processing
•Extent of distributed processing •Extent that currently developed code can be designed for
reuse
•Performance requirements
•Extent of conversion and installation included in the design
•Expected operational environment
•Extent of multiple installations in an organisation and
•Extent of online data entries variety of customer organisations
•Extent of multi-screen or multi-operation online data •Extent of change and focus on ease of use
input

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 33

Function Point(FP)
•CAF is calculated using 14 aspects of processing complexity and these 14
questions answered on a scale of 0-5.
•0 – no influence
•1- incidental
•2 – moderate
•3- average
•4 – significant
•5 – essential

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 34

Function Point(FP)

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 35

Function Point(FP)
•EI password, panic button
activate/deactivate
•EQ zone inquiry, sensor inquiry
•ILF system configuration file
•EO messages, sensor status
•EIF test sensor, zone setting,
activate/deactivate, alarm alert

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 36

Function Point(FP)
•Considering the simple weighing factor

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 37

Function Point(FP)
•Considering a moderately complex product
•Sum Fi = 14 X 2 = 28 2 – Moderate
•CAF = 0.65 + (0.01 X 28) =0.93

•FP = UFP x CAF = 50 x 0.93 = 46.5

•Assume LOC required per FP is 50.
•Calculate the total LOC.
•LOC = 50 X 46.5 = 2325

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 38

Function Point(FP)
•Given the following values, calculate the FP when complexity adjustment factors
are significantly complex product and weighting factors are high.
•User input = 55
•User output = 35
•User enquiries = 40
•User files = 8
•External interfaces = 5
•Assume LOC required per FP is 60.
•Calculate the total LOC.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 39

Function Point(FP)

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 40

Function Point(FP)
•Considering a significantly complex product
•Sum Fi = 14 X 4 = 56 4 – Moderate
•CAF = 0.65 + (0.01 X 56) =1.21

•FP = UFP x CAF = 985 x 1.21 = 1191.85

•LOC = 60 X 1191.85 = 71,511

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 41

Function Point(FP)
•Shortcomings
•does not take into account the algorithmic complexity of a function. assumes
that the effort required to design and develop any two different functionalities
of the system is the same.

•To overcome this , we have Feature point metric that incorporates algorithm
complexity as an extra parameter. This parameter ensures that the computed
size using the feature point metric reflects the fact that higher the complexity of
a function, the greater the effort required to develop it—therefore, it should
have larger size compared to a simpler function.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 42

Project estimation techniques
•an important project planning activity.
•Need to estimate size, effort, duration and cost.
•form the basis for resource planning and scheduling
•Estimation techniques can be broadly classified into three main categories
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 43

Empirical Estimation Techniques
•based on making an educated guess of the project parameters.
•prior experience with development of similar products is helpful.
•There exists two such formalization
• Expert judgement
• Delphi technique

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 44

Expert judgement(empirical estimation)
•an expert makes an educated guess about the problem size after analysing the
problem thoroughly.
•Usually, the expert estimates the cost of the different components (i.e. modules
or subsystems) that would make up the system and then combines the
estimates for the individual modules to arrive at the overall estimate.
•Shortcomings
•subject to human errors and individual bias.
•an expert may overlook some factors inadvertently
•an expert making an estimate may not have relevant experience and knowledge
of all aspects of a project.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 45

Expert judgement(empirical estimation)
•A more refined form of expert judgement is the estimation made by a group of
experts.
•Chances of errors arising out of issues such as individual oversight, lack of
familiarity with a particular aspect of a project, personal bias, and the desire to
win contract through overly optimistic estimates is minimised when the
estimation is done by a group of experts.
•However, the estimate made by a group of experts may still exhibit bias due to
reasons such as those arising out of political or social considerations.
•Another important shortcoming of the expert judgement technique is that the
decision made by a group may be dominated by overly assertive members.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 46

Delphi Cost Estimation Technique
•Overcomes some shortcomings of the expert judgement approach carried out
by a team comprising a group of experts and a co-ordinator.
•the co-ordinator provides each estimator with a copy of the software
requirements specification (SRS) document and a form for recording his cost
estimate.
•Estimators complete their individual estimates anonymously and submit them
to the co-ordinator.
•In their estimates, the estimators mention any unusual characteristic of the
product which has influence d their estimations.
•The co-Ordinator prepares the summary of the responses of all the estimators,
and also includes any unusual rationale noted by any of the estimators.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 47
Delphi Cost Estimation Technique
•The prepared summary information is distributed to the estimators.
•Based on this summary, the estimators re-estimate.
•This process is iterated for several rounds.
•However, no discussions among the estimators is allowed during the entire
estimation process to avoid influence of experienced estimators.
•After the completion of several iterations of estimations, the co-ordinator takes
the responsibility of compiling the results and preparing the final estimate.
•The Delphi estimation, though consumes more time and effort, overcomes an
important shortcoming of the expert judgement technique in that the results
can not unjustly be influenced by overly assertive and senior members.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 48

Heuristic Techniques
•Heuristic techniques assume that the relationships that exist among the
different project parameters can be satisfactorily modelled using suitable
mathematical expressions.

•Once the basic (independent) parameters are known, the other (dependent)
parameters can be easily determined by substituting the values of the
independent parameters in the corresponding mathematical expression.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 49

COCOMO Model
•Cocomo (Constructive Cost Model) is a regression model based on LOC,
i.e number of Lines of Code.

•It is a procedural cost estimate model for software projects and is often used as
a process of reliably predicting the various parameters associated with making a
project such as size, effort, cost, time, and quality.

•It was proposed by Barry Boehm in 1981 and is based on the study of 63
projects, which makes it one of the best-documented models.

SUSHREE S., IIIT-BHUBANESWAR 50

COCOMO Model
•The key parameters which define the quality of any software products, which
are also an outcome of the COCOMO are primarily Effort & Schedule:

• Effort: Amount of labor that will be required to complete a task. It is measured in

person-months units.

• Schedule: Simply means the amount of time required for the completion of the job,
which is, of course, proportional to the effort put in. It is measured in the units of
time such as weeks, and months.

SUSHREE S., IIIT-BHUBANESWAR 51

COCOMO Model
•Different models of COCOMO have been proposed to predict the cost estimation at
different levels, based on the amount of accuracy and correctness required.

•All of these models can be applied to a variety of projects, whose characteristics

determine the value of the constant to be used in subsequent calculations.

•The different system types as defined by Boehm’s are

• Organic
• Semidetached
• Embedded system

SUSHREE S., IIIT-BHUBANESWAR 52

COCOMO Model
•Organic – A software project is said to be an organic type if
• the team size required is adequately small,
• the problem is well understood and has been solved in the past and
• the team members have a nominal experience regarding the problem.

•Example : simple business systems, simple inventory management systems and

data processing systems

SUSHREE S., IIIT-BHUBANESWAR 53

COCOMO Model
•Semi-detached – A software project is said to be a Semi-detached type if
• the vital characteristics such as team size, experience, and knowledge of the various
programming environment lie in between that of organic and Embedded.
• The projects classified as Semi-Detached are comparatively less familiar and difficult to
develop compared to the organic ones and require more experience and better guidance and
creativity.
• The team is a mix of experienced and inexperienced staff.
• The team is unfamiliar with some aspects of the system being developed.

•Examples : developing new operating systems, Compilers, database management

systems, complex inventory management systems

SUSHREE S., IIIT-BHUBANESWAR 54

COCOMO Model
•Embedded – A software project requiring the highest level of complexity,
creativity, and experience requirement fall under this category.
•Such software requires a larger team size than the other two models and also
the developers need to be sufficiently experienced and creative to develop such
complex models.
•The software being developed is strongly coupled to complex hardware.

•Example : ATM, Air traffic control

SUSHREE S., IIIT-BHUBANESWAR 55

Basic COCOMO Model
•The basic COCOMO model provides an estimation of the following parameters
• Effort = E = a(KLOC)b person months
• Development Time = D = c(Effort)d months
• Person required = Effort / Time = E / D
•The constant values a,b,c,d for basic model for different categories of system

SUSHREE S., IIIT-BHUBANESWAR 56

Basic COCOMO Model
•Example
•Suppose a project was estimated to be made in 400 kLOC. Lets calculate its
effort, time, and the number of people required while considering the project is
of organic type:

• Effort(E) = 2.4(400 kLOC)1.05 = 1295.31 person−months

• Time(T) = 2.5(1295.31)0.38= 30.07 months

• People required = 1295.31 / 30.07=43.07 persons

SUSHREE S., IIIT-BHUBANESWAR 57

Basic COCOMO Model
•Assume that the size of an organic type software product has been estimated to
be 32,000 lines of source code. Assume that the average salary of a software
developer is Rs. 15,000 per month. Determine the effort required to develop the
software product, the nominal development time, and the cost to develop the
product.
•From the basic COCOMO estimation formula for organic software:
•Effort = 2.4 × (32)1.05 = 91 PM
•Nominal development time = 2.5 × (91)0.38 = 14 months
•Staff cost required to develop the product = 91 × Rs. 15, 000 = Rs.1,465,000

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 58

Intermediate COCOMO
•The basic COCOMO model assumes that effort and development time are
functions of the product size alone.
•However, other project parameters besides the product size affect the effort as
well as the time required to develop the product.

•The intermediate COCOMO model refines the initial estimate obtained using the
basic COCOMO expressions by scaling the estimate up or down based on the
evaluation of a set of attributes of software development.
•The intermediate COCOMO model uses a set of 15 cost drivers (multipliers) that
are determined based on various attributes of software development.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 59

Intermediate COCOMO
•In general, the cost drivers identified by Boehm can be classified as being attributes of
the following items:
•Product: The characteristics of the product that are considered include the inherent
complexity of the product, reliability requirements of the product, etc.
•Computer: Characteristics of the computer that are considered include the execution
speed required, storage space required, etc.
•Personnel: The attributes of development personnel that are considered include the
experience level of personnel, their programming capability, analysis capability, etc.
•Development environment: Development environment attributes capture the
development facilities available to the developers. An important parameter that is
considered is the sophistication of the automation (CASE) tools used for software
development.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 60
Complete COCOMO
•Shortcoming of basic and intermediate COCOMO
•consider a software product as a single homogeneous entity.

•most large systems are made up of several smaller sub-systems. These sub-
systems often have widely different characteristics. For example, some sub-
systems may be considered as organic type, some semidetached, and some even
embedded. N
•ot only may the inherent development complexity of the subsystems be
different, but for some subsystem the reliability requirements may be high, for
some the development team might have no previous experience of similar
development, and so on.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 61
Complete COCOMO
•The complete COCOMO model considers these differences in characteristics of
the subsystems and estimates the effort and development time as the sum of
the estimates for the individual sub-systems.

•The cost to develop each sub-system is estimated separately, and the complete
system cost is determined as the subsystem costs. This approach reduces the
margin of error in the final estimate.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 62

Complete COCOMO
•Example
•A distributed management information system (MIS) for an organization having
offices at several locations
•It will have the following sub-components with various complexity
• Database part – semi-detached
• Graphical user interface (GUI) part – organic
• Communication part – embedded
•The costs for these three components can be estimated separately, and summed
up to give the overall cost of the system.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 63

Complete COCOMO example

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 64

Analytical Estimation Techniques
•Analytical estimation techniques derive the required results starting with certain
basic assumptions regarding a project.
•have certain scientific basis.

•Example Halstead’s metrics for estimating software maintenance efforts.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 65

Halstead’s Software Metrics
•Halstead’s Software metrics are a set of measures proposed by Maurice
Halstead to evaluate the complexity of a software program.
•These metrics are based on the number of distinct operators and operands in
the program and are used to estimate the effort required to develop and
maintain the program.
•It can be used to estimate
• Size
• Complexity
• Effort required

SUSHREE S., IIIT-BHUBANESWAR 66

Halstead’s Software Metrics
•Fields of Halstead Metrics
•Program length (N): This is the total number of operator and operand occurrences in
the program.
•Vocabulary size (n): This is the total number of distinct operators and operands in the
program.
•Program volume (V): This is the product of program length (N) and the logarithm of
vocabulary size (n), i.e., V = N*log2(n). It represents the size in bits of the space
necessary for storing the program. This parameter depends on specific algorithm
implementation.
•Program level (L): This is the ratio of the number of operator occurrences to the
number of operand occurrences in the program, i.e., L = n1/n2, where n1 is the number
of operator occurrences and n2 is the number of operand occurrences.

SUSHREE S., IIIT-BHUBANESWAR 67

Halstead’s Software Metrics
•Fields of Halstead Metrics
•Program difficulty (D): This is the ratio of the number of unique operators to the
total number of operators in the program, i.e., D = (n1/2) * (N2/n2).
•Program effort (E): This is the product of program volume (V) and program
difficulty (D), i.e., E = V*D.
•Time to implement (T): This is the estimated time required to implement the
program, based on the program effort (E) and a constant value that depends on
the programming language and development environment.

SUSHREE S., IIIT-BHUBANESWAR 68

Halstead’s Software Metrics
•Halstead Metrics
•n1 – number of distinct operators
•n2 – number of distinct operands
•N1 – Total number of occurrences of operators
•N2 – Total number of occurrences of operands
•Halstead Program Length
•N = N1 + N2
•Halstead vocabulary
•n = n1 + n2

SUSHREE S., IIIT-BHUBANESWAR 69

Halstead’s Software Metrics
•Program volume
•V = size * (log2 vocabulary) = N * log2(n)

•Potential minimum volume

•V* is the most succinct program in which the problem can be coded.
•V* = (2 + n2*) * log2(2 + n2*)
Here, n2* is the count of unique input and output parameters

SUSHREE S., IIIT-BHUBANESWAR 70

Halstead’s Software Metrics
•Program level
•To rank the programming languages, the level of abstraction provided by the
programming language, Program Level (L) is considered. The higher the level of a
language, the less effort it takes to develop a program using that language.

L = V* / V

•The value of L ranges between zero and one, with L=1 representing a program written
at the highest possible level (i.e., with minimum size).

•And estimated program level is L^ =2 * (n2) / (n1)(N2)

SUSHREE S., IIIT-BHUBANESWAR 71

Halstead’s Software Metrics
•Program difficulty
•This parameter shows how difficult to handle the program is.

D = (n1 / 2) * (N2 / n2)

D=1/L

•As the volume of the implementation of a program increases, the program level
decreases and the difficulty increases. Thus, programming practices such as
redundant usage of operands, or the failure to use higher-level control
constructs will tend to increase the volume as well as the difficulty.

SUSHREE S., IIIT-BHUBANESWAR 72

Halstead’s Software Metrics
•Programming effort
•Measures the amount of mental activity needed to translate the existing
algorithm into implementation in the specified program language.
E=V*D
•Language Level
•Shows the algorithm implementation program language level. The same
algorithm demands additional effort if it is written in a low-level program
language. For example, it is easier to program in Pascal than in Assembler.

SUSHREE S., IIIT-BHUBANESWAR 73

Halstead’s Software Metrics
•Intelligence Content
•Determines the amount of intelligence presented (stated) in the program This
parameter provides a measurement of program complexity, independently of
the programming language in which it was implemented.

I=V/D

SUSHREE S., IIIT-BHUBANESWAR 74

Halstead’s Software Metrics
•Programming Time
•Shows time (in minutes) needed to translate the existing algorithm into
implementation in the specified program language.
T = E / (f * S)
•Where S is called as Stoud’s moment which as been empirically
developed from psychological reasoning. Its value for programming
application is 18 moments/second.
•f is called the seconds-to-minutes factor = 60

SUSHREE S., IIIT-BHUBANESWAR 75

 Halstead’s Software Metrics
•Counting rules for C Language
[Link] are not considered.
[Link] identifier and function declarations are not considered
[Link] the variables and constants are considered operands.
[Link] variables used in different modules of the same program are counted as multiple occurrences
of the same variable.
[Link] variables with the same name in different functions are counted as unique operands.
[Link] calls are considered operators.
[Link] looping statements e.g., do {…} while ( ), while ( ) {…}, for ( ) {…}, all control statements e.g., if ( )
{…}, if ( ) {…} else {…}, etc. are considered as operators.
[Link] control construct switch ( ) {case:…}, switch as well as all the case statements are considered as
operators.

SUSHREE S., IIIT-BHUBANESWAR 76

Halstead’s Software Metrics
[Link] reserve words like return, default, continue, break, size, etc., are considered operators.
[Link] the brackets, commas, and terminators are considered operators.
[Link] is counted as an operator and the label is counted as an operand.
[Link] unary and binary occurrences of “+” and “-” are dealt with separately. Similarly “*”
(multiplication operator) is dealt with separately.
[Link] the array variables such as “array-name [index]” “array-name” and “index” are considered
as operands and [ ] is considered as operator.
[Link] the structure variables such as “struct-name, member-name” or “struct-name -> member-
name”, struct-name, and member-name are taken as operands, and ‘.’, ‘->’ are taken as
operators. Some names of member elements in different structure variables are counted as
unique operands.
[Link] the hash directives are ignored.

SUSHREE S., IIIT-BHUBANESWAR 77

Halstead’s Software Metrics
Example if (x[i] < x[j])
int sort (int x[ ], int n) {
{ Save = x[i];
int i, j, save, im1; x[i] = x[j];
/*This function sorts array x in x[j] = save;
ascending order */ }
If (n< 2) return 1; }
for (i=2; i< =n; i++) return 0;
{ }
im1=i-1;
for (j=1; j< =im1; j++)

SUSHREE S., IIIT-BHUBANESWAR 78

 Operators Occurrences Operands Occurrences

int 4 sort 1

() 5 x 7

Halstead’s Software Metrics

,

[]
4

7
n

i
3

if 2 j 7

< 2 save 3

; 11 im1 3

for 2 2 2

= 6 1 3

– 1 0 1

<= 2 – –

++ 2 – –

return 2 – –

{} 3 – –

n1=14 N1=53 n2=10 N2=38

SUSHREE S., IIIT-BHUBANESWAR 79

 Halstead’s Software Metrics
N = 91
n = 24
V = 417.23 bits
N^ = 86.51
n2* = 3 (x:array holding integer to be sorted. This is used both as input and output)
V* = 11.6
L = 0.027
D = 37.03
L^ = 0.038
T = 610 seconds

SUSHREE S., IIIT-BHUBANESWAR 80

Halstead’s Software Metrics
•Advantages
•It is simple to calculate.
•It measures the overall quality of the programs.
•It predicts the rate of error.
•It predicts maintenance effort.
•It does not require a full analysis of the programming structure.
•It is useful in scheduling and reporting projects.
•It can be used for any programming language.

SUSHREE S., IIIT-BHUBANESWAR 81

Halstead’s Software Metrics
•Advantages
•Easy to use
•Quantitative measure: The metrics provide a quantitative measure of the
complexity and effort required to develop and maintain a software program,
which can be useful for project planning and estimation.
•Language independent: The metrics can be used for different programming
languages and development environments.
•Standardization: The metrics provide a standardized way to compare and
evaluate different software programs.

SUSHREE S., IIIT-BHUBANESWAR 82

Halstead’s Software Metrics
•Disadvantages
•It depends on the complete code.
•It has no use as a predictive estimating model.
•Limited scope: The metrics focus only on the complexity and effort required to develop
and maintain a software program, and do not take into account other important factors
such as reliability, maintainability, and usability.
•Limited applicability: The metrics may not be applicable to all types of software
programs, such as those with a high degree of interactivity or real-time requirements.
•Limited accuracy: The metrics are based on a number of assumptions and
simplifications, which may limit their accuracy in certain situations.

SUSHREE S., IIIT-BHUBANESWAR 83

Scheduling
•The scheduling problem, in essence, consists of deciding which tasks would be
taken up when and by whom.

•Once a schedule has been worked out and the project gets underway, the
project manager monitors the timely completion of the tasks and takes any
corrective action that may be necessary whenever there is a chance of schedule
slippage.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 84

Scheduling
•In order to schedule the project activities, a software project manager needs to do the
following:
1. Identify all the major activities that need to be carried out to complete the project.
2. Break down each activity into tasks.
3. Determine the dependency among different tasks.
4. Establish the estimates for the time durations necessary to complete the tasks.
5. Represent the information in the form of an activity network.
6. Determine task starting and ending dates from the information represented in the
activity network.
7. Determine the critical path. A critical path is a chain of tasks that determines the
duration of the project.
8. Allocate resources to tasks.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 85

Scheduling
•The first step in scheduling a software project involves identifying all the
activities necessary to complete the project.
•A good knowledge of the intricacies of the project and the development process
helps the managers to effectively identify the important activities of the project.
Next, the activities are broken down into a logical set of smaller activities (sub-
activities).
•The smallest sub-activities are called tasks which are assigned to different
developers. The smallest unit of work activities that are subject to management
planning and control are called tasks.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 86

Scheduling
•A project manager breakdowns the tasks systematically by using the work
breakdown structure technique.
•After the project manager has broken down the activities into tasks, he has to
find the dependency among the tasks. Dependency among the different tasks
determines the order in which the different tasks would be carried out. If a task
A requires the results of another task B, then task A must be scheduled after
task B and A is said to be dependent on B. In general, the task dependencies
define a partial ordering among tasks. That is, each tasks may precede a subset
of other tasks, but some tasks might not have any precedence ordering defined
between them (called concurrent task ).

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 87

Scheduling
•The dependency among the activities are represented in the form of an activity
network.
•Once the activity network representation has been worked out, resources are
allocated to each activity.
•Resource allocation is typically done using a Gantt chart. After resource
allocation is done, a project evaluation and review technique (PERT) chart
representation is developed. The PERT chart representation is useful to a project
manager to carry out project monitoring and control.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 88

Work Breakdown Structure
•Work breakdown structure (WBS) is used to recursively decompose a given set
of activities into smaller activities.

•Tasks are the lowest level work activities in a WBS hierarchy. They also form the
basic units of work that are allocated to the developer and scheduled.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 89

Work Breakdown Structure
•why it is necessary to break down project activities into tasks?

•Once project activities have been decomposed into a set of tasks using WBS, the
time frame when each activity is to be performed is to be determined. The end
of each important activity is called a milestone. The project manager tracks the
progress of a project by monitoring the timely completion of the milestones. If
he observes that some milestones start getting delayed, he carefully monitors
and controls the progress of the tasks, so that the overall deadline can still be
met.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 90

 Work Breakdown Structure
•WBS provides a notation for representing the
activities, sub-activities, and tasks needed to
be carried out in order to solve a problem.
•Each of these is represented using a rectangle.
•The root of the tree is labelled by the project
name.
•Each node of the tree is broken down into
smaller activities that are made the children of
the node.
•To decompose an activity to a sub-activity, a
good knowledge of the activity can be useful.
•The figure represents the WBS of the MIS
software

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 91

Work Breakdown Structure
•How long to decompose?
•The decomposition of the activities is carried out until any of the following is
satisfied:
• A leaf-level subactivity (a task) requires approximately two weeks to develop.
• Hidden complexities are exposed, so that the job to be done is understood
and can be assigned as a unit of work to one of the developers.
• Opportunities for reuse of existing software components is identified.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 92

Work Breakdown Structure
•Breaking down tasks to fine level vs coarse •Coarse-grained decomposition –
level weeks/months
•Fine-grained decomposition – 1-2days •Pros
•Pros
•Less effort in planning/updating
•Frequent monitoring
•Cons
•Early issue detection
•Enables parallelism •Delays noticed too late
•Cons •Difficult to correct issues in time
•High overhead
•Frequent plan revisions
•Manager burden

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 93

Activity Networks
•An activity network shows the different activities making up a project, their
estimated durations, and their interdependencies.
•Two equivalent representations for activity networks are possible and are in use:
•Activity on Node(AoN) - each activity is represented by a rectangular (some use
circular) node and the duration of the activity is shown alongside each task in
the node. The inter-task dependencies are shown using directional edges
•Activity on Edge(AoE) - tasks are associated with the edges. The edges are also
annotated with the task duration. The nodes in the graph represent project
milestones.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 94

Activity Networks

T2 T4

T1 T6

T3 T5

T7

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 95

Critical Path Method
•A path in the activity network graph is any set of consecutive nodes and edges in
this graph from the starting node to the last node.
•A critical path consists of a set of dependent tasks that need to be performed in
a sequence and which together take the longest time to complete.
•A critical task is one with a zero slack time.
•A path from the start node to the finish node containing only critical tasks is
called a critical path.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 96

Critical Path Method
•CPM involves calculating the following quantities for the different tasks:
•Minimum time (MT): It is the minimum time required to complete the project.
It is computed by determining the maximum of all paths from start to finish.
•Earliest start (EST): It is the time of a task is the maximum of all paths from the
start to this task. The ES for a task is the ES of the previous task plus the duration
of the preceding task. Largest EFT of preceding task except first task for which it
is 0.
•Latest start time (LST): It is the difference between MT and the maximum of all
paths from this task to the finish. The LST can be computed by subtracting the
duration of the subsequent task from the LST of the subsequent task.
LST = LFT - D

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 97

Critical Path Method
•CPM involves calculating the following quantities for the different tasks:
•Earliest finish time (EFT): The EFT for a task is the sum of the earliest start time
of the task and the duration of the task. EFT = EST + D
•Latest finish (LFT): LF indicates the latest time by which a task can finish without
affecting the final completion time of the project. A task completing beyond its
LF would cause project delay. LF of a task can be obtained by subtracting
maximum of all paths from this task to finish from MT. LST of following
task(except for the last task for which EFT = LFT)
•Slack time (ST): The slack time (or float time) is the total time that a task may be
delayed before it will affect the end time of the project. The slack time indicates
the ”flexibility” in starting and completion of tasks. ST for a task is LS-ES and can
equivalently be written as LF-EF. SL = LFT - EFT
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 98
Critical Path Method

EST D EFT

ACTIVITY NAME

LST ST LFT

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 99

 CRITICAL PATH
T1 - > T2 -> T4 -> T6

Critical Path Method

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 100

Critical Path Method
Task Duration Dependent EST EFT LST LFT ST
on tasks
T1 Specification 15 - 0 15 0 15 0
T2 Design database 45 T1 15 60 15 60 0
T3 Design GUI part 30 T1 15 45 90 120 75
T4 Code data base 105 T2 60 165 60 165 0
T5 Code GUI part 45 T3 45 90 120 165 75
T6 Integrate and test 120 T4 AND T5 165 285 165 285 0
T7 Write user manual 60 T1 15 75 225 285 210

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 101

Critical Path Method
•Draw the activity network, compute the EST, LST, LFT, EFT and Slack Time. Mark
the Critical Path and list the Critical Tasks.

Activity Predecessor Duration(in months)

A - 5
B A 4
C A 5
D B 6
E C 3
F D,E 4

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 102

 CRITICAL PATH
A -> B -> D -> F

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 103

Critical Path Method
Task Duration Dependent on tasks EST EFT LST LFT ST
A 5 - 0 5 0 5 0
B 4 A 5 9 5 9 0
C 5 A 5 10 7 12 2
D 6 B 9 15 9 15 0
E 3 C 10 13 12 15 2
F 4 D,E 15 19 15 19 0

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 104

PERT
•The activity durations computed using an activity network are only estimated
duration.
•It is therefore not possible to estimate the worst case (pessimistic) and best case
(optimistic) estimations using an activity diagram.
•Since, the actual durations might vary from the estimated durations, the utility
of the activity network diagrams are limited.
•The CPM can be used to determine the duration of a project, but does not
provide any indication of the probability of meeting that schedule.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 105

PERT
•Project evaluation and review technique (PERT) charts are a more sophisticated
form of activity chart.
•Project managers know that there is considerable uncertainty about how much
time a task would exactly take to complete.
•The duration assigned to tasks by the project manager are after all only
estimates.
•Therefore, in reality the duration of an activity is a random variable with some
probability distribution.
•In this context, PERT charts can be used to determine the probabilistic times for
reaching various project mile stones, including the final mile stone.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 106

PERT
•PERT charts like activity networks consist of a network of boxes and arrows.
•The boxes represent activities and the arrows represent task dependencies.
•A PERT chart represents the statistical variations in the project estimates
assuming these to be normal distribution.
•PERT allows for some randomness in task completion times, and therefore
provides the capability to determine the probability for achieving project
milestones based on the probability of completing each task along the path to
that milestone.
•Each task is annotated with three estimates:
•Optimistic (O): The best possible case task completion time.
•Most likely estimate (M): Most likely task completion time.
•Worst case (W): The worst possible case task completion time.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 107
PERT
•The optimistic (O) and worst case (W) estimates represent the extremities of all
possible scenarios of task completion.
•The most likely estimate (M) is the completion time that has the highest
probability.
•The mean estimated time is calculated as
•ET = (O + 4M + W) / 6

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 108

PERT
Activity O M W Estimated
Time
A 6 8 10
B 2 3 20
C 10 11 18
D 3 4 11
E 4 4 4

ET = (O + 4M + W) / 6

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 109

PERT
Activity O M W Estimated
Time
A 6 8 10 8
B 2 3 20 5.6
C 10 11 18 12
D 3 4 11 5
E 4 4 4 4

ET = (O + 4M + W) / 6

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 110

PERT Chart

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 111

Gantt Chart
•Gantt chart has been named after its developer Henry Gantt.
•A Gantt chart is a form of bar chart.
•The vertical axis lists all the tasks to be performed. The bars are drawn along the
y-axis, one for each task.
•Gantt charts used in software project management are actually an enhanced
version of the standard Gantt charts.
•In the Gantt charts used for software project management, each bar consists of
an unshaded part and a shaded part.
•The shaded part of the bar shows the length of time each task is estimated to
take. The unshaded part shows the slack time or lax time.
•The lax time represents the leeway or flexibility available in meeting the latest
time by which a task must be finished.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 112
Gantt Chart
•Gantt charts are useful for resource planning (i.e. allocate resources to
activities). The different types of resources that need to be allocated to activities
include staff, hardware, and software.

•Gantt chart representation of a project schedule is helpful in planning the

utilization of resources, while PERT chart is useful for monitoring the timely
progress of activities. Also, it is easier to identify parallel activities in a project
using a PERT chart. Project managers need to identify the parallel activities in a
project for assignment to different developers.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 113

Gantt Chart

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 114

Project Monitoring and Control
•Once a project gets underway, the project manager monitors the project
continuously to ensure that it is progressing as per plan.
•The project manager designates certain key events such as completion of some
important activity as a milestone.
•A few examples of milestones are as following—a milestone can be the
preparation and review of the SRS document, completion of the coding and unit
testing, etc.
•Once a milestone is reached; the project manager can assume that some
measurable progress has been made. If any delay in reaching a milestone is
predicted, then corrective actions might have to be taken.
•This may entail reworking all the schedules and producing a fresh schedule.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 115
Project Monitoring and Control
•The PERT chart is especially useful in project monitoring and control.
•A path in this graph is any set of consecutive nodes and edges from the starting
node to the last node. A critical path in this graph is a path along which every
milestone is critical to meeting the project deadline.
•In other words, if any delay occurs along a critical path, the entire project would
get delayed. It is therefore necessary to identify all the critical paths in a
schedule—adhering to the schedules of the tasks appearing on the critical paths
is of prime importance to meet the delivery date.
•Please note that there may be more than one critical path in a schedule. The
tasks along a critical path are called critical tasks. The critical tasks need to be
closely monitored and corrective actions need to be initiated as soon as any
delay is noticed.
•If necessary, a manager may switch resources from a non-critical task to a critical
task so that all milestones along the critical path are met.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 116
The Make/Buy Decision
•In many software application areas, it is often more cost effective to acquire
rather than develop computer software.
•Software engineering managers are faced with a make/ buy decision that can be
further complicated by a number of acquisition options:
•(1) software may be purchased (or licensed) off-the-shelf,
•(2) “full-experience” or “partial-experience” software components may be
acquired and then modified and integrated to meet specific needs, or
•(3) software may be custom built by an outside contractor to meet the
purchaser’s specifications.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 117

The Make/Buy Decision
•The steps involved in the acquisition of software are defined by the criticality of
the software to be purchased and the end cost. In some cases (e.g., low-cost PC
software), it is less expensive to purchase and experiment than to conduct a
lengthy evaluation of potential software packages. In the final analysis, the
make/buy decision is made based on the following conditions:
•(1) Will the delivery date of the software product be sooner than that for
internally developed software?
•(2) Will the cost of acquisition plus the cost of customization be less than the
cost of developing the software internally?
•(3) Will the cost of outside support (e.g., a maintenance contract) be less than
the cost of internal support? These conditions apply for each of the acquisition
options.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 118
The Make/Buy Decision
•Creating a decision tree
•The steps just described can be augmented
using statistical techniques such as decision
tree analysis
•For example, Figure depicts a decision tree
for a software based system X.
•In this case, the software engineering
organization can
•(1) build system X from scratch,
•(2) reuse existing partial-experience
components to construct the system,
•(3) buy an available software product and
modify it to meet local needs, or
•(4) contract the software development to an
outside vendor.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 119

 The Make/Buy Decision
•Creating a decision tree
•Expected cost=∑(path probability)iX(estimated path cost)i
•where i is the decision tree path. For the build path,
•Expected costbuild = 0.30 ($380K) + 0.70 ($450K) = $429K
•Expected costreuse = 0.40 ($275K) + 0.60 [0.20 ($310K)+
0.80 ($490K)] = $382K
•Expected costbuy = 0.70 ($210K) + 0.30 ($400K) = $267K
•Expected costcontract = 0.60 ($350K) + 0.40 ($500K) = $410K
•The lowest expected cost is the “buy” option.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 120

The Make/Buy Decision
•It is important to note, however, that many criteria—not just cost— must be
considered during the decision-making process.
•Availability, experience of the developer/ vendor/contractor, conformance to
requirements, local “politics,” and the likelihood of change are but a few of the
criteria that may affect the ultimate decision to build, reuse, buy, or contract.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 121

The Make/Buy Decision
•Outscourcing
•Sooner or later, every company that develops computer software asks a
fundamental question: “Is there a way that we can get the software and systems
we need at a lower price?”
•Answer : Outsourcing
•Software engineering activities are contracted to a third party who does the
work at lower cost and, hopefully, higher quality. Software work conducted
within a company is reduced to a contract management activity.
•The decision to outsource can be either strategic or tactical. At the strategic
level, business managers consider whether a significant portion of all software
work can be contracted to others. At the tactical level, a project manager
determines whether part or all of a project can be best accomplished by
subcontracting the software work.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 122

Earned Value Analysis
•the Earned Value System offers a standardized way to measure progress across
all tasks in a software project, no matter the type of work involved.

•By estimating the total hours needed for the project and assigning a portion of
that value to each task, progress can be tracked quantitatively.

•Essentially, earned value measures how much work has actually been
completed relative to the plan. This method helps avoid relying on intuition or
subjective assessments of progress.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 123

Earned Value Analysis
•Steps
•1. The budgeted cost of work scheduled (BCWS) is determined for each work task
represented in the schedule. During estimation, the work (in person-hours or person-
days) of each software engineering task is planned. Hence, BCWSi is the effort planned
for work task i. To determine progress at a given point along the project schedule, the
value of BCWS is the sum of the BCWSi values for all work tasks that should have been
completed by that point in time on the project schedule.
•2. The BCWS values for all work tasks are summed to derive the budget at completion
(BAC). Hence,
•BAC = ∑ (BCWSk) for all tasks k
•3. Next, the value for budgeted cost of work performed (BCWP) is computed. The value
for BCWP is the sum of the BCWS values for all work tasks that have actually, been
completed by a point in time on the project schedule.
SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 124
Earned Value Analysis
•The BCWS represents the budget of the activities that were planned to be
completed and the BCWP represents the budget of the activities that actually
were completed
•Schedule performance index, SPI = BCWP / BCWS
•an indication of the efficiency with which the project is utilizing scheduled
resources. An SPI value close to 1.0 indicates efficient execution of the project
schedule.
•Schedule variance, SV = BCWP – BCWS
•SV is simply an absolute indication of variance from the planned schedule.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 125

Earned Value Analysis
•Percent scheduled for completion = BCWS / BAC
•provides an indication of the percentage of work that should have been completed by
time t.

•Percent complete = BCWP / BAC

•provides a quantitative indication of the percent of completeness of the project at a
given point in time t.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 126

Earned Value Analysis
•The value for Actual cost of work performed ACWP is the sum of the effort actually
expended on work tasks that have been completed by a point in time on the project
schedule.
•Cost performance index, CPI = BCWP / ACWP
•Cost variance, CV = BCWP – ACWP
•A CPI value close to 1.0 provides a strong indication that the project is within its defined
budget. CV is an absolute indication of cost savings (against planned costs) or shortfall
at a particular stage of a project.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 127

Numerical
•Earned value
•If your budget is $10,000 and your percent complete is 40%, the earned value is
•EV = %complete x total budget
•EV = 40% x $10,000
•EV = $4,000

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 128

Numerical
•Scheduled value
To get SV, calculate the difference between earned value and planned value (PV),
which is the budgeted amount for the work scheduled for completion.
SV = EV – PV
If the planned value to date is $5,000 — meaning 50% of the project should have
already been completed —
SV will be computed as follows:
SV = $4,000 – $5,000
SV = –$1,000
SV is negative, so the project is behind schedule.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 129

Numerical
Cost variance (CV)
To calculate cost variance, subtract the actual cost (AC) from EV. Let’s say your AC
is $4,500.
CV = EV – AC
CV = $4,000 – $4,500
CV = –$500

CV is negative, so the project is over budget.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 130

Numerical
Schedule performance index (SPI)
SPI = EV/PV
SPI = $4,000/$5,000
SPI = 0.8
The project is 20% behind schedule.
Cost performance index (CPI)
Much like CV, CPI indicates project cost efficiency and also provides an estimate of the
variance.
CPI = EV/AC
CPI = $4,000/$4,500
CPI = 0.89
The project is 11% over budget.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 131

Numerical
Expected Monetary Value (EMV)
= Probability of the Risk (P) * Impact of the Risk (I)
or simply, EMV = P * I
EMV calculates the average outcome when the future includes uncertain
scenarios — positive (opportunities) or negative (threats). Opportunities are
expressed as positive values, while threats have negative values. Both the values
will be considered by adding them together.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 132

Numerical
•Example: You’re doing a prototype for your project, but you’re not sure whether
to proceed with this prototype. If you do the prototype, it will cost you
$100,000; and, of course, if you don’t pursue it, there will be no cost. If you do
the prototype, there is 30 percent chance that the prototype might fail, and for
that the cost impact will be $50,000. However, if the prototype succeeds, the
project will make $500,000. If you do not do any prototype, you’re already
taking a risk, the chance of which is 80 percent with a failure impact of
$250,000. But, again, without a prototype, should you succeed, the project will
make the same money as mentioned before. What should you do?

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 133

Numerical
•To begin your analysis, start from the left
and move from the left to the right. First,
draw the event in a rectangle for the
event — “Prototype or Not.” This
obviously will lead to a decision node (in
the small, filled-up square node as shown
below).
•From there, you have two options — “Do
Prototype” and “Don’t Prototype.” They
are also put in rectangles as shown
below.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 134

Numerical
•Each option will lead to two events or chances — success or failure — branching
out from the chance nodes.
•Taking the first option, if it fails, which has a 30 percent chance, the impact will
be $50,000. If it succeeds (a 70 percent chance), there’s no cost, but there is a
payoff of $500,000. These are noted on the arrows.
•Similarly, for the second decision, “Don’t Prototype”:

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 135

Numerical

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 136

Numerical
EMV for Chance Node 1, the first circle:
The net path value for the prototype with 70 percent success = Payoff – Cost:
= +$500,000 – $100,000
= +$400,000
The net path value, for the prototype with a 30 percent failure = Payoff – Cost:
= -$50,000 – $100,000
= -$150,000
EMV of chance node 1 = [70% * (+$400,000)] + (30% * (-$150,000)]
= +$280,000 – $45,000
= +$235,000

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 137

Numerical
EMV for Chance Node 2 (the second circle):
The net path value for the prototype with a 20 percent success = Payoff – Cost:
= +$500,000 – $0
= +$500,000
The net path value for the prototype with 80 percent failure = Payoff – Cost:
= -$250,000 – $0
= -$250,000
EMV of chance node 2 = [20% * (+$500,000)] + (80% * (-$250,000)]
= +$100,000 – $200,000
= -$100,000

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 138

Which alternative would you take? Look at the EMV of the decision node (the filled-up
square). That’s +$235,000. With the other option — no prototyping — you’re losing
money. Hence, you should go for the prototype.
Decision tree analysis can be applied to various project management situations where
you’re faced to options or alternatives.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 139

Numerical
▪Dave owns a condo in the Far East and is considering buying a new apartment in Italy, but his
wife would rather spend the money on modernizing their current condo.
▪Dave had previously considered modernizing your condo, but purchasing or importing modern
furniture in your city has been a problem in the Far East.
▪Remodelling costs of the condo if new furniture and fittings are available will cost $ 45,000, but
there is a 50/50 chance that the furniture is not available locally and will need to be imported
which will then cost $65,000.
▪Dave has found an old townhouse in Naples but it will need a lot of work to make it habitable.
The price is $ 105,000. He has found a local builder and he has given you a best case cost of
$55,000 and a worst case cost of $75,000. The builder advises that the best case is 60% likely.
▪Dave expects to get $160,000 for the sale of his condo, and now needs to discuss the possible
outcomes with his wife. Draw a decision tree and calculate the Net Path Value (Expected
Monetary Value).

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 140

 Cost = $0

Cost = +$160,000 -$105,000

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 141

Numerical
EMV of refurbishing = [50% x (-$45,000)] + (50% x (-$65,000)]
= -$22,500 - $32,500
= -$55,000
EVM of Itlay = +$160,000 -$105,000 –[60% x $55,000 + 40% x $75,000]
= +$160,000 -$105,000 –[ $33,000 + $30000]
= +$160,000 -$105,000 – $63,000
= -$8,000
Dave should buy a new house in Italy.

SUSHREE S. , SILICON UNIVERSITY, BHUBANESWAR 142