Feasibility Study

D. P. Mohapatra
NIT Rourkela
1
 Life Cycle Model: Milestones

• Milestones help software project

managers:
–Track the progress of the project.
–Phase entry and exit are
important milestones.

2
 Life Cycle and Project Management
• When a life cycle model is
followed:
–The project manager can at any time
fairly accurately tell,
•At which stage (e.g., design, code,
test, etc.) the project is.
3
Project Management Without Life Cycle Model

• It becomes very difficult to track the

progress of the project.
–The project manager would have to
depend on the guesses of the team
members.
• This usually leads to a problem:
–known as the 99% complete syndrome.
4
 Project Deliverables: Myth and Reality
Myth:
The only deliverable for a successful project is
the working program.
Reality:
Documentation of all aspects of software
development are needed to help in
operation and maintenance.
5
• Many life cycle models have been proposed.
• We confine our attention to only a few commonly
used models.
–Waterfall Life Cycle Model (CONT.)

–V model,
–Evolutionary, Traditional models
–Prototyping
–Spiral model,
–Agile models
6
• Software life cycle (or software process):
–Series of identifiable stages that a
software product undergoes during its
life time:
• Feasibility study
• Requirements analysis and specification,
• Design,
• Coding, Software Life Cycle
• Testing
• Maintenance. 7
 Classical Waterfall Model
• Classical waterfall model divides life
cycle into following phases:
–Feasibility study, Conceptualize

Retire Specify
–Requirements analysis and
Design
Maintain
specification,
–Design, Deliver Code

Test
–Coding and unit testing,
–Integration and system testing,
–Maintenance. 8
 Classical Waterfall Model
Feasibility Study

Simplest and most

Req. Analysis
intuitive
Design

Coding

Testing

Maintenance

9
 Relative Effort for Phases
• Phases between feasibility study
and testing 60
50
–Called development phases. 40

Relative Effort
• Among all life cycle phases 30
20
–Maintenance phase consumes 10
maximum effort. 0

Maintnce
Design

Test
Coding
Req. Sp
• Among development phases,
–Testing phase consumes the
maximum effort.
• Most organizations usually define:
–Standards on the outputs (deliverables) produced
at the end of every phase
–Entry and exit criteria for every phase.
• They also prescribe methodologies for:
–Specification,
Process Model
–Design,
–Testing,
–Project management, etc.
Feasibility Study
Economic
feasibility
(also called
cost/benefit
feasibility)

Technical Feasibility Schedule

feasibility Dimensions feasibility

12
• Main aim of feasibility study: determine
whether developing the software is:
– Financially worthwhile Feasibility Study
– Technically feasible.
First Step
• Roughly understand what customer wants:
–Data which would be input to the system,
–Processing needed on these data,
–Output data to be produced by the system,
–Various constraints on the behavior of the
system. 13
• SPF Scheme for CFL
• CFL has a large number of employees, exceeding
50,000.
• Majority of these are casual labourers
• Mining being a risky profession:
– Casualties are high
Case Study
• Though there is a PF:
– But settlement time is high
• There is a need of SPF:
– For faster disbursement of benefits
14
 Feasibility: Case Study
• Manager visits main office, finds out the
main functionalities required
• Visits mine site, finds out the data to be
input
• Suggests alternate solutions
• Determines the best solution
• Presents to the CFL Officials
• Go/No-Go Decision
15
 Activities During Feasibility Study
• Work out an overall understanding of the
problem.
• Formulate different solution strategies.
• Examine alternate solution strategies in
terms of:
• resources required,
• cost of development, and
• development time. 16
• Perform a cost/benefit analysis:
–Determine which solution is the best.
–May also find that none of the
solutions is feasible due to:
• high cost, Activities during
Feasibility Study
• resource constraints,
• technical reasons.

17
 Cost benefit analysis (CBA)
• Need to identify all costs --- these could be:
– Development costs
– Set-up
– Operational costs
• Identify the value of benefits

• Check benefits are greater than costs

18
 The business case
• Benefits of delivered
project must outweigh
Benefits
costs
Costs • Costs include:
- Development
Rs - Operation
Rs • Benefits:
– Quantifiable
– Non-quantifiable

19
 The business case
• Feasibility studies should help write a
‘business case’
• Should provide a justification for starting
the project
• Should show that the benefits of the
project will exceed:
– Various costs
• Needs to take account of business risks 20
1. Executive summary
2. Project background:
 The focus must be on what, exactly, the project is undertaking, and should
not be confused with what might be a bigger picture.

3. Business opportunity
- What difference will it make? Writing an Effective
- What if we don’t do it?
Business Case
4. Costs
- Should include the cost of development, implementation, training, change
management, and operations.

5. Benefits
 Benefits usually presented in terms of revenue generation and cost
reductions.

6. Risks
− Identify risks.
− Explain how these will be managed.
21
 Summary
• Discussed how Life Cycle and Project
Management are related.
• Discussed the Relative Effort distribution for
different Phases of SDLC model.
• Explained the different types of feasibility.
• Described the steps of feasibility study.
• Discussed the different activities carried out
during feasibility study.
• Explained feasibility study by taking a case
study.
• Briefly explained C-B Analysis.
• Explained what is business case and how to
write a business case. 22
 References
1. Fundamentals of Software Engineering, Rajib
Mall, Fifth Edition, PHI, 2018.
2. Software Project Management, Bob Huges,
Mike Cotterell, Rajib Mall, Fifth Edition, PHI,
2018.

23
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Introduction
 Introduction
 Many software projects fail:
◦ due to faulty project management practices:
 It is important to learn different aspects of software project
management.

3
 Introduction cont…
 Goal of software project management:
◦ enable a group of engineers to work efficiently towards
successful completion of a software project.

4
 Outline of talk
In this introduction the main questions to be addressed will
be:
◦ What is software project management? Is it really different
from ‘ordinary’ project management?
◦ How do you know when a project has been successful? For
example, do the expectations of the customer/client match
those of the developers?
Why is project management important?
 Large amounts of money are spent on ICT e.g. UK
government in 2003-04 spent £2.3 billions on contracts for
ICT and only £1.4 billions on road building
 Project often fail – Standish Group claim only a third of ICT
projects are successful. 82% were late and 43% exceeded
their budget.
 Poor project management is a major factor in these failures
 What is a project?
Some dictionary definitions:
“A specific plan or design”
“A planned undertaking”
“A large undertaking e.g. a public works scheme”
Longmans dictionary
Key points above are planning and size of task
 Jobs versus projects

‘Jobs’ – repetition of very well-defined and well understood

tasks with very little uncertainty
‘Exploration’ – e.g. finding a cure for cancer: the outcome is
very uncertain
Projects – in the middle!
 Characteristics of projects
A task is more ‘project-like’ if it is:
 Non-routine
 Planned
 Aiming at a specific target
 Carried out for a customer
 Carried out by a temporary work group
 Involving several specialisms
 Made up of several different phases
 Constrained by time and resources
 Large and/or complex
 Are software projects really different from
Not really …but
other projects?

 Invisibility
 Complexity
 Conformity
 Flexibility
make software more problematic to build than other
engineered artefacts.
 Contract management versus technical
project management
Projects can be:
 In-house: clients and developers are employed by the same
organization
 Out-sourced: clients and developers employed by different
organizations
 ‘Project manager’ could be:
◦ a ‘contract manager’ in the client organization
◦ a technical project manager in the supplier/services
organization
 Activities covered by project management

Feasibility study
Is project technically feasible and worthwhile from a business point of
view?
Planning
Only done if project is feasible
Execution
Implement plan, but plan may be changed as we go along
The software development life-cycle (ISO 12207)
 ISO 12207 life-cycle
 Requirements analysis
◦ Requirements elicitation: what does the client need?
◦ Analysis: converting ‘customer-facing’ requirements into
equivalents that developers can understand
◦ Requirements will cover
 Functions
 Quality
 Resource constraints i.e. costs
 ISO 12207 life-cycle
 Architecture design
◦ Based on system requirements
◦ Defines components of system: hardware, software,
organizational
◦ Software requirements will come out of this
 Code and test
◦ Of individual components
 Integration
◦ Putting the components together
 ISO12207 continued
 Qualification testing
◦ Testing the system (not just the software)
 Installation
◦ The process of making the system operational
◦ Includes setting up standing data, setting system parameters,
installing on operational hardware platforms, user training etc
 Acceptance support
◦ Including maintenance and enhancement
 Plans, methods and methodologies
Methodology = a set of methods
Context

Plan
Methods
+ start and end dates for each activity,
A way of working staffing, tools and materials etc
 Some ways of categorizing projects
Distinguishing different types of project is important as
different types of task need different project approaches
e.g.
 Voluntary systems (such as computer games) versus
compulsory systems e.g. the order processing system in
an organization
 Information systems versus embedded systems
 Objective-based versus product-based
 Product-development versus outsourced
 Project Charter
 Project Charter is an important high level document that
authorizes the starting of a project and use of the required
resources.
 Besides, it outlines the project objectives, deliverables and
the resources required.
 It also documents the aspects that are out of scope, and
identifies the main stakeholders, their roles and
responsibilities.
 Project Charter cont…
The project charter is usually a short document that is only a
couple of pages long and typically contains the following:

 Overall objectives of the project and the broad items that

are within the scope of the project and those that are out of
scope.
 The time schedule in terms of the start date and the
expected completion date of the project.
 Project Charter cont…
 The important stakeholders and their responsibilities
towards the project.
 Overview of the resources that will be needed for the
project and the overall budget.
 Major risks to the project and the broad strategies that can
be adopted for overcoming those.
 Stakeholders
These are people who have a stake or interest in the project
In general, they could be users/clients or
developers/implementers
They could be:
 Within the project team
 Outside the project team, but within the same organization
 Outside both the project team and the organization
Different stakeholders may have different objectives – need to
define common project objectives
 Setting objectives
 Answering the question ‘What do we have to do to have a
success?’
 Need for a project authority
◦ Sets the project scope
◦ Allocates/approves costs
 Could be one person - or a group
◦ Project Board
◦ Project Management Board
◦ Steering committee
 Objectives
Informally, the objective of a project can be defined by
completing the statement:
The project will be regarded as a success if……….
…………
Rather like post-conditions for the project
Focus on what will be put in place, rather than how activities
will be carried out
 Objectives should be SMART
S – specific, that is, concrete and well-defined
M – measurable, that is, satisfaction of the objective can be
objectively judged
A – achievable, that is, it is within the power of the individual
or group concerned to meet the target
R – relevant, the objective must relevant to the true purpose
of the project
T – time constrained: there is defined point in time by which
the objective should be achieved
 Goals/sub-objectives
These are steps along the way to achieving the objective.
Informally, these can be defined by completing the sentence:

To reach objective X, the following must be in place

A……………
B……………
C……………
etc
 Goals/sub-objectives cont…
Often a goal can be allocated to an individual
Individual might have the capability of achieving goal on their
own, but not the overall objective e.g.
Overall objective – user satisfaction with software product
Analyst goal – accurate requirements
Developer goal – reliable software
 Measures of effectiveness
How do we know that the goal or objective has been
achieved?
By a practical test, that can be objectively assessed.
e.g. for user satisfaction with software product:
 Repeat business – they buy further products from us
 Number of complaints – if low etc.
 The business case
 Most projects need to have a justification or business case:
the effort and expenses of pushing the project through
must be seen to be worthwhile in terms of the benefits
that will eventually be felt.
 A cost-benefit analysis will often be part of the project's
feasibility study.
 This will itemize and quantify the project's costs and
benefits.
 The business case cont…
 The benefits will be affected by the completion date: the
sooner the project is completed, the sooner the
benefits can be experienced.
 The quantification of benefits will often require the
formulation of a business model which explains how the
new application can generate the claimed benefits.
 The business case cont…
 A simple example of a business model is that a new
web-based application might allow customers from all
over the world to order a firm's products via the
internet, increasing sales and thus increasing revenue
and profits.
 The business case cont…
Any project plan must ensure that the business case is
kept intact. For example:
 that development costs are not allowed to rise to a
level which threatens to exceed the value of benefits;
 that the features of the system are not reduced to a
level where the expected benefits cannot be realized;
 that the delivery date is not delayed so that there is an
unacceptable loss of benefits.
 The business case cont…

Benefits Benefits of delivered project

must outweigh costs
Costs Costs include:
- Development
- Operation
£ Benefits
£ Quantifiable
Non-quantifiable
 Project success/failure
 Degree to which objectives are met
scope (of deliverables)

time cost

In general if, for example, project is running out of time, this

can be recovered for by reducing scope or increasing costs.
Similarly costs and scope can be protected by adjusting other
corners of the ‘project triangle’.
 Other success criteria
These can relate to longer term, less directly tangible assets
 Improved skill and knowledge
 Creation of assets that can be used on future projects e.g.
software libraries
 Improved customer relationships that lead to repeat
business
 Summary
 Projects are non-routine - thus uncertain
 The particular problems of projects e.g. lack of visibility
 Clear objectives which can be objectively assessed are
essential
 Stuff happens. Not usually possible to keep precisely plan –
need for control
 Communicate, communicate, communicate!
 References

1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth

Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI
Learning Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Introduction Cont …

2
 What is management?
This involves the following activities:
 Planning – deciding what is to be done
 Organizing – making arrangements
 Staffing – selecting the right people for the job
 Directing – giving instructions
continued…
 What is management? cont…
 Monitoring – checking on progress
 Controlling – taking action to remedy hold-ups
 Innovating – coming up with solutions when problems
emerge
 Representing – liaising with clients, users, developers and
other stakeholders
Principal project management processes
 Principal project management processes
cont…
 Fig. shows that project management is carried out over
three well defined stages or processes, irrespective of the
methodology used.
 In the project initiation stage, an initial plan is made.
 As the project starts, the project is monitored and
controlled to proceed as planned.
 Principal project management processes
cont…
 However, the initial plan is revised periodically to
accommodate additional details and constraints about the
project as they become available.
 Finally, the project is closed. In the project closing stage, all
activities are logically completed and all contracts are
formally closed.
 Project Planning
 Carried out before development starts.
 Important activities:
◦ Estimation
◦ Scheduling
◦ Staffing
◦ Risk management
◦ Miscellaneous plans
Management control
 Management control
Data – the raw details
e.g. ‘6,000 documents processed at location X’
Information – the data is processed to produce something
that is meaningful and useful
e.g. ‘productivity is 100 documents a day’
Comparison with objectives/goals
e.g. we will not meet target of processing all documents by 31st
March

continued…..
 Management control – cont…
Modelling – working out the probable outcomes of various
decisions
e.g. if we employ two more staff at location X how quickly can we get
the documents processed?
Implementation – carrying out the remedial actions that have
been decided upon
 Software development and project
management life cycles
 In contrast to the software development life cycle (SDLC),
the project management life cycle typically starts well
before the software development activities start and
continues for the entire duration of the SDLC. This aspect
has schematically been shown in Figure (next slide).
Fig: Project management life cycle versus
software development life cycle
Fig: Project management life cycle versus
software development life cycle
 A few examples of the project management processes
carried out by a project manager include
◦ project initiation,
◦ planning, execution,
◦ monitoring,
◦ controlling, and
◦ closing.
 As shown in Figure, ‘project life cycle’ is a more generic
term and is often used to denote both software
development life cycle and project management life cycle.
 Software development and project
management life cycles cont…
 The activities carried out by the developers during
software development life cycle as well as the project
management life cycle are grouped into a number of
phases.
 Typical sets of phases and their sequencing in the software
development life cycle and the project management life
cycle have been shown in Figure (next slide)
Fig. Different phases of project management
life cycle and software development life cycle
 Fig. Different phases of project management life
cycle and software development life cycle
 As can be seen from Figure, the phases of the software
development life cycle are requirements analysis, design,
development, test and delivery.
 The different phases of the project management life cycle
are initiation, planning, execution and closing.
 Further observe from Figure that by the time the software
development processes start, the initiation phase of the
software project management life cycle is almost complete.

 Project Managemet Life Cycle
• Project Initiation
• W5HH Principle
• Project biding
• Project Planning
• Project Execution
• Project Closure
 Project Initiation
• The project initiation phase usually starts with project
concept development.
• During concept development the different characteristics
of the software to be developed are thoroughly
understood.
• The different aspects of the project that are investigated
and understood include: the scope of the project, project
constraints, the cost that would be incurred and the
benefits that would accrue.
 Project Initiation cont…
• Based on this understanding, a feasibility study is
undertaken to determine whether the project would be
financially and technically feasible.
• This is true for all types of projects, including the in-house
product development projects as well as the outsourced
projects.
 Project Initiation cont…
• For example, an organization might feel a need for a
software to automate some of its activities, possibly for
more efficient operation. Based on the feasibility study, the
business case is developed. Once the top management
agrees to the business case, the project manager is
appointed, the project charter is written, and finally the
project team is formed. This sets the ground for the
manager to start the project planning phase.
 Project Initiation cont…
• As has already been pointed out, during the project
initiation phase it is crucial for the champions of the
project to develop a thorough understanding of the
important characteristics of the project.
• In his W5HH principle, Barry Boehm summarized the
questions that need to be asked and answered in order to
have an understanding of these project characteristics.
 W5HH Principle
• The name of this principle (W5HH) is an acronym
constructed from the first letter of each question. This set
of seven questions is the following:
• Why is the software being built?
• What will be done?
• When will it be done?
• Who is responsible for a function?
• Where are they organizationally located?
• How will the job be done technically and managerially?
• How much of each resource is needed?
 Project bidding
• Once an organization's top management is convinced by
the business case, the project charter is developed. For
some categories of projects, it may be necessary to have a
formal bidding process to select a suitable vendor based
on some cost-performance criteria.
• If the project involves automating some activities of an
organization, the organization may either decide to
develop it in-house or may get various software vendors
to bid for the project.
 Project bidding
Different types of bidding techniques and their implications
and applicability.
• Request for quotation (RFQ)
• Request for proposal (RFP)
• Request for Information (RFI)
 Project planning
An important outcome of the project initiation phase is the
project charter. During the project planning phase, the
project manager carries out several processes and creates
the following documents:
 Project plan This document identifies the project tasks,
and a schedule for the project tasks that assigns project
resources and time frames to the tasks.
 Resource plan It lists the resources, manpower and
equipment that would be required to execute the project.
 Project planning
 Financial plan It documents the plan for manpower,
equipment and other costs.
 Quality plan Plan of quality targets and control plans are
included in this document,
 Risk plan This document lists the identification of the
potential risks, their prioritization and a plan for the
actions that would be taken to contain the different risks..
 Project execution
 In this phase the tasks are executed as per the project plan
developed during the planning phase.
 A series of management processes are undertaken to
ensure that the tasks are executed as per plan.
 Monitoring and control processes are executed to ensure
that the tasks are executed as per plan and corrective
actions are initiated whenever any deviations from the plan
are noticed.
 Project execution
 However, the project plan may have to be revised
periodically to accommodate any changes to the project
plan that may arise on account of change requests, risks
and various events that occur during the project execution.
 Quality of the deliverables is ensured through execution of
proper processes.
 Once all the deliverables are produced and accepted by
the customer, the project execution phase completes and
the project closure phase starts.
 Project closure
 It involves completing the release of all the required
deliverables to the customer along with the necessary
documentation.
 Agreements with the vendors are terminated and all
pending payments are completed.
 Finally, a post implementation review is undertaken to
analyse the project performance and to list the lessons
learnt for use in future projects.
 Traditional versus Modern Project
Management
 Projects are increasingly being based on either tailoring
some existing product or reusing certain pre-built libraries.
 Facilitating and accommodating client feedbacks
 Facilitating customer participation in project development
work
 Incremental delivery of the product with evolving
functionalities.
 Quality management becomes necessary.
 Change management becomes important.
 Summary
 Discussed what is management.
 Principal project management processes
 Project Planning
 Management control
 Software development and project management life cycles
 Traditional versus Modern Project Management
 References

1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth

Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI
Learning Pvt. Ltd., 2018.
Thank you
Project Evaluation and
Programme Management
 Contents

• Business case for a project

• Project portfolio
management
• Project evaluation
• Cash-flow forecasting
• Detailed steps of C-B
Analysis
• Categories of costs and
benefits
 The business case
• Feasibility study is also called as “business case”
• Main focus is to determine whether it would be financially
& technically feasible to develop the S/W.
• Provides a justification for starting the project
• Should show that the benefits of the project will exceed
the costs of development, implementation and operation
(or production)
• Needs to take account of business risks
 Types of feasibility study
• Technical Feasibility

• Financial Feasibility

• Operational Feasibility
 Contents of a business case / feasibility
study
1. Introduction/ 5. The benefits
background 6. Outline implementation
2. The proposed plan
project 7. Costs
3. The market 8. The financial case
4. Organizational and 9. Risks
operational 10. Management plan
infrastructure
 Contents of a business case cont…
• Introduction/background: describes a problem to be
solved or an opportunity to be exploited.
• The proposed project: a brief outline of the project
scope.
• The market: the project could be to develop a new
product (e.g. a new computer game). The likely demand for
the product in the market needs to be assessed.
 Contents of a business case cont…
• Organizational and operational infrastructure: How
the organization would need to change? This would be
important where a new information system application was
being introduced.
• Benefits Normally, these should be expressed in financial
terms. In the end, it is up to the client to assess these – as
they are going to pay for the project.
 Contents of a business case cont…
• Outline implementation plan: How the project is going
to be implemented? This should consider the disruption to
an organization that a project might cause.
• Costs: The implementation plan will supply information to
establish these.
• Financial analysis: Combines costs and benefit data to
establish value of the project
 Contents of a business case cont…
• Risks: Two types
 Project Risk: related to threats to successful project execution.
 Business Risk: related to factors threatening the benefits of the
delivered project.
In business case, main focus is on Business Risk.

• Management Plan: Detailed plan for smooth management of

the organization.
 Project Portfolio Management (PPM)
• Provides an overview of all the projects that an
organization is undertaking.
• Prioritizes the allocation of resources to projects.
• Decides which new projects should be accepted and
which existing ones should be dropped.
Project portfolio management cont …
The concerns of project portfolio management include:
• Evaluating proposals for projects
• Assessing the risk involved with projects
• Deciding how to share resources between projects
• Taking account of dependencies between projects
• Removing duplication between projects
• Ensuring that necessary developments have not
been inadvertently missed.
Project portfolio management cont…
There are three elements (concerns) to PPM:
1. Project portfolio definition
– Create a central record of all projects within an
organization
– Must decide whether to have ALL projects in the
repository or, say, only ICT projects
– Note the difference between new product development
(NPD) projects and renewal projects.
 Project portfolio management cont…
2. Project portfolio management
Actual costing and performance of projects can be
recorded and assessed
3. Project portfolio optimization
Information gathered above can be used to achieve better
balance of projects e.g. some that are risky but potentially
very valuable balanced by less risky but less valuable
projects
 Pros and cons of Project portfolio
management
Pros:
•Allows some small ad-hoc tasks to be done outside the
portfolio e.g. quick fixes to systems.
Cons:
•While the full-time staff are allocated to a project, they may
effectively be part-time because, they still have routine work to
do.
•The official project portfolio may not accurately reflect
organizational activity, if some projects are excluded.
 Evaluation of individual projects
Technical assessment:
• Consists of evaluating whether the required
functionality can be achieved with current affordable
technologies.
• Cost of the technology adopted must be taken into
account in the financial assessment (cost-benefit
analysis).
 Evaluation of individual projects cont...
Financial assessment (Cost benefit analysis):
This relates to an individual project.You need to:
• Identify all the costs which could be:
– Development costs (e.g. Salary to staffs)
– Set-up cost (e.g. Hardware cost, recruitment and staff training cost)
– Operational cost (e.g. Cost for operating the system after
installation)
• Identify the value of benefits
• Check that benefits are greater than costs
 Cash-flow forecasting
• Like C-B analysis, it is also important to produce a cash-flow
forecast, which indicates when expenditure and income will
take place.
• The development of the project will incur costs. We need to
spend money such as purchasing equipments, staff payment
during project development.
• These expenses cannot wait until income is received from
the project.
• When the system or product is released it will generate
income that gradually pays off costs.
• Also, the timing of costs and income for a product of system
needs to be estimated.
Product/system life cycle cash flows
• We need to know that, whether we can fund these expenses
either from the own resources or by borrowing.
• So, a forecast is needed.

Typical product life-cycle cash-flow

Cost-benefit analysis – Detailed Steps
1. Identify the costs and benefits pertaining to the project
2. Categorize the various costs and benefits
3. Select a cost-benefit evaluation technique
4. Interpret the results of the analysis
5. Take appropriate action.
 Identify the costs and benefits pertaining
to the project
• Certain costs and benefits are easily identifiable, e.g. direct
costs, such as the price of a computer etc. can be easily
identified.
• Direct benefits often relate one-to-one to direct costs,
especially savings from reducing costs in the activity in
question.
 Identify the costs and benefits pertaining
to the project cont…
• Some direct costs and benefits, may not be well defined,
since they represent estimated costs or benefits that have
some uncertainty, e.g. cost reserved for bad debt.
• A category of costs or benefits that is not easily identifiable
is opportunity costs and benefits. These are the costs or
benefits forgone by selecting one alternative over another.
Categorize various costs and benefits for
analysis
• Tangible or Intangible

• Direct or indirect

• Fixed or variable
Categorize various costs and benefits for
analysis
Tangible costs.
• Tangibility refers to the ease with which costs or benefits
can be measured.
• An outlay of cash for a specific item or activity is referred
to as a tangible cost.
• Examples: purchase of hardware or software, personnel
training, and employee salaries.
Categorize various costs and benefits for
analysis cont...
Intangible costs
• Costs that are known to exist but whose financial value cannot be
accurately measured.
• Example: employee morale problems caused by a new system or
lowered company Image.
• In some cases, they are easy to Identify but difficult to measure, e.g. the
cost of breakdown of an online system during banking hours will cause
the bank to loose deposits and waste human resources. But, by how
much? Difficult to measure.
• In some cases, these costs may be difficult even to identity, e.g.
improvement in customer satisfaction due to online systems. ystem.
Categorize various costs and benefits for
analysis cont...
Tangible benefits
• Benefits which can be measured/quantified.
• Examples: Benefits due to completing jobs in fewer hours
or producing reports with no errors.
Categorize various costs and benefits for
analysis cont...
Intangible benefits
• Benefits which cannot be easily measured / quantified.
• Example: More satisfied customers or an improved
corporate image.
• Both tangible and intangible costs and benefits, should
be considered in the evaluation process.
• Management often tends to deal irrationally with
intangibles by ignoring them, which should not be.
 Categorize various costs and benefits for
analysis cont...
Direct Costs
• Costs those with which a dollar figure can be directly
associated in a project.
• Easy to quantify in monetary terms.
• For example, the purchase of a box of diskettes for $35 is a
direct cost because we can associate the diskettes with the
dollars expended.
• Other examples: Development cost, setup cost, operational
cost .
Categorize various costs and benefits for
analysis cont...
Direct benefits
• Benefits which can be specifically attributable to the given
project.
• Example: A new online system that can handle 25 percent
more transactions per day.
 Categorize various costs and benefits for
analysis cont...
Indirect costs
• These costs are the results of operations that are not
directly associated with a given system or activity. They are
often referred to as overhead.
• Example: Insurance, maintenance, protection of the
computer center from heat and fire, lighting, and air
conditioning.
• But, it is difficult to determine the proportion of each,
attributable to a specific activity.
Categorize various costs and benefits for
analysis cont...
Indirect benefits
• The benefits which are realized as a by-product of
another activity or system.

• Examples: benefits due to selling of fertilizers in a steel

plant, selling of empty oil containers (tin boxes), etc.
 Categorize various costs and benefits for
analysis cont...
Fixed Costs
• Some costs are constant, regardless of how well a system is
used.They are called fixed costs.
• Once encountered, they will not recur.
• Examples: Straight-line depreciation of hardware, exempt
employee salaries, and insurance etc.
 Categorize various costs and benefits for
analysis cont...
Variable costs
• These costs are incurred on a regular (weekly, monthly)
basis.
• They are usually proportional to work volume and
continue as long as the system is in operation.
• Example: Costs of computer forms which vary in
proportion to the amount of processing or the length of
the reports required.
Categorize various costs and benefits for
analysis cont...
Fixed benefits
• These benefits are also constant and do not change.
• Example: Benefits due to the decrease in the number of
personnel by 20 percent resulting from the use of a new
computer.
• The benefit of personnel savings may recur every month.
Categorize various costs and benefits for
analysis cont...
Variable Benefits
• On the other hand, these benefits are realized on a regular
basis.
• Example: Consider a safe deposit tracking system that
saves 20 minutes preparing customer notices compared
with the manual system. The amount of time saved varies
with the number of notices produced.
 Summary
• Discussed the concept of business case and its
contents.
• Presented the concerns of project portfolio
management (PPM) and the elements to PPM.
• In order to evaluate individual projects, one has to
carry out
 Technical Assessment
Financial Assessment (C-B Analysis)
 Summary cont …

• Discussed the steps for carrying out C-B Analysis.

• Learnt the different types of costs and benefits with
suitable examples.
• These costs and benefits have to be considered properly in
C-B analysis.
 References :

1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,

McGraw Hill Education (India) Pvt. Ltd., 2018.
2. E. M. Awad, Systems Analysis and Design, Second Edition. Galgotia Publications
Pvt. Ltd., 2009.
3. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Evaluation and Programme
Management cont…
Contents
• Cost-benefit evaluation techniques
Cost-benefit analysis – Detailed Steps
1. Identify the cost and benefits pertaining to the project
2. Categorize the various costs and benefits
3. Select cost-benefit evaluation technique
4. Interpret the results of the analysis
5. Take appropriate action.
Select cost-benefit evaluation technique
Different cost-benefit evaluation techniques are:
1. Net benefit (profit) analysis
2. Payback period
3. Return on Investment (ROI)
4. Present value analysis
5. Net present value (NPV)
6. Internal rate of return (IRR)
7. Break-even analysis
 Net Profit
• Net profit of a project is the difference between the
total costs and the total income over the life of the
project.
 Net Profit - Example
Year Cash-flow
• In this example, ‘Year 0’ represents all the
0 -100,000 costs before system is in operation.
1 10,000 • ‘Cash-flow’ is the value of income less
outgoing.
2 10,000
• Net profit is the value of all the cash-flows
3 10,000
for the lifetime of the application.
4 20,000
• For this example, net profit is $50,000.
5 100,000
• Cons: Does not take into account the
Net profit 50,000 timing of the cash flows.
Another Example: Four project cash-flow projections
Year Cash-flow Cash-flow Cash-flow Cash-flow So, project 2
Project 1 ($) Project 2($) Project 3($) Project 4($) shows
largest net
profit, but, at
0 -100,000 -1000,000 -100,000 -120,000 the expense
1 10,000 200,000 30,000 30,000 of huge
2 10,000 200,000 30,000 30,000
investment

3 10,000 200,000 30,000 30,000

4 20,000 200,000 30,000 30,000

5 100,000 300,000 30,000 75,000

Net
50,000 100,000 50,000 75,000
profit($)
 Pay back period
Year Cash- Accumulated • It is the time taken to break even or pay
flow ($) ($) back the initial investment.
0 -100,000 -100,000
• This is the time it takes to start generating
a surplus of income over the expenditure.
1 10,000 -90,000
• The project with shortest payback period
2 10,000 -80,000 is preferred, as the owner wishes to
minimize the time that a project is “in
3 10,000 -70,000
debt”.
4 20,000 -50,000 • For this example, payback period is year 5.

5 100,000 50,000
Another Example: Four project cash-flow projections
Year Cash-flow Cash-flow Cash-flow Cash-flow
Project 1 ($) Project 2($) Project 3($) Project 4($)

0 -100,000 -1000,000 -100,000 -120,000 So, project 3

1 10,000 200,000 30,000 30,000 is the most
2 10,000 200,000 30,000 30,000 beneficial
3 10,000 200,000 30,000 30,000 Project
4 20,000 200,000 30,000 30,000
5 100,000 300,000 30,000 75,000

Net profit 50,000 100,000 50,000 75,000

PB period Year 5 Year 5 Year 4 At end of Year 4

 Pay back period cont...
Pros:
• Simple to calculate
• Not particularly sensitive to small forecasting errors
Cons:
• Ignores the overall profitability of the project
• Ignores any income (expenditure) once the project has broken-even
• So, the fact that Projects 2 and 4 are, overall, more profitable than
Project 3, is ignored
 Return on investment (ROI)
• Provides a way of comparing the net profitability to the
investment period.
• Provides a simple and easy-to-calculate measure of return
on capital.
Return on investment (ROI) cont...
Average annual profit
ROI = X 100
Total investment
In the previous example
• Average annual profit
= 50,000/5
= 10,000
• So, ROI = 10,000/100,000 X 100
= 10%
Another Example: Four project cash-flow projections
Year Cash-flow Cash-flow Cash-flow Cash-flow
Project 1 ($) Project 2($) Project 3($) Project 4($)
So, Project 4
is the most
0 -100,000 -1000,000 -100,000 -120,000 beneficial
1 10,000 200,000 30,000 30,000 project
2 10,000 200,000 30,000 30,000
3 10,000 200,000 30,000 30,000
4 20,000 200,000 30,000 30,000
5 100,000 300,000 30,000 75,000

Net profit 50,000 100,000 50,000 75,000

ROI 10% 2% 10% 12.5%

 Return on investment (ROI) cont...
Cons:
• Like the net profitability, it does not take into account the
timing of the cash flows.
• Bears no relationship to the interest rates charged by
banks since it takes no account of the timing of the cash
flows.
• It is therefore, potentially, very misleading.
 Present value (PV) analysis
• In developing long-term projects, it is often difficult to
compare today's costs with the full value of tomorrow's
benefits.
• The time value of money allows for interest rates, inflation,
and other factors that alter the value of the investment.
• So, PV analysis is important. It controls the above problems
by calculating the costs & benefits of the system in terms of
today's value of the investment and then comparing across
alternatives.
• A critical factor to consider in computing present value is a
discount rate equivalent to the forgone amount that the
money could earn if it were invested in a different project.
 Present value analysis cont…
• In other words, the annual rate by which we discount
the future earnings is known as discount rate.
• Discount Factor (DF) is calculated as follows:
1
DF 
(1 r )
t

where r= discount rate, t= number of years into the

future that the cash flow occurs.
 Present value analysis cont…
• In the case of 10% rate and one year
Discount Factor = 1/(1+0.10) = 0.9091
• In the case of 10% rate and two years
1
DiscountFactor 
(1 0.10)
2

=0.8264
Similarly, the discount factor can be computed for any
given year and discount rate.
 Discount rate (%)
Year
NPV discount factors
5 6 8 10 12 15

1 0.9524 0.9434 0.9259 0.9091 0.8929 0.8696

2 0.9070 0.8900 0.8573 0.8264 0.7972 0.7561

3 0.8638 0.8396 0.7938 0.7513 0.7118 0.6575

4 0.8227 0.7921 0.7350 0.6830 0.6355 0.5718

5 0.7835 0.7473 0.6806 0.6209 0.5674 0.4972

6 0.7462 0.7050 0.6302 0.5645 0.5066 0.4323

7 0.7107 0.6651 0.5835 0.5132 0.4523 0.3759

8 0.6768 0.6274 0.5403 0.4665 0.4039 0.3269

9 0.6446 0.5919 0.5002 0.4241 0.3606 0.2843

10 0.6139 0.5584 0.4632 0.3855 0.3220 0.2472

15 0.4810 0.4173 0.3152 0.2394 0.1827 0.1229

20 0.3769 0.3118 0.2145 0.1486 0.1037 0.0611

25 0.2953 0.2330 0.1460 0.0923 0.0588 0.0304

 Present value analysis cont…
• Suppose that $3000 is to be invested in a project, and the
average annual benefit is $1500 for the four-years life of the
project. The investment has to be made today, whereas the
benefits are in the future.
• We compare present values to future values by considering
the time value of money to be invested.
• The amount that we are willing to invest today is
determined by the value of the benefits at the end of a given
period (year).
• The amount is called the present value of the benefit.
 Present value analysis cont…
To compute the present value, we use the formula for future
value as given below
P
F 
(1 r )
t

where,
F = future value
P = present value
r = discount rate
t = number of years into the future that the cash flow occurs.
 Present value analysis cont…
On solving the above equation, we obtain the formula for
present value (P) as follows :
F
P t
(1 r )
where,
F = future value
P = present value
r = discount rate
t = number of years into the future that the cash flow
occurs.
 Present value analysis cont…
So the present value of $1,500 invested at 10% interest at the end of
4th year is:
1500
P 
(1 0.10)
4

1500
  1027.39
1.61
That is, if we invest $1,027.39 today at 10 percent interest, we can
expect to have $1,500 in four years.
This calculation can be represented for each year where a benefit is
expected.
 Net Present Value (NPV) analysis
• NPV is a project evaluation technique that takes into
account the profitability of a project and the timing of the
cash flows that are produced.
• The net present value is obtained by discounting each cash
flow (both negative & positive) and summing the discounted
values.
 Net Present Value (NPV) analysis -
Example (project 1)
Year Cash-flow ($) Discount factor Discounted cash
flow ($)

0 -100,000 1.0000 -100,000

1 10,000 0.9091 9,091
2 10,000 0.8264 8,264
3 10,000 0.7513 7,513
4 20,000 0.6830 13,660
5 100,000 0.6209 62,090
NPV 618
Net Present Value (NPV) analysis - cont…
Cons:
 The main difficulty with NPV for deciding between projects is
selecting an appropriate discount rate.
 Using NPV, it might not be directly comparable with earnings
from other investments or the costs of borrowing capital.
Exercise:
Calculate the NPV values for Projects 2, 3 and 4 and draw the
inference.
 Internal Rate of Return (IRR)
• IRR provides a profitability measure as a percentage return
that is directly comparable with interest rates. So, a project
that shows an IRR of 10% would be worth if the capital
could be borrowed for less than 10% or the capital could
not be invested elsewhere for a return greater than 10%.
• IRR is the discount rate that would produce an NPV of 0 for
the project.
• Can be used to compare different investment opportunities.
• Can be calculated using a spread sheet. Also, Microsoft Excel
provides functions, such as IRR(), which take a value and an
initial guess as input and return an IRR as the output.
 Internal Rate of Return (IRR) cont ...
Cons:
• It does not indicate the absolute size of the return.
• A project with an NPV of $100,000 with an IRR of 15% can
be more attractive than one with an NPV of $10,000 with an
IRR of 18%.
• Under certain conditions, it is possible to find more than one
rate that will produce zero NPV. In these cases, take the
lowest value and ignore the others.
 Break-even Analysis
• Break-even is the point where the cost of the candidate
(proposed) system and that of the current one are equal.
• Unlike the payback method that compares costs and
benefits of the candidate system, break-even analysis
compares the costs of the current and candidate (proposed)
systems.
 Break-even Analysis cont ...
• When a candidate (proposed) system is developed, the
initial costs usually exceed those of the current system. This
is an investment period.
• When both the costs are equal, it is break-even.
• Beyond that point, the candidate (proposed) system
provides greater benefit (profit) than the old one. This is the
return period.
 Break-even analysis

Processing cost($)

Break- even chart [Awad, 2009]

 Break-even Analysis cont ...
• Straight lines are used to show the model’s relationships in
terms of the variable, fixed, and total costs of the two
processing methods and their economic benefits.
• Intersection B’ indicates the point where the total cost of
processing 65,000 transactions by the current system is
equal to the total cost of using the candidate system.
 Break-even Analysis cont …
• The shaded area beyond that point is the return period.
• The shaded area AB’A’ is the investment period.
• According to the chart, then, it would be more economical
to process manually when volume is below 65,000
transactions during a given time period.
• Processing volume above B’ favours the candidate system.
 Summary
• Discussed different cost-benefit evaluation techniques with
suitable examples.
• Also, described the advantages and disadvantages of each
technique.
• Presented which technique will be best suitable in which
circumstances.
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. E. M. Awad, Systems Analysis and Design, Second Edition. Galgotia Publications
Pvt. Ltd., 2009.
3. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Evaluation and Programme
Management cont…
Contents
• Last two steps of C-B Analysis
• Risk evaluation
Cost-benefit analysis – Detailed Steps
1. Identify the cost and benefits pertaining to the project
2. Categorize the various costs and benefits
3. Select a cost-benefit evaluation technique
4. Interpret the results of the analysis
5. Take appropriate action.
 Interpret the results of the analysis
• After the C-B evaluation of the project is complete, the
results should be interpreted.
• This requires comparing the actual results against a
standard or the result of an alternative investment.
• The interpretation & the decision phases are subjective in
nature and require judgment & intuition.
• Based on the level of uncertainty, the project manager may
be confronted with a single known value or a range of
values for the different measures such as NPV.
 Interpret the results of the analysis
• In both the cases (single value or range of values), simpler
techniques such as net profit analysis, are easier to
implement than other techniques.
• If it can be modified to include the time value of money, the
net profit method would be comparable to NPV. But, it is
difficult to implement the complex techniques such as NPV.
 Take appropriate action
• After interpreting the results, appropriate decision/ action
has to be taken, which may be highly subjective.
• This depends on the project manager’s or end user’s
confidence in the estimated costs and benefits and the
magnitude of investment.
• The final decision/action is to select the most cost effective
and beneficial system / project, for the user.
• Prepare the feasibility study report containing the measure
findings and recommendations.
 Limitations of C-B analysis
• Valuation problems: Intangible costs and benefits are difficult to
quantify.
• Distortion problems: two ways of distorting the results of
C-B analysis.
• Internal favoritism of an alternative for political reasons.
• When data are incomplete or missing from analysis.
• Completeness problems: cost related to C-B analysis may be on
the high side or not enough costs might be considered to a
complete analysis.
Dealing with uncertainty: Risk evaluation
• Every project has some risk.
• Two types of risks are there:
1. Project Risk: related to threats to successful
project execution.
2. Business Risk: related to factors threatening
the benefits of the delivered project.
• In business case, main focus is on Business Risk.
Risk evaluation methods
• Risk identification and ranking
• Risk and NPV
• C-B Analysis
• Risk profile analysis
• Using decision trees
 Risk identification and ranking
• In any project evaluation we should identify the risks and
quantify their effects.
• One approach is to construct a project risk matrix utilizing
a checklist of possible risks and classifying risks according
to their relative importance and likelihood.
• Importance and likelihood need to be separately assessed
– we might be less concerned with something that, although serious,
is very unlikely to occur than with something less serious that is
almost certain.
 Risk identification and ranking cont ...

• For example, project A might appear to give a better

return than B, but could be riskier
• Could draw up a project risk matrix for each project to
assess risks.
 Example of a project risk matrix
Risk+ importance likelihood

Client rejects proposed look and feel of site H --

Competitors undercut prices H M

Warehouse unable to deal with increased M L
demand
Online payment has security problems M M

Maintenance costs higher than estimated L L

Response times deter purchasers M M

- - means unlikely
 Risk and net present value
• Where a project is relatively risky, it is a common
practice to use a higher discount rate to calculate net
present value.
• This risk premium might, for example, be an additional
2% for a reasonably safe project or 5% for a fairly risky
one.
• Projects may be categorized as high, medium, or low risk
using a scoring method and risk premiums designated
for each category.
• The premiums, even if arbitrary, provide a consistent
method of taking risk into account.
 Risk evaluation using C-B analysis
• A more sophisticated approach to the evaluation of risk
is to consider each possible outcome and estimate the
probability of its occurring and the corresponding value
of the outcome.
• Rather than a single cash flow forecast for a project, we
will then have a set of cash flow forecasts, each with an
associated probability of occurring.
• The value of the project is then obtained by summing the
cost or benefit for each possible outcome weighted by its
corresponding probability.
 Cost-benefit analysis - Example
A company is planning to develop a payroll application and is
currently engaged in C-B analysis. Study of the market shows that if
the company can target it efficiently and no competing products
become available, it will obtain a high level of sales generating an
annual income $8,00,000. It estimates that there is a 1 in 10 chances
of this happening. However a competitor might launch, another
application before its own launch date, and then sales might generate
only $1,00,000 per year. It estimates that there is 30% chance of this
happening. The most likely outcome is somewhere in between these 2
extremes- it will gain a market lead by launching before any competing
product becomes available, and achieve annual income of $650000.
The expected sales income are shown in following table.
 Cost-benefit analysis - Example
Sales Annual sales Prob. (p) Expected
income (i) value (i*p)
High 800000 0.1 80000
Medium 650000 0.6 390000
Low 100000 0.3 30000
Expected income 500000
 Cost-benefit analysis - Example
• Development costs estimated to be $750000
• Sales levels are expected to be constant for at least 4
years
• Annual costs are estimated at $200000

Would you advice going ahead with the project?

Cost-benefit analysis – Example (solution)
• Expected sales of $500000 over 4 years would generate
expected income of $1200000 (2000000-200000*4).
• This would provide a good return on investment of
$750000
• But if sales are low and there is a 30% chance of this, the
company will loose money.
• So it is not advisable to take up this risky project.
 Cost-benefit analysis – limitations

• Assigning probabilities of occurrence is a challenge.

• Does not take full account of worst case scenarios.
 Risk profile analysis
• An approach which attempts to overcome some problems
of C-B analysis method, is by constructing risk profiles using
sensitive analysis.
• This involves each of the parameters that affect the
project’s cost or benefit to ascertain how sensitive the
projects profitability is to each factor.
• We might vary one of the original estimates by plus or
minus 5% and recalculate the expected costs and benefits
for the project.
• By repeating this exercise for each of our estimates in turn,
we can evaluate the sensitivity of the project to each factor.
 Risk profile analysis cont …
• By studying the results of sensitive analysis, we can identify
those factors that are most important to the success of the
project.
• We then need to decide whether we can exercise better
control over these factors or otherwise mitigate their
effects.
• If neither is the case, then we must live with the risk or
abandon the project.
 Using decision trees to evaluate risks
• The previous approaches assume that the project
managers are passive by standards allowing nature to take
its own course.
• The project manager can only reject the over risky
projects or choose those with risk profile.
• But, in some cases it is required to evaluate whether risk
is important and, decide a suitable course of action.
 Using decision trees to evaluate risks

• Such decisions will limit or affect future options and is

important to asses how a decision will affect the future
profitability of the project.
• Decision trees come in a handy in these scenarios.
 Example
A company is considering when to replace its sales order processing
system. The decision depends on the rate at which its business expands. If
its market share increases, then the existing system might need to be
replaced within two years. Not replacing the system in time could be an
expensive option as it could lead to lost revenue, if it cannot cope with the
increased sales. Replacing the system immediately will be very expensive.
Extending the system will have an NPV of $75,000. If the market expands,
this will be turned into a loss with an NPV of -$100000 due to lost revenue.
If the market expands, replacing the system will have an NPV of $250000,
due to the benefits of handling increased sales and other benefits. If sales
don’t increase, the benefits will be severely reduced and project will suffer
with an NPV of -$50000.
Company estimates the likelihood of the market increasing significantly at
20%, and hence he probability that it will not increase is 80%. Construct the
decision tree.
Decision tree for the example

Market (Due to lost of

revenue)

(existing system)

(Due to benefits of
increased sales,
(with an automated system) better MIS, etc.)
 Analysis of the decision tree
• The analysis consists of evaluating the expected benefit of
taking each path from the decision point D.
• The expected value of each path is the sum of the values
of each possible outcome multiplied by its probability.
• Expected value of extending the system is
($75,000*0.8) + (– $1,00,000 *0.2) = $40,000
• Expected value of replacing the system is
($2,50,000*0.2) +( – $50,000 *0.8) = $10,000
• So, the company should choose the option of extending
the existing system.
 Summary cont…
• Discussed the last two steps of C-B Analysis.
• Presented the limitations of C-B analysis.
• Discussed the following risk evaluation techniques, with
suitable examples.
– Risk identification and ranking
– Risk and NPV
– C-B Analysis
– Risk profile analysis
– Using decision trees
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. E. M. Awad, Systems Analysis and Design, Second Edition. Galgotia Publications
Pvt. Ltd., 2009.
3. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Evaluation and Programme
Management cont…
Contents
• Programme management
• Benefits Management
 Programme management
• There will be an element of risk with any single project.
• Hence, organizations should take a broad view of all its
projects to ensure that while some projects may disappoint,
organizational developments overall will generate substantial
benefits.
• So, there is a need of proper programme management.
 Programme management cont …
• Definition of programme:
‘a group of projects that are managed in a co-ordinated way to
gain benefits that would not be possible were the projects to be
managed independently’
By D. C. Ferns
 Different types of Programmes
• Strategic programmes
• Business cycle programmes
• Infrastructure programmes
• Research and development programmes
• Innovative partnerships programmes
 Different types of Programmes cont …
• Strategic programmes: projects implementing a single
strategy
• Business cycle programmes: projects that an
organization undertakes within a planning cycle, e.g. The
projects to be implemented within a given ICT budget
within a fixed period, may be in a Financial Year.
• Infrastructure programmes: projects performing the
activities of identifying common infrastructure and its
implementation and maintenance, e.g. setting up and
maintaining the ICT infrastructure (including N/W,
Workstations, Servers) on which different applications can
run.
 Different types of Programmes cont …
• Research and development programmes: projects
involved in developing new innovative products based on
some research
• Innovative partnerships programmes: projects based
on collaboration by different organizations.
 Programme managers versus project
managers
Programme manager Project manager
– Many simultaneous projects – One project at a time
– Personal relationship with – Impersonal relationship
skilled resources with resources
– Optimization of resource – Minimization of demand for
use resources
– Projects tend to be seen as – Projects tend to be seen as
similar unique
 Strategic programme management
• It is a different form of programme management where
portfolio of projects all contribute to a common objective
• Based on OGC (Office of Government commerce, a UK
Govt. agency) approach.
• Now, let us discuss how to create a programme based on
OGC.
 Creating a programme
• Initial planning document is the Programme Mandate
describing
– The new services/capabilities that the programme should deliver
– How an organization will be improved
– Fit with existing organizational goals
• A programme director should be appointed to provide
initial leadership for the programme.
 Next stages/documents
• The programme brief – equivalent of a feasibility study:
emphasis on costs and benefits
• The vision statement – explains the new capability that
the organization will have
• The blueprint – explains the changes to be made to
obtain the new capability
 Aids to programme management

• There may be physical and technical dependencies between

projects
• This can be represented using dependency diagrams
which are similar to activity networks
An example of a dependency diagram
 Benefits management
developers users organization

use for
the
benefits
application
build to deliver

•Providing an organization with a capability does not guarantee that

this will provide benefits envisaged – need for benefits management
•This has to be outside the project – project will have been
completed
•Therefore done at programme level
 Benefits management cont…
• It encompasses the identification, optimization and tracking
of the expected benefits from a business change in order
to ensure that they are actually achieved.
• To carry this out, you must:
 Define expected benefits
 Analyse balance between costs and benefits
 Plan how benefits will be achieved
 Allocate responsibilities for their achievement
 Monitor achievement of benefits
 Types of Benefits
These might include:
• Mandatory requirement
• Improved quality of service
• Increased productivity
• More motivated workforce
• Internal management benefits
• Risk reduction
• Economies
• Revenue enhancement/acceleration
• Strategic fit
 Quantifying benefits
Benefits can be:
• Quantified and valued e.g. a reduction of x staff saving £y
• Quantified but not valued e.g. a decrease in customer
complaints by x%
• Identified but not easily quantified – e.g. public approval for
an organization in the locality where it is based
 Summary
• Discussed about programmes and programme
management
• Discussed about benefits and benefits management
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. E. M. Awad, Systems Analysis and Design, Second Edition. Galgotia Publications
Pvt. Ltd., 2009.
3. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt.
Ltd., 2018.a
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
A step wise approach to planning
software projects
 ‘Step Wise’ - aspirations
 Students, and others, were often at a loss as to where to start
when new to project planning. A structured approach was
seen as catering for the needs of such people.
 The approach described here is designed to be applicable to a
range of different types of projects.

3
 ‘Step Wise’ - aspirations
 It might be asked why a standard approach such as PRINCE2
has not been adopted. There has been caution about using
PRINCE2 more centrally because:
PRINCE2 tend to be used mainly in the UK
PRINCE2 tends to focus more on procedural and bureaucratic
matters at the expense of techniques – the few planning techniques
that are associated with PRINCE, for example, the development of
product flow diagrams, are used in the Step Wise approach as well.

4
‘Step Wise’ - an overview
 ‘Step Wise’ - an overview
0. Select project There must be some process by which the
project to be executed was selected.

1. Identify project objectives It is important that at the

outset the main stakeholders are all aware of the precise
objectives of the project.
 ‘Step Wise’ - an overview
2. Identify project infrastructure
• This may not be a significant step where you are working
on an in-house project in a very familiar environment.
• However, where the project is being carried out for
external clients then you may need to investigate the
characteristics of the environment in which the project is
to be carried out.
 ‘Step Wise’ - an overview
3.Analyse project characteristics
• Different types of projects will need different technical and
management approaches.
• For example,
 A project to implement control software embedded in
industrial equipment will need a different set of
methods than a project to implement a business
information system.
 A multimedia application would again need a different
set of activities.
 ‘Step Wise’ - an overview
4. Identify products and activities
• With software projects, it is best to start by listing the
products, both deliverable and intermediate, to be created.
• The activities needed to create the products can then be
identified
5. Estimate effort for activity.
• After identifying the activities, estimate the effort that will
be required for carrying the activities.
 ‘Step Wise’ - an overview
6. Identify activity risks
• Having assessed the amount of effort and the elapsed time
for a project, the reasons why these might be vary during
the actual execution of the project need to be considered.
• Where there is a very high risk of additional effort/time
being needed, then actions to reduce this risk may be
formulated.
7.Allocate resources
• With software projects, these resources will mainly be
staff, but could be equipment etc.
 ‘Step Wise’ - an overview
8. Review/publicize plan
• It is no good having a plan if no one knows about it.
• So review and publicize the proposed plan.

9. Execute Plan
• Execute the proposed plan.
 ‘Step Wise’ - an overview
10. Lower level planning
• Not all of a project, especially when it is large, can be
planned in detail at the outset.
• Not all the information needed to plan the later stages will
be available at the beginning: for example software
development cannot be broken down into precise sub-
tasks with realistic target times until more is known about
what the overall design of the system is known.
• So, plan later at the lower level / in detail.
A project scenario: Brightmouth College
Payroll
 College currently has payroll processing carried out by a
services company
 This is very expensive and does not allow detailed analysis of
personnel data to be carried out
 Decision made to bring payroll ‘in-house’ by acquiring an ‘off-
the-shelf’ application

13
 Project scenario - continued
 The use of the off-the-shelf system will require a new,
internal, payroll office to be set up
 There will be a need to develop some software ‘add-ons’: one
will take payroll data and combine it with time-table data to
calculate the staff costs for each course run in the college
 The project manager is Brigette.

14
 Step 1 establish project scope and
objectives
 1.1 Identify objectives and measures of effectiveness
◦ ‘how do we know if we have succeeded?’
 1.2 Establish a project authority
◦ ‘who is the boss?’
 1.3 Identify all stakeholders in the project and their
interests
◦ ‘who will be affected/involved in the project?’

15
 Step 1 continued
 1.4 Modify objectives in the light of stakeholder analysis
◦ ‘do we need to do things to win over stakeholders?’
 1.5 Establish methods of communication with all parties
◦ ‘how do we keep in contact?’

16
 Back to the scenario

 Project authority
- Brigette finds she has two different clients for the new
system: the finance department and the personnel office.
A vice principal agrees to be official client, and monthly
meetings are chaired by the VP and attended by Brigette
and the heads of finance and personnel
- These meetings would also help overcome communication
barriers

17
 Back to the scenario
 Stakeholders/revision to objectives
◦ The application will not ultimately be a success if project team
members are not happy to use the system.
◦ They might be happier to use the testing system if the results of their
own tests were automatically notified to them personally by the
software application, so that this might have to be added as a
requirement for the project.

18
 Back to the scenario - continued
 Stakeholders
◦ For example, personnel office would supply details of
new staff, leavers and changes (e.g. promotions)
◦ To motivate co-operation Brigette might ensure new
payroll system produces reports that are useful to
personnel staff

19
Step 2 Establish project infrastructure
 2.1 Establish link between project and any strategic plan
◦ ‘why did they want the project?’
 2.2 Identify installation standards and procedures
◦ ‘what standards do we have to follow?’
 2.3. Identify project team organization
◦ ‘where do I fit in?’

20
 Step 2 Establish project infrastructure
 At the same time as establishing exactly what the project
objectives are, the person responsible may know little
about the organizational environment in which the
application is to be developed and implemented. The
actions in Step 2 address this problem.

21
 Step 3 Analysis of project characteristics
 3.1 Distinguish the project as either objective or
product-based.
◦ Is there more than one way of achieving success?
 3.2 Analyse other project characteristics (including
quality based ones)
◦ what is different about this project?

22
 Step 3 Analysis of project characteristics
 3.1 Objective-based versus product-based projects.
With a product-based project the developers have to create a
product, the specification of which is often (but not always) clearly
defined.
In an objective-based project, a problem is defined that needs to be
solved but there could be more than one solution. For example, if an
organization needed a payroll application they might consider (a)
writing the system themselves (b) using a service company to do the
payroll for them (c) acquire an off-the-shelf package.

23
 Step 3 Analysis of project characteristics
 3.2 Analyse other project characteristics – such as is it an
information system or an embedded real time or a
multimedia application? Is it safety-critical? etc.
◦ The payroll application is clearly an information system.

24
 Step 3 continued
 3.3 Identify high level project risks
◦ ‘what could go wrong?’
◦ ‘what can we do to stop it?’
 3.4 Take into account user requirements concerning
implementation
 3.5 Select general life cycle approach
◦ waterfall? Increments? Prototypes?
 3.6 Review overall resource estimates
◦ ‘does all this increase the cost?’
25
 Back to the scenario
 Objectives vs. products
◦ An objective-based approach has been adopted
 Some risks
◦ There may not be an off-the-shelf package that caters for
the way payroll is processed at Brightmouth College
 Answer?
◦ Brigette decides to obtain details of how main candidate
packages work as soon as possible; also agreement that if
necessary processes will be changed to fit in with new
system.
26
 Step 4 Identify project products and
activities
 4.1 Identify and describe project products - ‘what do we have
to produce?’

27
 Products
 The result of an activity: intermediate / final product to be
delivered
 Could be (among other things)
◦ physical thing (‘installed pc’),
◦ a document (‘logical data structure’)
◦ a person (‘trained user’)
◦ a new version of an old product (‘updated software’)

28
 Products
 The following are NOT normally products:
◦ activities (e.g.‘training’)
◦ events (e.g.‘interviews completed’)
◦ resources and actors (e.g. ‘software developer’) - may
be exceptions to this
 Products CAN BE deliverable or intermediate

29
 Product description (PD)
 Product identity  Relevant standards
 Description - what is it?  Quality criteria
 Derivation - what is it
based on?
 Composition - what Create a PD for ‘test data’
does it contain?
 Format

30
 Step 4 continued
 4.2 document generic product flows

31
 Step 4 continued
 The product flow diagram shows the order in which the
products have to be completed. Effectively it defines a
method of working. The example above is a possible solution
to Exercise 3.3 in the textbook.
 The flow of the PFD is generally from top to bottom and left
to right. We do no put in lines which loop back. This is not
because iterative and back-tracking is not accepted. Rather it
is that you can in theory jump back to any preceding product.

32
 Step 4.3 Recognize product instances
 The PBS and PFD will probably have identified generic
products e.g.‘software modules’
 It might be possible to identify specific instances e.g.
‘module A’,‘module B’ …
 But in many cases this will have to be left to later, more
detailed, planning

33
 4.4. Produce ideal activity network
 Identify the activities needed to create each product in the
PFD
 More than one activity might be needed to create a single
product
 Hint: Identify activities by verb + noun but avoid
‘produce…’ (too vague)
 Draw up activity network

34
An ‘ideal’ activity

35
Step 4.5 Add check-points
if needed
 Step 5:Estimate effort for each activity
 5.1 Carry out bottom-up estimates
◦ distinguish carefully between effort and elapsed time
 5.2. Revise plan to create controllable activities
◦ break up very long activities into a series of smaller
ones
◦ bundle up very short activities (create check lists?)

37
 Step 6: Identify activity risks
 6.1.Identify and quantify risks for activities
◦ damage if risk occurs (measure in time lost or money)
◦ likelihood if risk occurring
 6.2. Plan risk reduction and contingency measures
◦ risk reduction: activity to stop risk occurring
◦ contingency: action if risk does occur
 6.3 Adjust overall plans & estimates to take account of risks
◦ For example, add new activities which reduce risks
associated with other activities e.g. training, pilot trials,
information gathering 38
 Step 7: Allocate resources
 7.1 Identify and allocate resources to activities
 7.2 Revise plans and estimates to take into account
resource constraints
◦ e.g. staff not being available until a later date
◦ non-project activities

39
 Week commencing
Gantt charts LT = lead tester
TA = testing assistant
APRIL
MARCH
12 19 26 2 9 16
5
Survey potential
suppliers Finance assistant
Analyse existing
system Business analyst
Obtain user
requirements
Business analyst

Generate test cases Systems assistant

Plan office layouts

Premises office

Calculate volumes
Systems assistant

Business
Draft and issue ITT analyst
 Step 8: Review/publicize plan
 8.1 Review quality aspects of project plan
 8.2 Document plan and obtain agreement

41
 Step 8: Review/publicise plan
 We have noted already that it is not feasible to produce a
detailed plan for all stages of the project right at the
beginning of the project planning process and not all the
information needed for the detailed planning of the later
stages is available at the outset. Initially an outline plan for the
whole project would be produced, plus a detailed plan for the
first stage.

42
 Step 9: Execute plan

Step10: Create lower level plans

43
 Summary
 Establish your objectives
 Think about the characteristics of the project
 Discover/set up the infrastructure to support the project
(including standards)
 Identify products to be created and the activities that will
create them
 Allocate resources
 Set up quality processes

44
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth
Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Selection of an appropriate project
approach
 Outline of lecture
 Building versus buying software
 Taking account of the characteristics of the project
 Process models
◦ Waterfall model
◦ Prototyping model
◦ Iterative model
◦ Incremental model
◦ Agile models
‘Step Wise’ - an overview
 Selection of project approaches
 This lecture concerned with choosing the right approach to
build a particular project: variously called technical planning,
project analysis, methods engineering and methods
tailoring.
 Relevant to Step 3, of the previous figure.
 In-house: often the methods to be used dictated by
organizational standards
 Suppliers: need for tailoring as different customers have
different needs
 Selection of project approaches
 Different types of projects need different types of
approach.
 If you are working in one particular environment which
specializes in one type of software, then the approach is
likely not to change much from one project to another.
 Where you work for different clients in different
organizations developing a variety of applications, then
the approach for each project may need to be tailored.
 Build or buy?

In-house
Outsource?
development?

either

Build Buy
 Build or buy?
• In-house development almost always involves developing
new code.
• If it is decided to use a specialist organization to
implement system, the supplier could either build a
‘bespoke’ system (created specially for one customer) for
you, or could install a pre-existing application.
• There are hybrids of these options, e.g. to build in-house
but use temporary contract staff, or Customised Off-the-
Shelf (COTS) where a basic existing core system is
modified for your particular requirements.
Some advantages of off-the-shelf (OTS) software
 Cheaper as supplier can spread development costs over a
large number of customers
 Software already exists
◦ Can be trialled by potential customer
◦ No delay while software being developed
 Where there have been existing users, bugs are likely to
have been found and eradicated
 Some possible disadvantages of off-the-shelf
 Customer will have same application as everyone else: no
competitive advantage, but competitive advantage may
come from the way application is used
 Customer may need to change the way they work in order
to fit in with OTS application
 Customer does not own the code and cannot change it
 Danger of over-reliance on a single supplier
 One concern is what happens if the supplier goes out of
business. Customer might not then be able to maintain the
system: hence the use of ‘escrow’ services where a 3rd
party retains a copy of the code.
 General approach
 Look at risks and uncertainties e.g.
◦ are requirement well understood?
◦ are technologies to be used well understood?
 Look at the type of application being built e.g.
◦ information system? embedded system?
◦ criticality? differences between target and development
environments?
 Clients’ own requirements
◦ need to use a particular method
 General approach
Control systems:
 A real-time system will need to be implemented using an
appropriate methodology. Real-time systems that employ
concurrent processing may have to use techniques such as
Petri nets.
 General approach
Information systems:
 An information system will need a methodology, such as
Information Engineering, that matches that type of
environment.
 Team members would therefore know exactly what is
expected.
 General approach
Availability of users:
 Where the software is for the general market rather than
application and user specific, then a methodology which
assumes that identifiable users exist who can be quizzed
about their needs would have to be thought about with
caution.
 Some business systems development methods assume an
existing clerical system which can be analysed to yield the
logical features of a new, computer-based, system.
 In these cases a marketing specialist may act as a surrogate
user.
 General approach
Specialized techniques:
 For example, expert system shells and logic-based
programming languages have been invented to expedite the
development of knowledge-based systems.
 Similarly, a number of specialized techniques and standard
components are available to assist in the development of
graphics-based systems.
 General approach
Hardware environment :
 The environment in which the system is to operate could
put constraints on the way it is to be implemented.
 The need for a fast response time or restricted computer
memory might mean that only low-level programming
languages can be used.
 General approach
Safety-critical systems:
 Where safety and reliability are essential, this might justify
the additional expense of a formal specification using a
notation such as OCL.
 Extremely critical systems could justify the cost of having
independent teams develop parallel systems with the same
functionality.
 The operational systems can then run concurrently with
continuous cross-checking. This is known as n-version
programming.
 General approach
Imprecise requirements:
 Uncertainties or a novel hardware/software platform mean
that a prototyping approach should be considered.
 If the environment in which the system is to be
implemented is a rapidly changing one, then serious
consideration would need to be given to incremental delivery.
 If the users have uncertain objectives in connection with the
project, then a soft systems approach might be desirable.
 Processes versus Process Models
 Starting from the inception stage:
◦ A product undergoes a series of transformations
through a few identifiable stages
◦ Until it is fully developed and released to the customer.
◦ This forms its life cycle or development process.
 Life cycle model (also called a process model):
◦ A graphical or textual representation of the life cycle.
 Structure versus speed of delivery
Structured approach
 Structured methods consists of sets of steps and rules
which, when applied, generate system products such as use
case diagrams.
 Each of these products is carefully defined.
 Such methods are more time consuming and expensive than
more intuitive approaches.
 The pay-off, it is hoped, is a less error prone and more
maintainable final system.
 Structure versus speed of delivery
Structured approach (cont…)
 This balance of costs and benefits is more likely to be
justified on a large project involving many developers and
users.
 Because of the additional efforts needed and their greater
applicability to large and complex projects, these are often
called heavyweight methods.
 Structure versus speed of delivery
Structured approach
 Also called ‘heavyweight’ approaches
 Step-by-step methods where each step and intermediate
product is carefully defined
 Emphasis on getting quality right first time
 Example: use of UML and USDP
 Future vision: Model-Driven Architecture (MDA). UML
supplemented with Object Constraint Language, press the
button and application code generated from the UML/OCL
model
 Structure versus speed of delivery
Agile methods
 Emphasis on speed of delivery rather than documentation
 RAD (Rapid application development): Emphasized use of
quickly developed prototypes
 JAD (Joint application development): Requirements are
identified and agreed in intensive workshops with users
 Choice of process models
 Based on the nature / characteristics of the project,
choose an appropriate process model for developing
the project. Some of the possible process models are:
 Waterfall model (also known as ‘one-shot’, or
‘once-through’ model)
 Prototyping model
 Incremental model
 RAD model
 Agile models
 What is Agile Software Development?
 Agile: Easily moved, light, nimble, active software processes

 How agility achieved?

◦ Fitting the process to the project

◦ Avoidance of things that waste time

 Emphasis on speed of delivery rather than documentation

25
 Important Themes of Agile Methods
 Incremental approach:
◦ At a time, only one increment is planned, developed,
and then deployed at the customer site.
 Emphasizes face-to-face communication over written
documents.
 An agile project usually includes a customer
representative in the team.
 Agile development projects usually deploy pair
programming.(one will write the code, the other one
will review the code, then the roles will be swapped).
Agile Models / Methodologies
 XP
 Scrum
 Unified process
 Crystal
 DSDM
 Lean

27
 combinations of approaches
installation
one-shot incremental evolutionary
one-shot yes yes no
incremental yes yes no
evolutionary yes yes yes

• One-shot or incremental installation – any construction

approach possible.
• Evolutionary installation implies evolutionary construction.
‘Rules of thumb’ about approaches to be
used
IF uncertainty is high
THEN use evolutionary approach
IF complexity is high but uncertainty is not
THEN use incremental approach
IF uncertainty and complexity both are low
THEN use one-shot model
IF schedule is tight
THEN use evolutionary or incremental model
 Comparison of Different Life Cycle
Models
 Iterative waterfall model
◦ most widely used model.
◦ But, suitable only for well-understood problems.
 Prototype model
o is suitable for projects which are not well understood in
the following aspects:
 user requirements
 technical aspects
30
 Comparison of Different Life Cycle
Models cont …
 Evolutionary model is suitable for large problems:
◦ can be decomposed into a set of modules that can be
incrementally implemented,
◦ incremental delivery of the system is acceptable to the
customer.
 Spiral model:
◦ suitable for development of technically challenging
software products that are subject to several kinds of
risks.

31
 Comparison of Different Life Cycle
 Agile model:
Models cont …
◦ to help projects to adapt to change requests
◦ In the agile model, the requirements are decomposed into many
small incremental parts that can be developed over one to four
weeks each.

32
 Summary
• We have discussed Building versus buying a software.
• We have discussed some characteristics of the projects such
as control systems, information systems, availability of users,
specialized techniques, hardware environment, safety-critical
systems, imprecise requirements.
• We have mentioned different Process models.
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth
Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI
Learning Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Evaluation and Programme
Management cont…
Project Estimation Techniques
Contents
• Introduction
• Project planning
• Basics of project estimation
‘Step Wise’ - an overview
 What makes a successful project?
Delivering: Stages:
 agreed functionality 1. set targets
 on time 2. Attempt to achieve
 at the agreed cost targets
 with the required quality

BUT what if the targets are not achievable?

Solution: Efficient project planning – Refers to Step 5 of

the Stepwise Approach.
 Introduction to project planning
• A project manager’s activities are varied.
– can be broadly classified into two categories:
• project planning
• project monitoring and control
 Project Planning
 Once a project is found to be feasible,
◦ project managers undertake project planning.
• Initial plan is made before development starts
---- then updated frequently.

8
Project Planning cont …

9
 Project Planning Activities
 Estimation:
◦ Effort, cost, resource, and project duration
 Project scheduling:
 Staff organization:
◦ staffing plans
 Risk handling:
◦ identification, analysis, and abatement procedures
 Miscellaneous plans:
◦ quality assurance plan, configuration management plan, etc.

10
 Project Planning Activities cont …
1. Identify the steps required to accomplish the project
objectives
2. Identify the tasks needed to be done at each step (using
Work Breakdown Structures)
3. Estimate of how much effort each task requires
4. Estimate the resources required for each task
5. (Given 3. and 4.) Calculate how long each task/step will take
6. (Given 4. and 5.) Estimate the task, step and project costs
7. Determine the inter-dependencies of tasks, if any.
8. Prepare the schedule for each task and the whole project
(Milestones, Deliverables, costs, payments)
 Why project planning?
 Requires utmost care and attention , because commitments to
unrealistic time and resource estimates result in:
◦ irritating delays.
◦ customer dissatisfaction
◦ adverse affect on team morale
 poor quality work
◦ project failure.

12
 Sliding Window Planning
 Involves project planning over several stages:
◦ protects managers from making big commitments too
early.
◦ More information becomes available as project progresses.
 Facilitates accurate planning

13
 SPMP Document
 After planning is complete:
◦ Document the plans:
◦ in a Software Project Management Plan(SPMP) document.

14
 Organization of SPMP Document
◦ Introduction (Objectives, Major Functions, Performance Issues, Management and
Technical Constraints)
◦ Project Estimates (Historical Data, Estimation Techniques, Effort, Cost &
Project Duration Estimates)
◦ Project Resources Plan (People, Hardware and Software, Special Resources)
◦ Schedules (Work Breakdown Structure, Task Network, Gantt Chart
Representation, PERT Chart Representation)
◦ Risk Management Plan (Risk Analysis, Risk Identification, Risk Estimation,
Abatement Procedures)
◦ Project Tracking and Control Plan
◦ Miscellaneous Plans (Process Tailoring, Quality Assurance, Configuration
Management)
15
 Fundamental estimation questions
 What is the size of the software to be developed?

 How much effort is required to complete an activity?

 How much calendar time is needed to complete an activity?

 What is the total cost of an activity?

 Sequence of Estimations
 First, determine size of the product.
 From the size estimate,
◦ determine the effort needed.
 From the effort estimate,
◦ determine project duration, and cost.

17
Sequence of Estimations and Scheduling
Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling
 Software cost components
 Hardware and software costs.
 Travel and training costs.
 Effort costs:
◦ The dominant factor in most projects
◦ The salaries of engineers involved in the project
 Overheads:
◦ Costs of building, heating, lighting.
◦ Costs of networking and communications.
◦ Costs of shared facilities (e.g. library, staff restaurant,
etc.).
◦ Rule of thumb: as much as the effort costs
 Person Month
 Suppose a project is estimated to take 300 person-months to
develop:
◦ Is one person working for 30 days same as 30 persons
working for 1 day?
◦ No? why?
 How many hours is a man month:
◦ Default Value: 152 hours per month
◦ 19 days at 8 hours per day.
 Why Person-Month and not Person-days or
Person years?
 Modern Projects typically take a few months to complete...

 Person-years is clearly unsuitable.

 Person-days would make monitoring and estimation overhead
large and tedious.
 Costing and pricing
 Estimates are made to discover the cost of producing a
software system.
◦ However, there is no simple relationship between the
development cost and the price charged to the customer.

◦ Broader organisational, economic, political and business

considerations influence the price charged.
 Cost Estimation Process
Effort
Requirements
Development Time
Estimation
Process Number of Personnel

Other Cost Drivers Cost

 Software pricing factors
Market A development organisation may quote a low price because it
opportunity wishes to move into a new segment of the software market.
Accepting a low profit on one project may give the opportunity
of more profit later. The experience gained may allow new
products to be developed.
Cost estimate If an organisation is unsure of its cost estimate, it may increase
uncertainty its price by some contingency over and above its normal profit.
Contractual terms A customer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects. The
price charged may then be less than if the software source code
is handed over to the customer.
Requirements If the requirements are likely to change, an organisation may
volatility lower its price to win a contract. After the contract is awarded,
high prices can be charged for changes to the requirements.
Financial health Developers in financial difficulty may lower their price to gain
a contract. It is better to make a smaller than normal profit or
break even than to go out of business.
 Words of wisdom
Unless a software project has clear definitions of its key
milestones and realistic estimates of the time and money it
will take to achieve them, there is no way that a project
manager can tell whether the project is under control or
not…
 When are estimates required?
Project phase Estimates required
Time, cost and benefit estimates in project
Initiation
definition.
Time estimates in project schedule.
Planning Cost estimates in project budget.
Cost & benefit estimates in business case.
Start of project Time and cost estimates reconfirmed for the
stages stage.
 Some problems with estimating
 Subjective nature of much of estimating
◦ It may be difficult to produce evidence to support your precise
target
 Political pressures
◦ Managers may wish to reduce estimated costs in order to win
support for acceptance of a project proposal
 Changing technologies
◦ these bring uncertainties, especially in the early days when there
is a ‘learning curve’
 Projects differ
◦ Experience on one project may not be applicable to another
 Over and under-estimating
 Parkinson’s Law: ‘Work expands to fill the time available’
 Underestimate:
◦ Advantage: No overspend
◦ Disadvantages: System is usually unfinished
 Over and under-estimating cont …
 Weinberg’s Zeroth Law of Reliability: ‘a software project that
does not have to meet a reliability requirement can meet any
other requirement’.
 Effect of Underestimation
 Research results confirm:
◦ Motivation and morale lowered with highly aggressive
target.
 Underestimation can lead to abandonment of the project:
◦ Developers usually respond to highly pressing deadlines
with substandard work.
 Basis for successful estimating
 Information about past projects
◦ Need to collect performance details about past project:
how big were they? How much effort/time did they need?
 Need to be able to measure the amount of work involved
◦ Traditional size measurement for software is ‘lines of code’
– but known to have problems
 Refining Estimates
 Reasons for Adjusting Estimates
◦ Interaction costs are hidden in estimates.
◦ Normal conditions do not apply.
◦ Things go wrong on projects.
◦ Changes in project scope and plans.
 Adjusting Estimates:
◦ Time and cost estimates of specific activities are adjusted
as the risks, resources, and situation particulars become
more clearly defined.
 Summary
 Discussed the various activities carried out during project
planning.
 Presented the contents of Software Project Management Plan
(SPMP) document.
 Discussed some basic concepts of project estimation.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Estimation Techniques
cont…
• A taxonomy of estimating methods
• Size Estimation
 A taxonomy of estimating methods
 Top-down or Bottom-up - activity based, analytical

 Parametric or algorithmic models e.g. function points

 Expert Judgement - just guessing?

 Analogy - case-based, comparative

 Price to win
 Pricing to win
 ‘Price to win’ is setting a target that is likely to win business when
tendering for work
 The project costs whatever the customer can spend on it.
 Advantages:You get the contract
 Disadvantages: Costs do not accurately reflect the work required.
Either:
◦ (1) the customer does not get the desired system or
◦ (2) the customer overpays.
 Pricing to win
 This approach may seem unethical and unbusiness-like….
◦ However, when detailed information is lacking it may be the only
appropriate strategy…
 Which is the most ethical approach?
◦ The project cost is agreed on the basis of an outline proposal and
the development is constrained by that cost
◦ A detailed specification may be negotiated or an evolutionary
approach used for system development
 Project Parameters to be Estimated
 For project planning, we need:
◦ Effort (cost)
◦ Duration

 Hard to estimate effort (or cost) or duration directly from a

problem description.
 Effort and Duration can be measured in terms of project
size (indirect metric)
 Project Parameters to be Estimated
cont …
 Size is a fundamental measure of work
 Based on the estimated size, two parameters are estimated:
◦ Effort Effort
◦ Duration Size
Duration
 Effort is measured in person-months:
◦ One person-month is the effort an individual can typically put in a
month.
 What is size? A Measure of Work…
 Project size is a measure of the problem complexity in terms of
the effort and time required to develop the product.
 Two metrics are popularly used to measure project size:
◦ Source Lines of Code (SLOC)
◦ Function point (FP)
 SLOC is conceptually simple
◦ But, FP is now-a-days favoured over SLOC
◦ Because of the many shortcomings of SLOC.
 Lines of code
 What's a line of code?
◦ Originally proposed when programs were typed on cards
with one line per card;
◦ What happens when statements in Java span several lines
or where there can be several statements on one line?
 What programs should be counted as part of the system?
GUI? Built-in Class?
 Initially software development consisted of only writing
code…
 Lines of Code – Some Terminologies
 LOC ≡ Line of Code
 KLOC ≡
◦ Thousands of LOC
 KSLOC ≡
◦ Thousands of Source LOC
 NCKSLOC ≡
◦ New or Changed KSLOC
 LOC: Few things counter intuitive…
 The lower the level of the language, the more
productive the programmer is:
◦ The same functionality takes more code to implement in a lower-
level language than in a high-level language.

 The more verbose the programmer, the higher

the productivity:
◦ Measures of productivity based on lines of code suggest that
programmers who write verbose code are more productive than
programmers who write compact code.
 Major Shortcomings of SLOC
 Size can vary with coding style.
 Focuses on coding activity alone.
 Correlates poorly with quality and efficiency of code.
 Penalizes higher level programming languages, code reuse,
etc.
 Major Shortcomings of SLOC
 Difficult to estimate at start of a project from problem
description
Only way to estimate is to make a guess…
So not useful for project planning
 Only a code measure
 Programmer-dependent
 Measures lexical/textual complexity only,
 Does not consider structural or logical complexity.
 Further Difficulties with SLOC
 SLOC can become ambiguous due to rapid changes in
programming methodologies, languages, and tools:
- Language advancements
- Automatic source code generation
- Custom software and reuse
- Object-orientation
 Expert Judgment-based Techniques
1. Basic expert judgment

2. Weighted average estimating

3. Consensus estimating

4. Delphi
 Basic Expert Judgment
 One or more experts predict software costs.
◦ Process iterates until some consensus is reached.

 Advantages: Relatively simple estimation method. Can be

accurate if experts have direct experience of similar
systems
 Disadvantages:Very inaccurate if there are no experts
available!
 Basic Expert Judgment Method: Steps
 Coordinator presents each expert with a specification and an estimation
form.
 Coordinator calls a group meeting in which the experts discuss
estimation issues with the coordinator and each other.
 Experts fill out forms anonymously
 Coordinator prepares and distributes a summary of the estimation on an
iteration form.
 Coordinator calls a group meeting, specially focusing on having the
experts discuss points where their estimates varied widely.
 Experts fill out forms, again anonymously, and Steps 4 and 6 are iterated
for as many rounds as appropriate.
Basic Expert Judgement Method cont. …
 An expert is familiar with and knowledgeable about the
application area and the technologies

 Particularly appropriate where existing code is to be

modified.

 Research shows that expert judgement in practice tends to

be based on analogy…
 Stages
 Identify significant features of the current project

 Look at previous project(s) with similar features

 Observe differences between the current and previous

projects

 Find out the possible reasons for error (risk)

 Take measures to reduce uncertainty

 Estimation by Analogy
 The cost of a project is computed by comparing the project
to a similar project in the same application domain:
 Advantages:
◦ May be accurate if project data available and people/tools the same
 Disadvantages:
◦ Impossible if no comparable project has been tackled.
◦ Needs systematically maintained cost database
 Basic Expert Judgement: Cons
 Hard to quantify

 It is hard to document the factors used by the experts or

expert-group.

 Expert may be biased, optimistic, or pessimistic, even though

they have been decreased by the group consensus.

 The expert judgment method always complements the

other cost estimating methods such as algorithmic method.
 Weighted average estimates
•Weighted average estimating is also known as sensitivity analysis estimating.
•Three estimates are obtained rather than one.
• Best case (O = optimistic), worst case (P = pessimistic) and most likely
(M = median).
•This provides a more accurate estimate than when only one estimate is
used.
•These are then used in the following formula:

Estimated effort = (O + 4M + P ) / 6
 Consensus estimating
Steps in conducting a consensus estimating session:
 A briefing is provided to the estimating team on the project.
 Each person is provided with a list of work components to estimate.
 Each person independently estimates O, M and P for each work
component.
 The estimates are written up on the whiteboard.
 Each person discusses the basis and assumptions for their estimates.
 A revised set of estimates is produced.
 Averages for the O, M and P values are calculated.
 These values are used in the formula.
 Delphi Estimation
 A variation of consensus estimation technique
 Team of Experts and a coordinator.
 Experts carry out estimation independently:
◦ mention the rationale behind their estimation.
◦ coordinator notes down any extraordinary rationale:
 circulates the estimation rationale among experts.
 Experts re-estimate.
 Experts never meet each other
◦ to discuss their viewpoints.
 Delphi
 Delphi is an expert survey in two or more "rounds".
 Starting from the second round, a feedback is given (about
the results of previous rounds).
 The same experts assess the same matters once more -
influenced by the opinions of the other experts
 important: anonymity
 Delphi Method: Steps
1. Coordinator presents each expert with a specification & an estimation
form.
2. Coordinator calls a group meeting in which the experts discuss
estimation issues with the coordinator.
3. Experts fill out forms anonymously.
4. Coordinator prepares and distributes a summary of the estimation on
an iteration form.
5. Coordinator calls a group meeting, specially mentioning the noted
rationale where the estimates varied widely.
6. Experts fill out forms, again anonymously, and Steps 4 and 6 are iterated
for as many rounds as appropriate.
 Types of Estimation Techniques
 Though there are many techniques of estimating, they can
broadly be classified into:
◦ Top-down
◦ Bottom-up
 What about:
◦ Algorithmic models?
◦ Expert opinion?
◦ Analogy ?
◦ Price to win?
 Bottom-up versus top-down
 Bottom-up
◦ identify all tasks that have to be done – so quite time-
consuming
◦ use when you have no data about similar past projects
 Top-down
◦ produce overall estimate based on project cost drivers
based on past project data
◦ divide overall estimate between jobs to be done
 Bottom-up estimating
1. Break the project activities into smaller and smaller
components
 Stop when you get to what one person can do in
one/two weeks
2. Estimate costs for the lowest level activities
3. At each higher level calculate estimate by adding
estimates for lower levels
 Top-down estimates
Estimate  Produce overall estimate
overall 100 days using effort driver(s)
project
 Distribute proportions of
overall estimate to
design code test components
30% 30% 40%
i.e. i.e. i.e. 40 days
30 days 30 days
Top-down Example
 Top-Down Estimating: Pros
 It accounts for system-level activities such as integration,
documentation, configuration management, etc.:

◦ Many of these may be ignored in bottom-up estimating

methods.

 It requires minimal project details:

◦ It is usually faster, easier to implement.

 Top-Down Estimating: Cons
 It often does not take into consideration the difficult low-
level problems:

◦ Tends to underestimate and overlook complexities of low-

level components.

 It provides no detailed basis for justifying decisions or

estimates.
 Bottom-up Estimating: Pro
 It permits the software group to estimate in an almost
traditional fashion:
◦ Each group estimates components for which it has
adequate experience.
 It is more stable because the estimation errors in the various
components more or less balance out.
 Bottom-up Estimating: Con
 It may overlook many of the system-level costs:
◦ Integration,
◦ configuration management,
◦ quality assurance, etc.
 It may be inaccurate because the necessary information may
not be available in the early phase.
 It tends to be more time-consuming.
 Criteria for a Good Algorithmic Model
 Defined—clear procedure
 Accurate
 Objective—avoids subjective factors
 Results understandable
 Stable— Results valid for a wide range of parameter values
 Easy to Use
 Causal—future data not required
 Algorithmic Models
 For project planning, we need:
◦ Effort (cost)
◦ Duration
 Hard to estimate effort (or cost) or duration directly from
a problem description.
 Effort and Duration can be measured in terms of certain
project characteristics that correlate with it:
◦ Called size
 Software Size
 What exactly is the size of a software project?
◦ How do you measure it?
 Any characteristic of software that is easily measured and
correlates with effort.
◦ SLOC
◦ Function point
 Algorithmic/Parametric models
 COCOMO (lines of code) and function points examples of
these
 A Problem with LOC based models (COCOMO etc):

guess algorithm estimate

but what is desired is

system algorithm estimate

characteristic
 Algorithmic Methods: Pro
 It is able to generate repeatable estimations.

 It is easy to modify input data, refine and customise formulas.

 It is efficient and able to support a family of estimations or a

sensitivity analysis.

 It can be meaningfully calibrated to previous experience.

 Algorithmic Methods: Cons
 It lacks means to deal with exceptional conditions, such as:

◦ exceptional teamwork, exceptional match between skill-

levels and tasks, etc.
 Poor sizing inputs and inaccurate cost driver rating will
result in inaccurate estimation.

 Some factors such as experience cannot be easily quantified.

 Model Calibration
 Many models are developed for specific situations and are, by
definition, calibrated to that situation.
 Such models usually are not useful outside of their particular
environment.
◦ Calibration is needed to increase the accuracy of one of
these general models.
◦ Calibration is in a sense customising a generic model.
 Items that can be calibrated in a model include:
◦ product types, operating environments, labour rates and
factors, various relationships between functional cost
items, etc.
 Some recommendations
 Do not depend on a single cost or schedule estimate.
 Use several estimating techniques or cost models:
◦ Compare the results and determine the reasons for any
large variations.
 Document the assumptions made when making the
estimates.
 Monitor the project to detect when assumptions that turn
out to be wrong jeopardize the accuracy of the estimate.
 Improve software process:
◦ Maintain a historical database
 Simplistic Model
 estimated effort = (system size) / productivity
 As example:
system size = lines of code What is wrong with the
simplistic model?
productivity = lines of code per day
 productivity = (system size) / effort
◦ based on past projects
 Example 1
Consider a transaction project of 38,000 lines of code, what is
the shortest time it will take to develop? Productivity is about
400 SLOC/staff month
Effort = (productivity)-1 (size)
= (1/.400 KSLOC/SM) (38 KSLOC)
= 2.5 (38) ≈ 100 SM
Min time = .75 T= (.75)(2.5)(SM)1/3
≈ 1.875(100)1/3
≈ 1.875 x 4.63 ≈ 9 months
 Summary
 Discussed the Price to win estimation method.
 Presented Size estimation.
 Also, discussed Expert Judgement – based estimation
techniques such as
 Basic judgement
 Weighted average estimating
 Consensus estimating
 Delphi Technique
 Explained the Analogy based estimation.
 Discussed top-down and bottom-up estimation techniques
 Discussed the algorithmic/parametric models for project
estimation.
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt.
Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Estimation Techniques cont…
• Parametric models
• Albrecht/IFPUG function points
 Parametric model for Size
Important example: Function Points
FPs originally used to estimate Lines of Code, rather than
effort

Number
of file types
‘system
model size’

Numbers of input
and output transaction types
Parametric models for Size
We shall examine four parametric models more closely :
1.Albrecht/IFPUG function points
2.Symons/Mark II function points
3.COSMIC function points
4.COCOMO81 and COCOMO II
International Function Point Users Group
(IFPUG)
Purpose
• To promote and encourage use of Function Points
• To develop consistent and accurate counting guidelines
Benefits
• Networking with other counters
• IFPUG Counting Practices Manual
• Research projects
• Hotline
• Newsletter
• Certification
Extent of Usage:
• Member companies include all industry sectors
• Over 1200 members in more than 30 countries
 Albrecht/IFPUG function point analysis
 Albrecht worked at IBM:
◦ Needed a way of measuring the relative productivity of
different programming languages.
◦ Needed some way of measuring the size of an
application without counting lines of code.
 Identified five parameters:
◦ Counted occurrences of each type of functionality in
order to get an indication of the size of an information
system
◦ It is a top-down approach
Why IFPUG Thinks One Should Not Use LOC?
 Lines of code tend to reward profligate design and
penalize concise design
 There is no industry standards (ISO or otherwise) for
lines of code
 Lines of code cannot be used for normalizing across
platform, language or by organization
 Some 4GL do not even use lines of code
 Lines of code can be misleading.
 How Do Function Points Overcome LOC
Problems?
 Function points are independent of the language, tools, or
methodologies used for implementation
 Function points can be estimated early in analysis and design
 Since function points are based on the user’s external view
of the system:
◦ Non-technical users of the software have a better
understanding of what function points are
measuring
Objectives of Function Point Counting
 Measure functionality that the user requests and receives…
 Measure software development and maintenance
independently of technology used for implementation…
 Simple enough to minimize the overhead of the
measurement process…
 A consistent measure among various projects and
organizations …
When Should You Count Function Points?
 Early and often
◦ The sooner you can quantify what a project is delivering,
the sooner it is under control
 Under IFPUG 4.1, there are rules and guidelines:
◦ Make it possible to count function points once the
requirements have been finalized
◦ The estimate of size in function points can be refined
continuously through out the development cycle.
 Function points should be recounted throughout the
development process: Can measure scope creep and
breakage
 Count Data
Determine
Functions
Unadjusted
Function Point
Count
Count
FP Computation Steps

Identify Transactional
Counting Functions Calculate
Scope and Adjusted Function
Application Point Count
Determine Value
Boundary
Adjustment
Factor
 Key Components in Function Point Analysis

Five key components (or External User Types) are identified

 External Inputs
 External Outputs
 External Inquiries
 Logical Internal Files
 External Interface Files
 Key Components in Function Point Analysis
cont…
1. External input (EI) types:
o Transactions which update internal computer files
2. External output (EO) types:
o Transactions which extract and display data from internal computer
files.
o Generally involves creating reports.
3. External inquiry (EQ) types:
o User initiated transactions which provide information but do not
update computer files.
o Normally the user inputs some data that guides the system to the
information the user needs.
 Key Components in Function Point Analysis
cont…

4. Logical interface file (LIF) types

o Equates roughly to a data store in systems analysis
terms. Created and accessed by the target system
5. External interface file types (EIF)
o Represents data retrieved from a data store which is
actually maintained by a different application.
 Function Point Parameters
External Input (Inputs)

External Input Count each unique user data or user control input type that (i)
(Inputs) enters the external boundary of the software system being measured
and (ii) adds or changes data in a logical internal file.
External Output Count each unique user data or control output type that leaves the
(Outputs) external boundary of the software system being measured.
Internal Logical File Count each major logical group of user data or control information
(Files) in the software system as a logical internal file type. Include each
logical file (e.g., each logical group of data) that is generated, used, or
maintained by the software system.
External Interface Files passed or shared between software systems should be counted
Files (Interfaces) as external interface file types within each system.
External Inquiry Count each unique input-output combination, where an input causes
(Queries) and generates an immediate output, as an external inquiry type.
 Definition of External input
An External Input (EI) processes data that comes from outside
the application’s boundary.

External Input
1.0
ON-LINE UPDATE
ENTRY Transaction CUSTOMER
INFORMATION

Multi-Screen

CUSTOMER INFO FILE

 Definition of External Output
An External Output (EO) generates data that is sent outside
the application boundary.

CUSTOMER INFO FILE

External Output
1.0

Category CATEGORIZE
END Summary CUSTOMER
USER INFO
 Definition of An Inquiry
An External Inquiry (EQ) is an output that results in data
retrieval. The result contains no derived data.

CUSTOMER INFO FILE

External Inquiry
1.0
END Selected DISPLAY
USER Customer CUSTOMER
Info INFO
 Definition of An IL File
An Internal Logical File (ILF) is a user-identifiable group of logically related
data that is maintained within the boundary of the application.

END
USER
1.0
UPDATE
CUSTOMER
INFO
Customer Info

Updated Customer Info

CUSTOMER INFO FILE

Internal Logical File

 Definition of an External Interface File
An External Interface File (EIF) is a user-identifiable group of data referenced by
the application, but maintained within the boundary of another application.

External Interface File

ZIP CODE
TABLE

VALID ZIP 1.0

CODES
VALIDATE UPDATES
ZIP CODE &
UPDATES UPDATE
CUSTOMER
END INFO
USER CUSTOMER INFO FILE
 Example
 Place Purchase Order:
◦ Input data items:
Date, Supplier Number,
Product Code
Quantity Required
Date Required
◦ Output data items:
PO Number (system generated)
◦ Entities referenced:
Product, Purchase Order
Supplier, Purchase Order Item
 Calculating the System Size
 For each function count:
◦ Number of input data items ni
◦ Number of output data items no
◦ Number of entities read/updated ne
 Add these up for the whole system, giving:
◦ Number of input data items Ni
◦ Number of output data items No
◦ Number of entities read/updated Ne
FP Counting - Example Requirement inputs outputs entity accesses

A1 10 2 4
A2 10 3 6
A3 1 25 1
A4 10 10 9
A5 4 10 5
A6 26 9 2
A7 5 11 8
A8 14 4 5
A9 22 7 4
A10 6 6 4
A11 9 9 7
A12 3 24 5
Ni = 120 No = 120 Ne = 60
 Albrecht complexity multipliers
External user Low Medium High
types complexity complexity complexity
External input type 3 4 6
External output type 4 5 7
External inquiry type 3 4 6
Logical internal file 7 10 15
type
External interface 5 7 10
file type
 IFPUG file type complexity
Number of Number of data types
record types

< 20 20-50 > 50

1 Low Low Average

2 to 5 Low Average High
>5 Average High High
 Example
A logical internal file might contain data about purchase
orders. These purchase orders might be organized into two
separate record types: the main PURCHASE –ORDER details,
namely purchase order number, supplier reference and
purchase order date, and then details for each PURCHASE-
ORDER-ITEM specified in the order, namely the product code,
the unit price and number ordered. The number of record
types for that file would therefore be 2 and the number of
data types would be 6. According to the previous table, this file
type would be rated as ‘low’. This would mean that according
to the previous table, the FP count would be 7 for this file.
 Example - 1
The Spell-Checker accepts as input a document file and an
optional personal dictionary file. The checker lists all words
not contained in either of these files. The user can query the
number of words processed and the number of spelling
errors found at any stage during processing.
Example 1 - cont…
errors found enquiry # words processed message

words processes enquiry

Spelling # errors message
User Checker User
document file
Dictionary

Personal dictionary report on misspelled words

 Example 1 - cont…
• 2 users inputs: document file name, personal dictionary name
(average)
• 3 users outputs: error report, word count,
misspelled error count (average)
• 2 users requests: # processed words?, #spelling errors? (average)
• 1 internal file: dictionary (average)
• 2 external files: document file, personal dictionary (average).
We know that, for average (medium) complexity parameters,
UFP= # inputs*4+ # outputs*5+ # inquiries*4+ # files*10+ #
interfaces*7
= 2×4 + 3 × 5 + 2 × 4 + 1 × 10 + 2 × 7
= 55
 Example - 2
Tom is starting a dental practice in a small town. He will have a dental
assistant, a dental hygienist, and a receptionist. He wants a system to
manage the appointments.
When a patient calls for an appointment, the receptionist will check
the calendar and will try to schedule the patient as early as possible
to fill in the vacancy. If the patient is happy with proposed
appointment, the receptionist will enter the appointment with the
patient name and purpose of appointment. The system will verify the
patient name and supply necessary details from the patient records,
including the patient’s ID number. After each exam or cleaning, the
hygienist or assistant will mark the appointment as completed, add
comments and, then schedule the patient for the next visit if
appropriate.
 Example - 2
The system will answer queries by patient name and by date.
Supporting details from the patient’s records are displayed along with
the appointment information. The receptionist can cancel
appointments. The receptionist can point out a notification list for
making reminder calls 2 days before appointments. The system
includes the patient’s phone numbers from the patient records. The
receptionist can also print out daily and weekly work schedules with
all the patients.

Calculate Unadjusted Function Point (UFP).

Type Simple
SolutionAverage Complex Total
Inputs • Patient name • Cancel appointment 13
• Appointment completed
• Appointment purpose

Outputs • Comments • Calendar • Daily schedule 38

• Supporting details • Weekly schedule
• Appointment
information
• Notification list

Inquires • Query by name • Verify patient 18

• Query by date • Check calendar
• Available appointment

Files • Patient data 10

Interfaces
Total 79
 Function Point: Refinement
14 General Systems Characteristics are evaluated and used to compute a
Value Adjustment Factor (VAF)
General System Characteristics
Data Communication On-Line Update
Distributed Data Processing Complex Processing
Performance Objectives Reusability
Heavily Used Configuration Conversion & Install Ease
Transaction Rate Operational Ease
On-Line Data Entry Multiple-Site Use
End-User Efficiency Facilitate Change

The final calculation is based upon the Unadjusted FP count X VAF

 Degrees of Influence
0 Not present, or no influence
1 Incidental influence
2 Moderate influence
3 Average influence
4 Significant influence
5 Strong influence throughout
 Procedures to Determine the VAF
 Evaluate each of the 14 general system characteristics on a
scale from zero to five to determine the degree of influence
(DI)
 Add the degrees of influence for all 14 general system
characteristics to produce the total degree of influence (TDI).
 Insert TDI into the following equation to produce the Value
Adjustment Factor (VAF) / Technical Complexity Factor (TCF).
VAF = (TDI * 0.01) + 0.65
 It expresses the overall impact of the corresponding
parameter on the development effort.
 Procedures to Determine the VAF
The following VAF is calculated, if the degree of influence (DI)
for each of the 14 GSC descriptions is 3, (i.e. 3*14):
VAF = (42 * 0.01) + 0.65 = 1.07
The Adjusted Function Point for Example – 1, is calculated as
follows:
FP=UFP* VAF
= 55*1.07
= 58.85
Procedures to Determine the VAF cont …
14 general system characteristics with different DIs: 8. End-user Efficiency 3
9. Complex Computations 0
1. Data Communication 3
10.Reusability 3
2. Distributed Data Processing 0 11.Ease of Installation 3
12.Ease of Operation 5
3. Performance Criteria 4
13.Portability 3
4. Heavily Utilized Hardware 0 14.Maintainability 3
5. High Transaction Rates 3
6. Online Data Entry 3
7. Online Updating 3
Total Degree of Influence (TDI)=36
Procedures to Determine the VAF cont …
So,VAF = (36 * 0.01) + 0.65 = 1.01

The Adjusted Function Point for Example – 1, is

calculated as follows:

FP = UFP * VAF

= 55 * 1.01

= 55.55
 Example 3
A Payroll application has:
1. Transaction to input, amend and delete employee details – an
EI that is rated of medium complexity
2. A transaction that calculates pay details from timesheet data
that is input – an EI of high complexity
3. A transaction of medium complexity that prints out pay-to-
date details for each employee – an EO of medium complexity
4. A file of payroll details for each employee – assessed as of
medium complexity LIF
5. A personnel file maintained by another system is accessed for
name and address details – a simple EIF
What would be the FP counts for these?
 External Low Medium High
user types complexit complexit complexit

FP counts External
y
3
y
4
y
6
input type
External 4 5 7
1. Medium EI = 4 FPs output
type
2. High complexity EI = 6 FPs External 3 4 6
inquiry
3. Medium complexity EO = 5 FPs type
Logical 7 10 15
4. Medium complexity LIF = 10 FPs internal
file type
External 5 7 10
5. Simple EIF = 5 FPs interface
file type
Total (UFP) = 30 FPs

If previous projects delivered 5 FPs a day, implementing the above should

take 30/5 = 6 days

You may compute the AFP considering all the influence values medium.
 Exercise 1: Tic-Tac-Toe Computer Game
 As soon as either of the human player or the computer wins,
◦ A message announcing the winner should be displayed.
 If neither player manages to get three consecutive marks
along a straight line,
◦ And all the squares on the board are filled up,
◦ Then the game is drawn.
 The computer always tries to win a game.
 Exercise 2
 It is needed to develop an Alumni Repository software for
IIM, Ranchi. The software will extract the details of
students from the existing academic software of IIM,
Ranchi. It will provide an online display of the Alumni
names. The details of the Alumni can be entered by any one
by double clicking on the Alumni name. The details of
Alumni would be stored in a file. It should be possible to
print out a report detailing all alumni.
 Determine UFP.
 Exercise 3: Supermarket Prize Scheme
 A supermarket needs to develop the following software to encourage regular customers.
 TO register, a customer needs to supply his/her residence address, telephone number, and
the driving license number.
 Each customer who registers for this scheme is assigned a unique customer number (CN)
by the computer.
 Based on the generated CN, a clerk manually prepares a customer identity card after
getting the market manager’s signature on it.
 A customer can present his customer identity card to the check out staff when he makes
any purchase. In this case, the value of his purchase is credited against his CN.
 At the end of each year, the supermarket intends to award surprise gifts to 10 customers
who make the highest total purchase over the year. Also, it intends to award a 22 caret gold
coin to every customer whose purchase exceeded Rs.10,000/-.
 The entries against the CN are reset on the last day of every year after the prize winners’
lists are generated.
 Exercise 4
Calculate Unadjusted Function Point (UFP), Complexity Adjustment Factor (CAF) and
Function Point (FP) for the following problem.
Number of user inputs=32
Number of user outputs=60
Number of user inquiries=24
Number of files=8
Number of external interfaces=2
Assume all weighting factors to be average and all complexity adjustment values to be average.
 Exercise 5
Calculate Unadjusted Function Point (UFP), Complexity Adjustment Factor (CAF) and
Function Point (FP) for the following problem.
Number of user inputs=24 (Weighting factor is average)
Number of user outputs=46 (Weighting factor is simple)
Number of user inquiries=8 (Weighting factor is complex)
Number of files=4 (Weighting factor is average)
Number of external interfaces=2 (Weighting factor is simple)
The various complexity adjustment values are 4, 1, 0, 3, 3, 5, 4, 4, 3, 3, 2, 2, 4, 5.
 Summary
 Discussed Albrecht/IFPUG function points analysis
 Also, discussed the steps to compute FP count
 Presented Albrecht/IFPUG function point parameters
 Explained Albrecht/IFPUG function points counting with
some suitable examples.
References :

1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,

McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Estimation Techniques cont…
• Parametric models
• Some more examples on Albrecht/IFPUG
function points

• Symons/Mark II function points

• COSMIC function points

• Object points
 Parametric models for Size
1.Albrecht/IFPUG function points

2.Symons/Mark II function points

3.COSMIC function points

4.COCOMO 81 and COCOMO II

 Example on Albrecht/IFPUG FP
Consider a project with the following functional units:
 50 user inputs, 40user outputs, 35 user enquiries,
6 user files, 4 external interfaces. Assume all complexity
adjustment factors and weighting factors are average.
 Compute the function points for the project.
 Suppose that program needs 70 LOC per FP.
 Find out the size of complete project.

5
 Solution
 UFP= 50 * 4 + 40 * 5 + 35 * 4 + 6 * 10 + 4 * 7
= 200+200+140+60+28 = 628
 VAF=0.65 + 0.01 (14 * 3) = 1.07
 AFP= UFP * VAF=628 * 1.07 = 672
 Size = FP * (LOC per FP) = 672 * 70 = 47040 LOC

6
 Another example
 Compute the function-point value for a project with the
following information-domain characteristics.
◦ Number of user Inputs: 32
◦ Number of User Output: 60
◦ Number of User Inquiries: 24
◦ Number of Files: 8
◦ Number of External interface:2
 Assume that all complexity adjustment values are average.
 Solution
 UFP = 32x4 + 60x5 + 24x4 + 8x10 + 2x7 = 128 + 300 + 96
+ 80 + 14 = 618
 VAF = 0.65 + 0.01x(14x3) = 0.65+0.42 = 1.07
 AFP = UFP x VAF = 618x1.07 = 661.26

8
 Example: super market
Determine the function point measure of the size of the following
supermarket software. A supermarket needs to develop the following
software to encourage regular customers. For this, the customer needs to
supply his/her residence address with telephone number, and the driving
license number. Each customer who registers for this scheme is assigned a
unique customer number (CN) by the computer. Based on the generated
CN, a clerk manually prepares a customer identity card after getting the
market manager’s signature on it. A customer can present his customer
identity card to the check out staff when he makes any purchase. In this
case, the value of his purchase is credited against his CN. At the end of
each year, the supermarket intends to award surprise gifts to 10 customers
who make the highest total purchase over the year. Also, it intends to
award a 22 caret gold coin to every customer whose purchase exceeded
Rs. 10,000. The entries against the CN are reset on the last day of every
year after the prize winners’ lists are generated. Assume that various
project characteristics determining the complexity of software
development have significant influence.
 Solution of Example: super market
Step 1: From an initial examination of the problem
description, we find that there are two inputs, three outputs,
two files (one for storing the customer details and another for
storing the daily purchase records), and no interfaces.
Now we get:
 UFP = 2 × 4 + 3 × 5 + 1 × 4 + 10 × 2 + 0 × 7 = 47
Ref: UFP= # inputs*4+ # outputs*5+ # inquiries*4+ # files*10+ # interfaces*7

10
 Solution of Example: super market cont…
Step 2: All the parameters are of medium complexity, except
the output parameter of customer registration, in which the
only output is the CN value. So, the complexity of the output
parameter of the customer registration function can be
categorized as simple or low. By consulting the table, we find
that the value for simple output is given to be 4.
The UFP can be refined as follows:
 UFP = 2 × 4 + 1 × 4 + 2 × 5 + 1 × 4 + 10 × 2 + 0 × 7 = 46
So, the refined UFP will be 46.

11
Solution of Example: super market cont…
 Step 3: Since the complexity adjustment factors have
significant influence values, therefore the total degrees of
influence would be: DI = 14 × 4 = 56
 TCF = (56 * 0.01) + 0.65 = 1.21
Therefore,Adjusted FP=46*1.21=55.66

12
 Function points Mark II
 Developed by Charles R. Symons

 ‘Software sizing and estimating - Mk II FPA’, Wiley & Sons,

1991.

 Builds on work by Albrecht

 Developed in parallel to IFPUG FPs

 A simpler and more usable method

 Function points Mk II cont…
 For each transaction, count
◦ data items input (Ni)
◦ data items output (No)
◦ entity types accessed (Ne)
 Function points Mk II cont…
#entities  Simpler than FP
accessed  Widely used in UK

Process
#input #output
items items

FP count = Ni * 0.58 + Ne * 1.66 + No * 0.26

 Function points for embedded systems
 Mark II and IFPUG function points were designed for
information systems, and not suitable for embedded systems:
 Dominated by input and output operations
 COSMIC Full FPs attempt to extend the concept to
embedded systems
 In an embedded system, its features will be hidden, because
the software’s user will probably not be a human,
◦ it will be hardware device or another software component
 Function points for embedded systems
cont...
 COSMICS deals with this by decomposing the system
architecture into a hierarchy of software layers.
 Embedded software is seen as being in a particular ‘layer’ in
the system
◦ Communicates with other layers and also other
components at same level
• The software component to be sized, can receive requests
for services from layers above and can request services from
those below it.
 Layered software

Higher layers
Receives request Supplies service
Data reads/ Peer to peer
communication
Persistent writes peer
storage Software component
component
Makes a request
for a service Receives service
Lower layers
 Function points for embedded systems
cont...
 This identifies the boundary of the software component to
be accessed and thus the points at which it receives inputs
and transmits outputs.
 Inputs and outputs are aggregated into data groups, where
each group brings together data items that relate to the
same object of interest.
 COSMIC FPs
Data groups can move about in 4 ways as follows.

 Entries: movement of data into software component from a

higher layer or a peer component

 Exits: movements of data out

 Reads: data movement from persistent storage

 Writes: data movement to persistent storage

Each counts 1 ‘COSMIC functional size unit’ (Cfsu).

 COSMIC FPs cont ...
 The overall FP count is derived by simply adding up the
counts for each of the 4 types of data movement.

 COSMIC FPs have been incorporated into ISO standard.

 COSMIC FPs cont ...
Cons:
 Does not take into account any processing of the data
groups once they have been moved into the software
component.
 Not recommended for use in systems involving complex
mathematical algorithms.
 Function Points: Pros and Cons
 Cons:
 Pros: ◦ Labor intensive
◦ Language independent ◦ Extensive training
◦ Inexperience may result in
◦ Understandable by client inaccuracy
◦ Weighted to file manipulation and
◦ Simple modeling transactions
◦ Errors may be introduced by
◦ Hard to fudge single person, multiple raters
advised…
◦ Visible feature creep
◦ Does not consider algorithmic
complexity of a function.
 Feature Point Metric
 FP metric Suffers from a major drawback:
◦ the size of a function is considered to be independent of
its complexity.
• In order to overcome this problem, an extension to the
function point metric, called feature point metric has been
proposed.
◦ considers an extra parameter:
 Algorithm Complexity.

24
 Feature Point Metrics cont ...
 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.
 Critical comments on the function point and feature
point metrics
 Proponents of function point and feature point metrics claim
that these two metrics are language-independent and can be
easily computed from the SRS document during project
planning stage itself.
 On the other hand, opponents claim that these metrics are
subjective and require a sleight of hand.
 An example of the subjective nature of the FP metric:
◦ the way one groups the input and output data items into logically
related groups can be very subjective.
 Critical comments on the function point and feature
point metrics cont…
 For example, consider that certain functionality requires the
employee name and employee address to be input. It is
possible that one can consider both these items as a single
unit of data, since after all, these describe a single employee.
It is also possible for someone else to consider an
employee’s address as a single unit of input data and name as
another.
 Such ambiguities leave sufficient scope for debate and keep
open the possibility for different project managers to arrive
at different FP measures for essentially the same problem.
 FP/SLOC Conversion
Median SLOC/function
Language
point
C 104
C++ 53
HTML 42
JAVA 59
Perl 60
J2EE 50
Visual
42
Basic
 Accurate Size Estimation

DEFINITION Situation Adjustments ESTIMATE

Schedule
REQUIREMENT PROJECT X PROJECT X RISK
SIZE COMPLEXITY FACTORS
Adjustments Effort Costs
Adjustments

FUNCTION POINT ANALYSIS

 Object Points
 Object points has nothing to do with object-oriented
programming
 Number of object points is estimated based on
◦ Number of separate screens displayed
◦ Number of reports that are produced
◦ Number of modules in the code
 Object points are simpler to estimate
◦ they take GUI into account
 Summary
• Solved some more examples on Albrecht/IFPUG function
points
• Discussed Symons/Mark II function points and COSMIC
function points.
• Also, discussed the concepts feature points and object
points.
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt.
Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Estimation Techniques cont…
• Parametric models
• COCOMO 81 and COCOMO II
 Parametric models for Size
1.Albrecht/IFPUG function points

2.Symons/Mark II function points

3.COSMIC function points

4.COCOMO 81 and COCOMO II

 COCOMO
 COCOMO (CONSTRUCTIVE COST MODEL) -First
published by Dr. Barry Boehm, 1981
 Several interactive cost estimation software
 packages available
 Derived from statistical regression of data
from a base of 63 past projects (2000 - 512,000 DSIs)
 COCOMO 81
 Based on industry productivity standards - database can be
constantly updated
 Allows an organization to benchmark its software
development productivity
 Basic model:
effort = c x sizek
◦ c and k depend on the type of system: organic, semi-
detached, embedded
◦ Size is measured in ‘kloc’ i.e.Thousands of lines of code
 COCOMO Mode & Model
 Three development environments (modes)
◦ Organic Mode
◦ Semidetached Mode
◦ Embedded Mode
 Three increasingly complex models
◦ Basic Model
◦ Intermediate Model
◦ Detailed Model
 COCOMO Modes
 Organic Mode
◦ Developed in familiar, stable environment
◦ Product similar to previously developed product
◦ <50,000 DSIs (ex: accounting system)
 Semidetached Mode
◦ somewhere between Organic and Embedded (e.g. compilers,
linkers etc.)
 Embedded Mode
◦ new product requiring a great deal of innovation
◦ inflexible constraints and interface requirements
(ex: operating systems, real-time systems)
 Modes
Feature Organic Semidetached Embedded

Organizational Thorough Considerable General

understanding of
product and
objectives
Experience in Extensive Considerable Moderate
working with related
software systems

Need for software Basic Considerable Full

conformance with
pre-established
requirements

Need for software Basic Considerable Full

conformance with
external interface
specifications
 COCOMO Models
 Basic Model
◦ Used for early rough, estimates of project cost, performance,
and schedule
◦ Accuracy: within a factor of 2 of actuals 60% of time
 Intermediate Model
◦ Uses Effort Adjustment Factor (EAF) from 15 cost drivers
◦ Doesn’t account for 10 - 20 % of cost (training, maintenance,
Quality, etc.)
◦ Accuracy: within 20% of actuals 68% of time
 Detailed Model
◦ Uses different Effort Multipliers for each phase of project
(Most project managers use intermediate model)
 Basic Effort Equation (COCOMO 81)
 Effort=c * (size)k
◦ c is a constant based on the developmental mode
 organic = 2.4
 semi = 3.0
 embedded = 3.6
◦ size = 1000s Source Lines of Code (KSLOC)
◦ k is a constant for a given mode
 organic = 1.05
 semi = 1.12
 embedded = 1.20
 The COCOMO constants
System type c k
Organic (broadly, information 2.4 1.05
systems)
Semi-detached (broadly utility apps) 3.0 1.12
Embedded (broadly, real-time) 3.6 1.20

k exponentiation – ‘to the power of…’

adds disproportionately more effort to the larger projects
takes account of bigger management overheads

12
 Basic Model:
Schedule Equation (COCOMO 81)
 Nominal Development time= 2.5*(Effort)exponent
 2.5 is constant for all modes
 Exponent based on mode
◦ organic = 0.38
◦ semi = 0.35
◦ embedded = 0.32
 Basic COCOMO Model (CONT.)

 Effort is
somewhat Effort

super-linear
in problem
size.
Size

14
 Basic COCOMO Model cont …
 Development time
◦ sublinear function of
product size. Dev. Time
 When product size
increases two times, 18 Months
◦ development time
does not double. 14 Months
 Time taken:
◦ almost same for all
the three product 30K 60K
Size
categories.

15
 Effort for
increasing LOC
3x 1.12
Duration for
increasing Effort*
2.5x 0.35

<1
exponent:
>1
 Basic COCOMO Model cont …
 Development time does not increase linearly with product
size:
◦ For larger products more parallel activities can be
identified:
 can be carried out simultaneously by a number of
engineers.

17
 Basic COCOMO Model cont …
 Development time is roughly the same for all the three
categories of products:
◦ For example, a 60 KLOC program can be developed in
approximately 18 months
 regardless of whether it is of organic, semi-detached, or
embedded type.
◦ There is more scope for parallel activities for system and
application programs,
 than utility programs.
 Example - 1
The size of an organic software product has been estimated to
be 32,000 lines of source code. Assume that 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.
 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 x Rs. 15,000=Rs. 1,465,000
 Example - 2
Suppose you are developing a software product in the organic
mode. You have estimated the size of the product to be about
100,000 lines of code. Compute the nominal effort and the
development time.
 Given that the size is 100 KLOC and the project is organic.
 Nominal effort=2.4 x 1001.05=2.4 x 125.893=302.1 man-
months
 Nominal development time=2.5 x (Effort)0.38=2.5 x
302.10.38=8.6 months
 Example - 3
Suppose that a certain software product for business
application costs Rs. 50,000 to buy off-the-shelf and that its size
is 40 KLOC. Assuming that in-house developers cost Rs. 6000
per PM (including overheads), would it be more cost-effective
to buy the product or build it?
The product is for business application and can be classified as
organic type. So,
 Nominal effort=2.4 x 401.05=2.4 x 48.1=115.5 man-months
 In-house engineers cost Rs. 6000/-.
 So, the cost of development is 115.5 x 6000=Rs. 693,000/-
 But, purchasing the above S/W will cost Rs. 50,000.
 So, it is better to go for buying the product.
 Example - 4
Suppose an organic project has 7.5 KLOC. Find the effort,
development time, average staff required and productivity.
◦ Effort 2.4x(7.5)1.05= 20 staff–months
◦ Development time 2.5x(20)0.38= 8 months
◦ Average staff required 20 / 8 = 2.5 staff
◦ Productivity 7,500 LOC / 20 staff-months = 375 LOC / staff-month

22
 Example - 5
Suppose an embedded project has 50 KLOC. Find the effort,
development time, average staff required and productivity.
◦ Effort 3.6x(50)1.20= 394 person–months
◦ Development time 2.5x(394)0.32= 17 months
◦ Average staff 394 / 17 = 23 staff
◦ Productivity 50,000 LOC / 394 staff-months = 127 LOC / staff-month

23
 Exercise
 A software package is required by a company to mine
existing customer data to select prospective customers for
a new launch.
◦ The size is estimated to be 30KLOC.
◦ Assume competent developers can be hired at Rs50,000/- per month.
◦ However, commercial offering supporting almost all of the required
features costs Rs. 100,000/-
 Should the company buy or build the product?
 Buy/Build Decision
 The make/buy decision can be made based on the following
conditions
◦ Will the software product be available sooner than
internally developed software?
◦ Will the cost of acquisition plus the cost of
customization be less than the cost of developing the
software internally?
◦ Will the cost of outside support (e.g., a maintenance
contract) be less than the cost of internal support?
 Summary
 Discussed fundamentals of Basic COCOMO
 Discussed various types of projects such as organic,
semidetached and embedded
 Presented Cost and Effort estimation using Basic
COCOMO
 Solved some examples on Cost and Effort estimation using
Basic COCOMO
 References :

1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixfth Edition,

McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Estimation Techniques cont …
• Intermediate COCOMO
• Complete COCOMO
 Intermediate COCOMO
 Basic COCOMO model assumes
◦ effort and development time depend on product size
alone.
 However, several parameters affect effort and development
time, such as:
◦ Reliability requirements
◦ Availability of CASE tools and modern facilities to the
developers
◦ Size of data to be handled

4
 Intermediate COCOMO
 For accurate estimation,
◦ the effect of all relevant parameters must be considered:
◦ Intermediate COCOMO model recognizes this fact:
 refines the initial estimate obtained by the basic
COCOMO by using a set of 15 cost drivers
(multipliers).

5
 Intermediate COCOMO cont …
For example,
 If modern programming practices are used,
◦ initial estimates are scaled downwards.

 If there are stringent reliability requirements on the product,

◦ initial estimate is scaled upwards.

6
 Intermediate COCOMO cont…
 Rate the different parameters on a scale of 1 to 3:
◦ Depending on these ratings,
 multiply cost driver values with the estimate obtained
using the basic COCOMO.
 In some cases, value of the parameters (cost drivers) may be
less than 1, e.g. if modern programming practices are being
used.

7
 Intermediate COCOMO cont …
 Takes basic COCOMO as starting point
 Identifies the attributes such as personnel, product,
computer and project attributes, which affect the cost and
development time.
 Multiplies basic cost by attribute multipliers which may
increase or decrease the costs.
 Attributes
Personnel attributes
 Analyst capability (ACAP)
 Virtual machine experience (VEXP)
 Programmer capability (PCAP)
 Programming language experience (LEXP)
 Application experience (AEXP)
Product attributes
 Reliability requirement (RELY)
 Database size (DATA)
 Product complexity (CPLX)
 More Attributes
Computer attributes
 Execution time constraints (TIME)
 Storage constraints (STOR)
 Virtual machine volatility (VIRT)
 Computer turnaround time (TURN)
Project attributes
 Modern programming practices (MODP)
 Software tools (TOOL)
 Required development schedule (SCED)
COCOMO effort multipliers (cost drivers)
 Each of the 15 attributes receives a rating on a six-point
scale that ranges from "very low" to "extra high" (in
importance or value).
 The product of all effort multipliers results in an effort
adjustment factor (EAF).
 Typical values for EAF range from 0.9 to 1.4.
 COCOMO – cost drivers
Cost Driver Very Low Nominal High Very High Extra High
low
Required reliability 0.75 0.88 1.0 1.15 1.40
Database size 0.94 1.0 1.08 1.16
Product complexity 0.70 0.85 1.0 1.15 1.30
Execution time constraint 1.0 1.11 1.30
Memory constraint 1.0 1.06 1.21
Virtual machine volatility 0.87 1.0 1.15 1.30
Computer turnaround time 0.87 1.0 1.07 1.15
Analyst capability 1.46 1.19 1.0 0.86 0.71
Application experience 1.29 1.13 1.0 0.91 0.82
Programmer capability 1.42 1.17 1.0 0.86 0.70
Virtual machine experience 1.21 1.10 1.0 0.90
Programming language experience 1.14 1.07 1.0 0.95
Modern programming practices 1.24 1.10 1.0 0.91 0.82
Use of software tools 1.24 1.10 1.0 0.91 0.83
Development schedule 1.23 1.08 1.0 1.04 1.10
 Intermediate Model
Effort Equation (COCOMO 81)
 Effort=EAF*c*(size)k
◦ EAF (effort adjustment factor) is the product of effort
multipliers corresponding to each cost driver rating
◦ c is a constant based on the developmental mode
◦ Some papers have taken value of c same as that of Basic
COCOMO, some other papers have taken value of c as
 for organic products, c = 3.2
 for semi-detached products, c = 3.0
 for embedded products, c = 2.8
◦ size = 1000s Delivered Source Instruction (KDSI)
◦ k is a constant for a given mode, same as Basic COCOMO
 Intermediate Model
Effort Equation (COCOMO 81) cont …
 The development time calculation uses effort in the same
way as in the Basic COCOMO, i.e.
Nominal Development time= 2.5*(Effort)exponent
where, 2.5 is constant for all modes, and
exponent is based on mode
organic = 0.38
semidetached = 0.35
embedded = 0.32
 Using COCOMO development effort
multipliers
An example: for analyst capability:
 Assess capability as very low, low, nominal, high or very high
 Extract multiplier:
very low 1.46
low 1.19
nominal 1.00
high 0.80
very high 0.71
 Adjust nominal estimate e.g. 32.6 x 0.80 = 26.8 staff months
 Example 1
 Determine effort, duration, and staffing level for the
following scenario:
◦ Estimated size 10,000 LOC = 10 KLOC.
◦ Small project, familiar development
◦ Analyst capability: Low
◦ Application experience: Low
◦ programmer capability: low
◦ Programmer experience: High
 Example 1 cont …
 Need to produce 10,000 LOC = 10 KLOC.
 Since a small project and familiar development, use organic
model:
◦ Effort =2.4(10)1.05 = 26.9 Person-Months
◦ Development-time = 2.5(26.9).38 = 8.73 Months
◦ Average Staff = 26.9 PM/8.73 Months = 3.08  3 People
 Example 1 cont…
 Now, the attribute multipliers will be as follows:
Analyst capability - 1.19 (low)
Application experience - 1.13 (low)
programmer capability - 1.17 (low)
programming experience - 0.95 (high)
 So, Adjustment factor = 1.19*1.13*1.17*0.95 = 1.49
 Effort = 26.9*1.49 = 40 Person-months
 Development time = 2.5*(40).38 = 10.2 Months
 Average Staff = 40PM/10.2M=3.9 (approx. 4) People
 Example 2
 Suppose the project to be developed is a flight control
system (mission critical) with 319,000 DSI in embedded
mode.
 Reliability must be very high (RELY=1.40). So we can
calculate:
Effort = 1.40*3.6*(319)1.20 = 5093 PM(approx.)
Duration = 2.5*(5093)0.32 = 38.4 months (approx.)
Average Staffing = 5093 PM/38.4 months = 133 People
(approx.)
 Example 3
 An embedded software system on microcomputer hardware
to be developed.
 Basic COCOMO predicts a 45 person-month effort
requirement
 Attributes = RELY (1.15), STOR (1.21), TIME (1.10), TOOL
(1.10)
 Intermediate COCOMO predicts
45 * 1.15 * 1.21 * 1.10 *1.10 = 76 person-months.
 Assume total cost of person month = Rs. 50,000.
 Total cost = 76 * 50,000 = Rs.38,00, 000
Shortcoming of basic and intermediate
COCOMO models
 For better accuracy:
◦ COCOMO has to be calibrated to an organizations’
environment.
 Very sensitive to parameter change:
◦ Over a person-year difference in a 10 KLOC project
with minor adjustments
 Broad brush model that can generate significant errors
 Shortcoming of basic and intermediate
COCOMO models cont …
 Do not take into account
◦ software reuse
◦ application generation programs
◦ object-oriented approaches
◦ application engineering (reuse, applications translation)
◦ need for rapid development
 Shortcoming of basic and intermediate
 Both models:
COCOMO models
◦ consider a software product as a single homogeneous
entity:
◦ However, most large systems are made up of several
smaller sub-systems.
 Some sub-systems may be considered as organic type,
some may be considered embedded, etc.
 for some the reliability requirements may be high, and so
on.

24
 Complete COCOMO
 Overcomes some of the limitations of Basic and
Intermediate COCOMO.
 Cost of each sub-system is estimated separately.
 Costs of the sub-systems are added to obtain total cost.
 Reduces the margin of error in the final estimate.

25
 Complete COCOMO Example
 A Management Information System (MIS) for an organization
having offices at several places across the country:
◦ Database part (semi-detached)
◦ Graphical User Interface (GUI) part (organic)
◦ Communication part (embedded)
 Costs of the individual components are estimated separately:
◦ summed up to give the overall cost of the system.

26
Six phases of detailed COCOMO
 Planning and requirements
 System structure
 Complete structure
 Module code and test
 Integration and test
 Cost Constructive model
 Summary
 Discussed the fundamentals of Intermediate COCOMO.
 Presented the different cost drivers (multipliers).
 Explained Cost and Effort estimation using Intermediate
COCOMO.
 Shown the limitations of Basic and Intermediate COCOMO.
 Solved some examples on Cost and Effort estimation using
Intermediate COCOMO.
 Discussed fundamentals of Complete (Detailed) COCOMO.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Estimation Techniques cont …
▪ COCOMO II
 COCOMO II
 Since the time that COCOMO estimation model was
proposed in the early 1980s,
◦ the software development paradigm as well as the
characteristics of development projects have undergone a
sea change.
 The present day software projects are much larger in size
and reuse of existing software to develop new products has
become pervasive.

4
 COCOMO II
 For example, component-based development and service-
oriented architectures (SOA) have become very popular.
 New life cycle models and development paradigms are being
deployed for web-based and component-based software.
 During the 1980s rarely any program was interactive, and
graphical user interfaces were almost non-existent.
 COCOMO II
 On the other hand, the present day software products are
highly interactive and support elaborate graphical user
interface.
 Effort spent on developing the GUI part is often as much as
the effort spent on developing the actual functionality of the
software.
 COCOMO II
 To make COCOMO suitable in the changed scenario,
◦ Boehm proposed COCOMO 2 in 1995.
 COCOMO 2 provides three models to arrive at
increasingly accurate cost estimations.
 These can be used to estimate project costs at different
phases of the software product.
 As the project progresses, these models can be applied at
the different stages of the same project.
 COCOMO II
 Main objectives of COCOMO II:
◦ To develop a software cost and schedule estimation
model tuned to the life cycle practices of the 1990’s and
2000’s
◦ To develop software cost database and tool support
capabilities for continuous model improvement
 From “Cost Models for Future Software Life Cycle Processes:
COCOMO 2.0," Annals of Software Engineering, (1995).
 COCOMO II models
 COCOMO II incorporates a range of sub-models:
▪ Produces increasingly accurate estimates.
 The sub-models in COCOMO II are:
▪ Application composition model. Used when software is
composed from existing parts.
▪ Early design model. Used when requirements are available but
design has not yet started.
▪ Reuse model. Used to compute the effort of integrating
reusable components.
▪ Post-architecture model. Used once the system architecture has
been designed and more information about the system is
available.
 COCOMO II
COCOMO 81 DSI - “Delivered Source Instructions”
COCOMO II SLOC - “Source Lines Of Code”
•The original COCOMO 81 model was defined in terms of
Delivered Source Instructions, which are very similar to
SLOC.
•The major difference between DSI and SLOC is that a single
Source Line of Code may be several physical lines.
•For example, an "if-then-else" statement would be counted
as one SLOC, but might be counted as several DSI.
 COCOMO II
 The core model is:
Effort (pm) = A× (size)(sf) ×(em1) ×(em2) ×(em3)….
where,
 pm = person months,
 A = 2.94,
 size is the number of thousands of source lines of code,
 sf is the scale factor
 em is an effort multiplier
 Application composition model
 Applicable to prototyping projects and projects where there is
extensive reuse.
 Based on standard estimates of developer productivity in terms
of application (object) points/month. Application points are
computed using objects such as screens, reports, modules
(components) etc.
 Takes CASE tool use into account.
 Formula is
▪ PM = ( NAP (100 - %reuse)/100 ) / PROD
▪ where, PM is the effort in person-months, NAP is the no. of
application points and PROD is the productivity.
 Application Composition Model
 Suitable for software built around graphical user interface
(GUI) and modern GUI-builder tools
 Uses object points as a size metric
◦ extension of function points
◦ count of the screens, reports, and modules, weighted by a
three-level factor (simple, medium, difficult)
 Application Points
 Used with languages such as database programming
languages or scripting languages.
 Number of application points is a weighted estimate of:
◦ Number of separate screens that are displayed:
Simple screens count as 1 object point, moderately
complex screens count as 2 and very complex screens
count as 3 object points.
 Application Points cont …
• Number of reports that are produced: For simple reports,
count 2 object points, for moderately complex reports,
count 5 and for reports which are likely to be difficult to
produce, count 8 object points.
• Number of modules in languages such as Java or C++ that
must be developed to supplement the database
programming code. Each of these modules counts as 10
object points.
 Application-point productivity
Developer’s
experience and
Very low Low Nominal High Very
capability high

ICASE
maturity and
Very low Low Nominal High Very
capability high

PROD
(NAP/month)
4 7 13 25 50
 The Scale Drivers (Exponents)
•An important factor contributing to a project's duration and cost is the
Scale Driver.
•The Scale Drivers determine the exponent used in the Effort Equation.
•Scale Drivers have replaced the Development Modes of
COCOMO 81.
•The 5 Scale Drivers are:
 Precedentedness
 Development Flexibility
 Architecture / Risk Resolution
 Team Cohesion
 Process Maturity
 Early Design Model
Effort =A * (Environment Multipliers) * [ Size ]
( Process Scale Factors )

Environment: Product, Platform, People, Project Factors

Size: Reuse and volatility effects
Process: Constraint, Risk/Architecture,Team, Maturity Factors

· Schedule = ( Multiplier ) * [Effort] ( Process Scale Factors )

 COCOMO II Scaling Exponent Approach
• Nominal person-months = A*EM * (size)B
• B = 0.91 + 0.01 (scale factor ratings)
- B ranges from 0.91 to 1.23
- 5 scale factors; 6 rating levels each
• Scale factors:
- Precedentedness (PREC)
- Development flexibility (FLEX)
- Architecture/ risk resolution (RESL)
- Team cohesion (TEAM)
- Process maturity (PMAT, derived from SEI CMM)
 COCOMO II Scale factors
Based on five factors which appear to be particularly sensitive
to system size
1. Precedentedness (PREC). Degree to which there are
past examples that can be consulted
2. Development flexibility (FLEX). Degree of flexibility
that exists when implementing the project
3. Architecture/risk resolution (RESL). Degree of
uncertainty about requirements
4. Team cohesion (TEAM).
5. Process maturity (PMAT) could be assessed by
CMMI
 Project Scale Factors
Scale Factors Very Low Low Nominal High Very High Extra High
(Wi)

PREC thoroughly largely somewhat generally largely familiar thoroughly

unprecedented unprecedented unprecedented familiar familiar
FLEX rigorous occasional some general some general goals
relaxation relaxation conformity conformity
RESL little (20%) some (40%) often (60%) generally mostly (90%) full (100%)
(75%)
TEAM very difficult some difficult basically largely highly seamless
interactions interactions cooperative cooperative cooperative interactions
interactions
PMAT weighted sum of 18 KPA achievement levels
 COCOMO II Scale factor values
Driver Very low Low Nom-inal High Very Extra
high high
PREC 6.20 4.96 3.72 2.48 1.24 0.00
FLEX 5.07 4.05 3.04 2.03 1.01 0.00
RESL 7.07 5.65 4.24 2.83 1.41 0.00
TEAM 5.48 4.38 3.29 2.19 1.10 0.00
PMAT 7.80 6.24 4.68 3.12 1.56 0.00
 Example: Usage of scale factor
 A software development team is developing an application:
◦ It is very similar to previous ones it has developed.
 A very precise software engineering document lays down very strict
requirements.
◦ PREC is very high (score 1.24).
 FLEX is very low (score 5.07).
 The good news is that requirements are unlikely to change:
◦ RESL is high with a score 2.83
 The team is tightly knit (high score of 2.19), but processes are informal:
◦ so PMAT is low and scores 6.24
 Example: Scale factor calculation
The formula for sf is
sf = 0.91 + 0.01 × Σ scale factor values
i.e. sf = 0.91 + 0.01
× (1.24 + 5.07 + 2.83 + 2.19 + 6.24)
= 1.0857
If system contained 10 KLOC, then the estimate would be
2.94 x 101.0857 = 35.8 person months
Using exponentiation (‘to the power of’) adds
disproportionately more to the estimates for larger
applications
 Environment / Effort multipliers
In addition to the scale factors,
- effort multipliers are also assessed. Followings are the 7 effort
multipliers used in Early Design Model:

RCPX Product reliability and complexity

RUSE Reuse required
PDIF Platform difficulty
PERS Personnel capability
PREX Personnel experience
FCIL Facilities available
SCED Schedule pressure
 Values of the Effort Multipliers
Extra Very Low Nom- High Very Extra
low low inal high high
RCPX 0.49 0.60 0.83 1.00 1.33 1.91 2.72
RUSE 0.95 1.00 1.07 1.15 1.24
PDIF 0.87 1.00 1.29 1.81 2.61
PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.50
PREX 1.59 1.33 1.12 1.00 0.87 0.74 0.62
FCIL 1.43 1.30 1.10 1.00 0.87 0.73 0.62
SCED 1.43 1.14 1.00 1.00 1.00
 Example
 A new project to be developed is similar in most characteristics
to those that an organization has been dealing for some time
 except
◦ the software to be produced is exceptionally complex and will
be used in a safety critical system.
◦ The software will interface with a new operating system that
is currently in beta status.
◦ To deal with this the team allocated to the job is regarded as
exceptionally good, but do not have a lot of experience on this
type of software.
 Example cont ...
RCPX very high 1.91
PDIF very high 1.81
PERS extra high 0.50
PREX nominal 1.00
All other factors are nominal
Say, the initial estimate is 35.8 person months.
With effort multipliers this becomes 35.8 x 1.91 x 1.81 x 0.5
x 1 = 61.9 person months
 The Reuse Model
 Reuse costs:
◦ overhead for assessing, selecting and assimilating
component
◦ small modifications generate disproportional large costs
 Takes into account:
◦ black-box code that is reused without change
◦ code that has to be adapted to integrate it with new code.
 The Reuse Model
There are two versions:
▪ Black-box reuse where code is not modified. An effort
estimate (PM) is computed.
▪ White-box reuse where code is modified.
▪ A size estimate equivalent to the number of lines of new
source code is computed.
▪ This then adjusts the size estimate for new code.
 Reuse Model Estimates
1. For generated (reused) code:
▪ PM = (ASLOC * AT/100)/ATPROD
▪ ASLOC is the number of lines of generated code
▪ AT is the percentage of code automatically generated.
▪ ATPROD is the productivity of engineers in integrating this code.
2 When code has to be understood and integrated:
▪ ESLOC = ASLOC * (1-AT/100) * AAM.
▪ ASLOC and AT as before.
▪ AAM is the adaptation adjustment multiplier computed from the
costs of changing the reused code, the costs of understanding how
to integrate the code and the costs of reuse decision making.
 Post-Architecture Model
 Uses the same formula as the early design model:
▪ but with 17 rather than 7 associated multipliers.
 The code size is estimated as:
▪ Number of lines of new code to be developed;
▪ Estimate of equivalent number of lines of new code
computed using the reuse model;
▪ An estimate of the number of lines of code that have to
be modified according to requirements changes.
 Example
A project with all Nominal Cost Drivers and Scale Drivers
would have an EAF (Effort Adjustment Factor) of 1.00 and
exponent, E, of 1.0997.
Assuming that the project is projected to consist of 8,000
source lines of code, COCOMO II estimates that 28.9
Person-Months of effort is required to complete it:
Effort = 2.94 * (1.0) * (8)1.0997 = 28.9 Person-Months
 Summary
• Discussed fundamentals of COCOMO II
• Explained the four sub-models of COCOMO II
▪ Application composition model.
▪ Early design model.
▪ Reuse model.
▪ Post-architecture model.
• Presented COCOMO II Scale factors and Effort
multipliers.
• Solved some examples on estimating effort and cost using
COCOMO II model.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Estimation Techniques
cont…
• Halstead's Software Science
 Halstead's Software Science
 An analytical technique to measure:
◦ size, development effort, and development time.

4
 Halstead's Software Science
 Halstead used primitive program parameters:
◦ developed expressions for:
 over all program length,
 potential minimum volume,
 actual volume,
 language level,
 effort,
 development time.
 Halstead's Software Science cont…
 For some given program, let:
◦ 1 be the number of unique operators used in the
program,
◦ 2 be the number of unique operands used in the
program,
◦ N1 be the total number of operators used in the
program,
◦ N2 be the total number of operands used in the
program.
 Halstead's Software Science cont…
 The terms operators and operands have intuitive
meanings,
◦ a precise definition of these terms is needed to avoid
ambiguities.
◦ Unfortunately there is no general agreement among
researchers
 on definition of operators and operands:
 Operators
 Some general guidelines can be provided:
◦ All assignment, arithmetic, and logical operators are
operators.
◦ A pair of parentheses,
 as well as a block begin --- block end pair, are
considered as single operators.
◦ A label is considered to be an operator,
 if it is used as the target of a GOTO statement.
 Operators
 An if ... then ... else ... endif and a
while ... do construct are single operators.
 A sequence (statement termination) operator ';' is a single
operator.
 In function call
◦ Function name is an operator,
◦ I/O parameters are considered as operands.
 Halstead's Software Science cont…
 The set of operators for the ANSI C language:() [] .
, -> * + - ~ ! ++ -- * / % +
- << >> < > <= >= != == & ^
| && || = *= /= %= += -= <<=
>>= &= ^= |= : ? { ; CASE DEFAULT
IF ELSE SWITCH WHILE DO FOR GOTO
CONTINUE BREAK RETURN and a function
name in a function call
Halstead's Software Science cont…
 Operands are those variables and constants
◦ which are being used with operators in expressions.
 Note that variable names appearing in declarations
◦ are not considered as operands.

1
 Examples
 In the expression a = &b;
◦ {a, b} are operands and
◦ { =, &, ;} are operators.

12
 Examples
 The function name in a function definition
◦ not counted as an operator.
◦ int func ( int a, int b )
{ ...
}
 the operators are: {}, ( )
 We do not consider func, a, and b as operands, since
these are part of the function definition.

13
 Examples cont…
 In the function call statement: func ( a, b );
◦ func “,” ( ) and ; are considered as operators.
◦ variables a, b are treated as operands.

14
 Length and Vocabulary
 Length of a program quantifies
◦ total usage of all operators and operands in the program:
◦ Thus, length N=N1+N2.
 Program vocabulary:
◦ number of unique operators and operands used in the
program.
◦ program vocabulary  = 1 + 2 .
 Program Volume
 The length of a program:
◦ total number of operators and operands used in the
code
◦ depends on the choice of the operators and operands,
 i.e. for the same program, the length depends on the
style of programming.
 Program Volume cont …
 We can have highly different measures of length
◦ for essentially the same problem.
 To avoid this kind of problem,
◦ the notion of program volume V is introduced:
◦ V= N log2 
 Potential Minimum Volume
 Intuitively, program volume V denotes
◦ minimum number of bits needed to encode the
program.
 To represent  different identifiers,
◦ we need at least log2  bits ( is the program
vocabulary)
 Potential Minimum Volume cont …
 The potential minimum volume V*:
◦ volume of the most succinct program in which the
program can be coded.
 Potential Minimum Volume cont …
 Minimum volume is obtained :
◦ when the program can be expressed using a single
source code instruction:
 say, a function call like foo( ).

20
 Potential Minimum Volume cont…
 Lower bound on volume:
◦ a program would have at least two operators
◦ and no less than the requisite number of operands (i.e.
input/output data items).
 Potential Minimum Volume cont …
 If an algorithm operates on input/output data d1, d2,... dn,
◦ the most succinct program is f(d1,d2, ...,dn);
◦ for which 1 = 2, 2 =n
 Therefore,V*=(2+ 2) log2(2+ 2)
 Potential Level
 The program level L is given by L=V*/V.
 L is a measure of the level of abstraction:
◦ languages can be ranked into levels that appear
intuitively correct.

2
 Effort and Time
 Effort E=V/L, where
◦ E is the number of mental discriminations required to
write the program
◦ also the effort required to read and understand the
program.
 Effort and Time cont …
 Thus, programming effort E = (V^2) / V*
◦ since L= V*/V varies as the square of the volume.
 Experience shows
◦ E is well correlated to the effort needed for
maintenance.

2
 Effort and Time cont …
 The programmer's time T=E/S,
◦ where S is the speed of mental discriminations developed
from psychological results due to Stroud,
◦ the recommended value for software is 18.

26
 Length Estimation
 Halstead assumed that it is quite unlikely that a program
has several identical parts ---
◦ or substrings of length greater than  ( being the
program vocabulary).

27
 Length Estimation cont …
 In fact, once a piece of code occurs identically in several
places,
◦ it is usually made into a procedure or a function.
 Thus, we can safely assume:
◦ any program of length N consists of N/ unique strings
of length .

28
 Length Estimation cont…
 Now, it is a standard combinatorial result, in which for any
given alphabet of size K,
◦ there are exactly K^r different strings of length r.
 Thus, N/  <=  
 Or, N < =  +1
 Length Estimation cont …
 Since operators and operands usually alternate in a
program,
◦ we can further refine the upper bound into
N < =  (1) 1 (2) 2 .

3
 Length Estimation cont…
 Also, N must include not only the ordered set of N
elements,
◦ but it must also include all possible subsets of that
ordered set, i.e. the power set of N strings.
◦ Therefore, 2N=  (1) 1 (2) 2 .
 Length Estimation cont …
 On solving, we get
 N = log2  + log2 (1122 )
  N=log2 (1122 ) (approx. by ignoring log2 )
  N=log2 (1) 1 + log2 (2) 2
 N=1 log2 1 + 2 log2 2
 Experimental analysis of large number of programs
suggests:
◦ the computed and actual lengths match very closely.

32
 Example
main()
{
int a,b,c,avg;
scanf("%d %d %d",&a,&b,&c);
avg=(a+b+c)/3;
printf("avg= %d",avg);
}

33
 Example:
 The unique operators are:
main, (), {}, int, scanf,&,
",", ";", =, +, /, printf
 The unique operands are:
a,b,c,&a,&b,&c,a+b+c,avg,3,
"%d %d %d", "avg=%d”

34
 Example cont…
 Therefore, 1=12, and 2=11
 So, Estimated Length=(12*log12+11*log11)
=(12*3.58 + 11*3.45) =(43+38)=81
Volume=Length*log(23)=81*4.52=366

35
 Summary
 Discussed Halstead’s software science for estimating
 length
 volume
 effort
 Time
 Worked out some examples using Halstead’s software
science

36
References:
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt.
Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Estimation Techniques cont …
• Staffing Level Estimation
• Putnam’s Model
• Jensen’s Model
 Project duration and staffing
 Like effort estimation, managers must estimate the calendar time
required to complete a project and when staff will be required.
 Calendar time can be estimated using COCOMO 2 formula
 TDEV = 3 * (PM)(0.33+0.2*(B-1.01))
 PM is the effort in person months and B is the exponent
computed (B is 1 for the early prototyping model).
 The time required is independent of the number of people
working on the project.
 Staffing requirements
 Staff required can’t be computed by diving the
development time by the required schedule.
 The number of people working on a project varies
depending on the phase of the project.
 The more people work on the project, the more total
effort is usually required.
 A very rapid build-up of people often correlates with
schedule slippage.
 Staffing Level Estimation
 Number of personnel required during any development
project:
◦ not constant.
 Norden in 1958 analyzed many R&D projects, and observed:
◦ Rayleigh curve represents the number of full-time
personnel required at any time.
 Rayleigh Curve
 Rayleigh curve is specified
by two parameters: Rayleigh Curve
◦ td is the time at which the Effort
curve reaches its maximum
◦ K is the total area under
the curve. td

 L=f(K, td) Time

 Staffing
 Norden was one of the first to investigate staffing pattern:
◦ Considered general research and development (R&D)
type of projects.
 Norden concluded:
◦ Staffing pattern for any R&D project can be
approximated by the Rayleigh distribution curve

Manpower
TD
Time
 Putnam’s Work
 In 1976, Putnam studied the problem of staffing of software
projects:
◦ observed that the level of effort required in software
development efforts has a similar envelope.
◦ found that the Rayleigh-Norden curve
 relates the number of delivered lines of code to effort
and development time.
 Putnam’s Work cont…
 Putnam analyzed a large number of army projects, and
derived the expression:
L=CkK1/3td4/3
◦ K is the effort expended and L is the size in KLOC.
◦ td is the time to develop the software.
◦ Ck is the state of technology constant
 reflects factors that affect programmer productivity.
 Putnam’s Work cont…
 Ck =2 for poor development environment
◦ no methodology, poor documentation, and review, etc.
 Ck =8 for good software development environment
◦ software engineering principles used
 Ck =11 for an excellent environment
 Rayleigh Curve cont …
 Very small number of engineers are needed at the beginning
of a project
◦ carry out planning and specification.
 As the project progresses:
◦ more detailed work is required,
◦ number of engineers slowly increases and reaches a peak.

Manpower
TD
Time
 Rayleigh Curve cont …
 Putnam observed that:
◦ the time at which the Rayleigh curve reaches its maximum
value
 corresponds to system testing and product release.
◦ After system testing,
 the number of project staff falls till product installation
and delivery.
 Rayleigh Curve cont …
 From the Rayleigh curve we may observe that:
◦ approximately 40% of the area under the Rayleigh curve is
to the left of td
◦ and 60% to the right.
 Putnam’s Model

Lines of code: SS
Person years invested: K

Time to develop: td
Technology coefficient: Ck
 Putnam’s Model
Lines of code: S S  C k K 1 / 3t d4 / 3

3
 SS 
Person years invested: K 
 C t 4/3 

 k d 
3/ 4
Time to develop:  SS 
td 
 C K 1/ 3 

 k 
 Putnam’s Work
 Putnam adapted the Rayleigh-Norden curve:
◦ Related the number of delivered lines of code to the
effort and the time required to develop the product.
◦ Studied the effect of schedule compression:
 Effort Applied vs. Delivery Time
 There is a nonlinear relationship between effort applied
and delivery time (Putnam-Norden-Rayleigh Curve)
◦ Effort increases rapidly as the delivery time is reduced
 Effort Applied vs. Delivery Time
Effort
cost
Impossible
region
E theoretical

E optimal
t minimum t theoretical t optimal
Development time
Effect of Schedule Change on Cost
 Using the Putnam's expression for L,
K=L3/ Ck 3td4
Or, K=C1/td4

 For the same product size, C1=L3/ Ck 3 is a constant.

 Or, K1/K2 = td24/td14

Effect of Schedule Change on Cost cont…
 Observe:
◦ A relatively small compression in delivery schedule
 can result in substantial penalty on human effort.
 Also, observe:
◦ benefits can be gained by using fewer people over a
somewhat longer time span.
 Example
 If the estimated development time is 1 year, then in order to
develop the product in 6 months,
◦ the total effort and hence the cost increases 16 times.
◦ In other words,
 The relationship between effort and the chronological
delivery time is highly nonlinear.
 Putnam’s Model
Example:
given SS =100,000
Ck =10,040
td = varies
compute K

td K
1 988 person-month
1.5 195 person-month
2 62 person-month
 Limitations of Putnam’s Model
 Putnam model indicates extreme penalty for schedule
compression
◦ and extreme reward for expanding the schedule.
 Putnam estimation model works reasonably well for very
large systems,
◦ but seriously overestimates the effort for medium and
small systems.
 Effect of Schedule Change on Cost cont…
 Boehm observed:

◦ “There is a limit beyond which the schedule of a

software project cannot be reduced by buying any more
personnel or equipment.”

◦ This limit occurs roughly at 75% of the nominal time

estimate.
 Effect of Schedule Change on Cost cont…
 If a project manager accepts a customer demand to
compress the development time by more than 25%
◦ very unlikely to succeed.
 every project has only a limited amount of parallel
activities
 sequential activities cannot be speeded up by hiring any
number of additional engineers.
 many engineers have to sit idle.
 Jensen Model
 Jensen model is very similar to Putnam model.
◦ attempts to soften the effect of schedule compression on
effort
◦ makes it applicable to smaller and medium sized projects.
 Jensen Model cont …
 Less sensitive to schedule compression than Putnam
 makes it applicable to smaller and medium sized projects.
SS = Cte * td * K1/2
So, K1/K2 = td22/td12
 Cte is the effective technology constant,
 td is the time to develop the software, and
K is the effort needed to develop the software.
 Effect of Schedule Change on Cost
 If the estimated development time is 1 year, then in order
to develop the product in 6 months,
◦ the total effort and hence the cost increases 4 times.
◦ Much less in comparison to Putnam’s model.
 Summary
 Explained Rayleigh Curve.
 Discussed Putnam’s model for staffing level estimation.
 Also discussed Jensen’s model for staffing level estimation.
 Presented the effect of schedule change on the effort / cost.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Scheduling

2
 Sequence of Estimations and Scheduling
Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling
 0.Select
Activity planning is carried out 1. Identify
project scope & objectives
project 2. Identify project
infrastructure

3. Analyse
project
characteristics
in steps 4 & 5

Review 4. Identify products

and activities
Lower
level 5. Estimate effort
detail for activity For each
6. Identify activity activity

risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan
 Introduction to Scheduling
 Scheduling the project tasks is an important project
planning activity.
 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.

5
 Steps for Scheduling
In order to schedule the project activities, a project manager
needs to do the followings:
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.

6
 Steps for Scheduling
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.

7
 Steps for Scheduling cont …
 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.
 A project manager breakdowns the tasks systematically by
using the work breakdown structure (WBS).
8
 Scheduling cont …
 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.
 The task dependencies define a partial ordering relation
among tasks, i.e. each task may precede a subset of other
tasks, but some tasks might not have any precedence
ordering defined between them (called concurrent tasks ).
 The dependency among the activities are represented in the
form of an activity network. 9
 Steps for Scheduling cont …
 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.
 Let us now discuss the work break down structure, activity
network, Gantt and PERT charts.

10
 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.

11
Necessity of breaking 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.
12
 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 as node of a
tree.The root of the tree is labeled by the problem name.
 Each node of the tree is broken down into smaller activities
that are made the children of the node.
 It is not useful to subdivide tasks into units which take less
than a week or two to execute.
◦ Finer subdivisions mean that a large amount of time must be spent on
estimating and chart revision.
13
Work Breakdown Structure - Example
Compiler Project

Requirements Design Code Test Write Manual

Lexer Parser Code Generator

 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.

15
 Breaking down tasks to too coarse levels
versus too fine levels
 Let us investigate the implications of carrying out the decompositions to
very coarse levels versus decomposing to very fine levels.
 When the granularity of the tasks is several months, by the time a
problem (schedule delay) is noticed and corrective actions are initiated, it
may be too late for the project to recover.
 On the other hand, if the tasks are decomposed into very small
granularity (one or two days), then the milestones get too closely spaced.
 This would require frequent monitoring of the project status and entail
frequent revisions to the plan document.
 This becomes a high overhead on the project manager and his
effectiveness in project monitoring and control gets reduced.

16
 Breaking down tasks to too coarse levels
versus too fine levels cont …
 While breaking down an activity into smaller tasks, a manager often has
to make some hard decisions.
 If an activity is broken down into a large number of very small sub-
activities, these can be distributed to a larger number of developers.
 If the task ordering permits that solutions to these can be carried out
independently (parallely), it becomes possible to develop the product
faster (with the help of additional manpower of course!).
 Therefore, to be able to complete a project in the least amount of time,
the manager needs to break large tasks into smaller ones, expecting to
find more parallelism.
 However, it is not useful to subdivide tasks into units which take less than
a week or two to execute. 17
 Scheduling
 Many managers believe
◦ an aggressive schedule motivates the engineers to do a
better and faster job.
◦ However, careful experiments show:
 unrealistic aggressive schedules cause engineers to compromise on
intangible quality aspects,
 also cause schedule delays.

18
 Scheduling cont …
 A good way to achieve accuracy:
◦ let people set their own schedules.
 Schedule for a large-sized task may take too long:
◦ Managers need to break large tasks into smaller ones to
find more parallelism
 can lead to shorter development time.
 Small-sized tasks help in better tracking

19
 Example
 Consider a project for development of a management
information system (MIS).
 The project manager has identified the main development
activities to be
◦ Requirements specification
◦ Design
◦ Code
◦ Test
◦ document

20
WBS of management information system (MIS)
MIS application

Requirements Design Code Test Document

specification

Database Graphical user Database Graphical user

part interface part part interface part
 Activity Planning
Earlier, we looked at methods for forecasting the effort required for
a project. A detailed plan for the project, must also include a
schedule indicating the start and completion times for each activity.
This will enable us to:
 ensure that the appropriate resources will be available precisely when
required;
 avoid different activities competing for the same resources at the same
time;
 produce a detailed schedule showing which staff carry out each activity;
 produce a detailed plan against which actual achievement may be
measured; .
 produce a timed cash flow forecast;
 replan the project during its life to correct drift from the target.
22
 Activity Planning cont …
• To be effective, a plan must be stated as a set of targets, the
achievement or non-achievement of which can be unambiguously
measured.
• The activity plan does this by providing a target start and
completion date for each activity.
• As a project progresses it is unlikely that everything will go
according to plan. Much of the job of project management
concerns recognizing when something has gone wrong, identifying
its causes and revising the plan to mitigate its effects.
• The activity plan should provide a means of evaluating the
consequences or not meeting any of the activity target dates and
guidance as to how the plan might most effectively be modified to
bring the project back to target. 23
 Objectives of Activity Planning
In addition to providing project and resource schedules, activity
planning aims to achieve a number of other objectives such as:
 Feasibility assessment: Is the project possible within required timescales and
resource constraints?
 Resource allocation: What are the most effective ways of allocating resources to
the project.When should the resources be available?
 Detailed costing: How much will be the project cost and when is that expenditure
likely to take place?
 Motivation: Providing targets and being seen to monitor achievement against
targets is an effective way of motivating staff.
 Coordination: When do the staff in different departments need to be available to
work on a particular project and when do staff need to be transferred between
projects?
24
 When to Plan
 Planning is an on-going process of refinement, each iteration
becoming more detailed and more accurate than the last. Over
successive iterations, the emphasis & purpose of planning will shift.
 During the feasibility study and project start-up, the main purpose
of planning will be to estimate timescales and the risks of not
achieving target completion dates or keeping within budget.
 As the project proceeds beyond the feasibility study, the emphasis
will be placed upon the production of activity plans for ensuring
resource availability and cash flow control.
 Throughout the project, until the final deliverable has reached the
customer, monitoring and replanning must continue to correct any
drift that might prevent meeting time or cost targets.
25
 Project Schedules
• Before work commences on a project, the project plan must be
developed to the level of showing dates when each activity should
start & finish and when and how much of each resource will be
required.
• Once the plan has been refined to this level of detail, we call it a
project schedule.
• Creating a project schedule comprises four main stages:
◦ The first step in producing the plan is to decide what activities need to
be carried out and in what order they are to be done. From this we can
construct an ideal activity plan – a plan of when each activity would
ideally be undertaken were resources not a constraint.
◦ The ideal activity plan will then be the subject of an activity risk analysis,
aimed at identifying potential problems. This might suggest alterations
to the ideal activity plan. 26
 Project Schedules cont …
◦ The third step is resource allocation. The expected availability of
resources might place constraints on when certain activities can be
carried out, and our ideal plan might need to be adapted to take
account of this.
◦ The final step is schedule production. Once resources have been
allocated to each activity, we will be in a position to draw up and
publish a project schedule, which indicates planned start and
completion dates and a resource requirements statement for each
activity.

27
 Summary
 Discussed Steps for Scheduling
 Explained Work Breakdown Structure
 Presented Activity Planning
 Discussed about project schedules

28
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project scheduling cont…
 Projects and Activities
 Let us first discuss what do we mean by a project and its
activities.
 We will also discuss some assumptions that will be relevant
when we start to produce an activity plan.

3
 Defining Activities
 A project is composed of a number of interrelated activities.
 A project may start when at least one of its activities is
ready to start.
 A project will be completed when all of the activities it
encompasses have been completed.
 An activity must have a clearly defined start and a clearly
defined end-point, normally marked by the production of a
tangible deliverable.

4
 Defining Activities cont …
 If an activity requires a resource, then that resource
requirement must be forecastable and is assumed to be
required at a constant level throughout the duration of the
activity
 The duration of an activity must be forecastable - assuming
normal circumstances, and the reasonable availability of
resources.
 Some activities might require that others are completed
before they can begin (these are known as precedence
requirements).

5
 Identifying activities
 Essentially there are three approaches to identifying the
activities or tasks that make up a project:
◦ the activity-based approach,
◦ the product-based approach and
◦ the hybrid approach

6
 The activity based approach
 It consists of creating a list of all the activities that the
project is thought to involve.
 This might require a brainstorming session involving the
whole project team or it might stem from an analysis of
similar past projects.
 When listing activities, particularly for a large project, it might
be helpful to subdivide the project into the main life cycle
stages and consider each of these separately.
 Rather than doing this in an ad hoc manner, with the obvious
risks of omitting or double-counting tasks, a much favoured
way of generating a task list is to create a Work Breakdown
Structure (WBS).
7
 The product-based approach
 It consists of producing a Product Breakdown Structure (PBS) and a
Product Flow Diagram (PFD).
 PFD indicates, for each product, which other products are required as
inputs. PFD can be easily transformed into an ordered list of activities by
identifying the transformations that turn some products into others.
 Proponents of this approach claim that it is less likely that a product will be
left out of a PBS than that an activity might be omitted from an
unstructured activity list.
 This approach is suitable when using methodologies such as SSADM or
USDP, which clearly specifies, for each step or task, each of the products
required and the activities required to produce it.
 For example, the SSADM Reference Manual provides a set of generic PBSs
for each stage in SSADM, which can be used as a basis for generating a
project specific PBS. 8
 The product-based approach cont …
 In the USDP, products are referred to as artefacts, and the sequence of
activities needed to create them is called a workflow.
 USDP emphasizes that processes are iterative. This means that it may not
be possible to map a USDP process directly onto a single activity in a
network.

9
10
A structuring of activities for USDP reqmnts capture work flow

11
 The hybrid approach
 The WBS discussed earlier is based entirely on a structuring of
activities.
 Alternatively, and perhaps more commonly, a WBS may be based upon
the project's products as shown in next figure, which is in turn based
on a simple list of final deliverables and, for each deliverable, a set of
activities required to produce that product.
 Next figure illustrates a flat WBS.

12
The hybrid approach

13
 The hybrid approach
 It is likely that, in a project of any size, it would be beneficial to
introduce additional levels – structuring both products and activities.
 The degree to which the structuring is product-based or activity-based
might be influenced by the nature of the project and the particular
development method adopted.
 As with a purely activity-based WBS, having identified the activities, we
are then left with the task of sequencing them.
 A framework dictating the number of levels and the nature of each
level in the structure may be imposed on a WBS. For example, IBM
recommends that the following five levels should be used in a WBS:

14
 The hybrid approach
 Level 1: Project.
 Level 2: Deliverables such as software, manuals and training courses.
 Level 3: Components, which are the key work items needed to produce
deliverables, such as the modules and tests required to produce the
system software.
 Level 4: Work-packages, which are major work items, or collections of
related tasks, required to produce a component.
 Level 5: Tasks, which are tasks that will normally be the responsibility of
a single person.

15
 Network Planning Models or Activity
Networks
 These project scheduling techniques model the project's activities and
their relationships as a network.
 In the network, time flows from left to right. These techniques were
originally developed in the 1950s – the two best known being CPM
(Critical Path Method) and PERT (Program Evaluation Review
Technique).
 Both of these techniques used an activity-on-arrow approach to
visualizing the project as a network where activities are drawn as
arrows joining circles, or nodes, which represent the possible start
and/or completion of an activity or set of activities.
 More recently a variation on these techniques, called precedence
networks, has become popular.
16
 Network Planning Models or Activity
Networks
 This method uses activity-on-node networks where activities are represented
as nodes and the links between nodes represent precedence (or sequencing)
requirements.
 This latter approach avoids some of the problems inherent in the activity-on-
arrow representation and provides more scope for easily representing certain
situations.
 This method is adopted in majority of computer applications currently available.
 These methods are very similar and it must be admitted that many people use
the same name (particularly CPM) indiscriminately to refer to any or all of the
methods.

17
 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)
◦ Activity on Edge (AOE) or Activity on Arrow (AOA)

18
 Activity Networks
 WBS structure can be refined into an activity network
representation:
◦ Network of boxes and arrows
◦ shows different tasks making up a project,
◦ represents the ordering among the tasks.
 It is important to realize that developing WBS and activity
network
◦ requires a thorough understanding of the tasks involved.

19
 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.

20
 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.

21
 Activity networks
 Activity networks were originally represented using activity
on edge (AOE) representation.
 However, later activity on node (AON) has become popular
since this representation is easier to understand and revise.

22
 Example
 Consider MIS development project.
 Suppose the project manager has determined the durations
and dependencies for each task as given in table.

Task number Task Duration Dependent

on Tasks
T1 Specification 15 -
T2 Design database 45 T1
T3 Design GUI 30 T1
T4 Code database 105 T2
T5 Code GUI part 45 T3
T6 Integrate and test 120 T4 and T5
T7 Write user manual 60 T1
23
Activity Network for MIS Design database Code database
45 105
Example

Specification Integrate and Finish

15 test 0
120

Design GUI Code GUI

30 45

Write user manual

60
Activity Network for Compiler Project
Code Lexer

Design Code Parser

Requirements Code Code Generator Test

Write Manual
 Activity Networks cont …
 Managers can estimate the time durations for the different
tasks in several ways.
 One possibility is that they can empirically assign durations to
different tasks.
 This however may not be such a good idea, because software
developers often resent such unilateral decisions.
 However, some managers prefer to estimate the time for
various activities themselves.

26
 Activity Network cont …
 They believe that an aggressive schedule would motivate
the developers to do a better and faster job.
 On the other hand, careful experiments have shown that
unrealistically aggressive schedules not only cause
developers to compromise on intangible quality aspects,
◦ but also cause greater schedule delays compared to the other
approaches.

27
 Activity Networks cont …
 A possible alternative is to let each developer himself
estimate the time for an activity he would be assigned to.
 This approach can help to accurately estimate the task
durations without creating undue schedule pressures.

28
 Gantt Charts
 Named after its developer Henry Gantt.
◦ a form of bar chart:
 each bar represents an activity,
 bars are drawn against a time line,
 length of each bar is proportional to the length of time planned for
the activity.
 Vertical axis lists all the tasks to be performed.
 The bars are drawn along the y-axis, one for each task.


29
 Gantt Charts cont …
 Gantt charts are not specific to software engineering.
 Gantt charts used in software project management are:
◦ enhanced version of standard Gantt charts.
◦ colored (shaded) part of a bar shows the length of time a task is
estimated to take.
◦ white (unshaded) part shows the slack time or lax time,
 the latest time by which a task must be finished.

30
 31
Gantt chart for MIS problem
 Gantt Chart for Compiler Project
Requirements
Design
Code Lexer
Code Parser
Code Code Generator
Test
Write Manual

32
 Gantt Chart cont …
 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
◦ Software

33
 Gantt Chart cont …
 Gantt chart representation of a project schedule is helpful in
planning the utilisation of resources,
◦ while PERT 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.

34
Available Online Tools
 GanttProject
 ProjectLibre

SPM (5e) Step Wise: an introduction to

project planning© The McGraw-Hill
Companies, 2009 35
 Summary
• We have defined activities.
• Discussed the approaches to identify the activities or tasks.
• Discussed the types of Activity Networks
• Explained Gantt Chart.
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth
Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI
Learning Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Scheduling cont…

2
 CPM and PERT Charts
 While Gantt charts show the different tasks and their
durations clearly:
◦ they do not show inter-task dependencies explicitly.
◦ this shortcoming of Gantt charts is overcome by PERT charts.
 CPM & PERT are operation research techniques developed
in the late 1950s.
 Later, these 2 techniques have got merged & many tools
support them as CPM/PERT.

3
 Critical Path Method
 Critical Path Method (CPM) is a technique for:
◦ Identifying critical paths
◦ Managing project.
 The CPM technique is not specific to software engineering
◦ has a much wider use.

4
 Critical Path Method
 CPM can assist in answering questions like:
◦ What are the critical paths in the project?
◦ What is the shortest time in which the project can be completed?
◦ What is the earliest (or latest) time a task can be started (or finished)
without delaying the project?

5
 Critical Path Method (CPM)
 A path in the activity network (graph) is any set of
consecutive nodes and edges 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.

6
 Critical Path Method (CPM)
 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.

7
 Critical Path Method (CPM)
 A critical path:
◦ is a path along which every milestone is critical to meeting the project
deadline.
 A Critical Path is a chain of tasks that determine the
duration of the project.

8
 Critical Path Method (CPM)
 A critical path is a sequence of tasks such that
◦ a delay in any of the tasks will cause a delay to the entire project.
 There can be more than one critical path in a project.
 It is important for the project manager to be aware of the
critical paths in a project:
◦ can ensure that tasks on these paths are completed on time.

9
 Critical Path Method (CPM)
 Other tasks may have some room for delay without affecting
the entire project.
◦ If necessary, the manager may switch resources from a noncritical task
to a critical task.
 Several software packages are available for automating the
scheduling process:
◦ MacProject on Apple Macintosh computer
◦ MS-Project on Microsoft Windows Operating System.

10
 Critical Path Method (CPM)
 CPM is an algorithmic approach to determine the critical
paths and slack times for tasks not in the critical paths.
 It involves calculating the following quantities:
◦ Minimum time (MT)
◦ Earliest start time (ES)
◦ Latest start time (LS)
◦ Earliest finish time (EF)
◦ Latest finish time (LF)
◦ Slack time (ST) (or float time)
11
 Quantities to be calculated in CPM
 Minimum time (MT)
◦ Minimum time required to complete the project.
◦ Computed by determining the maximum of all paths from start node
to finish node.
 Earliest start time (ES)
◦ The time of a task which 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.

12
 Quantities to be calculated in CPM cont…

 Latest start time (LS)

◦ The difference between MT and the maximum of all paths from this
task to the finish.
◦ Computed by subtracting the duration of the subsequent task from
the LS of the subsequent task.

13
 Quantities to be calculated in CPM
 Earliest finish time (EF)
◦ The EF for a task is the sum of the earliest start time of the task and
the duration of the task.
 Latest finish time (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.
◦ Obtained by subtracting maximum of all paths from this task to finish
node from MT.

14
Quantities to be calculated in CPM
 Slack time (ST) (or float time)
◦ Total time that a task may be delayed before it will affect the end time
of the project.
◦ Indicates the flexibility in starting and completion of tasks.
◦ ST for a task is LS-ES and can equivalently be written as LF-EF.

15
 What data do we need to construct a
CPM graph?
 To construct a CPM graph,
◦ A list of tasks and their durations are required.
◦ Also, for each task a list of tasks upon which it depends is required.
◦ A task may depend on more than one task.
 The task details can be given in the form of a table.

16
 How do we work out the various start
and finish times for tasks?
 Minimum time to complete project (MT) = Maximum of all
paths from start to finish
 Earliest start time (ES) of a task = Maximum of all paths from
start to this task
 Earliest finish time (EF) of a task = ES + duration of the task
 Latest finish time (LF) of a task = MT - Maximum of all paths
from this task to finish
 Slack time = LS - ES = LF - EF

17
What are the float time (or slack time) of
tasks?
 Float time (or slack time) is the total time that a task may
be delayed
◦ before it will affect the end time of the project.
 The float times indicate the "flexibility" in starting and
completion of tasks:
 A critical activity is an activity with zero (0) slack or float
time.

18
Example - Activity Network for MIS
Design database Code database
45 105

Specification Integrate and Finish

15 test 0
120

Design GUI Code GUI

30 45

Write user manual

60
 Activity on Node Network
 Activities are represented as nodes (boxes).
 The lines between nodes represent dependencies.

20
 Example: MIS problem
Steps for finding the critical path
 Compute ES and EF for each task
◦ Use the rule: ES is equal to the largest EF of the immediate
predecessors
 Compute LS and LF for each task
◦ Use the rule: LF is equal to the smallest LS of the immediate successors
 Compute ST for each task
◦ Use the rule: ST=LF-EF

21
Project parameters (ES & EF) for MIS problem
Task Duration ES EF
Specification 15 0 15

Design data 45 15 60
base
Design GUI 30 15 45
part
Code data 105 60 165
base
Code GUI 45 45 90
part
Integrate 120 165 285
and test
Write user 60 15 75
manual
22
Project parameters (LS & LF) for MIS problem
Task Duration LS LF
Specification 15 0 15

Design data 45 15 60
base
Design GUI 30 90 120
part
Code data 105 60 165
base
Code GUI 45 120 165
part
Integrate 120 165 285
and test
Write user 60 225 285
manual
23
 Slack Times for MIS problem
Task ES EF LS LF ST
Specification 0 15 0 15 0

Design data 15 60 15 60 0
base
Design GUI 15 45 90 120 75
part
Code data 60 165 60 165 0
base
Code GUI part 45 90 120 165 75

Integrate and 165 285 165 285 0

test
Write user 15 75 225 285 210
manual
24
ES and EF for MIS problem
(ES, EF) (ES, EF)
Design database Code database
(15, 60) (60, 165)

(ES, EF) (ES, EF) (ES, EF)

Specification Integrate and Finish
(0, 15) test (285, 285)
(165, 285)

(ES, EF) (ES, EF)

Design GUI Code GUI
(15, 45) (45, 90)

(ES, EF)
Write user manual
(15, 75)
LS and LF for MIS problem (LS, LF) (LS, LF)
Design database Code database
(15, 60) (60, 165)

(LS, LF) (LS, LF) (LS, LF)

Specification Integrate and Finish
(0, 15) test (285, 285)
(165, 285)

(LS, LF) (LS, LF)

Design GUI Code GUI
(90, 120) (120, 165)

(LS, LF)
Write user manual
(225, 285)
Critical Path for MIS problem (EF, LF) (EF, LF)
Design database Code database
(60, 60) (165, 165)

(EF, LF) (EF, LF) (EF, LF)

Specification Integrate and Finish
(15, 15) test (285, 285)
(285, 285)

(EF, LF) (EF, LF)

Design GUI Code GUI
(45, 120) (90, 165)

(EF, LF)
Write user manual
(75, 285)
Screenshot showing the Activity Network
& CP for MIS Problem using ProjectLibre

28
 Summary
 We have discussed Critical Path Method (CPM).
 Solved an example to find the critical path.

29
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth
Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI
Learning Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Scheduling cont…

2
 Formulating a Network Model
The first stage in creating a network model is to represent the
activities and their interrelationships as a graph". In activity-on-
node, we do this by representing activities as nodes (boxes) in
the graph.The edges between nodes represent dependencies.
Some rules for constructing precedence networks
 A project network should have only one start node
 A project network should have only one end node
 A node has some duration
 Links normally have no duration
 Precedents are the immediate preceding activities
 Time moves from left to right
 A network may not contain loops
 A network should not contain dangles
3
 A project network should have only one start node

 Although it is logically possible to draw a network with

more than one starting node, it is undesirable to do so as it
is a potential source of confusion.
 In such cases (for example, where more than one activity
can start immediately the project starts) it is normal to
invent a 'start' activity which has zero duration but may have
an actual start date.

4
 A project network should have only one end node

 The end node designates the completion of the project and

a project may finish only once! Although it is possible to
draw a network with more than one end node, it will
almost certainly lead to confusion.
 Where the completion of a project depends upon more
than one final activity it is normal to invent a 'finish' activity.

5
 A node has some duration
 A node represents an activity and, in general, activities take
time to execute.
 Notice, however, that the network in the next figure does
not contain any reference to durations.
 This network drawing merely represents the logic of the
project – the rules governing the order in which activities
are to be carried out.

6
The IOE annual maintenance contracts project activity
network fragment with a checkpoint activity added

7
 Links normally have no duration
 Links represent the relationships between activities. Normally, links do
not have any duration.
 In the below figure, installation cannot start until program testing is
complete. Program testing cannot start until both coding and data take-
on have been completed.

Figure: fragment of a precedence network

8
 Precedents are the immediate preceding activities
 In the previous figure, the activity ‘Program test’ cannot start
until both ‘Code' and 'Data take-on' have been completed and
activity 'Instal' cannot start until ‘Program test’ has finished.
 'Code' and 'Data take-on‘ can therefore be said to be
precedents of Program test', and 'Program test' is a precedent
of 'Instal”.
 Note that we do not speak of 'Code' and 'Data take-on' as
precedents of 'Instal' – that relationship is implicit in the
previous statement.

9
 Time moves from left to right
 If at all possible, networks are drawn so that time moves
from left to right.
 It is rare that this convention needs to be flouted but some
people add arrows to the lines to give a stronger visual
indication of the time flow of the project.

10
 A network may not contain loops
 The next figure demonstrates a loop in a network. A loop is
an error in the sense that it represents a situation that
cannot occur in practice.
 While loops, in the sense of iteration, may occur in practice,
they cannot be directly represented in a project network.
 Note that the logic of the figure suggests that program
testing cannot start until the errors have been corrected.

11
A loop represents an impossible sequence

12
 A network may not contain loops cont…
 If we know the number of times we expect to repeat a set of
activities, e.g. a test-diagnose--correct sequence, then we can draw
that set of activities as a straight sequence, repeating it the
appropriate number of times.
 If we do not know how many times a sequence is going to be
repeated then normally we cannot calculate the duration of the
project unless we adopt an alternative strategy.
 Although it is easy to see the loop in this simple network fragment,
very large networks can easily contain complex loops which are
difficult to spot when they are initially constructed. All network
planning applications usually detect loops and generate error
messages when they are found. 13
 A network should not contain dangles
 A dangling activity such as 'Write user manual in the figure
should not exist as it is likely to lead to errors in subsequent
analysis.
 Indeed, in many cases dangling activities indicate errors in logic
when activities are added as an afterthought.
 If, in the figure, we mean to indicate that the project is complete
once the software has been installed and the user manual written,
then we should redraw the network with a final completion
activity - which, at least in this case, is probably a more accurate
representation of what should happen.
 The redrawn network is shown in the next figure.
14
Figure: a dangle

Figure: resolving the dangle 15

 Representing lagged activities
 We might come across situations where we wish to undertake two
activities in parallel so long as there is a lag between the two. We might
wish to document amendments to a program as it is being tested -
particularly if evaluating a prototype. In such a case we could designate
an activity test and document amendments'. This would, however, make
it impossible to show that amendment recording could start, say, one
day after testing had begun and finish a little after the completion of
testing.
 Where activities can occur in parallel with a time lag between them, we
represent the lag with a duration on the linking arrow as shown in the
next figure. This indicates that documenting amendments can start one
day after the start of prototype testing and will be completed two days
after prototype testing is completed.
16
Representing lagged activities

Figure: Activity Network indicating lags

17
 Hammock activities
 Hammock activities are activities which, in themselves, have
zero duration but are assumed to start at the same time as
the first 'hammocked' activity and to end at the same time
as the last one.
 They are normally used for representing overhead costs or
other resources that will be incurred or used at a constant
rate over the duration of a set of activities.

18
 Another way of labeling activities

Earliest start Duration Earliest finish

Activity label, activity description
Latest start Float Latest finish
 Example
Find the critical activities and the critical path for the following example.
Activity Activity Name Duration Precedence
Label (Weeks)
A Hardware Selection 6 ---
B System configuration 4 ---
C Install hardware 3 A
D Data migration 4 B
E Draft office procedures 3 B
F Recruit staff 10 ---
G User training 3 E,F
H Install and test 2 C,D
 Steps
 First Draw Task Network
 Compute ES, EF, LS and LF
 Compute the slack time (float time) for each activity
 Identify the critical activities, i.e. activities for which
slack time is zero.
 Identify the critical path, i.e. the which contains only the
critical activities.
 There may be more than one critical path.

21
 Activity Network
6 wks 3 wks
A. Hardware selection C. Install hardware

4 wks 4 wks 2 wks

Start B. Software config D. Data migration H. Install and test Finish

10 wks 3 wks 3 wks

F. Recruit staff E. Draft office proc G. User training
 Forward Pass
 The forward pass is carried out to calculate the earliest
dates on which each activity may be started and completed.
 Rule:
◦ The earliest start date for an activity is the earliest finish date for the
preceding activity.
◦ Where there is more than one immediately preceding activity we
take the latest of the earliest finish dates for those activities.

23
 After Forward Pass Step 1
0 6 wks 6 3 wks
A. Hardware selection C. Install hardware

0 4 wks 4 4 wks 2 wks

Start B. Software config D. Data migration H. Install and test Finish

0 10 wks 10 3 wks 3 wks

F. Recruit staff E. Draft office proc G. User training

24
 After Forward Pass Step 2
0 6 wks 6 6 3 wks 9
A. Hardware selection C. Install hardware

0 4 wks 4 4 4 wks 8 2 wks

Start B. Software config D. Data migration H. Install and test Finish

0 10 wks 10 4 3 wks 7 3 wks

F. Recruit staff E. Draft office proc G. User training

25
 After Forward Pass Step 3 (Final)
0 6 wks 6 6 3 wks 9
A. Hardware selection C. Install hardware

0 4 wks 4 4 4 wks 8 9 2 wks 11

Start B. Software config D. Data migration H. Install and test Finish

0 10 wks 10 4 3 wks 7 10 3 wks 13

F. Recruit staff E. Draft office proc G. User training

26
 The Backward Pass
 The backward pass is carried out to calculate the latest start
date at which each activity may be started and finished
without delaying the end date of the project.
 Rule
◦ The latest finish date for an activity is the latest start date for the
activity that commences immediately that activity is complete.
◦ Where more than one activity can commence we take the earliest of
the latest start dates for those activities.

27
 After Backward Pass Step 1
0 6 wks 6 6 3 wks 9
A. Hardware selection C. Install hardware

0 4 wks 4 4 4 wks 8 9 2 wks 11

Start B. Software config D. Data migration H. Install and test Finish
11 2 13

0 10 wks 10 4 3 wks 7 10 3 wks 13

F. Recruit staff E. Draft office proc G. User training
10 0 13
After Backward Pass Step 2
0 6 wks 6 6 3 wks 9
A. Hardware selection C. Install hardware
11
8 2 11

0 4 wks 4 4 4 wks 8 9 2 wks 11

Start B. Software config D. Data
11migration H. 13
Install and test Finish
7 3 11 11 2 13

0 10 wks 10 4 3 wks 7 10 3 wks 13

F. Recruit staff E. 10
Draft office proc G. User13
training

7 3 10 10 0 13

29
 After Backward Pass Step 3 (Final)
0 6 wks 6 6 3 wks 9
A. Hardware selection C. Install hardware
8 11
2 2 8 8 2 11

0 4 wks 4 4 4 wks 8 9 2 wks 11

Start B. 7
Software config D. Data11
migration H. 13
Install and test Finish
3 3 7 7 3 11 11 2 13

0 10 wks 10 4 10
3 wks 7 10 313
wks 13
F. Recruit staff E. Draft office proc G. User training
0 0 10 7 3 10 10 0 13

30
 Critical Path
 The critical path is the longest path through the network.
 The difference between an activity’s earliest start date and
its latest start date (or equally, the difference between its
earliest and latest finish dates) is known as activity’s float.
 Any activity with a float of zero is critical in the sense that
◦ any delay in carrying out the activity will delay the completion date of
the project as a whole.

31
 Activity float
 Free float
◦ The time by which an activity may be delayed without affecting any
subsequent activity.
◦ It is calculated as the difference between the earliest completion date
for the activity and the earliest start date of the succeeding activity.
 Interfering float
◦ The difference between total float and free float.
◦ It tells by how much the activity may be delayed without delaying the
project end date,
 even though it will delay the start of some subsequent activities.

32
 Critical Path
0 6 wks 6 6 9
Critical Activities – F, G
3 wks
A. Hardware selection C. Install hardware

2 2 8 8 2 11

0 4 wks 4 4 4 wks 8 9 2 wks 11

Start B. Software config D. Data migration H. Install and test Finish
3 3 7 7 3 11 11 2 13

0 10 wks 10 4 3 wks 7 10 3 wks 13

F. Recruit staff E. Draft office proc G. User training
0 0 10 7 3 10 10 0 13

33
The example shown in ProjectLibre with
duration & predecessors

34
The WBS for the example

35
Gantt chart for the example

36
Activity Network showing the Critical Path
for the example

37
The task usage details for the example

38
 Shortening the Project Duration
 If we wish to shorten the overall duration of a project we
would normally consider attempting to reduce activity
durations. In many cases this can be done by applying more
resources to the task – either working overtime or
procuring additional staff.
 The critical path indicates where we must look to save time -
if we are trying to bring forward the end date of the project,
there is clearly no point in attempting to shorten non-critical
activities.
 For example, in last figure, it can be seen that we could
complete the project in week 12 by reducing the duration of
the critical activity F by one week (i.e. to 9 weeks). 39
Shortening the Project Duration cont…
 As we reduce activity times along the critical path, we must continually
check for any non critical path emerging and redirect our attention
wherever necessary.
 There will come a point when we can no longer safely, or cost-effectively,
reduce the critical activity durations in an attempt to bring forward the
project end date.
 Further savings, if needed, must be sought in a consideration of our work
methods and by questioning the logical sequencing of activities.
 Generally, time savings are to be found by increasing the amount of
parallelism in the network and the removal of bottlenecks.

40
 Summary
 Discussed the rules to construct the activity networks.
 Solved another example on finding the critical activities
and critical path.
 Discussed how to shorten the project duration.

41
References:
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth
Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI
Learning Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Scheduling cont…

2
 Activity on Edge Network
 Activities are represented by links/edges/arrows.
 Nodes represent events of activities (or group of activities)
starting or finishing.

3
 Example
Activity Activity Name Duration Precedence
Label (Weeks)
A Hardware Selection 6 ---

B System configuration 4 ---

C Install hardware 3 A
D Data migration 4 B
E Draft office procedures 3 B
F Recruit staff 10 ---
G User training 3 E,F
H Install and test 2 C,D
Corresponding AOE Network

5
 AOE Rules and Conventions
 A project network may have only one start node.
◦ This is a requirement of activity on edge networks rather than merely
desirable as is the case with activity on node networks.
 A project network may have only one end node.
◦ Again, this is a requirement for activity on edge networks.

6
 AOE Rules and Conventions
 A link has duration
◦ A link represents an activity and in general, activities take time to
execute.
◦ The links are not drawn in any way to represent the activity durations.
◦ The network drawing merely represents the logic of the project
 The rules governing the order in which activities are to be carried out.

7
 AOE Rules and Conventions
 Nodes have no duration
 Nodes are events and are instantaneous points in time.
 The source node is the event of the project becoming ready
to start
 The sink node is the event of the project becoming
completed.
 Intermediate nodes represent two simultaneous events
 The event of all activities leading into a node having been completed
 and the event of all activities leading out of that node being in a position to
be started.
8
 AOE Rules and Conventions
 Node 3 is the event that both coding and data take-on have
been completed and the activity program test is free to start.
 Installation may be started only when event 4 has been
achieved, i.e. as soon as program test has been completed.

9
 AOE Rules and Conventions
 Time moves from left to right.
◦ In AOE networks, time moves from left to right.
 Nodes are numbered sequentially.
◦ There are no precise rules about node numbering but
 nodes should be numbered so that head nodes (those at the arrow end of
an activity) always have a higher number than tail events (those at the non-
arrow end of an activity).
 This convention makes it easy to spot loops.

10
 AOE Rules and Conventions
 A network may not contain loops.
◦ Loops are either an error of logic or a situation that must be resolved
by itemizing iterations of activity groups.
◦ A loop represents an impossible sequence.

11
 AOE Rules and Conventions
 A network may not contain dangles.
◦ A dangling activity cannot exist
 as it would suggest there are two completion points for the project.
 Node 5 represents the true project completion point and
there are no activities dependent on activity Write user
manual.

12
 AOE Rules and Conventions
 Then the network should be redrawn so that activity Write
user manual starts at node 2 and terminates at node 5.
 In practice, we would insert a dummy activity between
nodes 3 and 5.
 In other words, all events, except the first and the last, must
have
◦ at least one activity entering them and
◦ at least one activity leaving them and
◦ all activities must start and end with an event.

13
 Dummy Activity
 When two paths within a network have a common event
although they are, in other respects, independent,
◦ A logical error might occur.

14
 Dummy Activity
 Suppose, it is necessary to specify a piece of hardware
before placing an order for it and before coding the
software.
 Before coding the software, it is also necessary to specify
the appropriate data structures, although clearly we do not
wait for this to be done before the hardware is ordered.

15
 Dummy Activity
 The following figure models the situation.

16
 Dummy Activity
 The network is incorrect
◦ as it requires both hardware specification and data structure design to
be completed before either an order may be placed or software
coding may commence.
 The problem is resolved by
◦ separating the two (more or less) independent paths and introducing
a dummy activity to link the completion of specify hardware to the
start of the activity code software.

17
 Dummy Activity
 This effectively breaks the link between data structure
design and placing the order.

18
 Dummy Activity
 Dummy activities, shown as dotted lines on the network
diagram, have a zero duration and use no resources.
 They are often used to aid in the layout of network
drawings.

19
 Dummy Activity
 The use of a dummy activity where two activities share the
same start and end nodes makes it easier to distinguish the
activity end points.
 These problems do not occur with activity on node (AON)
network.

20
 Representing lagged activities
 Activity on edge networks are less elegant when it comes to
representing lagged parallel activities.
 We need to represent these with pairs of dummy activities as
shown below.

 Where the activities are lagged because a stage in one

activity must be completed before the other may proceed, it
is likely to be better to show each stage as a separate activity.
21
 Activity labeling
 There are a number of conventions that have been adopted
for entering information on an activity on edge network.
 Typically, the diagram is used to record information about
the events rather than the activities
◦ Activity based information (other than labels or description) is
generally held on a separate activity table.

22
 Activity labeling
 One of the more common conventions for labeling nodes is
◦ to divide the node circle into quadrants and
◦ use those quadrants to show
 the event number,
 the latest and
 earliest dates by which the event should occur, and
 the event slack.

Event
number
Earliest Latest
date date
Slack 23
 Network Analysis
 Analysis proceeds in the same way as with activity on node
networks, although the discussion places emphasis on the
events rather than activity start and completion time.

24
 Example
Activity Activity Name Duration Precedents
Label (Weeks)
A Hardware Selection 6 ---

B System configuration 4 ---

C Install hardware 3 A
D Data migration 4 B
E Draft office procedures 3 B
F Recruit staff 10 ---
G User training 3 E,F
H Install and test 2 C,D
 Forward Pass
 The earliest start date for an event is
◦ the earliest finish date for all the activities terminating at that event.
 Where more than one activity terminates at a common
event
◦ we take the latest of the earliest finish dates for those activities.

26
Forward Pass

27
 Forward Pass
Activity Duration Earliest Latest Earliest Latest Total float
(weeks) start date start finish date finish
date date

A 6 0 6
B 4 0 4
C 3 6 9
D 4 4 8
E 3 4 7
F 10 0 10
G 3 10 13
H 2 9 11
28
 Backward Pass
 The latest finish date for an event is the latest start date for
all the activities that may commence from that event.
 Where more than one activity commences at a common
event we take the earliest of the latest start dates for those
activities.

29
Backward Pass

30
 Backward Pass
Activity Duration Earliest Latest Earliest Latest Slack
(weeks) start date start finish date finish Time
date date

A 6 0 2 6 8 2
B 4 0 3 4 7 3
C 3 6 8 9 11 2
D 4 4 7 8 11 3
E 3 4 7 7 10 3
F 10 0 0 10 10 0
G 3 10 10 13 13 0
H 2 9 11 11 13 2
31
 Identifying the critical path
 Critical activities are activities with 0 slack time (F & G).
Critical path is the path joining all nodes with a 0 slack time.
 Here, CP is through nodes 1-5-6. The critical path is the
longest path in the network.

32
 Example
 A project involves three tasks:
◦ task a takes 4 hours,
◦ task b takes 5 hours
◦ task c takes 8 hours.
◦ task c cannot commence until task a is completed.
 What is the shortest time in which the project can be
completed?
1
start b=5 finish

a=4 2 c=8 3
33
 Example
 Clearly, the project continues until task a and then task c
complete:
◦ which is 12 hours.
◦ Task b takes only 5 hours.
◦ Task b can have 7 hours of leeway to start and finish.

1
start b=5 finish

a=4 2 c=8 3
34
 CPM
 CPM can be used to determine the minimum estimated
duration of a project and the slack times associated with
various non-critical tasks.
 Thus, any path whose duration equals MT is a critical path.
 There can be more than one critical path for a project.
 Tasks which fall on the critical path should receive special
attention by both project manager and the personnel
assigned to perform those tasks.

35
 CPM
 One way is to draw the critical paths with a double line
instead of a single line or the path may be coloured.
 The critical path may change as the project progresses.
 This may happen when tasks are completed either behind
or ahead of schedule.

36
 Summary
 We have discussed Activity-On-Edge Network.
 The rules for constructing Activity-On-Edge Network.
 Solved some examples for finding the critical path in
Activity-On-Edge Networks.

37
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth
Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Scheduling cont…

2
 What is PERT and how does it work?
 PERT (Program Evaluation and Review Technique) is a
variation of CPM:
◦ incorporates uncertainty about duration of tasks.
 Gantt charts can be derived automatically from PERT charts.
 Gantt chart representation of schedule is helpful in planning
the utilization of resources,
◦ while PERT chart is more useful for monitoring the timely progress of
activities.

3
Program Evaluation and Review Technique (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. 4
Program Evaluation and Review Technique (PERT)
 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.

5
 Program Evaluation and Review Technique (PERT)

 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 milestones,
including the final milestone.

6
 Program Evaluation and Review Technique (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.

7
 Program Evaluation and Review Technique
(PERT)
 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.

8
 Program Evaluation and Review Technique
(PERT)
 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.

9
 Program Evaluation and Review Technique
(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 three estimates are used to compute the expected
value of the standard deviation.

10
 Program Evaluation and Review Technique
(PERT)
 The entire distribution lies between the interval (M-3*ST)
and (M+3*ST),
◦ where ST is the standard deviation.
 Thus, the standard deviation for a task is ST=(W-O)/6.
 The mean estimated time ET=(O+4M+W)/6.

11
 Program Evaluation and Review Technique
(PERT)
 Since all possible completion times between the minimum
and maximum duration for every task has to be considered
◦ there can be many critical paths,
 depending on the various permutations of the estimates for each task.
 This makes critical path analysis in PERT charts very
complex.

12
 Program Evaluation and Review Technique (PERT)

Design database Code database

40, 45, 60 95, 105, 120

Specification Integrate Finish

12, 15, 20 and test 0
100, 120,
140

Design GUI Code GUI

24, 30, 38 38, 45, 52

Write user manual

50, 60, 70

13
 PERT
 PERT was developed to take account of the uncertainty
surrounding estimates of task durations.
 It was developed in an environment of expensive, high risk
and state-of-the-art projects
◦ Not that dissimilar to many of today’s large software projects.

14
 Estimates in PERT
 Most likely time
◦ The time we would expect the task to take under normal
circumstances.
◦ We shall identify this by the letter m or M.
 Optimistic time
◦ The shortest time in which we could expect to complete the activity,
barring outright miracles.
◦ We shall use the letter a or O, for this.
 Pessimistic time
◦ The worst possible time, allowing for all reasonable eventualities but
excluding ‘acts of God and warfare’.
◦ We shall call this b or P. 15
 Estimates in PERT
 PERT then combines these three estimates to form a single
expected duration, te or ET, using the formula
te= (a+4m+b)/6 (te, a, m & b correspond to ET, O, M & P respectively).
 The expected durations are used to carry out a forward
pass through a network, using the same method as the CPM
technique.
 In this case, however, the calculated event dates are not the
earliest possible dates but the dates by which we expect to
achieve those events.

16
PERT event labelling convention
Event Target
number date
Expected Standard
date Deviation
 Activity standard deviations
 A quantitative measure of the degree of uncertainty of an
activity duration estimate may be obtained by calculating the
standard deviation s of an activity time using the formula
◦ s=(b-a)/6
 The activity standard deviation is proportional to the
difference between the optimistic and pessimistic estimates,
and can be used as a ranking measure of the degree of
uncertainty of risk for each activity.

18
 Example
Activity Activity Name
Label
A Hardware Selection

B System configuration

C Install hardware

D Data migration

E Draft office procedures

F Recruit staff

G User training

H Install and test

 Example cont…
Activity Optimistic Activity duration (weeks), Pessimistic Precedents
Label (a) Most Likely (m) (b)
A 5 6 8 ---

B 3 4 5 ---

C 2 3 3 A
D 3.5 4 5 B
E 1 3 4 B
F 8 10 15 ---
G 2 3 4 E,F
H 2 2 2.5 C,D
 Expected Time Estimates (te)
Activity duration (weeks)
Activity Optimistic Most Likely Pessimistic Expected
(a) (m) (b) te=(a+4m+b)/6
A 5 6 8 (5+4*6+8)/6= 6.17
B 3 4 5 (3+4*4+5)/6= 4
C 2 3 3 (2+4*3+3)/6= 2.83
D 3.5 4 5 (3.5+4*4+5)/6= 4.08
E 1 3 4 (1+4*3+4)/6= 2.83
F 8 10 15 (8+4*10+15)/6= 10.5
G 2 3 4 (2+4*3+4)/6= 3
H 2 2 2.5 (2+4*2+2.5)/6= 2.08
21
 Activity Deviation (s)
Activity Optimistic (a) Pessimistic (b) Standard deviation
s=(b-a)/6
A 5 8 (8-5)/6= 0.5
B 3 5 (5-3)/6= 0.33
C 2 3 (3-2)/6= 0.17
D 3.5 5 (5-3.5)/6= 0.25
E 1 4 (4-1)/6= 0.5
F 8 15 (15-8)/6= 1.17
G 2 4 (4-2)/6= 0.33
H 2 2.5 (2.5-2)/6= 0.08
22
 Expected Time Estimates (te) & SD (s)
Activity duration (weeks)
Acti Optimis Most Pessimis Expected Standard
vity tic (a) Likely (m) tic (b) Time (te) Deviation (s)

A 5 6 8 6.17 (8-5)/6= 0.5

B 3 4 5 4 (5-3)/6= 0.33
C 2 3 3 2.83 (3-2)/6= 0.17
D 3.5 4 5 4.08 (5-3.5)/6= 0.25
E 1 3 4 2.83 (4-1)/6= 0.5
F 8 10 15 10.5 (15-8)/6= 1.17
G 2 3 4 3 (4-2)/6= 0.33
H 2 2 2.5 2.08 (2.5-2)/6= 0.08
23
 Example
 In the following PERT network, we expect the project to take
13.5 weeks.
 The network is obtained after forward pass.

24
The likelihood of meeting targets
 The main advantage of the PERT technique is that
◦ it provides a method for estimating the probability of meeting or
missing target dates.
 There might be only a single target date, the project
completion,
◦ but we might wish to set additional intermediate targets.

25
 The likelihood of meeting targets
 Suppose that we must complete the project within 15 weeks
at the outside.
 We expect it will take 13.5 weeks but it could take more or
perhaps less.
 In addition, suppose
◦ that activity C must be completed by week 10,
 as it is to be carried out by a member of staff who is scheduled to be
working on another project, and
◦ that event 5 represents the delivery of intermediate products to the
customer,
 which must take place by week 10.
26
 The likelihood of meeting targets
 These three target dates are shown on the PERT network
below.

27
 The likelihood of meeting targets
 The PERT technique uses the following three-step method
for calculating the probability of meeting or missing a target
date:
◦ Calculate the standard deviation of each project event.
◦ Calculate the z value for each event that has a target date.
◦ Convert z values to probabilities.

28
 Calculating the standard deviation of each
project event
 Standard deviations for the project events can be calculated
by carrying out a forward pass using the activity standard
deviations.
 To add two standard deviations
◦ Add their squares and then find the square root of the sum.
 One practical outcome of this is that
◦ the contingency time to be allocated to a sequence of activities as a
whole would be less than the sum of the contingency allowances for
each of the component activities.

29
 Event Standard Deviation
Event Event Standard Deviation

1 0
2 √(0.5)2=0.5
3 √(0.33)2=0.33
4 max{√{(0.33)2+(0.25)2}, √{(0.5)2+(0.17)2}} =max{√{0.1089+0.0625},
√{0.25+0.0289}} =max{√0.1714, √0.2789} =max{0.41, 0.53} =0.53

5 max{√(1.17)2, √{(0.33)2+(0.5)2}} =max{1.17, √{0.1089+0.25}} =max{1.17,

√0.3589} =max{1.17, 0.6} =1.17

6 max{√{(0.53)2+(0.08)2}, √{(1.17)2+(0.33)2}} =max{√{0.2809+0.0064},

√{1.3689+0.1089}} =max{√0.2873, √1.4778} =max{0.54, 1.22} =1.22
30
 Calculating the z values
 The z value is calculated for each node that has a target
date.
 It is equivalent to the number of standard deviations
between the node’s expected and target dates.
 It is calculated using the formula
◦ z=(T-te)/s
 where te is the expected date and T the target date.

31
 z Values for different events
 Event 4
◦ Target date is 10
◦ z=(T-te)/s=(10-9)/0.53=1/0.53=1.89
 Event 5
◦ Target date is 10.
◦ z=(T-te)/s=(10-10.5)/1.17= - 0.5/1.17= - 0.43
 Event 6
◦ Target date is 15
◦ z=(T-te)/s=(15-13.5)/1.22=1.5/1.22=1.23
32
 Converting z values to probabilities
 A z value may be converted to the probability of not
meeting the target date by using the shown graph.
 This graph is the equivalent of tables of z values, also known
as standard deviation, which may be found in most statistics
textbooks.

33
Converting z values to probabilities

34
 Probabilities
 Event 4
◦ Φ(1.89)=0.97
◦ So, there is a probability of 97% risk of meeting the target date.
◦ Or, there is a probability of 3% risk of not meeting the target date.
 Event 5
◦ Φ(-0.43)=1-Φ(0.43)=1-0.67=0.33
◦ There is a probability of 33% risk of meeting the target date.
◦ There is a probability of 67% risk of not meeting the target date.

35
 Probabilities
 Event 6
◦ Φ(1.23)=0.89
◦ There is a probability of 89% risk of meeting the target date.
◦ There is a probability of 11% risk of not meeting the target date.

36
 Assignment
 What is the probability of completing the project by
week 14?

37
Normal Table

38
 Advantages of PERT
 PERT focuses attention on the uncertainty of forecasting
◦ By requesting multi-valued activity duration estimates and calculating
expected dates.
 The technique can be used to
◦ calculate the standard deviation for each task and
◦ rank them according to their degree of risk.

39
 Advantages of PERT
 Using this ranking, it can be seen that, for example, that
◦ activity F is the one regarding which we have greatest uncertainty,
whereas
◦ activity C should , in principle, give us relatively little cause for
concern.

40
 Advantages of PERT

 If we use the expected times and standard deviations for

forward passes through the network,
◦ we can, for any event or activity completion,
 estimate the probability of meeting any set target.
 In particular, by setting target dates along the critical path,
◦ we can focus on those activities posing the greatest risk to the
project’s schedule.

41
 Summary
 We have discussed PERT.
 Solved some examples on PERT.

42
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
3. Kanti Swarup, P. K. Gupta, Man Mohan, Operations Research, Nineteenth
Edition, Sultan Chand and Sons, 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
More Examples on CPM / PERT
Algorithm for Critical Path Method (CPM)
1. List all the jobs and then draw network diagram. Each job is
indicated by an arrow with the direction of the arrow showing
the sequence of jobs. The length of the arrows has no
significance. Place the jobs on the diagram one by one keeping
in mind that what precedes and follows each job as well as
what job can be done simultaneously.
2. Consider the job’s time can be deterministic. Indicate them
above the arrow representing the task.
3. Calculate ES, EF, LS and LF.
 Algorithm for CPM cont …
4. Tabulate various times, i.e., activity normal times, earliest
and latest times, and mark them on the arrow of the
diagram.
5. Determine the total float (slack) for each activity by taking
difference between LS and ES or LF and EF.
6. Identify the critical activities and connect them with the
beginning node and the ending node in the network
diagram by double line arrows or colour arrows. This gives
the critical path.
7. Calculate the total project duration.
 Example - CPM
A project consists of a series of tasks labelled A, B,...., H, I with
the following relationships (W < X ,Y means X and Y cannot
start until W is completed ;X, Y < W means W cannot start
until both X and Y are completed). With these notations,
construct the network diagram having the following
constraints:
A < D, E ; B, D < F ; C < G ; B, G < H; F, G < I.
 Find also the minimum time completion of the project, when
the time (in days) of completion of each task is as follows:
 Activity Network

Figure 1: Resulting Activity Network

Calculation table
 Critical path
Critical events: (1,3), (3,4), (4,6), (6,7)
Critical tasks: A, D, F, I, Critical Path–Shown as double arrows
Total duration: 67 days

Figure 2: Resulting network with critical path

 PERT Algorithm
1. Make a list of activities that make up the project including
immediate predecessors.
2. Making use of step 1 sketch the required network.
3. Denote the most likely time by m the optimistic time by a
and pessimistic time by b .
4. Using beta distribution for the activity duration, the
expected time 𝐭 𝐞 , for each activity is computed by using
the formula
𝐭 𝐞 = (a + 4m + b )/6 ()
5. Tabulate various times, i.e., expected activity times, earliest
and latest times and mark the ES and LF on the arrow
diagram. 9
 PERT Algorithm cont…
6. Determine the total float for each activity by taking the
difference between EF and LF .
7. Identify the critical activities and connect them with the
beginning node and the ending node, in the network
diagram by double line arrows. This gives the critical path
and the expected date of completion of the project.
8. Using the values of b and a , compute the variance (σ2) of
each activity’s time estimates by using the formula:

σ2 = ( b − a )2
6

10
 PERT Algorithm cont…
9. Compute the standard normal deviate:
DueDate − ExpectedDateOfCompletion
z0 =
√Variance

• Use standard normal tables to find the probability

P(z ≤ z0) of completing the project within the scheduled
time, where z ∼ N(0, 1).

11
 Example - PERT
A small project is composed of seven activities whose time
estimates are listed in the table as follows.
 Example - PERT cont…
 Draw the project network.
 Find the expected duration and variance of each activity. Calculate early and late
occurrence times for each event. What is the expected project length?
 Calculate the variance and standard deviation of project length. What is the
probability that the project will be completed:
a. at least 4 weeks earlier than expected?
b. no more than 4 weeks later than expected?
 If the project due date is 19 weeks, what is the probability of meeting the due date?
Given
z 0.50 0.67 1.00 1.33 2.00
p 0.3085 0.2514 0.1587 0.0918 0.0228
Resultant network
 Solution
The expected time and variance of each activity is computed in t h e table
shown below.
Activity (i –j) a m b te = a+4m+b
6 ( b−a
6
)2
1–2 1 1 7 2 1

1–3 1 4 7 4 1

1–4 2 2 8 3 1

2–5 1 1 1 1 0

3–5 2 5 14 6 4

4–6 2 5 8 5 1

5–6 3 6 15 7 4
 Solution cont…
 Earliest expected times E {µi } for each event is obtained by taking the
sum of expected times for all the activities leading to an event i .
 When more than one activity leads to event i , the greatest of E {µi } is
chosen.
Thus,
 E {µ1} = 0.
 E {µ2} = 0 + 2 = 2.
 E {µ3} = 0 + 4 = 4.
 E {µ4} = 0 + 3 = 3.
 E {µ5} = max.{4 + 6, 2 + 1} = 10.
 E {µ6} = max.{10 + 7, 3 + 5} = 17.
 Solution cont…
• For the latest expected times we start with E {µi } for the last event
and move backwards, subtracting ” 𝐭 𝐞 ” for each activity link.
Thus,
• E {L6} = 17.
• E {L5} = 17 − 7 = 10.
• E {L4} = 17 − 5 = 12.
• E {L3} = 10 − 6 = 4.
• E {L2} = 10 − 1 = 9.
• E {L1} = min.{9 − 2, 4 − 4, 12 − 3} = 0.
 Solution cont…
 Resultant network
 The critical path is shown by thick line arrows.
 Solution cont…
 Critical path: 1→3→5→6.
 Other paths: 1→2→5→6 and 1→4→6.
 The expected duration of the project is 17 weeks.
 Variance of the project length is given by σ2 = 1 + 4 + 4 = 9.
The standard normal deviate is:

DueDate − ExpectedDateOfCompletion
z0 =
√
Variance
 Solution cont…
(a) at least 4 weeks earlier than expected?

z= 13 − 17 = −4 = −1.33
3 3
Now,
P(z ≤ −1.33) = 0.5−Φ(1.33) = 0.5−0.4082 = 0.0918 ≡ 9.18%
See normal table
Or in next slide

P(z ≤ −1.33) = Φ(−1.33) = 1−Φ(1.33) = 1−0.9082 = 0.0918 ≡ 9.18%

Interpretation: If the project is performed 100 times under the same
conditions, there will be 9 occasions when this job will be completed 4
weeks earlier than expected.
Normal Table

21
 Solution cont…
(b) no more than 4 weeks later than expected?

21−17 4
z = = = 1.33
3 3

The probability of meeting the due date (4 weeks later than

expected) is
P(z ≤ 1.33) = Φ(1.33) = 0.9082 ≡ 90.82%
 Solution cont…

When the due date is 19 weeks

19−17 2
z = = = 0.67
3 3

The probability of meeting the due date is

P(z ≤ 0.67) = Φ(0.67) = 0.7486 ≡ 74.86%

Thus, the probability of not meeting the due date is 1-0.7486, i.e., 0.2514
or 25.14%.
 Summary
 Discussed the algorithm for CPM.
 Discussed the algorithm for PERT.
 Solved some more problems on CPM and PERT.
 References :
1. Kanti Swarup, P. K. Gupta, Man Mohan, Operations Research, Nineteenth Edition,
Sultan Chand and Sons, 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Risk management
 Introduction
 Suppose, three experienced programmers were available for the coding of
modules A, B, C and D of a project. However, two developers left for
better-paid jobs, and so far only one replacement has been recruited, who
happens to be a trainee. What to do?
 In another project - payroll implementation project, imagine that a payroll
package has been purchased. However, a new requirement emerges that
the payroll database should be accessed by a new application that
calculates the staff costs for each course delivered by the college.
Unfortunately, the purchased payroll application does not allow this access.
What to do?
 Introduction
 In this chapter we consider whether the two project leaders
could have foreseen that these problems were likely to
occur and made plans to deal with them.
 In other words, could these problems have been identified as
risks?
 Risk
 PM-BOK (Project Management Body of Knowledge) defines
risk as 'an uncertain event or condition that, if it occurs, has a
positive or negative effect on a project's objectives'.
 PRINCE2, the UK government sponsored project
management standard, defines risk as “the chance of
exposure to the adverse consequences of future events".
 The two definitions differ, as the first includes situations
where a future uncertainty actually works in our favour and
presents us with an opportunity.
 Risk
 The key elements of a risk are as follows:
◦ It relates to the future: Future is uncertain. Some things which seem
obvious when a project is over, might not have been so obvious during
planning, e.g. the costs were underestimated or a new technology was
overly difficult to use, etc.
◦ It involves cause and effect: For example, a ‘cost over-run' might be
identified as a risk, but ‘cost over-run' describes some damage, but does
not say what causes it. Example: an inaccurate estimate of effort, the
use of untrained staff, or a poor specification etc. Both the cause (or
hazard), such as inexperienced staff', and a particular type of negative
outcome, such as “lower productivity', should be defined for each risk.
 Most of the techniques used to assure the quality of
software, such as reviews and testing, are designed to reduce
the risk of faults in project deliverables.
 The key role of risk management is considering uncertainty
remaining after a plan has been formulated. Every plan is
based on assumptions and risk management tries to plan for
and control the situations where those assumptions become
incorrect.
 0.Select
Risk planning is carried out in 1. Identify
project scope & objectives
project 2. Identify project
infrastructure

3. Analyze
project
characteristics
Steps 3 & 6

Review 4. Identify products

and activities
Lower
level 5. Estimate effort
detail for activity
For each
activity
6. Identify activity
risks
10. Lower level
7. Allocate
planning
resources

8. Review/ publicize
9. Execute plan plan
Categories of Risk
• Risks: Two types
 Project Risk: related to threats to successful project
execution.
 Business Risk: related to factors threatening the
benefits of the delivered project.
In business case, main focus is on Business Risk.
Categories of Risk
 An ICT project manager is normally given the objective of
installing the required application by a specified deadline and
within an agreed budget. Other objectives might be set,
especially with regard to quality requirements.
 Project risks are those that could prevent the achievement of
the objectives given to the project manager and the project
team.
Categories of Risk
 There could be risks that an application after successful
implementation is a business failure, e.g. if an e-commerce site is
established to sell a product, the site might be correctly
implemented, but customers fail to use the site because of the
uncompetitive prices demanded.
 Dealing with these business risks is likely to be outside the direct
responsibilities of the application implementation team.
 However, the failure to meet any project objective could have a
negative impact on the business case for the project. For example,
an increase in development cost might mean that the income (or
savings) generated by the delivered application no longer
represents a good return on the increased investment.
Categories of Risk
 Risks have been categorized in other ways. Kalle Lyytinen and his
colleagues, for instance, have proposed a sociotechnical model of
risk, a diagrammatic representation of which appears in next figure.
 Actors refers to all the people involved in the development of the
application in question. A typical risk in this area is that high staff
turnover leads to expertise of value to the project being lost.
 Technology encompasses both the technology used to
implement the application and that embedded in the delivered
products. Risks here could relate to the appropriateness of the
technologies and to possible faults within them, especially if they
are novel.
Lyytinen-Mathiassen-Ropponen risk
framework
 Structure describes the management structures and systems, including
those affecting planning and control. For example, the implementation
might need user participation in some tasks, but the responsibility for
managing the users' contribution might not be clearly allocated.
 Tasks relate to the work planned. For instance, the complexity of the
work might lead to delays because of the additional time required to
integrate the large number of components.
 In the figure, all boxes are interlinked, e.g. risks often arise from the
relationships between actors and technology. If a development technology
is novel then the developers might not be experienced in its use and
delay results. The novelty of the new technology is really a characteristic
of the developers: once they are used to the technology, it is no longer
‘novel'.
Risk Management Approaches
 Risk management approaches can broadly be classified into
reactive and proactive approaches. The latter Approach is
much more effective in risk handling and, therefore, used
wherever possible.
Reactive approaches
 Reactive approaches take no action until an unfavourable
event occurs.
 Once an unfavourable event occurs, these approaches try to
contain the adverse effects associated with the risk and take
steps to prevent future occurrence of the same risk events.
 An example of such a risk management strategy can be the
Following.
Example of reactive approach
 Consider a project in which the server hosting the project
data crashes. Once this risk event has occurred, the team
members may put best effort to recover the data and also
initiate the practice of taking regular backups, so that in
future such a risk event does not recur.
 It is similar to calling the emergency fire-fighting service once
a fire has been noticed, & then installing fire-fighting
equipment in all the rooms of the building to be able to
instantly handle fire the next time it is noticed.
 It can be seen that the main objective of this is to minimize
the damage due to the risk and take steps to prevent future
recurrence of the risk.
Proactive approaches
 The proactive approaches try to anticipate the possible risks that the
project is susceptible to. After identifying the possible risks, actions are
taken to eliminate the risks. If a risk cannot be avoided, these approaches
suggest making plans to contain the effect of the risk.
 For example, if man power turnover is anticipated (i.e. some personnel
may leave the project), then thorough documentation may be planned.
Also, more than one developer many work on a work item and also some
stand-by man power may be planned.
 Obviously, proactive approaches incur lower cost and time overruns
when risk events occur and, therefore, are much more preferred by
teams. However, when some risks cannot be anticipated, a reactive
approach is usually followed.
A Framework for Dealing with Risk
Planning for risk includes these steps:
(i) Risk identification
(ii) Risk analysis and prioritization
(iii) Risk planning
(iv) Risk monitoring
A Framework for Dealing with Risk
• Steps (i) to (iii) will probably be repeated.
• When risks that could prevent a project success are
identified, plans can be made to reduce or remove their
threat.
• The plans are then reassessed to ensure that the original
risks are reduced sufficiently and no new risks inadvertently
introduced.
Example
• Consider the risk that staff inexperience with a new
technology could lead to delays in software development.
• To reduce this risk, consultants who are expert in the new
technology might be recruited.
• However, the use of consultants might introduce the new risk
that knowledge about the new technology is not transferred
to the permanent staff, making subsequent software
maintenance problematic.
• Having identified this new risk, further risk reduction
activities can be planned.
Risk Identification
There are two main approaches to the identification of risks:

 use of checklists
 brainstorming
Checklists
 Checklists are simply lists of the risks that have been found
to occur regularly in software development projects.
 A specialized list of software development risks by Barry
Boehm appears in the next table in a modified version.
 Ideally a group of representative project stakeholders
examines a checklist identifying risks applicable to their
project.
 Often the checklist suggests potential countermeasures for
each risk.
Software project risks and strategies of Risk reduction
Risk Risk reduction techniques

Staffing with top talent; job matching;

Personnel shortfalls teambuilding; training and career development;
early scheduling of key personnel

Multiple estimation techniques; design to cost;

Unrealistic time and cost
incremental development; recording and analysis
estimates
of past projects; standardization of methods

Improved software evaluation; formal

Developing the wrong software
specification methods; user surveys; prototyping;
functions
early user manuals
Developing the wrong user
Prototyping; task analysis; user involvement
interface
Software project risks and strategies of Risk reduction cont..
Risk Risk reduction techniques
Requirements scrubbing, prototyping, design
Gold plating
to cost
Late changes to requirements Change control, incremental development
Benchmarking, inspections, formal
Shortfalls in externally supplied
specifications, contractual agreements, quality
components
controls
Shortfalls in externally performed Quality assurance procedures, competitive
tasks design etc
Real time performance problems Simulation, prototyping, tuning
Development technically too Technical analysis, cost-benefit analysis,
difficult prototyping , training
Checklists
 Project management methodologies, such as PRINCE2, often
recommend that on completion of a project a review
identifies any problems during the project and the steps that
were (or should have been) taken to resolve or avoid them.
 In some cases, these problems could be added to an
organizational risk checklist for use with new projects.
Brainstorming
 Ideally, representatives of the main stakeholders should be
brought together once some kind of preliminary plan has
been drafted.
 Then, they identify, the problems that might occur, using their
individual knowledge of different parts of the project.
 Summary
 Discussed categories of risks.

 Discussed risk management approaches.

 Presented a Framework for Dealing with Risk.

◦ Explained the first step, i.e. Risk Identification.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Risk management cont…
A Framework for Dealing with Risk
Planning for risk includes these steps:
(i) Risk identification
(ii) Risk analysis and prioritization
(iii) Risk planning
(iv) Risk monitoring
A Framework for Dealing with Risk
• Steps (i) to (iii) will probably be repeated.
• When risks that could prevent a project success are
identified, plans can be made to reduce or remove their
threat.
• The plans are then reassessed to ensure that the original
risks are reduced sufficiently and no new risks inadvertently
introduced.
Example
• Consider the risk that staff inexperience with a new
technology could lead to delays in software development.
• To reduce this risk, consultants who are expert in the new
technology might be recruited.
• However, the use of consultants might introduce the new risk
that knowledge about the new technology is not transferred
to the permanent staff, making subsequent software
maintenance problematic.
• Having identified this new risk, further risk reduction
activities can be planned.
Risk Identification
There are two main approaches to the identification of risks:

 use of checklists
 brainstorming
Checklists
 Checklists are simply lists of the risks that have been found
to occur regularly in software development projects.
 A specialized list of software development risks by Barry
Boehm appears in the next table in a modified version.
 Ideally a group of representative project stakeholders
examines a checklist identifying risks applicable to their
project.
 Often the checklist suggests potential countermeasures for
each risk.
Software project risks and strategies of Risk reduction
Risk Risk reduction techniques

Staffing with top talent; job matching;

Personnel shortfalls teambuilding; training and career development;
early scheduling of key personnel

Multiple estimation techniques; design to cost;

Unrealistic time and cost
incremental development; recording and analysis
estimates
of past projects; standardization of methods

Improved software evaluation; formal

Developing the wrong software
specification methods; user surveys; prototyping;
functions
early user manuals
Developing the wrong user
Prototyping; task analysis; user involvement
interface
Software project risks and strategies of Risk reduction cont..
Risk Risk reduction techniques
Requirements scrubbing, prototyping, design
Gold plating
to cost
Late changes to requirements Change control, incremental development
Benchmarking, inspections, formal
Shortfalls in externally supplied
specifications, contractual agreements, quality
components
controls
Shortfalls in externally performed Quality assurance procedures, competitive
tasks design etc
Real time performance problems Simulation, prototyping, tuning
Development technically too Technical analysis, cost-benefit analysis,
difficult prototyping , training
Checklists
 Project management methodologies, such as PRINCE2, often
recommend that on completion of a project a review
identifies any problems during the project and the steps that
were (or should have been) taken to resolve or avoid them.
 In some cases, these problems could be added to an
organizational risk checklist for use with new projects.
Brainstorming
 Ideally, representatives of the main stakeholders should be
brought together once some kind of preliminary plan has
been drafted.
 Then, they identify, the problems that might occur, using their
individual knowledge of different parts of the project.
Risk Assessment
 A common problem with risk identification is that a list of
risks is potentially endless.
 A way is distinguishing the damaging and likely risks. This can
be done by estimating the risk exposure for each risk using
the following formula:
risk exposure = (potential damage) X (probability of
occurrence)
Risk Assessment
 Usually, the potential damage is assessed as a money value.
 Example: Suppose, a project depends on a data centre
vulnerable to fire. It might be estimated that if a fire occurred
a new computer configuration could be established for
£500,000. It might also be estimated that where the
computer is located there is a 1 in 1000 chance of a fire
actually happening, that is a probability of 0.001.
 Then, the risk exposure in this case would be:
£500,000 X 0.001 = £500
Risk Assessment
 A crude way of understanding this value is as the minimum
sum an insurance company would require as a premium.
 If 1000 companies, all in the same position, each contributed
£500 to a fund then, when the 1 in 1000 chance of the fire
actually occurred, there would be enough money to cover
the cost of recovery.
Risk Assessment
 The calculation of risk exposure assumes that the amount of
damage sustained will always be the same. However, it is
usually the case that there could be varying amounts of
damage.
 For example, as software development proceeds, more
software is created, and more time would be needed to re-
create it if it were lost.
 With some risks, there could be not only damage but also
gains. The testing of a software component is scheduled to
take six days, but is actually done in three days. A team leader
might therefore feel justified in producing a probability chart
for this.
Risk Assessment
 Most managers resist very precise estimates of loss or of the
probability of something occurring, as such figures are usually
guesses. Barry Boehm has suggested that, because of this,
both the risk losses and the probabilities be assessed using
relative scales in the range 0 to 10.
 The two figures could then be multiplied together to get a
notional risk exposure.
 Next table provides an example, of where this has been done.
This value could be used to prioritize the importance of
risks, although more sophisticated risk calculations are not
possible.
 Example for risk exposure assessment
Ref Hazard Likelihood Impact Risk
Changes to requirements specification
R1 8 8 64
during coding
R2 Specification takes longer than expected 3 7 21
Significant staff sickness affecting critical
R3 5 7 35
path activities
Significant staff sickness affecting non-
R4 10 3 30
critical activities
Module coding takes longer than
R5 4 5 20
expected
Module testing demonstrates errors or
R6 4 8 32
deficiencies in design
Another approach for risk exposure assessment
 Even using indicative numbers in the range 0 to 10, rather
than precise money values and probabilities, is not completely
satisfactory. The values are likely to be subjective, and
different analysts might pick different numbers.
 Another approach is to use qualitative descriptions of the
possible impact and the likelihood of each risk (see next
tables, for examples). Consistency between assessors is
facilitated by associating each qualitative description with a
range of values.
Qualitative descriptors of risk probability and
associated range values
Probability level Range
Greater than 50% chance of
High
happening
Significant 30-50% chance of happening
Moderate 10-29% chance of happening
Low Less than 10% chance of happening
Qualitative descriptors of impact on cost and
associated range values
Probability level Range
Greater than 30% above budgeted
High
expenditure
20 to 29% above budgeted
Significant
expenditure
10 to 19% above budgeted
Moderate
expenditure
Within 10% of budgeted
Low
expenditure
Another approach for risk exposure assessment
 In the later table, the potential amount of damage has been
categorized in terms of its impact on project costs. Other
tables could be drawn to show the impact of risks on
project duration or on the quality of the project
deliverables.
 To some extent, the project manager, in conjunction with
the project sponsor, can choose whether the damage
inflicted by a risk affects cost, duration or the quality of
deliverables.
Probability impact matrix
 Where the potential damage and likelihood of a risk are
defined by qualitative descriptors, the risk exposure cannot
be calculated by multiplying the two factors together. In this
case, the risk exposure is indicated by the position of the
risk in a matrix (see next figure).
 These matrices have variously been called probability
impact grids (matrix) or summary risk profiles.
 In this figure, some of the cells in the top right of the matrix
have been zoned off by a tolerance line. Risks that appear
within this zone have a degree of seriousness that calls for
particular attention.
Probability impact matrix
Another approach for risk exposure assessment
 We know that there is a need for frequent reassessment of effort and
duration estimates during a project. This also applies to risk exposure as
well, as some risks apply only at certain stages.
 A risk might be that key users are unavailable when needed to supply
details of their requirements. As requirements are gathered, so this risk
will diminish until it is no longer significant.
 In general, the element of uncertainty will lessen as a project progresses
and more is learnt by the developers about user requirements and any
new technology. This would be reflected in lower risk probabilities.
Another approach for risk exposure assessment
 On the other hand, the potential damage will tend to increase as the
amount invested in the project grows.
 Example: If you type a substantial report using a word processor and
neglect to take back-ups, as each day adds more text to the report, it
also adds to the number of days needed to re-key the report in the
event of file loss.
 Risk Planning
 Having identified the major risks and allocated priorities, the
next task is to decide how to deal with them.
 The choices are:
◦ risk acceptance;
◦ risk avoidance;
◦ risk reduction and mitigation;
◦ risk transfer.
 Risk acceptance

 This is the do-nothing option. We will already, in the risk

prioritization process, have decided to ignore some risks in
order to concentrate on the more likely or damaging.
 We could decide that the damage inflicted by some risks
would be less than the costs of action that might reduce the
probability of a risk happening.
 Risk avoidance
 Some activities may be so prone to accident that it is best
to avoid them altogether. If you are worried about sharks
then don't go into the water.
 For example, given all the problems with developing
software solutions from scratch, managers might decide to
retain existing clerical methods, or to buy an off-the-shelf
solution.
 Risk reduction
 Here we decide to go ahead with a course of action despite
the risks, but take precautions that reduce the probability of
the risk.
 Suppose, two of the staff scheduled to work on a project
departed for other jobs. If this has been identified as a risk,
steps might have been taken to reduce possible departures
of staff.
 For instance, the developers might have been promised
generous bonuses to be paid on successful completion of
the project.
 Risk reduction
 Suppose, after the purchase of the payroll package, there is a
requirement for the payroll database to be accessed by another
application. Unfortunately, the application that had been
bought did not allow such access.
 An alternative scenario is that the project manager identified
this as a possible risk early on in the project. She might have
come across Richard Fairley’s four COTS software acquisition
risks (see next table), where one risk is difficulty in integrating
the data formats & commn. protocols of different applications.
 She might have specified that the selected package must use a
widely accepted data management system like Oracle that
allows easier integration.
Fairley’s four commercial off-the-shelf (COTS)
software acquisition risks
Difficulties in integrating the data formats and
Integration
communication protocols of different
applications.
When the supplier upgrades the package, the
Upgrading package might no longer meet the users'
precise requirements. Sticking with the old
version could mean losing the supplier's
support for the package.
If you want to enhance the system, you might
No source code
not be able to do so as you do not have
access to the source code.
The supplier of the application might go out
Supplier failures or buyouts
of business or be bought out by a rival
supplier.
 Risk mitigation
 Risk mitigation can sometimes be distinguished from risk
reduction.
 Risk reduction attempts to reduce the likelihood of the risk
occurring, but, risk mitigation is action taken to ensure that
the impact of the risk is lessened when it occurs.
 For example, taking regular back-ups of data storage would
reduce the impact of data corruption but not its likelihood.
Mitigation is closely associated with contingency plans.
 Risk transfer
 In this case the risk is transferred to another person or
organization. With software projects, an example of this
would be where a software development task is outsourced
to an outside agency for a fixed fee.
 You might expect the supplier to quote a higher figure to
cover the risk that the project takes longer than the average
expected time.
 On the other hand, a well-established external organization
might have productivity advantages as its developers are
experienced in the type of development to be carried out.
 The need to compete with other software development
specialists would also tend to drive prices down.
Contingency
Risk Management
 Risk reduction activities would appear to have only a small
impact on reducing the probability of some risks, for example
staff absence through illness.
 While some employers encourage their employees to adopt a
healthy lifestyle, it remains likely that some project team
members will at some point be brought down by minor
illnesses such as flu. These kinds of risk need a contingency
plan.
 This is a planned action to be carried out if the particular risk
materializes. If a team member involved in urgent work were
ill, then the project manager might draft in another member of
staff to cover that work.
 Risk Management
 The preventative measures that were discussed under the
'Risk reduction' heading above will usually incur some cost
regardless of the risk materializing or not.
 The cost of a contingency measure will only be incurred if
the risk actually materializes.
 However, there may be some things that have to be done in
order for the contingency action to be feasible.
 An obvious example is that back-ups of a database have to
be taken if the contingency action when the database is
corrupted is to restore it from back-ups. There would be a
cost associated with taking the back-ups.
 Deciding on the risk actions
 Five generic responses to a risk have been discussed above.
For each actual risk, however, specific actions have to be
planned. In many cases, experts have produced lists
recommending practical steps to cope with the likelihood of
particular risks (see, for example. Boehm's top ten software
engineering risks).
 Whatever the countermeasures that are considered, they
must be cost-effective. On those occasions where a risk
exposure value can be calculated as a financial value using
the (value of damage) x (probably occurrence) formula, the
cost-effectiveness of a risk reduction action can be assessed
by calculating the risk reduction leverage (RRL).
 Deciding on the risk actions
 RRL = (RE before – RE after)/(cost of risk reduction)
 REbefore is the risk exposure, before risk reduction actions
have been taken.
 REafter is the risk exposure after taking the risk reduction
action.
 An RRL above 1.00 indicates that the reduction in risk
exposure achieved by a measure is greater than its cost.
 Example
 Suppose, it might cost £200,000 to replace a hardware
configuration used to develop a software application. There
is a 1% chance of a fire (because of the particular location of
the installation). The risk exposure would be 1% of
£200,000, that is £2,000.
 Installing fire alarms at a cost of £500 would reduce the
chance of fire to 0.5%. The new risk exposure would be
£1,000, a reduction of £1,000 on the previous exposure.
 So, RRL = (2000 – 1000)/500 = 2.0.
 Inference: The action would be deemed worthwhile.
 Example cont …
 Earlier, we likened risk exposure to the amount you might
pay to an insurance company to cover a risk.
 To continue the analogy, an insurance company in the above
example might be willing to reduce the premium you pay to
have cover against fire from £2,000 to £1,000 if you installed
fire alarms.
 As the fire alarms would cost you only £500 and save
£1,000, the cost would clearly be worthwhile.
 Creating and maintaining the risk register
 When the project planners have picked out and examined
what appear to be the most threatening risks to the project,
they need to record their findings in a risk register.
 After work starts on the project more risks will emerge and
be added to the register. At regular intervals, the risk
register should be reviewed and amended.
 Many risks threaten just one or two activities, and when the
project staff have completed these, the risk can then be
"closed' as no longer it is relevant.
 In any case, as noted earlier, the probability and impact of a
risk are likely to change during the course of the project.
The risk register
Risk Mitigation, Monitoring and Management Plan
 It is usually advisable for the project manager to develop a risk
mitigation, monitoring and management (RMMM) plan for a project.
 An important component of this document is a risk table. Each
row of the table contains the name of the risk, its probability and
its impact on the project.
 For each risk in the risk table, the specific conditions or events that
need to be monitored to check whether the risk has actually
occurred is mentioned.
 The possible ways in which the risk can be avoided (mitigation) is
also documented.
 A contingency plan to contain the effect of the risk is also
documented.
 Summary
Discussed
I. Risk identification
II. Risk analysis and prioritization
III. Risk planning
IV. Risk monitoring
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Risk Management cont …
 Topics to be covered
 Monte Carlo Simulation
 Critical Chains
 Evaluating Risks to the Schedule
 It can be shown that a job might take 5 days, but that there
is a small chance it might need 4 or 6 days, and a smaller
chance of 3 or 7 days, and so on.
 If a task in a project takes longer than planned, we might
hope that some other task might take less and thus
compensate for this delay.
 We have already discussed that PERT takes account of the
uncertainties in the durations of activities within a project.
 Now, we will discuss Monte Carlo simulation, which is a
more powerful and flexible tool, that also tackles the same
problem.
 Monte Carlo Simulation
 As an alternative to the PERT technique, we can use Monte
Carlo simulation approach.
 Monte Carlo simulation are a class of general analysis
techniques that are valuable to solve any problem that is
nonlinear, or involves more than just a couple of uncertain
parameters. Hence, it can be used to handle risks in projects.
 Monte Carlo simulations involve repeated random sampling
to compute the results.
 Since this technique is based on repeated computation on
random numbers, it becomes easier to use this technique
when available as a computer program.
 Monte Carlo Simulation
 When Monte Carlo simulation is used to analyse the risk of
not meeting the project deadline, the project completion
time is first modelled as a mathematical expression involving
the probability distributions of the completion times of
various project activities and their precedence relationships.
 Activity durations can be specified in a variety of forms,
depending upon the information available.
 For example, if historic data are available about the durations
of similar activities as shown in the probability chart in next
figure, we might be able to specify durations as pertinent
probability distributions.
Probability impact matrix
 Monte Carlo Simulation
 With less information available, we should, at least, be able to
provide three time estimates as used by PERT.
 Monte Carlo simulation essentially evaluates a range of input
values generated from the specified probability distributions
of the activity durations.
 It then calculates the results repeatedly; each time using a
different set of random values generated from the given
probability functions.
 Depending upon the number of probabilistic parameters and
the ranges specified for them, a Monte Carlo simulation
could involve thousands or even millions of calculations to
complete.
 Monte Carlo Simulation
 After the simulation results are available, these are analysed,
summarized and represented graphically, possibly using a
histogram.
 Steps for Monte Carlo simulation
 Step 1: Express the project completion time in terms of the
duration of the n activities (xi, i=1,n and their dependences as a
precedence graph, d = f(x1, x2, ...,xn)).
 Step 2: Generate a set of random inputs, xi1, xi2, ..., xin using the
specified probability distributions.
 Step 3: Evaluate the project completion time expression and
store the result in di
 Step 4: Repeat Steps 2 and 3 for the specified number of
times.
 Step 5: Analyse the results di, i=1,n; summarize and display using
a histogram.
Monte Carlo Simulation
 Advantage of Monte Carlo simulations
• In the manual approach, a few combinations of each project
duration are chosen (such as best case, worst case, and most
likely case), and the results recorded for each selected
scenario.
• In contrast, in Monte Carlo simulation, hundreds or
thousands of possible random sampling of probability
distribution functions of the activity durations are considered
as samples for evaluation of the project completion time
expression to produce outcomes.
• Monte Carlo simulation is expected to give a more realistic
result than manual analysis of a few cases, especially because
manual analysis implicitly gives equal weights to all scenarios.
 Critical Chain Concepts
 A drawback to the application of methods like PERT is that,
in practice there is a tendency for developers to work to
the schedule even if a task could be completed more quickly.
 Even if tasks are completed earlier than planned, project
managers are not always quick to exploit the opportunities
to start subsequent activities earlier than scheduled.
 Critical chain management will be explored as a way of
tackling this problem.
 Critical Chain Concepts
 The forecast for the duration of an activity cannot in reality
be a single number, but must be a range of durations.
 However, we would want to pick one value in that range,
which would be the target.
 The duration chosen as the target might be the one that
seems to be the most likely.
 Example
 Imagine someone who cycles to work each day. It may be
that on average it takes them about 45 minutes to complete
the journey, but on some days it could be more and on other
days it could be less.
 If the cyclist had a very important meeting at work, it is likely
that they would give themselves more time – say an extra 15
minutes – than the average 45 minutes to make sure that
they arrive in time.
 Example
 According to PERT, the most likely duration is the middle
value and the pessimistic estimate is the equivalent of 45 +
15 = 60 minutes. Of course, there will be some days when
the cyclist will beat the average of 45 minutes.
 When a project is actually being executed, the project
manager will be forced to focus on the activities where the
actual durations exceed the target.
 Activities which are actually completed before the target
date are likely to be overlooked. If these early completions,
are properly handled, it can put some time in hand that will
allow the project to meet its target completion date, if the
later activities are delayed.
 Example
 Next figure shows the findings of Michiel van Genuchten, a
researcher who analysed the reasons for delays in the
completion of software development tasks. This bar chart
shows that about 30% of activities were finished on time,
while 9% were a week early and 17% were a week late.
 The big jump of 21 percentage points between being a week
early and being on time is compatible with the “Parkinson's
Law” which says that 'work expands to fill the time available'.
 This tendency should not be blamed on inherent laziness, van
Genuchten found that the most common reason for delay
was the time that had to be spent on non-project work. The
developers used the spare time on some other urgent work.
Percentage of activities early or late
 One approach which attempts to solve some of these
problems is the application of the critical chain concept
originally developed by Eliyahu Goldratt.
 In order to demonstrate the principles of this approach, the
example shown in next figure is redrawn as a Gantt chart.
 The next figure shows what the Gantt chart for this project
might look like if a “traditional approach' were adopted, but
we have already adopted the most likely durations.
 The general steps in the Critical Chain approach are
explained in the next slides.
PERT activity time estimates for a project
Activity Optimistic (a) Most likely (m) Pessimistic (b)
A 5 6 8
B 3 4 5
C 2 3 3
D 3.5 4 5
E 1 3 4
F 8 10 15
G 2 3 4
H 2 2 2.5
PERT network
Gantt chart – ‘traditional’
planning approach
Steps in Critical Chain approach
 Derive the ‘most likely' activity durations
 Use the latest start dates for activities
 Insert project and feeder buffers
 Derive ‘most likely' activity durations
 The target date generated by critical chain planning is one
where it is estimated that there is a 50% chance of success –
this approximates to the expected time identified in the
PERT method.
 In critical chain method, the developers are asked to supply
two estimates.
◦ One of these would be a 'most likely' estimate and
◦ the other would include a safety margin or comfort zone.
Probability chart
PERT activity time estimates for a project
Activity Optimistic (a) Most likely (m) Pessimistic (b)
A 5 6 8
B 3 4 5
C 2 3 3
D 3.5 4 5
E 1 3 4
F 8 10 15
G 2 3 4
H 2 2 2.5
Most likely and comfort zones estimates

Plus comfort
Activity Most likely Comfort zone
zone
A 6 8 2
B 4 5 1
C 3 3 0
D 4 5 1
E 3 4 1
F 10 15 5
G 3 4 1
H 2 2.5 0.5
 Use latest start dates for activities
 Working backwards from the target completion date, each
activity is scheduled to start as late as possible.
 Among other things, this should reduce the chance of staff
being pulled off the project on to other work. It is also
argued – with some justification according to van
Genuchten's research – that most developers would tend to
start work on the task at the latest start time anyway.
However, it does make every activity ‘critical’, i.e. if one is late,
the, the whole project is late.
 Insert project and feeder buffers
 To cope with activity overruns, a project butter is inserted at
the end of the project before the target completion date.
 One way of calculating this buffer is as the equivalent of 50%
of the sum of lengths of the comfort zones that have been
removed from the critical chain.
 The critical chain is the longest chain of activities in the
project, taking account of both task and resource
dependencies.
 Insert project and feeder buffers
 This is different from the critical path as the latter only takes
account of task dependencies, not resource dependencies.
 A resource dependency is where one activity has to wait for
a resource (usually a person in software development) which
is being used by another activity to become available.
 If an activity on this critical chain is late, it will push the
project completion date further into the project buffer.
 Why the buffer should be 50% of the total comfort zones?
Reason: It is based on the grounds that if the estimate for an
activity was calculated as having a 50% chance of being
correct, the buffer would only need to be called upon by the
50% of cases where the estimate was not correct.
 An alternative proposal
 An alternative proposal is to sum the squares of the comfort
zones and then take the square root of the total. This is
based on the idea that each comfort zone is the equivalent to
the standard deviation of the activity.
 This method of calculation still produces a figure which is less
than simply summing all the comfort zones.
 This is justified on the grounds that the contingency time
needed for a group of activities is less than the sum of the
individual contingency allowances as the success of some
activities will compensate for the shortfalls in others.
 Feeding buffers
 Buffers are also inserted into the project schedule where a
subsidiary chain of activities feeds into the critical chain.
 These feeding buffers could once again be set at 50% of the
length of the 'comfort zone' removed from the subsidiary or
feeding chain.
 Worked example
 Next figure shows the results of this process.
 The critical chain in this example happens to be the same as
the critical path, that is activities F and G which have comfort
zones of 5 weeks and I (one) week respectively, making a
total of 6 weeks.
 The project buffer is therefore (5+1)/2 = 3 weeks.
 Gantt chart – ‘critical
chain’ planning approach
 Feeding Buffers
 Subsidiary chains feed into the critical chain where activity H
links into the project buffer and where activity E links into G
which is part of the critical chain.
 Feeding buffers are inserted at these points. For the first
buffer the duration would be 50% of the saved comfort zones
of A, C and H, i.e. (2 + 0 + 0.5)/2 = 1.25 weeks.
 It could be argued that B, D & H could form a feeder chain
which also has a comfort zone of (1+1+0.5)/2 = 1.25 weeks.
 In situations, where there are parallel alternative paths on a
feeder chain, the practice is to base the feeding buffer on
whichever comfort zone total is greater. This because if one
or both parallel paths are late they could use the same buffer.
 It could be argued that the feeding and the final project buffer
could also be merged, but explanations of critical chain
planning, make clear that this is not to be done.
 This could be because a delay penetrating the feeding buffer
time does not affect the completion date of the project, while
penetrating project buffer does.
 In the second place, where a feeder chain of activities joins
the critical chain, the feeder buffer would be 50% of the
comfort zones of activities B and E, i.e. (1+1) / 2 = 1 week.
Project execution
When the project is executed, the following principles are
followed:
 No chain of tasks should be started earlier than scheduled,
but once it has been started it should be finished as soon as
possible – this invokes the relay race principle,
◦ where developers should be ready to start their tasks as soon as the
previous, dependent, tasks are completed.
 Buffers are divided into three zones: green, amber and
red, each of an even (33%) size.
Project execution
 green, where no action is required if the project completion
date creeps into this zone;
 amber, where an action plan is formulated if the project
completion dates moves into this zone;
 red, where the action plan above is executed if the project
penetrates this zone.
 Summary
 Discussed Monte Carlo Simulation.
 Discussed Critical Chain method with an example.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Resource Allocation
 Introduction
 Nature of resources
 Identifying resource requirements
Introduction
• In project scheduling, activity network analysis
techniques are used to plan when the different
activities should take place.
• But, these plans do not take into account the
availability of resources.
• Now, we will discuss how to match the activity plan
to available resources.
• We will also assess the efficacy of changing the plan
to fit the resources, wherever necessary.
Introduction cont …
Output: Final result of resource allocation will be a number
of schedules such as:
• Activity schedule: indicates the planned start and
completion dates for each activity. It can be prepared by
using precedence network (activity plan).
• Resource schedule: shows the dates on which each
resource will be required and level of that requirement
• Cost schedule: shows the planned cumulative
expenditure incurred by the use of resources over time.
 The Nature of Resources
 Resource: any item or person required for execution
of the project
 Some resources such as project manager will be
required for whole duration of the project,
◦ whereas others such as programmer, might be required for a
single activity.
 Project manager is very much vital to success of the
project.
 Does not require the same level of scheduling as a
programmer.
 Manager may request for the use of a programmer who
belongs to a pool of resources at programme level.
5
Categories of Resources
• Labour: Members of the development project, such as
project manager, systems analyst, programmers etc.
• Equipment: Computing and other equipment (e.g. servers,
workstations, desktops, keyboards, printers, scanners etc.)
• Materials: Items that are consumed, rather than used (e.g.
disks, CDs, papers etc.)
• Space: Office space / working space

6
Categories of Resources
• Services: Some projects may require procurement of
specialized services, e.g. development of a wide area
distributed system, may require scheduling of
telecommunication services; postal/courier services etc.
 Time: elapsed time can be reduced by adding more staff
 Money: It is a secondary resource, used to buy the other
resources. It is similar to other resources in that it is
available at a cost – in this case interest charges.

7
 Resource allocation - Steps
 Identify the resources needed for each activity and create a
resource requirement list
 Identify resource types - individuals are interchangeable
within the group (e.g. ‘VB programmers’ as opposed to
‘software developers’)
 Allocate resource types to activities and examine the
resource histogram

8
Identify the resource requirements
 Identify hardware

 Identify software

 Identify support

9
Identify hardware
Steps:
1. List all the hardware needs of the project (e.g. desktops,
servers, backup media, keyboards, switches, ports and cables,
display devices, printers, plotters, touch screens etc.)
2. For each piece of hardware, specify what it needs to do
3. For each piece of hardware, specify what it needs in order to
function properly (e.g. the required software, cables etc.)
4. Specify who needs what hardware to do his task (Do not
provide everyone with every piece of hardware, if they do not
require it)
5. Specify, when the team needs the hardware, may be in advance
10
Identify software
 Many other supporting software (such as OS, DB packages,
etc.) are needed to develop a software project.
 Basic software like operating systems, compilers etc. may
cause project delays if installed incorrectly or upgraded
randomly.
 Different versions of software, mismatched service packs,
and different releases of libraries may also create problems.
 Ignoring these issues may lead to problems.

11
Identify software cont…
 Experienced project managers know that software
upgrades during a project cost the team productivity and
may create serious problems.
 So, there is a need to plan for upgrades and schedule them,
when the impact on the team and the project can be
minimized.
 Project managers can get a handle on software support by
following below steps.
12
Identify software cont…
Steps:
 List the Software Requirements
 Specify the Software Versions
 Identify Upgrades and Service Packs
 Identify Who Upgrades Which Software
 Specify When to Upgrade Which Software

13
List Software Requirements.
 The team may need a well-specified set of software
products so that product inconsistencies can be
minimized, upgrades can be planned, and licensing can be
done properly.
 To get this set, the project manager needs to manage the
details of all the software to be used.
 He may start by specifying the software that the team
will need, including the followings:

14
List Software Requirements cont…
 Operating systems
 Compilers
 Configuration management system
 Email systems
 Supporting software (FTPs, web browser, etc.)
 Libraries (dynamic link libraries, standard template libraries,
graphic user interface libraries, etc.)
 Office software (word processing, excel sheet, presentation, etc.)
 Software tools (CASE tools, Design tools, Testing tools, SPM tools)

15
Specify the Software Versions.
 Given the list of existing software products, specify the
team needs exactly which version of each of these pieces
of software.

 Also, specify when changes to these might become

available.

16
Identify Upgrades and Service Packs

 Software is not a static entity. There will be upgrades and

enhancements from time to time.
 The project manager needs to know which pieces of
software need these upgrades and when they will occur
during the project.
 Answer the following questions for each software product
the team will use:
1) What is the length of your project in relation to upgrades, service
packs, or new versions of these software products?
2) Will the team need to upgrade?
3) When will the upgrade be available?
17
Identify Who Upgrades Which Software
 Identify who is responsible for installing and upgrading of
each piece of software (e.g. system administrator or
project team).

 Make sure that the project manager has identified who

does what and everyone agrees on who performs
installations and upgrades.

18
Specify When to Upgrade Which Software
 Once the project manager has a handle on the list of
software and an idea of what upgrades the team will need
to make during the project,
◦ he can decide when to upgrade.
 Upgrades just before a major milestone are very risky. Up
grading immediately after a milestone will allow time to
troubleshoot problems that arise but may invalidate
testing done prior to the milestone.

19
Specify When to Upgrade Which Software
cont…
 Consider all the software that the team will use in the
project. If you want to upgrade the software, plan to
upgrade when the team and project can best handle
unexpected problems.
 Never plan on a best-case scenario when upgrading
software. Expect problems to occur and plan time to
handle them. If problems don't pop up, the team has extra
time. If they do pop up, the planning provides time to
handle problems.
20
Identify support
Steps:
1. Identify the support needed from each group.
2. Specify when support will be required, so that the project can
make progress without any delay.
3. Specify how support occurs (e.g. will the staff be available via
phone, email, or in person?)
4. Gain commitment from each group for the support required
(e.g. through a verbal commitment or a contract or a
commitment letter).
5. Maintain a good relationship with support staff
21
Prepare a resource requirement list
 First step in producing a resource allocation plan is to prepare
a resource requirement list containing the resources that will
be required along with the expected level of demand.
 This can be done by considering each activity present in a
precedence network & identifying the resources required by it.
 There can be some resources that are not activity specific, but
are part of the project infrastructure (for example project
manager) or required to support other resources (for example
office space).

22
An Example of Precedence Network

23
A sample resource requirements list
Stage Activity Resource Days Quantity Notes
All All Project Manager 104 F/T
1 All Workstation --- 34 Check software availability
IoE/P/1 Senior analyst 34F/T
2 All Workstation --- 3 One per person essential
IoE/P/2 Analyst/Designer 20F/T
IoE/P/3 Analyst/Designer 15F/T
IoE/P/4 Analyst/Designer 25F/T
IoE/P/5 Analyst/Designer 15F/T Could use analyst/programmer
3 All Workstation --- 2
IoE/P/6 Senior analyst* 2F/T
4 All Workstation --- 3 As stage 2
IoE/P/7 Analyst/Designer 7F/T
A sample resource requirements list
cont…
Stage Activity Resource Days Quantity Notes

IoE/P/8 Analyst/Designer 6 F/T

IoE/P/9 Analyst/Designer 4 F/T
IoE/P/10 Analyst/Designer 4F/T
5 All Workstation --- 4 One per programmer
All Office space --- If contract programmers used
IoE/P/11 Programmer 30F/T
IoE/P/12 Programmer 28F/T
IoE/P/13 Programmer 15F/T
IoE/P/14 Programmer 25F/T
6 All Full system --- 3 Approx. 16 hours for full
access system test
IoE/P/15 Analyst/Designer 6F/T
 Summary
 Discussed the different categories of resources
 Explained the identification of resource requirements
 Presented the steps for identifying hardware, software
and support staff
 Discussed preparation of resource requirements list
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Resource Allocation cont …
 Resource allocation - Steps
 Identify the resources needed for each activity and create a
resource requirement list
 Identify resource types - individuals are interchangeable
within the group (e.g. ‘VB programmers’ as opposed to
‘software developers’)
 Allocate resource types to activities (scheduling resources)
and examine the resource histogram

3
 Scheduling resources
 After producing the resource requirements list, the next
stage is to identify the resource types. Then, map the
resources on to the activity plan to assess the distribution
of resources required over the duration of the project.
 This is done by representing the activity plan as a bar
chart & using this to produce a resource histogram for
each resource.
 The next figure illustrates the example activity plan as a
bar chart and a resource histogram for analyst/designers.
 Each activity has been scheduled to start at its earliest
start date. Earliest start date scheduling, frequently creates
resource histograms that start with a peak and then tail
off. 4
An Example of Precedence Network

5
A sample resource requirements list
Stage Activity Resource Days Quantity Notes
All All Project Manager 104 F/T
1 All Workstation --- 34 Check software availability
IoE/P/1 Senior analyst 34F/T
2 All Workstation --- 3 One per person essential
IoE/P/2 Analyst/Designer 20F/T
IoE/P/3 Analyst/Designer 15F/T
IoE/P/4 Analyst/Designer 25F/T
IoE/P/5 Analyst/Designer 15F/T Could use analyst/programmer
3 All Workstation --- 2
IoE/P/6 Senior analyst* 2F/T
4 All Workstation --- 3 As stage 2
IoE/P/7 Analyst/Designer 7F/T
A sample resource requirements list
cont…
Stage Activity Resource Days Quantity Notes

IoE/P/8 Analyst/Designer 6 F/T

IoE/P/9 Analyst/Designer 4 F/T
IoE/P/10 Analyst/Designer 4F/T
5 All Workstation --- 4 One per programmer
All Office space --- If contract programmers used
IoE/P/11 Programmer 30F/T
IoE/P/12 Programmer 28F/T
IoE/P/13 Programmer 15F/T
IoE/P/14 Programmer 25F/T
6 All Full system --- 3 Approx. 16 hours for full
access system test
IoE/P/15 Analyst/Designer 6F/T
Sample Bar chart and resource
histogram for analyst/designers

8
 Scheduling resources cont…
 Changing the level of resources on a project over time,
particularly personnel, generally adds to the cost of a
project. Recruiting staff has costs and, even where staff are
transferred internally, time will be needed for
familiarization with the new project environment.
 The resource histogram shown in the previous figure
poses some problems. Some analysts/designers may sit
idle for some days (e.g. between the specification and
design stages of the histogram). It is unlikely that there
would have another project requiring their skills for
exactly those periods of time.
 This idle time may be charged to the project.
 The ideal resource histogram will be smooth (even) with
an initial build-up and a staged run-down. 9
Resource histogram: An Example
5
4
3
2
1
1 2 3 4 5 6 7
WEEK
10
Resource smoothing
 It is usually difficult to get specialist staff who will work
odd days to fill in gaps – there is a need for staff to learn
about application, etc
 Staff often have to be employed for a continuous block of
time
 Therefore it is desirable to employ a constant number of
staff on a project – who as far as possible are fully
employed
 Hence there is a need for resource smoothing

11
Resource histogram after
smoothing
5
4
3
2
1
1 2 3 4 5 6 7 8
WEEK
Resource smoothing cont ...
 Another problem with an uneven resource histogram is
that it may call for levels of resource beyond those
available.
 The next figure illustrates how, by adjusting the start date
of some activities and splitting others, a resource
histogram can be smoothed to contain resource demand
at available levels, subject to constraints such as
precedence requirements.
 The different letters in the figure represent staff working
on a series of module testing tasks, i.e. 1 person working
on task A, 2 on tasks B and C etc. 13
Resource smoothing cont ...

A resource histogram showing demand for staff before and after

smoothing 14
Resource smoothing cont ...
 In this figure, the original histogram was created by
scheduling the activities at their earliest start dates. The
resource histogram shows the typical peaked shape
caused by earliest start date scheduling & calls for a total
of 9 staff where only 5 are available for the project.
 By delaying the start of some of the activities, it is
possible to smooth the histogram and reduce the
maximum level of demand for the resource.

15
Resource smoothing cont ...
Revised
Precedence
Network

16
Resource smoothing cont ...
 Notice that some activities, such as C and D, have been
split. Where non-critical activities can be split they can
provide a useful way of filling troughs in the demand for a
resource.
 But, in software projects it is difficult to split tasks without
increasing the time they take.
 Some of the activities may call for more than one unit of
the resource at a time, e.g. activity F requires 2
programmers, each working for 2 weeks.
 It is possible to reschedule this activity to use one
programmer over 4 weeks (although not done here).
17
Resource clashes
 Resource clashes: Where same resource is needed in
more than one place (activity) at the same time
 Can be resolved by:
◦ delaying one of the activities
 taking advantage of float to change start date
 delaying start of one activity until finish of the other activity that
resource is being used on - puts back project completion
◦ moving resource from a non-critical activity
◦ bringing in additional resource - increases costs
Prioritizing activities
 In practice, resources are allocated to a project on an activity-
by-activity basis.
 Finding the best allocation is time consuming and difficult.
 Allocating a resource to one activity limits the flexibility for
resource allocation and scheduling of other activities.
 So, there is a need to prioritize the activities so that resources
can be allocated to competing activities in some rational order.
 The priority must almost always be to allocate resources to
critical path activities and then to those activities that are most
likely to affect others.
 In this way, lower–priority activities are made to fit around the
more critical, already scheduled activities. 19
Prioritizing activities cont ...
There are two main ways of doing this:

 Total float priority

 Ordered list priority

20
Total float priority
 Total Float: It is a measure of how much the start or
completion of an activity may be delayed without affecting the
end date of the project.
 In this method, activities with the smallest float have the
highest priority.
 Activities are allocated resources in ascending order of their
floats.
 As scheduling proceeds, activities may be delayed (if resources
are not available at their earliest start dates) and total floats
will be reduced.
 So, it is desirable to recalculate the floats (and hence reorder
the list) each time an activity is delayed. 21
Ordered list priority
 In this method, activities that can proceed at the same
time are ordered according to a set of simple criteria.

 Example: Burman’s priority list

 This method takes account of the duration of the activity

as well as the float.

22
 Burman’s priority list
Give priority to the activities as in the following order:
1. Shortest critical activities
2. Other critical activities
3. Shortest non-critical activities
4. Non-critical activities with least float
5. Non-critical activities

23
Alternatives to resource smoothing
 Resource smoothing is not always possible
◦ Deferring activities to smooth out resource peaks
often puts back project completion.
• In this case the project manager needs to consider
alternative ways, such as
◦ Increasing the available resource levels
◦ Altering working methods such as doing overtime
work, working in holidays etc.
24
Resource usage
 Project manager needs to maximize % usage of
resources i.e. to reduce the idle periods between tasks
 There is a need to balance costs against early
completion date
 There is a need to allow for contingency

25
Creating critical path

 Scheduling resources can create new critical paths.

 Delaying the start of an activity because of lack of
resources will cause that activity to become critical if this
uses of its float.
 Further, a delay in completing one activity can delay the
availability of a resource required for a later activity.
 If the later one is already critical, then the earlier one
might now have been made critical by linking their
resources.
26
Creating critical path cont ...
 Scheduling resources can create new dependencies
between activities.
 It is better not to add dependencies to the activity
network to reflect resource constraints
◦ Makes network very messy
◦ A resource constraint may disappear during the project,
but link remains on network
 Rather, amend dates on schedule to reflect resource
constraints

27
Summary
 Discussed the scheduling of resources
 Presented what is a resource histogram?
 Explained the concept of resource smoothing
 Described fundamentals of resource clashes
 Discussed the methods for prioritizing activities
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Resource Allocation cont …
 Contents
 Allocation of resources to individuals
 Publishing the Resource Schedule
 Cost Schedules
 Scheduling Sequence
 Output of resource allocation
Final result of resource allocation will be a number of
schedules such as:
• Activity schedule: indicates the planned start and
completion dates for each activity. It can be prepared by
using precedence network (activity plan).
• Resource schedule: shows the dates on which each
resource will be required and level of that requirement
• Cost schedule: shows the planned cumulative
expenditure incurred by the use of resources over time.
Counting the Cost
• So far we have concentrated on trying to complete the
project by the earliest completion date with the minimum
number of staff.
• Doing this places constraints on when activities can be
carried out and increases the risk of not meeting target dates.
Counting the Cost cont ...
• Alternatively, the project manager can consider using
additional staff or lengthening the overall duration of the
project.
• The additional costs of employing extra staff would need to be
compared to
• the costs of delayed delivery and
• the increased risk of not meeting the scheduled date.

6
Allocation of resources to individuals
 Allocating resources and smoothing resource histograms are
relatively straightforward where all resources of a given type
can be considered more or less equivalent.

 Example: When allocating labourers to activities in a large

building project, we need not distinguish among individuals –
they may be treated as equals so far as skills and productivity
are concerned.

7
Allocation of resources to individuals cont ...

 But, this is not the case with software projects.

 Because of the nature of software development, skill and
experience play a significant role in determining the time
taken and quality of the final product.
 Usually, the project manager should allocate individual
members of staff to activities, as early as possible.

8
Factors affecting allocation of individuals to tasks
In allocating individuals to tasks, the following factors need
to be taken into account.
 Availability: Project manager needs to know whether a particular
individual will be available when required.
 Criticality: Allocate the more experienced personnel to activities
lying on the critical path.
◦ This helps in shortening project durations or at least reducing the risk
of overrun.

9
Factors affecting allocation of individuals to tasks
cont...
 Risk: Identifying the activities posing the greatest risk, and knowing
the factors influencing them, help to allocate staff.
◦ Allocating the most experienced staff to the highest-risk activities has more
effect in reducing the overall project uncertainties.
◦ But, more experienced staff are, usually more expensive.
 Training: It will benefit the organization if junior staff are allocated
to non-critical activities, where there will be sufficient slack time for
them to train and develop skills.
◦ There can even be direct benefits to the particular project since some
costs may be allocated to the training budget.

10
Factors affecting allocation of individuals to tasks
cont...

 Team building: The selection of individuals must also take

account of the
◦ final shape of the project team (e.g. Chief programmer team or
Democratic team or Mixed control team) and
◦ the way they will work together.

11
Publishing the Resource Schedule
 In allocating and scheduling resources we have used the
activity plan (or a precedence network), activity bar charts
and resource histograms.
 But, they are not the best way of publishing and
communicating project schedules.
 For this we need some form of work plan / work schedule.
Work plans are commonly published as either lists or charts
such as shown in the next figure.

12
Work schedule

13
Cost Schedules
 Cost schedule shows the weekly or monthly costs over the
life of the project. This will provide a more detailed and
accurate estimate of costs and will serve as a plan against
which the progress of the project can be monitored.
 Calculating cost is straightforward where the organization has
standard cost figures for staff and other resources.
◦ Where this is not the case, then the project manager will have to
calculate the costs.

14
Categories of costs
In general, costs are categorized as follows:
 Staff costs: These will include staff salaries as well as the other direct costs of
employment such as employer's contribution to social security funds, pension
scheme contributions, holiday pay & sickness benefit. These are commonly charged
to projects at hourly rates based on weekly work records completed by staff.
 Overheads: Overheads represent expenditure that an organization incurs, which
cannot be directly related to individual projects or jobs, including space rental,
interest charges and the costs of service departments (such as human resources).
 Usage charges In some organizations, projects are charged directly for use of
resources such as computer time (rather than their cost being recovered as an
overhead). This will normally be on an “as used” basis.

15
An example cost schedule

16
An example cost schedule cont ...
 The given figure shows the weekly costs over the 20 weeks
that the project manager expects the project to take.
 This is a typical cost profile - building up slowly to a peak
and then tailing off quite rapidly at the end of the project.

17
An example for cumulative project costs

18
Scheduling Sequence
 Going from an ideal activity plan to a cost schedule can be
represented as a sequence of steps.
 Usually, the project manager should start with the activity
plan and use this as the basis for the risk assessment.
 The activity plan and risk assessment would provide the basis
for the resource allocation & resource schedule from which
the project manager would produce the cost schedules.

19
Figure showing the scheduling sequence

20
Scheduling Sequence cont ...
 Usually, successful resource allocation often necessitates
revisions to the activity plan, which, in turn, will affect the risk
assessment.
 Similarly, the cost schedule might indicate the need to
reallocate resources or revise activity plans – particularly
where that schedule indicates a higher overall project cost
than originally anticipated.

21
Scheduling Sequence cont ...
 The interplay between the plans and schedules is complex –
any change to any one will affect each of the others.
 Some factors can be directly compared in terms of money,
such as the cost of hiring additional staff can be balanced
against the costs of delaying the project's end date.
◦ Some factors, however, are difficult to express in money terms (e.g. the
cost of an increased risk) and will include an element of subjectivity.

22
Scheduling Sequence cont ...
 While good project planning software will assist greatly in
demonstrating the consequences of change and keeping the
planning synchronized,
◦ successful project scheduling is largely dependent upon the skill and
experience of the project manager in juggling the many factors involved.

23
 Summary
 Discussed the allocation of resources to individuals and the
factors to be considered during allocation.
 Presented how to publish the resource schedule using a
work schedule
 Presented how to represent cost schedules
 Explained the scheduling sequence
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. J. Henry, Software Project Management – A Real-World Guide to Success, Pearson
Education, 2004.
3. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Monitoring and Control
Contents
 Introduction
 Project Control Cycle
 Project reporting structures
 Assessing progress
 Collecting progress details
 Partial Completion Reporting
 Project Review
Introduction
 Once work schedules have been published and the project is
started,
◦ attention must be focused on progress.
 This requires
◦ monitoring of what is happening,
◦ comparison of actual achievement against the schedule and,
◦ where necessary, revision of plans and schedules to bring the project as
far as possible back on target.
Introduction
 The project manager designates certain key events as a
milestone (e.g. completion of some important activity).
 A few examples of milestones are:
◦ preparation and review of the SRS document,
◦ development of DFDs and UML diagrams
◦ completion of the coding and unit testing, etc.
Introduction cont...
 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.
Introduction cont...
 PERT (Project Evaluation and Review Technique) chart is
especially useful in project monitoring and control.
 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.
Introduction cont...
 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 project manager may switch resources from a
non-critical task to a critical task so that all milestones along
the critical path are met.
Introduction cont...
• Several tools are available which can help you to figure out
the critical paths in an unrestricted schedule,
• but figuring out an optimal schedule with resource limitations and with
a large number of parallel tasks is a very hard problem.
• Several commercial products for automating the scheduling
techniques, are available. Example: MS-Project software
available on personal computers.
Introduction cont...
 In earlier classes, we have discussed the importance of
producing plans that can be monitored.
 Now, we will discuss how information about the progress of
the project is gathered and what actions must be taken to
ensure that a project meets its targets.
Creating the Framework
 Exercising control over a project and ensuring that targets are
met is a matter of regular monitoring, i.e.
◦ finding out what is happening and comparing it with targets.

 There may be a mismatch between the planned outcomes and

the actual ones. Then, replanning may be needed to bring the
project back on target.
 Alternatively, the target has to be revised.
 A Model of
Project Control
Cycle
 Creating the Framework cont …

• The project control cycle shows how, once the initial project plan has been
published,
– project control is a continual process of monitoring progress against
that plan and, where necessary, revising the plan to take account of
deviations.
• It also illustrates the important steps that must be taken after completion
of the project so that
– the experience gained in any one project can feed into the planning
stages of future projects,
• thus allowing us to learn from past mistakes.
Creating the Framework
 In practice, the project manager normally concerned with
four types of shortfall
◦ Delays in meeting target dates,
◦ shortfalls in quality,
◦ inadequate functionality, and
◦ costs going over target.
Responsibilities

 The overall responsibility for ensuring satisfactory progress

on a project is often the role of the project steering
committee, or project management board.
 Day-to-day responsibility will rest with the project manager.
 Other aspects of the projects can be delegated to team
leaders.
Project reporting structures
Responsibilities cont ...
 The previous figure illustrates the typical reporting structure
found with medium and large projects.
 With small projects (employing around half a dozen or fewer
staff), individual team members usually report directly to the
project manager, but in most cases team leaders will collate
reports on their section’s progress and forward summaries to
the project manager.
 These, in turn, will be incorporated into project-level reports
for the steering committee and, via them or directly, progress
reports for the client.
Responsibilities cont ...
 Reporting may be
◦ oral or written,
◦ formal or informal, and
◦ regular or ad hoc.
 Informal communication is necessary and important,
◦ but any such informal reporting of project progress must be complemented by
formal reporting procedures
Categories of reporting
Report type Examples Comment
While reports may be oral,
Weekly or monthly
Oral formal regular formal written minutes
progress meetings
should be kept
While largely oral, likely to
End-of-stage review
Oral formal adhoc receive and generate
meetings
written reports
Normally weekly using
Written formal regular Job sheets, progress reports
forms
Exception reports, change
Written formal adhoc
reports
Often provides early
Canteen discussion, social
Oral informal adhoc warning; must be backed up
interaction
by formal reporting
 Assessing progress
 Some information used to assess project progress will be
collected routinely,
◦ while other information will be triggered by specific events.
 Wherever possible, this information should be objective and
tangible
◦ for example, whether or not a particular report has been delivered
 Assessing progress cont ...
• It is essential to set a series of checkpoints in the initial
activity plan.
Checkpoints – predetermined times when progress is
checked
Two types:
◦ Event driven: check takes place when a particular event has been
achieved (i.e. tied to specific events such as the production of a report
or other deliverable.)
◦ Time driven: date of the check is pre-determined, or regular (e.g.
Weekly / Monthly)
Frequency of reporting
• The frequency of progress reports will depend upon the
size and degree of risk of the project.
• The higher the management level, the less frequent (i.e.
longer the gaps between checkpoints) and less detailed the
reporting needs to be.
• Example: Team leaders may assess progress daily, where as
managers do weekly or monthly.
• Major, or project-level, progress reviews generally take
place at particular points during the life of a project
- commonly known as review points or control points.
Collecting progress details
Need to collect data about:
◦ Achievements
◦ Costs
A big problem: how to deal with partial completions -
99% completion syndrome
Possible solutions:
◦ Control of products, not activities
◦ Subdivide into lots of sub-activities
Collecting the data
 As a rule, managers should try to break down long activities
into more controllable tasks of one or two weeks’ duration.
 Still it will be necessary to gather information about the
partially completed activities and, in particular, forecasts of
how much work is left to be completed.
 It can be difficult to make such forecasts accurately.
 Where there is a series of products, partial completion of
activities is easier to estimate.
Collecting the data cont ...

 For example, counting the number of record specifications or

screen layouts produced, can provide a reasonable measure of
progress.
 In some cases, intermediate products can be used as activity
milestones, e.g. the first successful compilation of a program,
might be considered a milestone, even though it is not a final
product.
Partial Completion Reporting
 Many organizations use standard accounting systems with
weekly timesheets to charge staff time to individual jobs.
 The staff time booked to a project indicates the work carried
out and the charges to the project.
 Drawback: It does not tell the project manager what has been
produced or whether tasks are on schedule.
 It is therefore common to adapt or enhance existing
accounting data collection systems to meet the needs of
project control.
Partial Completion Reporting cont ...
 Weekly timesheets, for example, are frequently adapted by
breaking jobs down to activity level and
◦ requiring information about work done in addition to time spent.
 The next figure shows an example of a report form
requesting information about likely slippage of completion
dates as well as estimates of completeness.
 A weekly
timesheet
and
progress review
form
Partial Completion Reporting cont ...
 Other reporting templates are also possible.
 For example, rather than asking for estimates of percentage
complete,
◦ some managers would prefer to ask for the number of hours already
worked on the task and an estimate of the number of hours needed to
finish the task off.
Red/Amber/Green reporting
 One popular way of overcoming the objections to partial
completion reporting is
◦ to avoid asking for estimated completion dates, but to ask instead for
the team members’ estimates of the likelihood of meeting the planned
target date.
 One way of doing this is the traffic-light method.
Red/Amber/Green reporting cont ...
This consists of the following steps:
◦ Identify the key (first level) elements for assessment in a piece of work.
◦ Break these key elements into constituent elements (second level).
◦ Assess each of the second-level elements on the scale
 green for ‘on target’,
 amber for ‘not on target but recoverable’, and
 red for ‘not on target and recoverable only with difficulty’.
◦ Review all the second-level assessments to arrive at first-level
assessments.
◦ Review first- and second-level assessments to produce an overall
assessment.
 Red/Amber/Green reporting
 Following completion of assessment forms for all activities,
the project manager uses these as a basis for evaluating the
overall status of the project.
 Any critical activity classified as amber or red will require
further consideration and often leads to a revision of the
project schedule.
 Non-critical activities are likely to be considered as a problem
if they are classified as red, especially if all their float is likely
to be consumed.
Sample
traffic
light
assessm
ent
Review
 From a manager’s perspective, review of work products is an
important mechanism for monitoring the progress of a
project and ensuring the quality of the work products.
 Every project is developed through iterations over a large
number of work products such as requirements document,
design document, project plan document, code etc.
 Each of these work products can have a large number of
defects in them due to mistakes committed by the
development team members.
Review cont …
 It is necessary to eliminate as many defects in these work
products to realize a product of acceptable quality.
 Testing is an effective defect removal mechanism.
 However, testing is applicable to only executable code.
 How can the defects from the non-executable work
products such as requirements document and design
document be removed?
 Review is a very effective technique to remove defects from
all work products including code.
Review cont …
 In fact, review has been acknowledged to be more cost-
effective in removing defects as compared to testing.
 Early review techniques focused on code and systematic
review techniques were developed for this specific purpose.
 But over the years, review techniques have become
extremely popular and have been generalized for use with
other work products.
Utility of Review
 A cost-effective defect removal mechanism.
 Review usually helps to identify any deviation from standards
including issues that might affect maintenance of the software.
 Reviewers suggest some ways to improve the work product
such as,
◦ using algorithms that are more time or space efficient,
◦ specific work simplifications,
◦ better technology opportunities that can be exploited, etc.
Utility of Review cont …
 In addition to defect identification, a review meeting often
provides learning opportunities to not only the author of a
work product, but also the other participants of the review
meeting.
◦ The lessons acquired from a review meeting allows participants to
avoid committing similar defects that were discussed in the review
meeting and also allows them to make use of the best practices that
were suggested.
 The review participants gain a good understanding of the
work product under review, making it easier for them to
interface or use the work product in their work.
Candidate work products for review

 All interim and final work products are usually candidates for
review.
 Usually, the work products considered to be suitable
candidates for review are as follows.
◦ Requirements specification documents
◦ User interface specification and design documents
◦ Architectural, high-level, and detailed design documents
◦ Test plan and the designed test cases
◦ Project management plan and configuration management plan
Review Roles
 In every review meeting, a few key roles need to be assigned
to the review team members.
 These roles are
◦ Moderator
◦ Recorder
◦ Reviewer
Moderator
 Plays a key role in the review process.
 The principal responsibilities include
◦ Scheduling and convening meetings
◦ Distributing review materials
◦ Leading and moderating the review sessions
◦ Ensuring that the defects are tracked to closure.
Recorder
 The main role is to record
◦ the defects found,
◦ the time and
◦ effort data
Reviewer
 The review team members
◦ review the work product and
◦ give specific suggestions to the author about the existing defects and
◦ also point out ways to improve the work product.
Review Process
 Review of any work product consists of the following four
important activities
◦ Planning
◦ Review preparation and overview
◦ Review meeting
◦ Rework and follow up
Review Process Model

Work product Review team and

Planning Preparation
schedule

Reviewer’s
logs

Summary report Rework and Defect log Review

follow-up meeting
Planning
• Once the author of the work product is ready for
submitting the work for review; the project manager
nominates a moderator.
• A moderator can be someone who is familiar with the work
product.
• In consultation with the moderator, a project manager
nominates the other members of the review team.
• Usually, the review process works best when the number of
members is between five and seven.
Planning cont …
The effectiveness of review drastically reduces if there are less
than three members. The review team is usually selected from
the following types of project team members.
• The author of preceding work product based on which the work
product under review was developed
• The member who would use the work product under review
• Peers of the author
• The authors of the work products that would interface with the work
product under review
The moderator usually schedules all review meetings.
Preparation
• To initiate the review process, the moderator convenes a
brief preparation meeting.
• In this meeting, copies of the work product are distributed
to the review team members. The author presents a brief
overview of the work product.
• The moderator highlights the objectives of the review.
• The reviewers then individually carry out review and record
their observations in review logs.
Review meeting
• In this meeting the reviewer’s give their comments based on
the logs. The author responds to the comments.
• Other reviewers also participate in the discussion.
• The recorder scribes all the defects and points that the
author agrees to and the review statistics in the form of a
review log.
Rework
• The author addresses all the issues raised by the reviewers
by carrying out necessary modifications to the work
products and prepares a rejoinder.
• The corrected work product along with the rejoinder is
circulated among all the review team members.
• In a final brief meeting, the review team members check
whether all the issues scribed in the review log have been
resolved satisfactorily.
• At the end of the meeting a final summary report is
prepared.
Data collection
• The results of the review meetings should be properly
recorded,
• The data about the time spent by the reviewers in the
review activity must also be captured.
• A record of the defect data is needed for tracking defects
in the project.
Data collection cont…
The different reports in which the review data are captured
are as follows:
• Review Preparation Log (contains data about defects, their
locations, their criticality, total time spent in doing the
review)
• Review log (contains the defects that are agreed to by the
author)
• Review summary report (summarizes of the review data
and presents an overall picture of the review. Contains
information regarding the total defects and the total time
spent)
Review Process

 The model captures the sequence of the activities that need

to be carried out, the input to the activities, and the output
produced from the activities.
Summary
 Discussed the importance and need of project monitoring and
control
 Explained the Project Control Cycle
 Presented the project reporting structures
 Explained how to assess the progress of a project
 Summary
• Discussed how to collect the progress details of a project
• Explained Partial Completion Reporting method
• Presented how to carry out project review
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. J. Henry, Software Project Management – A Real-World Guide to Success,
Pearson Education, 2004.
3. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning
Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Contents

 Code Review
 Code Walk Through
 Code Inspection
 Cleanroom Technique
 Visualizing the Progress of a project
 Gantt Chart
 Slip chart
 Time line chart
Candidate work products for review
 All interim and final work products are usually candidates for review.
 Usually, the work products considered to be suitable candidates for
review are as follows.
◦ Requirements specification documents
◦ User interface specification and design documents
◦ Architectural, high-level, and detailed design documents
◦ Source code
◦ Test plan and the designed test cases
◦ Project management plan and configuration management plan
Code Review
 Review is a very effective technique to remove defects
from source code.
 In fact, review has been acknowledged to be more cost-
effective in removing defects as compared to testing.
 Over the years, review techniques have become extremely
popular and have been generalised for use with other
work products.
Code Review cont...

 Code review for a module is undertaken after the module

successfully compiles, i.e. all the syntax errors have been
eliminated from the module.
 Obviously, code review does not target to design syntax
errors in a program, but is designed to detect logical,
algorithmic, and programming errors.
 Code review has been recognised as an extremely cost-
effective strategy for eliminating coding errors and for
producing high quality code.
Code Review cont...
 The reason behind why code review is a much
more cost-effective strategy to eliminate errors
from code compared to testing is that reviews
directly detect errors.
 On the other hand, testing only helps detect
failures and significant effort is needed to locate
the error during debugging.
Code Review cont...
 The rationale behind the above statement is explained as
follows. Eliminating an error from code involves three
main activities—testing, debugging, and then correcting
the errors.
 Testing is carried out to detect if the system fails to
work satisfactorily for certain types of inputs and under
certain circumstances. Once a failure is detected,
debugging is carried out to locate the error that is
causing the failure and to remove it.
Code Review cont...
 Of the three testing activities, debugging is
possibly the most laborious and time consuming
activity.
 In code inspection (which is a type of review),
errors are directly detected, thereby saving the
significant effort that would have been required to
locate the error.
Code Review cont...
Normally, the following two types of reviews are
carried out on the code of a module:
 Code walkthrough.
 Code inspection.
Code inspection and code walk through
 After a module has been coded,
◦ code inspection and code walk through are carried out
◦ ensures that coding standards are followed
◦ help detect as many errors as possible before testing.

10
Code inspection and code walk through
cont...
 Detect as many errors as possible during
inspection and walkthrough:
◦ detected errors require less effort for correction
 much higher effort needed if errors were to be
detected during integration or system testing.

11
Code Walk Through
 An informal code analysis technique.
◦ undertaken after the coding of a module is complete.
 A few members of the development team
select some test cases:
◦ simulate execution of the code by hand using these test
cases, i.e. the members mentally trace the execution
through different statements and functions of the code.

12
Code Walk Through cont...
 The members note down their findings of their code walk
through and discuss those in a walkthrough meeting.
 Even though it is an informal technique:
◦ several guidelines have evolved over the years
◦ making this naive but useful analysis technique more
effective.
◦ These guidelines are based on
 personal experience, common sense, and several
subjective factors.
13
Code Walk Through cont...
 The guidelines should be considered as
examples:
◦ rather than accepted as rules to be applied dogmatically.
 The team performing code walk through
should not be either too big or too small.
◦ Ideally, it should consist of between three to seven
members.
14
Code Walk Through cont...
 Discussion should focus on discovery of
errors:
◦ and not on how to fix the discovered errors.
 To foster cooperation:
◦ avoid the feeling among engineers that they are being
evaluated in the code walk through meeting,
◦ managers should not attend the walk through meetings.

15
Code Inspection
 In contrast to code walk through,
◦ code inspection aims mainly at discovery of the commonly
made errors that usually creep into code due to programmer
mistakes and oversights .
◦ also aims at checking adherence to coding standards.
 During code inspection:
◦ the code is examined for the presence of certain kinds of
errors,
◦ in contrast to the hand simulation of code execution done in
code walk through.
16
Benefits of code inspection
 Finds the commonly made errors
 Programmer receives feedback on
◦ programming style,
◦ choice of algorithm, and
◦ programming techniques

17
Code Inspection cont...
 For instance, consider:
◦ classical error of writing a procedure that modifies a
formal parameter
◦ while the calling routine calls the procedure with a
constant actual parameter.
 It is more likely that such an error will be
discovered:
◦ by looking for this kind of mistakes in the code,
◦ rather than by simply hand simulating execution of the
procedure.
18
Code Inspection cont...
 Good software development companies:
◦ collect statistics of errors committed by their engineers
◦ identify the types of errors most frequently committed.
 A list of common errors:
◦ can be used during code inspection to look out for
possible errors.

19
Examples of some commonly made errors
 Use of uninitialized variables.
 Use of incorrect logical operators or incorrect precedence among
operators.
 Non-terminating loops.
 Array indices out of bounds.
 Incompatible assignments.
 Improper storage allocation and deallocation.
 Actual and formal parameter mismatch in procedure calls.
 Jumps into loops
 Improper modification of loop variables, etc.
20
Cleanroom Technique
 Pioneered at IBM
 The term cleanroom was first coined at IBM by drawing
analogy to the semi-conductor fabrication units where the
defects are avoided by manufacturing in an ultra-clean
atmosphere.
 Relies heavily on walkthroughs, inspection and formal
verification for bug removal
 Programmers are not allowed to test any of their code by
executing the code other than doing some syntax testing
using a compiler 21
Cleanroom Technique cont ...
Pros:
• This technique reportedly produces documentation & code that
are more reliable and maintainable than other development
methods relying heavily on code execution based testing.
Cons:
 The testing effort is increased as walkthroughs, inspection and
verification are time consuming for detecting simple errors.
 Some errors might escape during manual inspection. Testing-
based error detection techniques may detect these errors.

22
Visualizing the Progress of a Project
 Having collected data about project progress, a manager
needs some way of presenting that data to greatest effect.
 Some methods of presenting a picture of the project and its
future.
◦ Methods that provide a static picture, a single snapshot (such as Gantt
charts)
◦ Methods that try to show how the project has progressed and changed
through time (such as timeline charts)
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, each bar consists of a unshaded part and a shaded
part.
Gantt chart
 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.
Gantt chart
 A Gantt chart is a special type of bar chart where each bar
represents an activity. The bars are drawn along a time line. The
length of each bar is proportional to the duration of time planned
for the corresponding activity.
 Gantt chart representation of a project schedule is helpful in
planning the utilisation of resources, while PERT chart is useful for
monitoring the timely progress of activities.
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.
Activity network representation of MIS problem
Gantt chart representation of the MIS problem
 Gantt chart
 One of the simplest and oldest techniques for tracking
project progress is the Gantt chart.
 This is essentially an activity bar chart indicating scheduled
activity dates and durations, frequently augmented with
activity floats (Activity float is the time by which an activity
may be delayed without affecting any subsequent activity).
 Reported progress is recorded on the chart (normally by
shading activity bars) and a ‘today cursor’ provides an
immediate visual indication of which activities are ahead or
behind schedule.
A Sample Gantt chart
Gantt chart cont …
 The figure shows a sample Gantt chart as at the end of
Tuesday of week 17.
 ‘Code and test module D’ has been completed ahead of
schedule and ‘Code and test module A’ appears also to be
ahead of schedule.
 The coding and testing of the other two modules are behind
schedule.
 The slip chart
• A slip chart is a very similar alternative favoured by some
project managers who believe
– it provides a more striking visual indication of those activities
that are not progressing according to schedule,
• the more the slip line bend, the greater the variation from the plan.
• Additional slip lines are added at intervals and, as they build
up, the project manager will gain an idea as to whether the
project is improving (subsequent slip lines bend less) or not.
• A very jagged slip line indicates a need for rescheduling.
A sample slip chart
The slip chart cont …
 To the left of the line are all the completed activities
and to the right those activities that have not been
completed.
 The more jagged the line, the more it means that
that there are some activities that are lagging to
various degrees and some that are ahead of
themselves.
 A very jagged line means that there is scope for re-
planning to move resources from those activities
that are ahead to those that are behind.
 The timeline chart
• One disadvantage of Gantt chart and Slip chart is that they do not
show clearly the slippage of the project completion date through
the life of the project.
• Analysing and understanding trends in the project so far, allows us
to predict the future progress of the project.
• For example, if a project is behind schedule because so far
productivity has not been as high as assumed at the planning stage,
it is likely that the scheduled completion date will be pushed back
even further, unless action is taken to compensate for or improve
productivity.
• The timeline chart is a method of recording and displaying the way
in which targets have changed throughout the duration of the
project.
A sample timeline chart
The timeline chart cont …
• The figure shows a sample time line chart at the end of the
sixth week.
• Planned time is plotted along the horizontal axis and
elapsed time down the vertical axis.
• The lines meandering down the chart represent scheduled
activity completion dates
– At the start of the project ‘analyse existing system’ is scheduled to
be completed by the Tuesday of week 3,
– ‘obtain user requirements’ by Friday of week 5
– ‘issue tender’, the final activity, by Tuesday of week 9, and so on.
The timeline chart cont …
• At the end of the first week, the project manager reviews
these target dates and leaves them as they are
– lines are therefore drawn vertically downwards from the
target dates to the end of week 1 on the actual time axis.
• At the end of week 2, he decides that ‘obtain user
requirements’ will not be completed until Tuesday of week 6
– he therefore extends that activity line diagonally to reflect this.
• The other activity completion targets are also delayed
correspondingly.
The timeline chart cont …
• By the Tuesday of week 3, ‘analyse existing system’ is completed and
the project manager puts a blob on the diagonal timeline to
indicate that this has happened.
• At the end of week 3 he decides to keep to the existing targets.
• At the end of week 4 he adds another 3 days to ‘issue tender’.
• Note that by the end of week 6, two activities have been completed
and three are still unfinished.
• Up to this point she has revised target dates on three occasions
and the project as a whole is running almost one week late.
The timeline chart cont …
 The timeline chart is useful both during the execution of a
project and as part of the post-implementation review.
 Analysis of the timeline chart, and the reasons for the changes,
can indicate failures in the estimation process or other errors
that might, with that knowledge, be avoided in future.
Summary
• Discussed two important code review techniques such as
code walk through and code inspection.
• Presented a list of some commonly made errors which
can be detected by code review.
• Discussed briefly Cleanroom Technique .
• Discussed various ways to visualize the progress of a
project such as
 Gantt chart,
 Slip chart and
 Time line chart.
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth
Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning
Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Contents
• Cost monitoring
• Earned value analysis
• Baseline budget
• Monitoring earned value
Cost monitoring
 A project could be late because the staff originally committed
have not been deployed
 In this case the project will be behind time but under budget
 A project could be on time but only because additional
resources have been added and so be over budget
 So, there is a need to monitor both achievements and costs
Cost monitoring cont ...
 Expenditure monitoring is an important component of project
control, not only in itself, but also because it provides an indication
of the effort that has gone into (or at least been charged to) a
project.
 A project might be on time but only because more money has
been spent on activities than originally budgeted.
 A cumulative expenditure chart provides a simple method of
comparing actual and planned expenditure.
 By itself it is not particularly meaningful.
◦ A project may run late or on time but the chart shows
substantial costs savings.
Tracking cumulative expenditure
Cost monitoring cont ...
• We need to take account of the current status of the
project activities before attempting to interpret the meaning
of recorded expenditure.
• Cost charts become much more useful,
• if we add projected future costs calculated by adding the estimated
costs of uncompleted work to the costs already incurred.
• Where a computer-based planning tool is used, revision of
cost schedules is provided automatically,
• once the actual expenditure has been recorded.
The cumulative expenditure
Cost monitoring cont ...
 The figure illustrates the additional information available
once the revised cost schedule is included
◦ In this case it is apparent that the project is behind schedule and
over budget.
 The figure also shows the revised estimates of cost and
completion date.
Earned value analysis

• Earned value analysis has gained in popularity in recent years

and may be seen as a refinement of cost monitoring.
• It originated in the USA’s Department of Defence (DOD) as
a part of a set of measures to control projects being carried
out by contractors for the DOD.
• It is based on assigning a ‘value’ to each task or work
package,
• based on the original expenditure forecasts.
Earned value analysis cont ...

• One way of looking at this is as the equivalent of the price

that might be agreed by a contractor to do some unit of
work.
• The assigned value is the original budgeted cost for the item
and is known as the planned value (PV) or budgeted cost of
work scheduled (BCWS).
• A task that has not started is assigned an earned value of
zero and when it has been completed, it, and hence the
project, is credited with the original planned value of the task.
Earned value analysis cont ...
• The total value credited to a project at any point is known as
the earned value(EV) or budgeted cost of work performed
(BCWP) and this can be represented as a money value, an
amount of staff time or as a percentage of the PV.
• EV is thus analogous to the agreed price to be paid to the
contractor once the work is completed.
Earned value analysis cont ...
 Where tasks have been started but are not yet complete,
some consistent method of assigning an earned value must
be applied.
 Some common methods, in case of software projects, are
◦ The 0/100 technique
◦ The 50/50 technique
◦ The 75/25 technique
◦ The milestone technique
◦ The percentage complete technique
Earned value analysis cont ...

 The 0/100 technique is preferred for software development.

 The 50/50 technique can give a false sense of security by
over-valuing the reporting of activity starts.
 The milestone technique might be appropriate for activities
with a long duration estimate,
◦ but, in such cases, it is better to break that activity into a number of
smaller ones.
The 0/100 technique
 A task is assigned a value of zero until such time that it is
completed, when it is given a value of 100% of the budgeted
value.
 The 50/50 technique
 A task is assigned a value of 50% of its value as soon as it is
started and then given a value of 100% once it is complete.
◦ Example: In some contractual arrangements where a contractor is given
half the agreed price when starting the work, perhaps to help pay for
raw materials, and the remainder on successful completion.
The 75/25 technique
 The task is assigned 75% on starting and 25% on completion
◦ Example: This is often used when a large item of equipment is being
bought:
 75% is paid when the equipment is actually delivered and the rest when
installation and testing have been satisfactorily completed.
 The milestone technique
 A task is given a value based on the achievement of
milestones that have been assigned values as part of the
original budget plan.
 Example: On completion of SRS document some value is
assigned, then after DFD / UML Diagrams, some value is
assigned, then after coding is over, some value is assigned.
The rest is assigned, after completion of testing and
installation.
 The percentage complete
 In some cases there may be a way of objectively measuring
the amount of work completed
◦ Example: As part of the implementation of a student information
system, a number of data records have to be manually typed into a
database.
◦ The actual number so far completed can be objectively counted and
the value can be assigned accordingly.
 Earned value analysis cont ...
 Planned value (PV) or Budgeted cost of work scheduled (BCWS)
– original estimate of the effort/cost to complete a task
(compare with idea of a ‘price’)
 Earned value (EV) or Budgeted cost of work performed
(BCWP) – total of PVs for the work completed at this time
The baseline budget
 The first step in setting up an earned value analysis is to
create the baseline budget.
 The baseline budget is based on the project plan and shows
the forecast growth in earned value through time.
 Earned value may be measured in monetary values but, in
the case of staff-intensive projects such as software
development, it is common to measure earned value in
person-hours and workdays.
The baseline budget
 The baseline budget cont ...
• The example baseline budget uses 0/100 technique for
crediting earned value to the project.
• This project is not expected to be credited with any earned
value until day 34, when the activity ‘specify overall system’
is to be completed.
• This activity was forecast to consume 34 person-days and it
will therefore be credited with 34 person-days of earned
value when it has been completed.
• The other steps in the baseline budget chart coincide with
the scheduled completion dates of other activities.
Monitoring earned value
 Having created the baseline budget, the next task is to
monitor earned value as the project progresses.
 This is done by monitoring the completion of tasks (or
activity starts and milestone achievements in the case of the
other crediting techniques).
 As well as recording EV, the actual cost of each task can be
collected as actual cost (AC).
 This is also known as the actual cost of work performed
(ACWP).
An earned value tracking chart
Monitoring earned value
 The figure illustrates the following performance
statistics, which can be shown directly or
derived from the earned value.
◦ Schedule variance (SV)
◦ Time variance (TV)
◦ Cost variance (CV)
◦ Performance ratios
Schedule variance (SV)
• The schedule variance is measured in cost terms as SV =
EV-PV
• It indicates the degree to which the value of completed
work differs from that planned.
• Say, for example, that work with a PV of ₤40,000 should
have been completed by now. In fact, some part of that work
has not been done, so that the EV is only ₤35,000.
• So, SV = ₤35,000- ₤40,000 = - ₤5,000.
• A negative SV means the project is behind schedule.
Time variance (TV)
 This is the difference between the time when the
achievement of the current earned value was
planned to occur and the time now.
 In this case, the current EV should have been
achieved in the early part of month 9 and as the
time now is the end of month 11,
◦ So, the TV is about -1.75 months.
◦ TV negative indicates project is running late.
 Cost variance (CV)
• This is calculated as CV = EV-AC
• It indicates the difference between the earned value or
budgeted cost and the actual cost of completed work.
• Say that when the SV above was calculated as -₤5,000,
₤55,000 had actually been spent to get the EV.
• So, in this case CV=₤35,000- ₤55,000 = - ₤20,000.
• It can also be an indicator of the accuracy of the original
cost estimates.
• A negative CV means that the project is over cost.
Performance ratios
 Two ratios are commonly tracked:
◦ The cost performance index (CPI=EV/AC)
◦ The schedule performance index (SPI=EV/PV)
 Using the examples,
◦ CPI would be ₤35,000/ ₤55,000, that is, 0.64
◦ SPI would be ₤35,000/ ₤40,000, that is, 0.88
 The two ratios can be thought of as a ‘value-for-money’
indices.
 A value greater than one indicates that work is being
completed better than planned, whereas a value of less
than one means that work is costing more than and/or
proceeding more slowly than planned.
Performance ratios cont ...
 CPI can be used to produce a revised cost estimate for the
project, called estimate at completion (EAC).
 EAC is calculated as BAC/CPI, where BAC (budget at
completion) is the current projected budget for the project.
 If the BAC was ₤100,000 then a revised estimate at
completion (EAC) would be ₤100,000/0.64 or ₤156,250.
 Similarly, the current SPI can be used to project the possible
duration of the project given the current rate of progress.
Performance ratios cont ...
 Suppose the planned duration is 23 months – in earned
value terminology, this is known as schedule at completion
(SAC).
 A time estimate at completion (TEAC) can be calculated as
SAC/SPI.
 In this case,TEAC= 23/0.88=26.14 months.
 This is only an approximate guide.
 Where there are several parallel chains of activities being
carried out concurrently,
 the project duration will depend on the degree to
which the activities that have been delayed are on the
critical path.
An earned value chart with revised forecasts
Performance ratios cont ...
• Earned value analysis has not yet gained universal
acceptance for use with software development projects,
– perhaps largely because of the attitude that, whereas a
half-built house has value reflected by the labour and
materials that have been used,
• a half-completed software project has virtually no
value at all.
• This is to misunderstand the purpose of earned value
analysis, which is a method for tracking what has been
achieved on a project
– Measured in terms of the budgeted costs of completed
tasks or products.
Earned value – an example
 Tasks with planned / estimated days
◦ Specify module 5 days
◦ Code module 8 days
◦ Test module 6 days
 At the beginning of day 20, PV = 19 days
 If everything but testing, completed EV = 13 days
 Schedule variance (SV) = EV-PV = 13-19 = -6
 Schedule performance indicator (SPI) = EV / PV = 13/19 =
0.68
 SV negative or SPI <1.00, indicates project is behind
schedule.
Earned value analysis – actual cost
 Actual cost (AC) is also known as Actual cost of work
performed (ACWP)
 In previous example, if

◦ ‘Specify module’ actually took 3 days

◦ ‘Code module’ actually took 4 days
 Actual cost = 7 days
 Cost variance (CV) = EV-AC = 13-7 = 6 days
 Cost performance indicator (CPI) = EV/AC = 13/7 = 1.86
 Positive CV or CPI > 1.00 means project is within budget.
Earned value analysis – actual costs
cont ...
 CPI can be used to produce new cost estimate
 Budget at completion (BAC) – current budget allocated to total costs
of project
 Estimate at completion (EAC) – updated / revised estimate = BAC/CPI
◦ e.g. say budget at completion is £19,000 and CPI is 1.86
◦ EAC = BAC/CPI = £10,215
◦ Projected costs reduced because work being completed
in less time
Earned value analysis - Time Variance
Example
 Time variance (TV) – difference between time when
specified EV should have been reached and time it
actually was
 For example, say an EV of £19000 was supposed to have
been reached on 1st April and it was actually reached on
1st July then TV = - 3 months
 TV negative indicates project is running late.
 Another Example
 Suppose a project is to be completed in one year at the
cost of Rs. 100,000. After 3 months, the manager realized
that the project is 30% complete at a cost of Rs. 40,000.
Assess the performance of the project.
Another Example ---- solution
 Planned value (PV) = planned percentage completion of
work X Budgeted cost = 25% X Rs.100,000 = Rs. 25,000.
 Earned value (EV) = percentage work actually completed
X Budgeted cost = 30% X Rs. 100,000 = Rs. 30,000.
 Cost performance index(CPI) = EV/Actual Cost incurred
= EV/AC =Rs.30,000/Rs.40,000 = 0.75
 Schedule performance Index (SPI)= EV/PV
=Rs.30,000/Rs.25,000 = 1.2
 Another Example ---- solution
 Assessment of project performance:
 Since CPI <1, the project is over budget. For every rupee
spent, we are getting only 0.75 worth of work.
 Since SPI >1, it indicates that the project is ahead of
schedule.
 At this rate, the project will be delivered ahead of
schedule, but at over budget.
 So, corrective action needs to be taken
 Summary
• Presented basic concepts of cost monitoring
• Discussed briefly earned value analysis
◦ The 0/100 technique
◦ The 50/50 technique
◦ The 75/25 technique
◦ The milestone technique
◦ The percentage complete technique
• Presented the concept baseline budget
 Summary
• Discussed monitoring of earned value through
◦ Schedule variance (SV)
◦ Time variance (TV)
◦ Cost variance (CV)
◦ Performance ratios

• Explained the above with suitable examples

References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
 Contents
• Prioritizing monitoring
• Getting the project back to target
Prioritizing monitoring
So far we have assumed that all aspects of a project will receive
equal treatment in terms of the degree of monitoring applied.
We might focus more on monitoring certain types of activity
e.g.
• Critical path activities
• Activities with no free float – if delayed later dependent activities are
delayed
• Activities with less than a specified float
• High risk activities
• Activities using critical resources
Critical path activities
 Any delay in an activity on the critical path will cause a
delay in the completion date for the project.
 Critical path activities are therefore likely to have a very
high priority for close monitoring.
Activities with no free float
 Free float – It is the amount of time that an activity may be
delayed without affecting any subsequent activity.
 A delay in any activity with no free float will delay at least
some subsequent activities even though, if the delay is less
than the total float, it might not delay the project completion
date.
 These subsequent delays can have serious effects on the
resource schedule,
◦ as a delay in a subsequent activity could mean that the resources for
that activity will become unavailable before that activity is completed.
 So these activities should be given priority while monitoring.
Activities with less than a specified float

 If any activity has very little float it might use up this float
before the regular activity monitoring brings the problem to
the project manager’s attention.
 It is a common practice to monitor closely those activities
with less than, say, one week free float.
 High risk activities
 A set of high-risk activities should have been identified as part
of the initial risk profiling exercise.
 If we are using the PERT, we should designate as high risk to
those activities that have a high estimated duration variance.
 These activities will be given close attention,
◦ because they are most likely to overrun or overspend.
Activities using critical resources
 Activities can be critical because they are very expensive (as
in the case of specialized contract programmers).
 Staff or other resources might be available only for a limited
period, especially if they are controlled outside the project
team.
 In any event, an activity that demands a critical resource,
requires a high level of monitoring.
Getting the project back to target
• Almost any project will, at one time or another, be subject
to delays and unexpected events.
• One of the tasks of the project manager is to recognize
when this is happening (or, if possible, about to happen) and,
with the minimum delay and disruption to the project team,
attempt to mitigate the effects of the problem.
• In most cases, the project manager, at least initially, tries to
ensure that the scheduled project end date remains
unaffected.
• This can be done by shortening remaining activity durations
or shortening the overall duration of the remaining project.
Getting the project back to target cont ...
• This might not always be the most appropriate response to
disruptions to a plan.
• There is little point in spending considerable amount in
overtime payments in order to speed up a project,
• if the customer is not overly concerned with the delivery date, and
• there is no other valuable work for the team members once this
project is completed.
• There are two main strategies to consider when drawing up
plans to bring a project back on target.
– Shortening the critical path
– Altering the activity precedence requirements
Shorten the critical path
 The overall duration of a project is determined by the
current critical path,
◦ so speeding up non-critical path activities will not bring forward a
project completion date.
 There are several ways in which this might be done.
◦ Adding resources - especially staff
◦ Increase use of current resources
◦ Reallocate staff to critical activities
◦ Reduce scope
◦ Reduce quality
Shorten the critical path
 By such means, we can attempt to shorten the timescale for
critical activities until such time as either we have brought
the project back to schedule or further efforts prove
unproductive or not cost-effective.
 Remember, however, that shortening a critical path often
causes some other path, or paths, to become critical.
Adding resources- especially staff
 Exhorting staff to ‘work harder’ might have some effect,
◦ it is better to follow a more positive form of action, such as increasing
the resources available for some critical activity.
 For example, fact-finding, might be speeded up by allocating
an additional analyst to interviewing users.
 But, it is unlikely, that the coding of a small module would be
shortened by allocating an additional programmer
◦ indeed, it might be counterproductive because of the
additional time needed for organizing and allocating tasks
and communicating.
Adding resources- especially staff
 While adding more staff may be able to speed up progress,
this would be at an additional cost.
 In EV terms, negative schedule variance (SV) may be
reduced, but at the price of increasing a negative cost
variance (CV).
Increase use of current resources

 Resource levels can be increased by making them available

for longer period.
 Thus, staff might be asked to work overtime for the
duration of an activity and computing resources might be
made available at times (such as evenings and weekends)
when they might otherwise be inaccessible.
Reallocate staff to critical activities
 The project manager might consider allocating more
efficient staff to activities on the critical path or swapping
resources between critical and non-critical activities.
 When a project is actually executed, the critical path may
change,
◦ as the actual durations of activities will vary from the original
estimates and staff allocations may be adjusted to reflect this.
Reduce scope
 The amount of work to be done could be reduced by
reducing the scope of the functionality to be delivered.
 The client may prefer to have a subset of the promised
features on time
◦ Especially if they are the most useful ones.
 Rather than have the delivery of the whole application delayed.
Reduce quality
 Some quality-related activities such as system testing could
be curtailed.
 This would probably lead to more corrective work having
to be done to the ‘live’ system once it has been
implemented.
Reconsider the precedence requirements
 If attempting to shorten critical activities proves insufficient,
the next step is to consider the constraints by which some
activities have to be deferred pending completion of others.
 The original project network would most probably have
been drawn up assuming ‘ideal’ conditions and ‘normal’
working practices.
 It might be that, to avoid the project delivering late, it is now
worth questioning whether as yet unstarted activities really
do have to await the completion of others.
Reconsider the precedence requirements
cont ...
 It might, in a particular organization, be ‘normal’ to complete
system testing before commencing user training.
 Example: In order to avoid late completion of a project it
might, however, be considered acceptable to alter ‘normal’
practice and start training earlier.
Reconsider the precedence requirements
cont ...
• One way to overcome precedence constraints is to
subdivide an activity into a component that can start
immediately and one that is still constrained as before.
• For example, a user handbook can be drawn up in a draft
form from the system specification and then be revised later
to take account of subsequent changes.
• If we decide to alter the precedence requirements in such a
way,
• the quality might be compromised and
• it may be required to make a consensus decision to compromise the
quality, wherever needed.
Reconsider the precedence requirements
cont ...
 It is equally important to assess the degree to which changes
in work practices increase risk.
 For example, it is possible, to start coding a module before its
design has been completed.
 It would normally, however, be considered foolhardy to do so
since,
◦ it may lead to compromising the quality, and
◦ it may increase the risk of having to redo some of the coding, once the
final design had been completed and thus delay the project further.
Getting back on track: options in nut shell
 Renegotiate the deadline – if not possible then
 Try to shorten critical path e.g.
◦ Work overtime
◦ Re-allocate staff from less pressing work
◦ Buy in more staff
 Reduce scope of the work
 Reduce the quality
 Reconsider activity dependencies
◦ Over-lap the activities so that the start of one activity doesn’t have
to wait for completion of another
◦ Split activities
Summary
• Discussed the priorities that might be applied while
monitoring different activities.
• Also, discussed how to get the project back to target.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
 Contents
• Change control
• Software configuration management
Change control
• When a document such as the user requirements is being
developed, there may be many different versions of the
document as it undergoes cycles of development and
review.
• Any change control process at this point would be very
informal and flexible.
• At some point of time, the final version will be created. This
is baselined, effectively frozen .
Change control cont...

• Baselined products are the foundation for the development

of further products
– for instance, interface design documents may be developed from
baselined user requirements.
 Change control cont ...
 Any changes to the baselined document could have knock-
on effects on other parts of the project.
 For this reason subsequent changes to baselined
documents need to be stringently controlled.
Steps in Change control procedure
• One or more users might perceive a need for a modification
to a system and ask for a change request to be passed to the
development staff.
• The user management would consider the change request
and, if they approve it, pass it to the development
management.
– There is a single authorized channel for requests for change (RFCs)
between the client community and the management of the
developers.
– There would be some filtering within the client community to ensure
that the proposed change does genuinely provide a benefit before the
RFC is generated.
Steps in Change control procedure cont ...
• There would be one person within the development area
who would receive and process RFCs.
– They would delegate a member to look at the request and to report
on the practicality and cost of carrying out the change.
– The developer would assess the products that would be affected by
the change.
• The development representative would report back to the
user management on the findings and the user management
would decide whether, in view of the cost quoted, they wish
to go ahead or not.
Steps in Change control procedure cont ...

• There would be some individual or group (may be Project

Board) who represented the major stakeholders, both users
and developers and also the project sponsor, who would
have the authority to prioritize the RFCs for action.
• A further step is to give the project managers allowances
that would allow them accept minor changes (as long as they
are documented with an RFC, etc.) as long as they do not
exceed planned cost and delivery targets.
Steps in Change control procedure cont ...

• A very large number of seemingly small changes could have

a serious accumulative effect on project progress which may
call for the attention of higher management.
• A very large set of changes might trigger the project
manager to produce an exception report.
Steps in Change control procedure cont ...
 Once an RFC has been approved for action, one or more
developers are authorized to take copies of the master
products that are to be modified (not the master products).
◦ This would need to be done through the configuration librarian.
 The copies are modified.
◦ In the case of software components, this would involve modifying the code
and recompiling and testing it.
Steps in Change control procedure cont ...
 When the development of new versions of the product has
been completed
◦ the user management will be notified and copies of the software will
be released for user acceptance testing.
 When the user is satisfied that the products are adequate,
they will authorize their operational release.
◦ The master copies of configuration items will be replaced.
Duties of configuration librarian, configuration
manager or project librarian
 Identification of all items that need to be subject to change
control
 Establishment and management of a central repository of
the master copies of all project documentation and software
products
 Setting up and running of a formal set of procedures to deal
with changes
 Maintenance of records of who has access to which library
items and the status of each library item (e.g. whether under
development, under test or released)
Typical change control process
1. One or more users might perceive the need for a change
2. User management decide that the change is valid and
worthwhile and pass it to development management
3. A developer is assigned to assess the practicality and cost of
making the change
4. Development management reports back to user
management on the cost of the change; user management
decides whether to go ahead based on the cost of change.
Change control process cont...
5. One or more developers are authorized to make copies
of components to be modified
6. Copies are modified (not the original version). After initial
testing, a test version might be released to users for
acceptance testing
7. When users are satisfied, then operational release is
authorized – master configuration items are updated
Software Configuration Management (SCM)
• Changes in a project can take place in any of the work
products and may be due to many reasons such as bug fix,
changes on account of work simplification, efficiency
considerations, etc.
• Change management can be done manually by a designated
configuration librarian.
• However, the manual change management process gets
overwhelmed
– when we consider changes taking place on all work products and
– when there are multiple variants of the product.
Software Configuration Management (SCM)
• In this situation, a systematic software configuration
management (SCM) process with appropriate tool support
needs to be deployed.
• SCM is concerned with tracking and controlling changes to
a software.
• In any systematic development and maintenance
environment:
– Various work products (such as code, design document, code, etc.)
associated with the software continually change during the
development as well as the maintenance phase.
Software Configuration Management (SCM)
• In a team development environment, each member of the
development or maintenance team would be assigned to
handle some modification requests.
• Therefore every work product would have to be accessed
and modified by several members.
• In such a situation, unless a proper configuration
management system is deployed, several problems can
appear.
What is configuration management?
 The set of activities through which the configuration items
are managed and maintained
◦ as the product undergoes its life cycle phases.
Context in which Configuration Management is necessary

• During the development phase, the work products get

modified as development activities are carried out.
• During the maintenance phase, the work products change
due to various types of enhancements and adaptations that
are carried out including bug fixes.
• Thus, the state of the work products continually change
both during the development as well as maintenance phase.
Context in which Configuration Management is
necessary cont …
• The state of all work products at any point of time is called
the configuration of the software product.
• Software configuration management deals with effectively
tracking and controlling the configuration of a software
product during its entire life cycle.
Context in which Configuration Management is
necessary
 For effective configuration management, it is necessary to
deploy a configuration management tool.
 There are many configuration management tools available,
some are open software, i.e. free of any licensing fees, and
others are commercial tools.
 Configuration management practices include version control
and the establishment of baselines.
Configuration
• The configuration of software is the state of various work
products that are under configuration control.
• The work products that are under configuration control are
usually referred to as the configuration items.
• It is convenient to think of a configuration as a set of files
representing various work products.
• For example, the configuration of a sample software product
shown in next figure consists of the configuration items
(work products) W1, W2, …,Wn.
Work product modifications under configuration management

W1 W2 W3 … Wn-1 Wn

Configuration
Reserve
Restore

Developer’s work space

Version
 As development and maintenance activities are carried out
on a software product, its configuration (that is, one or
more configuration items) keeps changing.
 It often becomes necessary to refer to the configuration
that existed at certain point of time.
 For example, we can say that refer to the last week’s
configuration of the software.
Version cont …
 Therefore, a version is a configuration that existed at
certain point in time.
 More technically, versioning is a numbering scheme that
helps us identify a specific configuration at a certain point
in time.
 This is achieved by a configuration tool by tagging the files
resenting the configuration items with the version name.
Version cont …
• As a software is released and used by the customers:
– errors are discovered,
– enhancements to the functionalities might be needed.
• A new release of the software is an improved system
intended to replace an old one.
• Usually a product is described as version m and
release n (or as version m.n)
Revision
• A revision system is a numbering scheme that is used to
identify the state of a configuration item at any time.
• Each time a work product is updated, its state changes.
• Thus, we can think of a work product going through a series
of updates till it reaches a desired state.
• The successive states of a work product are its successive
revisions.
• Thus each time a configuration item is updated, a new
revision gets formed.
• It becomes possible to refer to a specific state of a work
product by using its revision number.
Baseline
 A baseline is a software configuration that has been formally
reviewed and agreed upon, and serves as a basis for further
development.
Variant

 Variants are versions that are intended to coexist.

 Different variants may be needed to run the software on
different operating systems or on different hardware
platforms.
 For example, one variant of a mathematical computation
package might run on Unix-based machines, another on
Microsoft Windows machines, and another on Solaris.
Variant cont …
 Variants may also be required to be created when the
software is intended to be used with different levels of
sophistication of the functionalities (e.g., novice version,
enterprise version, professional version, etc.).
 Variants are often created during the operation phase,
during the development phase, and as and when software
products with overlapping functionalities are required.
 Even the initial delivery of software might consists of
several versions and more variants may be created later.
Purpose of SCM
 Problems associated with concurrent access
 Undoing Changes
 System accounting
 Handling variants and helping fix bugs in them
 Accurate determination of project status
 Preventing unauthorized access to the work products
 Problems associated with concurrent access
• Possibly, the most important reason for configuration
management is to control the access to the different
deliverable objects.
• Unless strict discipline is enforced regarding update and
storage of different work product, several problems can
appear.
• Let us assume that only a single copy of a program module
is maintained, and several developers are working on it.
• Two developers may simultaneously carry out changes to
the different functions of the same work product, and while
saving overwrite each other.
Undoing Changes
 It becomes easy to undo some part of a revision or even
rollback development to a certain version.
 Unless proper configuration management system is in place,
it becomes very difficult to undo a change.
System accounting
• System accounting denotes keeping track of who made a
particular change to a configuration item, what change was
exactly made, and when the change was made.
• Knowing the what, who, and when of changes will help in
understanding why changes were made and whether some
changes are redundant or for comparing the performance
of particular versions.
• It may at times be required to rollback to a previous
baseline if a change is not justified or is improper.
System accounting cont …
• Users may wish to compare today’s version of some
software with yesterday’s version or last year’s version.
• Since a configuration management system keeps track of
every version and revision, this becomes a simple task.
Handling variants
• It often becomes necessary to create variants.
• Without a configuration management system, keeping
track of all variants, their versions and revisions is a
nontrivial task.
• Further, existence of variants of a software product causes
some peculiar problems.
• Suppose you have several variants of the same module, and
find that a bug exists in one of them. Then it has to be
fixed in all versions and revisions.
Handling variants
• To do it efficiently, you should not have to fix it in each and
every version and revision of the software separately.
• Making a change to one program should be reflected in all
relevant versions and revisions.
Accurate determination of project status
 Normally, a project manager performs the configuration
management activity by using a configuration management
tool.
 In addition, a configuration management tool helps to keep
track of various deliverable objects so that the project
manager can quickly and unambiguously determine the
current state of the project.
 The configuration management tool enables the developer
to change the various components in a controlled manner.
Preventing unauthorized access to the work products
 Configuration management helps implement a controlled
change process.
 It therefore becomes possible to prevent unauthorized
changes to the work products.
 Summary

• Discussed the need of change control.

• Also discussed the change control procedure.
• Explained the concept of software configuration
management, the context in which it is necessary and it’s
purpose.
References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Contents

• Configuration Management Process

• Configuration Management Tools
• Project management tools
Configuration management process
 Configuration management is carried out through the
following two principal activities.
◦ Configuration identification
 Involves deciding which parts of the system should be kept under
configuration management
◦ Configuration control
 Used to ensure that changes to a system occur smoothly.
Configuration identification
• Project managers normally classify the work products
associated with a software development process into three
main categories
– Controlled
– Pre-controlled
– Uncontrolled
• Controlled work products are those that are put under
configuration control
– Team members must follow some formal procedures to change
these.
• Pre-controlled work products are not yet under
configuration control, but will eventually be under
configuration control.
Configuration identification cont …

• Uncontrolled work products will not be subject to

configuration control.
• Controllable work products include both controlled and pre-
controlled work products.
Configuration identification cont …
• Typical controllable work products include the following
– Requirements specification document
– Design documents
– Tools used to build the system such as compilers, linkers, lexical
analysers, parsers, etc.
– Source code for each module
– Test cases
– Problem reports
Configuration control
• Configuration control is the part of configuration
management system that most directly affects the day-to-
day operations of developers.
• Configuration control allows only authorized changes to
the controlled objects and prevents unauthorized changes.
• The project manager can give permission to some
members to be able to change or access specific work
products.
• In order to change a controlled work product such as a
code module, a developer can get a private copy of the
module through a reserve operation.
Configuration Control cont …
 Two main operations:
◦ Reserve
◦ Restore

W1 W2 W3 … Wn-1 Wn

Reserve Configuration
Restore

Developer’s work space

Configuration Control cont …
 Configuration management tools allow only one team
member to reserve a module at any time.
 Once a work product is reserved, it does not allow anyone
else to reserve this module until the reserved module is
restored.
 Thus, by preventing more than one developer to
simultaneously reserve a module, the problems associated
with concurrent access are taken care of.
Modifications to a work product under configuration
control
• When developers need to change a work product, they first
make a reserve request.
• A reserve request by a team member is honoured only if
appropriate authorization has been given by the project
manager to that member for the specific work product.
• After the reserve command successfully executes, a private
copy of the work product is created in their local directory.
• Then they carry out all necessary changes to the work
product on their private copy.
Modifications to a work product under configuration
control cont...
• Once they have satisfactorily completed all necessary
changes, the changes need to be restored in configuration
management repository.
• However, restoring the changed work product to the system
configuration requires the permission of a change control
board (CCB).
• CCB is usually constituted from among the development
team members.
• For every change that needs to be carried out, the CCB
reviews the changes made to the controlled work product
and certifies certain aspects about the change such as:
Modifications to a work product under configuration
control cont...
 Change is well-motivated
 Developer has considered and documented the effects of
the change
 Changes interact well with the changes made by other
developers
 Appropriate people (may be CCB) have validated the
change, e.g. someone has tested the changed code, and has
verified that the change is consistent with the need.
Modifications to a work product under configuration
control cont...
• The change control board (CCB) is a group of people.
• Except for vary large projects, the functions of the change
control board are normally discharged solely by the project
manager or some senior member of the development team.
• Once the CCB reviews the changes to the module and
approves them, the project manager updates the old
configuration item through a restore operation.
Modifications to a work product under configuration
control cont...

• A configuration control tool does not allow a developer to

replace a work product in the configuration with his local
copy unless he gets an authorization from the CCB.
• Therefore, incompletely modified or improperly modified
work products cannot be updated in the configuration.
Release Management

• Release Management process which systemizes the work

carried out by developers to provide a new release of a
software and on the part of the users to smoothly obtain
and use a new release.
• The release process should involve minimal effort on the
part of the developer to upload a new release of a software
and on the part of the users to effortlessly download and
install it.
Release Management cont ...
• For example, when a new version of the system is to be
released, a tool should automatically determine the changed
components, the dependencies, and all interdependent
components should be retrievable as a group so that there is
no possibility of inconsistency.
• Also retrievals of unnecessary and unchanged components
should be avoided.
Open source configuration management tools
• Two popular configuration management tools on UNIX
systems
– SCCS (Source Code Control System)
– RCS (Revision Control System)
• SCCS or RCS can be used for controlling and managing
different versions of text files.
• SCCS and RCS do not handle binary files (i.e., executable
files, documents, files containing diagrams, etc.).
• SCCS and RCS provide an efficient way of storing versions
that minimize the amount of occupied disk space.
Open source configuration management tools cont...
• Suppose, a module MOD is present in three versions
MOD1.1, MOD1.2, and MOD1.3.
• Then SCCS and RCS store the original module MOD1.1
together with changes needed to transform MOD1.1 into
MOD1.2 to MOD1.3.
• The changes needed to transform each baseline file to the
next version are stored and are called deltas.
• The main reason behind storing the deltas rather than
storing the full revision files is to save disk space.
Open source configuration management tools cont...

• The change control facilities provided by SCCS and RCS

include the ability to incorporate restrictions on the set of
individuals who can create new versions, and facilities for
checking components in and out (i.e., reserve and restore
operations).
• Individual developers check out components and modify
them.
• After they have made all the necessary changes to a
component, and after these changes have been reviewed,
they check-in the changed module into SCCS or RCS.
SCCS (Source Code Control System)

 SCCS is a configuration management tool:

◦ available on Unix systems:
◦ helps control and manage text files.
◦ also implements an efficient way of storing versions:
 minimizes the amount of occupied disk space.
SCCS cont …
 Suppose a module is present in 3 versions:
◦ MOD1.1, MOD1.2, and MOD1.3.
 SCCS stores the original module MOD1.1
◦ together with changes needed to transform it into MOD1.2 and
MOD1.3.
◦ the modifications are called deltas.
SCCS Features
• Access control facilities provided by SCCS include:
– facilities for checking components in and out.
– Individual developers check out components and modify
them.
• after they have changed a module as required and the module has
been successfully tested,
• they check in the changed module into SCCS.
SCCS Features

 Revisions are denoted by numbers in ascending order,

◦ e.g, 1.1, 1.2, 1.3 etc.
 It is also possible to create variants of a component
◦ by creating a fork in the development history.
Some project management tools
 Ganttproject is freeware (GPL-Licensed) project
management software that runs under the Windows, Linux
and Mac operating systems.
 Microsoft Project is the basic project management software
from Microsoft Corporation. Advanced capabilities are
supported through MS-Office Project Server, and MS-Office
Project Web Access software.
 ProjectLibre is a open source software tool intended as an
alternative to commercial software like Microsoft Project.
project management tools cont…
 Primavera project management software is a widely used
suite of project management software.
◦ SureTrack is the entry-level software and Primavera 6 is the advanced
software.
 Using SureTrack’s Project KickStart a project manager can
define
◦ project phases, establish goals, anticipate obstacles, and delegate
assignments.
Gantt Project
 It is a software package that allows effective, and on-going
management of project data.
 The application is particularly suited to the so-called
waterfall model of project management, in which tasks must
be executed in an inter-related sequence, leading to a final
end goal state.
 To install GanttProject, use your web browser to navigate to
http://www.ganttproject.biz
Features of Ganttproject
 Create a Gantt chart
 Cost management
 Link (dependency) management
 Display the critical path
 View a PERT chart
GanttProject
• Launch the program
by clicking on the
newly installed
GanttProject icon on
the desktop, which is
obtained using the
given link.
• Permit Java to update
if needed.
• Then, in the menubar,
click Project > New
to open a Create new
project window.
GanttProject

Figure shows a Gantt chart to plan and track the progress of the project
ProjectLibre
• ProjectLibre is a open source software tool intended as an
alternative to commercial software like Microsoft Project.

• It is free software, just as the name implies, but it is also

compatible with any other project management software.
ProjectLibre features
The features include:

• task management,
• work breakdown structure generation (a list and a graphical
• representation),
• resource allocation and tracking, and
• Gantt charts that provide a clear view of the critical path
elements of the schedule.
Install ProjectLibre
• Installing ProjectLibre on a single computer is quite
straightforward.
• go to http://sourceforge.net/projects/projectlibre/, and
download the Windows.msi file
• When the download is complete, double click on the file
to open it, and follow the instructions from the installer
that are initiated from the installation wizard.
• Then, simply complete the installation following the
directions on the screen.
Project libre cont…
 click on “New” to start the process.
ProjectLibre cont…
 If you select “new”, the dialog box shown in Figure pops up and its
primary purpose is to name the new project to be managed.
 The only box that must be filled-in is the name, but you may also list the
manager's name, change the date or add notes in the provided spaces.
Once you have made the desired entries, click “OK” to proceed.
Project libre cont…
 Screenshot of a sample project
What is Microsoft Project?
 Microsoft Project (or MSP) is a project management
software program.
 It is designed to assist project managers in:
• developing plans
• assigning resources to tasks
• tracking progress
• managing budgets
• analyzing workloads
 Feature Description
 Project creates budgets based on assignment work and
resource rates
 Resources – people, equipment and materials
 MSP Offers
 Robust management tools with the right blend of:
◦ Usability
◦ Power
◦ Flexibility

 That’s why you can manage projects more efficiently and

effectively.
MSP Main Features
 Resource Pooling:
◦ Used to share resource definitions.
 Task Linking:
◦ Allows interlinking of tasks in a project.
 Support for collaboration:
◦ Used with internet allowing faster and easier information
dissemination among the team members.
 Portfolio View:
◦ Helps the project manager examine multiple projects simultaneously
thereby giving an idea to the user on how changes in one project can
affect the other projects.
The Project Map
 The Project Map outlines the three phases of the project life
cycle:
• Build a plan
• Track and manage a project
• Close a project
Activities for building a plan
 Define a project
 Plan project activities
 Plan for procuring resources
 Plan project costs
 Plan for quality and risks
 Plan communication and security
 Optimize a project plan
 Print and distribute project information
Activities for tracking and managing a project

 Track progress
 Manage a schedule
 Manage resources
 Manage costs
 Manage risks
Activity for closing a project
 Review final project information

Each one of project phase’s activities has it’s own goals

 Enhancements
 Microsoft Project’s capabilities were extended with the
introduction of:
◦ Microsoft Office Project Server
◦ Microsoft Project Web Access
 Also, newer versions provide for cross-functionality with
products like:
◦ PowerPoint
◦ Visio
Source for Download
 https://www.microsoft.com/en-us/evalcenter/evaluate-
project-server-2016
 This provides with a 90 days trial pack
 Other websites like softonic and cnet can also be referred
for free download
Primavera
 Enables the organizations to manage time, tasks, costs,
resources, contracts, change and risks to consistently
execute profitable projects
 It is an industry leading project and program management
solution for projects of any size
 Organizations leverage Primavera to:
◦ Effectively collaborate across the entire project team
◦ Proactively manage projects to meet success requirements
◦ Standardize business processes and best practices
Offerings include
 Enterprise Visibility of all Projects
 Role Based Views
 Access information in real time and online
 Standardise reporting formats
 Collaboration with Stake holders
 Manage Documents and Submittals
 Forecast project performance and cost at completion
 Monitor and Control Contractor’s Performance
 Early warning Indicator
 Capture and reuse Templates, Streamline Processes
 Issue Management
Benefits
 Easy-to-use solution
 Great for simple projects
 Integrated suite of features
 Modern platform
Features of the project management tools

Portfolio Cost Resource

Web- Open
Software manage Scheduling manage managem
based source
ment ment ent
Ganttproject √ √ √
ProjectLibre √ √ √
Microsoft
√ √ √ √ √
Project
Primavera √ √ √ √ √
 Summary

• Explained briefly the configuration management process.

• Presented some configuration management tools such as
SCCS and RCS.
• Also presented some project management tools.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Contract management
Contents
• Introduction to managing contracts
• Types of contracts
• Stages in contract placement
• Contract checklist
• Contract management
 Introduction
 Many organizations choose to obtain their software
externally. Given their limited capability for developing new
and reliable software, this seems sensible.
 These organizations think that it is more cost-effective to
employ outside software developers for new development
while a reduced group of in-house software development
staff maintain and support existing systems.
 Introduction cont...
 The buying of goods and services, rather than ‘doing it
yourself’, is attractive when money is available but other,
less flexible, types of resource, especially staff time, are in
short supply.
 It is essential that customer organizations should find time
to clarify their exact requirements at the beginning, and to
ensure that the goods and services delivered are satisfactory.
 Introduction cont...
 Potential suppliers are likely to be more accommodating
before any contract is signed than afterwards – especially if
the contract is for a fixed price.
 Thus, as much forethought and planning are needed with an
acquisition project as with internal development.
 Types of contracts
 Bespoke system - created specially for one customer
 Off-the-shelf package - bought ‘as is’ (also known as shrink-
wrapped software)
 Customized off-the-shelf (COTS) software - a core system is
customized to meet needs of the client
 Types of contracts cont …
• Where an equipment is purchased, it is referred to as a
contract for the supply of goods.
• With the supply of software this may be regarded as
supplying a service (i.e. to develop the software) or the
granting of a license (i.e. permission) to use the software
which remains in the ownership of the supplier .
 Types of contract cont …
Another way of classification based on the calculation of
payment to suppliers is as follows:
 fixed price contracts
 time and materials contracts
 fixed price per delivered unit
 Fixed price contracts
 In this case, the price is fixed when the contract is signed.
 The customer knows that, if there are no changes in the
contract terms, this is the price they will pay on completion.
 The customer's requirement has to be fixed at the outset, i.e.
the detailed requirements analysis have already been made.
 Once the development is under way, the customer cannot
change their requirements without renegotiating the price of
the contract.
 Fixed price contracts cont …
Advantages to customer
 known expenditure
 supplier motivated to be cost-effective
 Fixed price contracts cont …
Disadvantages
 supplier will increase price to meet contingencies/absorb
risks
 difficult to modify requirements
 cost of changes likely to be higher
 threat to system quality
 Time and materials contracts
 In this case, the customer is charged at a fixed rate per unit
of effort, for example, per staff-hour or per person-month.
 The supplier may provide an initial estimate of the cost
based on their current understanding of the customer's
requirements, but this is not the basis for the final payment.
 The supplier usually sends invoices to the customer for the
work done at regular intervals, say monthly / quarterly.
 Time and materials contacts cont …
Advantages to customer
 easy to change requirements
 lack of price pressure can assist product quality
 Time and materials
Disadvantages
 Customer liability - the customer absorbs all the risk
associated with poorly defined or changing requirements
 Lack of incentive for supplier to be cost-effective
Fixed price per unit delivered contracts
• This is often associated with function point (FP) counting.
• The size of the system to be delivered is calculated or
estimated at the outset of the project.
• The size could be estimated in lines of code, but FPs can be
more easily derived from requirements documents.
• A price per unit is also quoted.
• The final price is then the unit price multiplied by the
number of units.
Fixed price per unit delivered contracts cont …
FP Count Design cost/FP Coding Total cost/FP
(in Rs.) cost/FP (in (in Rs.)
Rs.)
upto 2000 200 700 900
2001-2500 240 760 1000
2501-3000 260 780 1040
3001-3500 270 800 1070
3501-4000 280 820 1100
4001-4500 300 840 1140
4501-5000 330 870 1200
Fixed price per unit delivered contracts cont …

 The company that produced this table in fact charges a

higher fee per FP for larger systems.
 For example, a system to be implemented contains 2700 FPs.
 The overall charge would be 2000 X Rs 900 + 500 x Rs
1,000 + 200 x Rs 1,040 = Rs 25, 08,000.
 Fixed price per unit delivered contracts cont …
 The scope of the application can grow during development.
 It would be unrealistic for a contractor to be asked to quote
a single price for all the stages of a development project:
how can they estimate the construction effort needed when
the requirements are not yet established?
 In this case, one approach would be to negotiate a series of
contracts, each covering a different stage of system
development.
Fixed price per unit delivered contracts cont …

Advantages for customer

 customer understanding of how price is calculated
 comparability between different pricing schedules
 emerging functionality can be accounted for
 supplier incentive to be cost-effective
Fixed price per unit delivered contracts cont …

Disadvantages
 difficulties with software size measurement - may need
independent FP counter
 changing (as opposed to new) requirements: how do you
charge?
Types of software contracts cont …
Another way of classification based on the approach that is
used in contractor selection is as follows:
 Open tendering process
 Restricted tendering process
 Negotiated procedure
 The open tendering process
• Any supplier can bid in response to the invitation to tender
(ITT) / request for proposal (RFP)
• All tenders must be evaluated in the same way
• Government bodies may have to do this by
local/international law
• With a major project this evaluation process can be time
consuming and expensive.
• Where the client is a public body, an open tendering process
may be compulsory.
 Restricted tendering process
• In this case, bids are received only from those suppliers
who have been specifically invited
• Unlike, the open tendering process, at any time, the
customer can reduce the number of suppliers being
considered at any stage
 Negotiated procedure / Single tendering
process
 Open or restricted tendering process may not be suitable in
some particular sets of circumstances.
 For example, suppose, there is a fire that destroys some ICT
equipment. The key concern here may be to get replacement
equipment up and running as quickly as possible, and there
may not be sufficient time to embark on a lengthy tendering
process.
 Negotiated procedure / Single tendering
process cont …
 Another situation might be where a new software application
had been successfully built by an outside supplier, but some
extensions are required to the system. As the original supplier
has staff familiar with the existing system, it might be
inconvenient to approach other potential suppliers via a full
tendering process.
 In these cases, an approach to a single supplier may be
justified, i.e. negotiate with one supplier.
 Negotiated procedure / Single tendering
process cont …
 However, approaching a single, supplier could expose the
customer to charges of favouritism.
 So, it should only be done with a proper justification.
Stages in contract placement
requirements
analysis

evaluation
plan

invitation to
tender

evaluation of
proposals
 Requirements document: sections

 Introduction
 Description of existing system and current environment
 Future strategy or plans
 System requirements -
◦ mandatory/desirable features
 Deadlines
 Additional information required from bidders
 Requirements
 These will include
◦ functions in software, with necessary inputs and outputs
◦ standards to be adhered to
◦ other applications with which software is to be compatible
◦ quality requirements e.g. response times
Evaluation plan

 How are proposals to be evaluated?

 Methods could include:
◦ reading proposals
◦ interviews
◦ demonstrations
◦ site visits
◦ practical tests
 Evaluation plan cont...
 Need to assess value for money (VFM) for each desirable
feature
 VFM approach is an improvement on previous emphasis on
accepting lowest bid
 Example:
◦ feeder file saves data input
◦ 4 hours work a month saved at £20 an hour
◦ system to be used for 4 years
◦ if cost of feature £1000, would it be worth it?
Invitation to tender (ITT)
 Note that bidder is making an offer in response to ITT
 acceptance of offer creates a contract
 Customer may need further information
 Cons: Different technical solutions to the same problem,
so difficult to evaluate
 Memoranda of agreement (MoA)
 Customer asks for technical proposals
 Technical proposals are examined and discussed
 Agreed technical solution is MoA
 Tenders are then requested from suppliers based on MoA
 Tenders are judged on price
 Fee could be paid for technical proposals by customer
 Evaluation of proposals

 It is needed to produce an evaluation plan describing how

each proposal will be checked against the selection criteria.
 This reduces risks of requirements being missed and
ensures that all proposals are treated consistently.
 It would be unfair to favour a proposal because of the
presence of a feature not requested in the original
requirement.
 Evaluation of proposals cont...
 An application could be bespoke, off-the-shelf, or
customized.
 In the case of off-the-shelf packages, the software itself could
be evaluated and it might be possible to combine some of
the evaluation with acceptance testing.
 With bespoke development, it would be a proposal that is
evaluated, while COTS may involve elements of both. Thus
different approaches would be needed.
Evaluation of proposals cont...
The process of evaluation may include:
 Scrutiny of the proposal documents
 Interviewing suppliers' representatives
 Demonstrations
 Site visits
 Practical tests
Evaluation of proposals cont...
 The proposal documents provided by the suppliers can be scrutinized to
see if they contain features satisfying all the original requirements.
 Clarification might be sought over certain points. It is important to get a
written, agreed, record of these clarifications.
 The customer might take initiative by taking minutes of meetings and
then writing afterwards to the suppliers to get them to confirm their
accuracy.
 A supplier could, in the final contract document, attempt to exclude any
commitment to any representations made in pre-contract negotiations –
the terms of the contract need to be scrutinized for this. Where there is
an existing product, there could be a demonstration.
 Evaluation of proposals cont...
 A frequent problem is that while an existing application
works well on one platform with a certain level of
transactions, it does not work satisfactorily with the
customer's ICT configuration or level of throughput.
 Demonstrations might not reveal this problem. Visits to
operational sites already using the system, could be more
informative.
 In the last resort a special volume test could be conducted.
Evaluation of proposals cont...
 Finally, a decision is made to award the contract to a
supplier.
 The reason for following a structured and objective
approach to evaluation is to demonstrate that the decision
has been made impartially.
 A project manager cannot be expected to be a legal expert
– needs advice.
 BUT must ensure that the contract reflects true
requirements and expectations of supplier and client.
 Contract checklist
• Definitions – what words mean precisely e.g. ‘supplier’,
‘user’,‘application’

• Form of agreement - For example, is this a contract for

a sale or a lease, or a license to use a software
application? Can the license be transferred?
 Contract checklist
Goods and services to be supplied –
 Equipment and software to be supplied: this should include
an actual list of the individual pieces of equipment to be
delivered, complete with the specific model numbers.
 Services to be provided: This would cover such things as
◦ Training
◦ Documentation
◦ Installation
◦ Conversion of existing files
◦ Maintenance agreements
◦ Transitional insurance arrangements
Contract checklist - continued
 Ownership of software
◦ Can client sell software to others?
◦ Can supplier sell software to others? Could specify that customer has
‘exclusive use’
◦ Does supplier retain the copyright?
◦ Where supplier retains source code, may be a problem if supplier
goes out of business; to circumvent a copy of code could be
deposited with an escrow service
Contract checklist - continued
 Environment – for example, where equipment is to be
installed, who is responsible for various aspects of site
preparation e.g. electricity supply, back up facilitation etc.?
 Customer commitments – for example providing access,
supplying information
Contract checklist - continued
 Acceptance procedures – Good practice is to accept a
delivered system only after user acceptance tests.
 Part of the contract would specify such details as the time
that the customer will have to conduct the tests, deliverables
upon which the acceptance tests depend and the procedure
for signing off the testing as completed.
Contract checklist - continued

 Standards to be met – This covers the standards with which

the goods and services should comply.
 For example, a customer could require the supplier to
conform to the ISO 12207 standard relating to the software
life cycle and its documentation (or, more likely, a customized
sub-set of the standard).
 Contract checklist
• Project and quality management – the arrangements for
the management of the project must be agreed. These
include the frequency and nature of progress meetings and
the progress information to be supplied to the customer.
• Timetable of activities – This provides a schedule of when
the key parts of the project should be completed
 Contract checklist
• Price and payment method– obviously the price is very
important. what also needs to be arranged is when the
payments are to be made.
• payments may be tied to completion of specific tasks.
Contract management
Some terms of contract will relate to management of contract,
for example,
 Progress reporting
 Decision points – could be linked to release of payments to
the contractor
 Variations to the contract, i.e. how are changes to
requirements dealt with?
 Acceptance criteria
How would you evaluate the following?
 usability of an existing package
 usability of an application yet to be built
 maintenance costs of hardware
 time taken to respond to requests for software support
 training
Contract management cont …

 Contracts should include agreement about how

customer/supplier relationship is to be managed e.g.
◦ decision points - could be linked to payment
◦ quality reviews
◦ changes to requirements
Summary
 Presented an introduction to managing contracts.
 Discussed the different classifications of contracts along with
their advantages and disadvantages.
 Also discussed which type of contract is best suitable in
which cases.
 Explained the different stages in contract placement
 Discussed the typical terms of a contract
 Explained some terms of contract which relate to
management of contract
 References :

1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,

McGraw Hill Education (India) Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Project Closeout
Contents
• Introduction
• Reasons for project closure
• Project closure process
• Performing a financial closure
• Project closure report
 Introduction
 Every project must come to an end sometime or other.
 This is the last phase of project management life cycle.
 It is the responsibility of project manager to decide the
appropriate time to close a project.
 Project closure activities can be divided into 2 types:
administrative closure and contract closure activities.
 Introduction cont …
 Administrative closure activities consist of ensuring that all
of the project deliverables are achieved and the project
know-how are transferred to the other personnel and are
properly documented and archived.

 Contract closure activities verify that all the terms of the

contract with the customer as well as various
subcontractors are met and satisfactorily closed.
Reasons for project closure
There are 2 main reasons for closing a project.

1. All the project goals have been successfully accomplished.

2. It has been found that the project is unlikely to achieve it’s
stated objectives and has to be prematurely terminated.
Reasons for prematurely terminating a project

There can be many reasons for prematurely terminating a

project. A few important reasons for project termination are
the followings:
 Lack of resources
 Changed business need of the customer
 The perceived benefits accruing from the project no longer
remain valid, e.g. meanwhile competitors arrive in market.
Reasons for prematurely terminating a project cont …

• Incomplete requirements.
 Changes to the regulatory policies (e.g. permission not
granted to use satellite communication-based product)
• Some key technologies used in the project have become
obsolete during project execution.
• Risks becoming unacceptably high
 Why are projects not properly closed?

 Lack of interest by the project team

 Underestimation of how fast know-how can get lost and
how much implicit knowledge exists with the team
members
 Emotional factors
 Indecision regarding project closure
 Lack of interest by the project team
 Since project closing activities are usually rather mundane
and require little creativity, the project team may lose
interest to participate in these activities.
 This may especially be the case, if the project team
members have already started working on other projects.
 There can also be reluctance on the part of the project
team to actively participate in project termination activities
for reasons such as apprehension about their redeployment,
once the project gets closed.
 Underestimation of how fast know-how can get lost &
how much implicit knowledge exists with the team members
 Usually team members working on a project build up significant
knowledge on the project and the associated technologies.
 One of the important outcomes of proper project termination is
transfer of know-how to other employees of the company,
documentation and archival of the knowledge pertaining to the project.
 However, it is often underestimated by the stakeholders as to how much
knowledge pertaining to the project exists with the team members and
how fast can the knowledge decay and get lost.
 Unless the knowledge with the team members is appropriately
transferred to others or is archived, it may be lost forever. If the project
manager and the other stakeholders overlook this, they may get busy
with other activities and accord low priority to project closure.
 Emotional factors
 After working for some time on a project, it may be
possible that the team members and the project manager
may become emotionally attached to the project and would
want the project to continue as long as possible.
Indecision regarding project closure

 Often some tough decisions might have to be taken by the

project manager and the senior management regarding
projects facing premature termination.
 At times, they may delay taking the required decisions,
thereby, letting the project to run longer than necessary.
Problems of improper project closure

Time and cost overrun

 If project termination is delayed, the project as a cost
centre runs up expenditure in the meanwhile, leading to
cost overrun.
 Also the project duration appears to be longer than what it
should actually be.
Problems of improper project closure cont ...

Locking up valuable human and other resources

 When there is delay in closing a project, redeployment of
project personnel and other resources get delayed.
 As a result, valuable resources and manpower that could
have been gainfully utilized in other projects gets wasted.
Problems of improper project closure cont ...

Stress on the project personnel

 The project personnel often lose out on experience that
they could have gathered on other projects on which they
might have been deployed, had the project closeout
occurred at the appropriate time.
 The feeling of not doing anything challenging, missing out on
the learning opportunities, and the impact of these on their
future career can be stressful for the team members.
Issues associated with project termination
 The problems with project termination are two-fold. One
is emotional and the other intellectual.
 The emotional issues can concern both the team members
and the clients.
 Issues associated with project termination cont …

 The emotional issues that the team members may experience

include the uncertainties and apprehensions concerning their
assignment to the next project.
 This may manifest as general loss of interest in work and lack
of enthusiasm to perform the remaining project work.
 There can also be diversion of attention. The team members
may pay more attention to issues such as getting reassigned
to a project of their choice and the project work can take a
back seat.
Issues associated with project termination cont …

 On the client side, there can be a sudden change in attitude

and loss of interest in the project.
 The client may even change the personnel dealing with the
project, and thereby causing further disconnect and
difficulties in project closure.
Issues associated with project termination cont …
 The intellectual problems may include handling some sensitive
issues.
 When a project is to be prematurely terminated, the terms of
contract and the list of deliverables need to be renegotiated.
 Also, even when some deliverables and tasks that are
considered to be not necessary any more, however, before
dropping these it needs to be verified with the client.
 Also, the closure decision has to be effectively communicated
to all stakeholders.
 Project Closure Process
 Before the project closure process can be initiated, the decision
regarding closing the project needs to have been taken in
consultation with the top management.
 For successful projects, it is expected that the requisite technical
documentation, user manuals, testing and user training should have
been completed and it should have been ensured that the project
outputs are usable by the customer without any difficulty.
 It also needs to be ensured that administrative activities such as
settling their claims and archiving their deliverables for future use
have been accomplished.
 Project Closure Process cont …

 For a project facing premature termination, the project

manager in consultation with the top management and the
customers has to take the decision as to whether to
terminate the project immediately or to keep it under watch
for some more time.
 For both normal closure and premature termination
categories of projects, it has to be ensured that there are no
further obligations.
 Project Closure Process - Steps
1. Getting client acceptance
2. Archiving project deliverables
3. Preserving project know-how
4. Performing a financial closure
5. Performing post-implementation project review
6. Preparing post-implementation review report
7. Releasing staff
Getting client acceptance
 The mechanism for client acceptance varies across different types
of projects.
 When the client is a sister organization, or another department in
the same organization, no formal record for acceptance of project
deliverables is required. The acceptance tends to be informal and
gets conveyed in meetings.
 When the project client is an external organization, a formal
procedure for accepting the project deliverables is needed. In this
case, the client approval is obtained after a formal acceptance
testing by the client and a written acceptance of the project
deliverables is required.
Archiving project deliverables
 The project documents are usually archived electronically,
so that these can be easily retrieved whenever required in
the future.
 The project archive should be properly documented, so that
anyone trying to use the archive in the future does not face
any problem.
 This document should at least contain information regarding
the description of the documents archived, the application
used to create the archive, the locations where these are
stored and the persons to contact for further information.
Performing a Financial Closure
 Every project is usually undertaken based on some financial
grant.
 This grant can have different components such as capital
and contingency budgets.
 All these components have to be reconciled and book
transfer of any capital goods that were purchased should be
carried out.
 Also, it has to be ensured that all the subcontractor
payments are complete and have been reconciled.
Post-implementation project review
 The goal of a post-implementation project review
(sometimes called post-mortem) is to perform a critical
analysis of the project in order to learn and improve, and
avoid repeating the same mistakes in future projects.
 By analysing past mistakes, the project teams can learn to do
better by improving their methods and practices.
 Not only the successful ones, even the unsuccessful projects
implicitly hold a lot of information that can be identified,
documented and disseminated to benefit other projects.
Steps of post-implementation project review
1. Conduct project survey to collect various types of
information
2. Collect objective information / project metrics
(e.g. cost/schedule/quality metrics)
3. Hold a debriefing (preparatory) meeting
4. Hold the final project review meeting and prepare post-
implementation review report
5. Publish the report
Project Closeout Report
 It documents the important results obtained from various project
closeout tasks.
 It starts with a historical summary of the projects deliverables
and baseline activities over the course of the project.
 Subsequently it presents the summary of the survey results and
the quantitative data gathering about the project's performance.
 Finally, the results of the final project review are presented. The
reasons for variances from the baseline plan, lessons learned, best
practices and disposition of project resources are highlighted.
 It also contains recommendations for improvement for other
similar projects.
Result publication
 The project leader summarizes the positive and negative
findings as well as the prescriptions for improvement.
 The summary is published so that all the teams can refer to
it and also the management can take initiative for any
necessary corrections based on it.
 The important findings of the post-implementation project
review audit can be published in a document. The document
can be used to disseminate the lessons learned and to work
as a reference for similar future projects.
Result publication cont …
 A typical way in which the post-implementation project
review report can be organized is as follows:
◦ Project description: Information about the project, to give context
◦ What worked well
◦ The factors that impeded the performance of the project
◦ A prescription for other projects to follow
 Releasing Staff
 This is the final step of the project closeout process.
 This is the last meeting before the project team members
disburse to different other projects.
 The project manager should see that the team members are
assigned to proper projects according to their expertise and
skill.
 This meeting is also the ground for celebration before the
team members disperse to different projects and for
recognizing exceptional performance by the team members
and recognizing the experience and proficiency gained by
the team members.
 Summary
• Discussed the reasons for project closure
• Discussed the problems of improper project closure
• Explained the issues with project termination
• Presented the steps for closure of a project
• Presented the structure of a typical project closure report
References:
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth
Edition, McGraw Hill Education (India) Pvt. Ltd., 2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Software quality
Introduction
 Traditional definition of quality:
◦ Fitness of purpose:
 A quality product does exactly what the users want it to do.

 Fitness of purpose for software products:

 Satisfaction of the requirements specified in SRS document.

3
Introduction cont …
 A satisfactory definition of quality for many products:
◦ A car, a table fan, a food mixer, microwave oven, etc.
 But, not satisfactory for software products.
◦ Why?

4
Quality for Software Products
 Consider a software product:
◦ Functionally correct:
 Performs all functions as specified in the SRS document.
◦ But, has an almost unusable user interface.
 Cannot be considered as a quality product.

5
Quality for Software Products
 Consider another example:
◦ A product which does everything that users want.
◦ But has an almost incomprehensible and unmaintainable code.
◦ Will you call it a quality product?

6
Modern View of Quality
 Several quality factors are associated with a software
product :
◦ Correctness
◦ Reliability
◦ Efficiency (includes efficiency of resource utilization)
◦ Portability
◦ Usability
◦ Reusability
◦ Maintainability

7
Correctness
 A software product is correct:
◦ If different requirements as specified in the SRS
document have been correctly implemented.
◦ Results are accurate.

8
Portability
 A software product is said to be portable:
◦ If it can be easily made to work
 In different operating systems.
 In different machines,
 With other software products, etc.

9
Reusability

 A software product has good reusability:

◦ If different modules of the product can easily be reused to develop
new products.

10
Usability
 A software product has good usability:
◦ If different categories of users (i.e. both expert and novice users) can
easily invoke the functions of the product.

11
Maintainability
 A software product is maintainable:
◦ If errors can be easily corrected as and when they show up,
◦ New functions can be easily added to the product,
◦ Functionalities of the product can be easily modified.

12
‘Step Wise’ - an overview
0.Select
1. Identify project 2. Identify project
project objectives infrastructure
3. Analyse
project
characteristics
Review 4. Identify products
and activities
Lower
5. Estimate effort
level
for activity For each
detail
6. Identify activity activity
risks
10. Lower level
7. Allocate
planning
resources
8. Review/ publicize
9. Execute plan plan
Place of software quality in project planning

 Quality will be of concern at all stages of project planning

and execution, but it will be of particular interest at the
following points in the step wise framework.
 Step 1: identify product scope and objectives – some
objectives could relate to the qualities of the application
to be delivered.
 Step 2: identify project infrastructure – within this step
activity 2.2 identifies installation standards and procedures.
Some of these will almost certainly be about quality.
 Step 3: Analyse project characteristics – In activity 3.2
(‘analyse other project characteristics – including quality
based ones’) the application to be implemented is
examined to see if it has any special quality requirements.
 If, for example, it is safety critical then a range of activities
could be added, such as n-version development where a
number of teams develop versions of the same software
which are then run in parallel with the outputs being
cross-checked for discrepancies.
 Step 4: identify the products and activities of the project – It is
at this point that the entry, exit and process requirements
are identified for each activity.
 Step 8: review and publicize plan – At this stage the overall
quality aspects of the project plan are reviewed.
The importance of software quality
 Increasing criticality of software – e.g. software is
increasingly being used in systems that can threaten or
support human life and well-being.
 The intangibility of software – it is difficult for observers to
judge the quality of software development, especially during
its early stages.
The importance of software quality
 Project control concerns:
◦ errors accumulate with each stage
i. The products of one sub-process in the development
process are the inputs to subsequent sub-processes, thus
ii. errors accumulate with each stage e.g. at the design stage,
the specification errors are incorporated into the design, and
at the coding stage specification and design errors are
incorporated into the software
◦ errors become more expensive to remove the later they are
found
◦ it is difficult to control the error removal process (e.g. testing)
Quality specifications
Where there is a specific need for a quality, produce a quality
specification
 Definition/description of the quality
 Scale: the unit of measurement
 Test: practical test of extent of quality
 Minimally acceptable: lowest acceptable value, if compensated for by
higher quality level elsewhere
 Target range: desirable value
 Now: value that currently applies
ISO standards: development life cycles
A development life cycle (like ISO 12207) indicates the
sequence of processes that will produce the software
deliverable and the intermediate products that will pass
between the processes.
deliverable
elicit require- intermediate
requirements tested code
ments products

design s/w
processes code/test
software architecture
 The deliverables are the products that are handed over to the
client at the end of the project, typically the executable code.
 Intermediate products are things that are produced during the
project, but which are not (usually) handed to the client at the
end. Typically they are things that are produced by one sub-
process (e.g. a requirements document created by the
requirements elicitation and analysis processes) and used by
others (e.g. a design process which produces a design that fulfils
the requirements).
 These sub-processes will fit into the overall framework of a
development cycle.
 Some software quality models focus on evaluating the quality of
software products, others on the processes by which the
products are created.
ISO standards
 The ISO 9000 series of standards establishes
requirements for quality management systems for the
creation/supply of all types of goods and services.
Software Quality Management System

 Quality management system (or quality system):

◦ Principal methodology used by organizations to ensure that the
products have desired quality.

25
Quality System
 A quality system consists of the following:
◦ Managerial Structure
◦ Individual Responsibilities.
 Responsibility of the organization as a whole.

26
Quality System
 Every quality conscious organization has an independent quality
department:
◦ Performs several quality system activities.
◦ Needs support of top management.
◦ Without support at a high level in a company:
 Many employees may not take the quality system seriously.

27
Quality System Activities
 Auditing of projects
 Development of:
◦ standards, procedures, and guidelines.
 Production of reports for the top management:
◦ Summarizing the effectiveness of the quality system in the organization.
 Review of the quality system itself.

28
Quality System
 A good quality system must be well documented.
◦ Without a properly documented quality system,
 Application of quality procedures become ad hoc,
 Results in large variations in the quality of the products delivered.

29
Quality System
 An undocumented quality system:
◦ Sends clear messages to the staff about the attitude of the
organization towards quality assurance.
 International standards such as ISO 9000 provide:
◦ Guidance on how to organize a quality system.

30
Evolution of Quality Systems
 Quality systems have evolved:
◦ Over the last six decades.
 Prior to World War II:
◦ Accepted way to produce quality products:
 Inspect the finished products
 Eliminate defective products.

31
Evolution of Quality Systems
 Since World war II,
◦ Quality systems of organizations have undergone:
 Four stages of evolution.
 Many advances came from Japanese:
◦ Helped resurrect Japanese economy.

32
Evolution of Quality Systems

33
Evolution of Quality Systems
 Initial product inspection method:
◦ Gave way to quality control (QC).
 Quality control:
◦ Not only detect the defective products and eliminate them
◦ But also determine the causes behind the defects.

34
Quality Control (QC)
 Quality control aims at correcting the causes of errors:
◦ Not just rejecting defective products.
 Statistical quality control (SQC):
◦ Quality of the output of the process is inferred using statistical
methods.
◦ In stead of inspection or testing of all products.

35
Quality Control (QC)
 The next breakthrough:
◦ Development of quality assurance principles.

36
Quality Assurance
 Basic premise of modern quality assurance:
◦ If an organization's processes are good and are followed rigorously:
 The products are bound to be of good quality.

37
Quality Assurance
 All modern quality paradigms include:
◦ Guidance for recognizing, defining, analyzing, and improving the
production process.

38
Total Quality Management (TQM)

 TQM advocates:
◦ Continuous process improvements through process measurements.

39
Business Process Reengineering

 BPR:A term related to TQM.

 Process reengineering goes a step further than quality
assurance:
◦ Aims at continuous process improvement.

40
Business Process Reengineering

 TQM focuses on reengineering of the software process.

 Whereas BPR aims at reengineering the way business is carried out in
any organization:
 Not just software development.

41
Total Quality Management (TQM)
 TQM goes beyond documenting processes
◦ Optimizes them through redesign.
 Over the years the quality paradigm has shifted:
◦ From product assurance to process assurance.

42
 Process Improvement
 Implies introducing process changes to improve:
◦ Product quality
◦ Reduce costs
◦ Accelerate schedules.
 Most process improvement work so far has focused on
defect reduction.

43
Process Attributes
Process Description
characteristic
Understandability To what extent is the process explicitly defined and how easy is it to
understand theprocess definition?
Visibility Do the process activities culminate in clear results so that the progress
of theprocess is externally visible?
Supportability To what extent can CASE tools be used to support the process
activities?
Acceptability Is t he defined process acceptable to and usable by the engineers
responsible for producing the software product?
Reliability Is the process designed in such a way thatprocess errorsare avoided or
trapped before they result in product errors?
Robustness Can theprocess continue in spite of unexpected problems?
Maintainability Can the process evolve to reflect changing organisational requirements
or identified process improvements?
Rapidity How fast can the process of delivering a system from a given
specification becompleted?
The Process Improvement Cycle

Measure

Change Analyse

45
Process Improvement Stages
 Process measurement
◦ Attributes of the process are measured.
◦ Form a baseline for assessing improvements.
 Process analysis
◦ The process is assessed and bottlenecks and weaknesses are
identified.
 Process change
◦ Changes to the process that have been identified during the
analysis are introduced.

46
 Process and Product Quality
 A good process is usually required to produce a good
product.
 For manufactured goods, process is the principal quality
determinant.
 For design-based activity, other factors are also involved:
◦ For example, the capabilities of the designers.

47
 Summary
 Discussed basic concepts of quality systems.
 Explained the quality factors associated with a software
product.
 Discussed the Evolution of Quality Systems
 Explained the Process Improvement Cycle
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Software quality cont…
ISO 9000
 ISO (international Standards Organization):
◦ a consortium of 63 countries established to formulate and foster
standardization.
 ISO published its 9000 series of standards in 1987.

3
What is ISO 9000 Certification?

 ISO 9000 certification:

◦ Serves as a reference for contract between independent parties.
 The ISO 9000 standard:
◦ Specifies guidelines for maintaining a quality system.

4
What is ISO 9000 Certification?
 ISO 9000 specifies:
◦ Guidelines for repeatable and high quality product development.
◦ Also addresses organizational aspects
 Responsibilities, reporting, procedures, processes, and resources for
implementing quality management.

5
ISO 9000
 A set of guidelines for the production process.
◦ Not directly concerned about the product it self.
◦ A series of three standards:
 ISO 9001, ISO 9002, and ISO 9003.

6
ISO 9000
 Based on the premise:
◦ If a proper process is followed for production:
 Good quality products are bound to follow.

7
ISO 9001
 Applies to:
◦ Organizations engaged in design, development, production, and
servicing of goods.
◦ Applicable to most software development organizations.

8
ISO 9002
 ISO 9002 applies to:
◦ Organizations who do not design products:
 but are only involved in production.
 Examples of this category of industries:
◦ Steel or car manufacturing industries
◦ Buy the product and plant designs from external sources:
 only manufacture products.
◦ Not applicable to software development organizations.

9
ISO 9003
 ISO 9003 applies to:
◦ Organizations involved only in installation and testing of the
products.

10
ISO 9000 for Software Industry
 ISO 9000 is a generic standard:
◦ Applicable to many industries,
 Starting from a steel manufacturing industry to a service rendering
company.

 Many clauses of ISO 9000 documents:

◦ Use generic terminologies
◦ Very difficult to interpret them in the context of software
organizations.

11
Software vs. Other Industries
 Very difficult to interpret many clauses for software
industry:
◦ Software development is radically different from development of
other products.

12
Software vs. Other Industries
 Software is intangible:
◦ Therefore difficult to control.
 It is difficult to control anything that we cannot see and feel.
◦ In contrast, in a car manufacturing unit:
 We can see a product being developed through stages such as fitting
engine, fitting doors, etc.
 One can accurately tell about the status of the product at any time.
◦ Software project management is an altogether different ball
game.

13
Software vs. Other Industries
 During software development:
◦ The only raw material consumed is data.
 For any other product development:
◦ Lot of raw materials consumed
 e.g. Steel industry consumes large volumes of iron ore, coal, limestone,
etc.

 ISO 9000 standards have many clauses corresponding to

raw material control .
 Not relevant to software organizations.
14
Software vs. Other Industries
 Radical differences exist between software and other
product development:
◦ Difficult to interpret various clauses of the original ISO standard in the
context of software industry.

15
ISO 9000 Part-3
 ISO released a separate document called ISO 9000 part-3
in 1991:
◦ To help interpret the ISO standard for software industry.
 At present:
◦ Official guidance is inadequate.

16
Why Get ISO 9000 Certification?
 Several benefits:
◦ Confidence of customers in an organization increases.
 If organization qualified for ISO 9001 certification.
 This is especially true in the international market.

17
Why Get ISO 9000 Certification?

 Many international software development contracts insist:

◦ Development organization to have ISO 9000 certification.

18
Why Get ISO 9000 Certification?
 Requires:
◦ A well-documented software production process to be in place.
◦ Contributes to repeatable and higher quality software.
 Makes development process:
◦ Focussed, efficient, and cost-effective

19
Why Get ISO 9000 Certification?
 Points out the weakness of an organizations:
◦ Recommends remedial action.
 Sets the basic framework:
◦ For development of an optimal process and TQM.

20
How to Get ISO 9000 Certification?
 An organization intending to obtain ISO 9000 certification:
◦ Applies to a ISO 9000 registrar for registration.
 ISO 9000 registration process consists of several stages.

21
How to Get ISO 9000 Certification?
 Application stage:
◦ Applies to a registrar for registration.
 Pre-assessment:
◦ The registrar makes a rough assessment of the organization.

22
How to Get ISO 9000 Certification?
 Document review and adequacy audit:
◦ Process and quality-related documents.
◦ The registrar reviews the documents.
◦ Makes suggestions for improvements.

23
How to Get ISO 9000 Certification?
 Compliance audit:The registrar checks:
 Whether the suggestions made by it during review have been
complied.

24
How to Get ISO 9000 Certification?
 Registration:
◦ The registrar awards ISO 9000 certificate after successful
completions of all previous phases.
 Continued surveillance:
◦ The registrar continues monitoring the organization periodically.

25
ISO 9000 Certification
 An ISO certified organization :
◦ Can use the certificate for corporate advertizements.
◦ Cannot use the certificate to advertize its products.
 ISO 9000 certifies organization's process
 Not any product of the organization.
◦ An organization using ISO certificate for product advertizements:
 Risks withdrawal of the certificate.

26
Summary of ISO 9001 Requirements
 Management responsibility(4.1):
◦ Management must have an effective quality policy.
◦ The responsibility and authority of all those whose work
affects quality:
 Must be defined and documented.

27
Salient Features of ISO 9001 Requirements:

 All documents concerned with the development of a

software product:
◦ Should be properly managed, authorized, and controlled.
 Proper plans should be prepared:
◦ Progress against these plans should be monitored.

28
Salient Features of ISO 9001 Requirements
 Important documents independently checked and
reviewed:
◦ For effectiveness and correctness.
 The product should be tested :
◦ Against specification.
 Several organizational aspects:
◦ e.g., management reporting of the quality team.

29
Shortcomings of ISO 9001 Certification (1)
 ISO 9000 requires a production process to be adhered to:
◦ But does not guarantee the process to be of high quality.
◦ Does not give any guideline for defining an appropriate process.

30
Shortcomings of ISO 9001 Certification (2)

 ISO 9000 certification process:

◦ Not fool-proof
◦ No international accreditation agency exists.
◦ Likely variations in the norms of awarding certificates:
 Among different accreditation agencies and among the registrars.

31
Shortcomings of ISO 9001 Certification (3)

 Organizations qualifying for ISO 9001 certification:

◦ Tend to downplay domain expertise.
◦ Tend to believe that since a good process is in place,
 Any engineer is as effective as any other engineer in doing any particular
activity relating to software development.

32
Shortcomings of ISO 9001 Certification (4)
 In manufacturing industry:
◦ Clear link between process quality and product quality.
◦ Once a process is calibrated:
 Can be run again and again producing quality goods.
 Software development is a creative process:
◦ Individual skills and experience is significant.

33
Shortcomings of ISO 9001 Certification (5)
 Many areas of software development are very specialized:
◦ Special expertize and experience (domain expertize) required.
 ISO 9001:
◦ Does not automatically lead to continuous process improvement,
◦ Does not automatically lead to TQM.

34
Shortcomings of ISO 9001 Certification (6)

 ISO 9001 addresses mostly management aspects.

 Techniques specific to software development have been
ignored:
◦ Configuration management
◦ Reviews
◦ Release builds
◦ Problem Notification system
◦ Intranets

35
 Summary
 Discussed ISO 9000 standard.
 Explained how to Get ISO 9000 Certification.
 Discussed requirements for ISO.
 Discussed the limitations of ISO.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Software quality cont…
SEI Capability Maturity Model (CMM)
 Developed by Software Engineering Institute (SEI) of the
Carnegie Mellon University, USA:
◦ To assist the U.S. Department of Defence (DoD) in software
acquisition.
◦ The rationale was to include:
 Likely contractor performance as a factor in contract awards.
SEI Capability Maturity Model
 Major DoD contractors began CMM-based process
improvement initiatives:
◦ As they vied for DoD contracts.
 SEI CMM helped organizations:
◦ Helped Improve quality of software they developed
◦ Realized adoption of SEI CMM model had significant business
benefits.
 Other organizations adopted CMM.
SEI Capability Maturity Model
 In simple words:
◦ CMM is a model for apprising the software process maturity of a
contractor into different levels.
◦ Can be used to predict the most likely outcome to be expected:
 from the next project that the organization undertakes.

5
SEI Capability Maturity Model
 Can be used in two ways:
◦ Capability evaluation
◦ Software process assessment.

6
Capability Evaluation
 Provides a way to assess the software process capability of
an organization:
◦ Helps in selecting a contractor
◦ Indicates the likely contractor performance.

7
Software Process Assessment
 Used by an organization to assess its current process:
◦ Suggests ways to improve the process capability.
◦ This type of assessment is for purely internal use.

8
SEI Capability Maturity Model
 The SEI CMM classifies software development industries
into:
 Five maturity levels.
 Stages are ordered so that improvements at one stage provide
foundations for the next.
 Based on the pioneering work of Philip Crosby.

9
SEI Capability Maturity Model
Optimizing (5)
Managed (4)
Defined (3)
Repeatable (2)

Initial (1)

10
Level 1: (Initial)
 Organization operates
◦ Without any formalized process or project plans
 An organization at this level is characterized by
◦ Ad hoc and often chaotic activities.

11
Level 1: (Initial)
 Software production processes are not defined,
◦ Different engineers follow their own process
◦ Development efforts become chaotic.
◦ The success of projects depend on individual efforts and heroics.

12
Level 2: (Repeatable)
 Basic project management practices
◦ Tracking cost, schedule, and functionality are followed.
 Size and cost estimation techniques:
◦ Function point analysis, COCOMO, etc. used.
 Production process is ad hoc:
◦ Not formally defined
◦ Also not documented.

13
Level 2: (Repeatable)
 Process used for different projects might vary between
projects:
◦ Earlier success on projects with similar applications can be
repeated.
◦ Opportunity to repeat process exist when a company produces a
family of products.

14
Level 3: (Defined)
 Management and development activities:
◦ Defined and documented.
◦ Common organization-wide understanding of activities, roles, and
responsibilities.

15
Level 3: (Defined)
 The process though defined:
◦ Process and product qualities are not measured.
 ISO 9001 aims at achieving this level.

16
Level 4: (Managed)
 Quantitative quality goals for products are set.
 Software process and product quality are measured:
◦ The measured values are used to control the product quality.
◦ Results of measurement used to evaluate project performance:
 Rather than improve process.

17
Level 4: (Managed)
 Organization sets quantitative quality goals.
 World-wide about 100 organizations assessed at this level.

18
Level 5: (Optimizing)
 Statistics collected from process and product
measurements are analyzed:
◦ Continuous process improvement based on the measurements.
 Known types of defects are prevented from recurring by tuning the
process
 Lessons learned from specific projects incorporated into the process

19
Level 5: (Optimizing)
 Identify best software engineering practices and
innovations:
◦ Tools, methods, or process are identified.
◦ Transferred throughout the organization.
 World-wide about 500 organizations have been assessed at this level.

20
Key Process Areas
 Each level is associated with a key process area (KPA)
which identifies:
◦ Where an organization at the previous level must focus to reach this
level.

21
Level 2 KPAs
 Software project planning:
◦ Size, cost, schedule.
◦ Project monitoring
 Configuration management
 Subcontract management

22
Level 3 KPAs

 Process definition and documentation.

 Reviews
 Training program

23
Level 4 KPAs
 Quantitative measurements.
 Process management.

24
Level 5 KPAs
 Defect prevention.
 Technology change management.
 Process change management.

25
A repeatable model

inputs
(requirements)

control (budget, construct the outputs (code,

schedule, standards) system documentation)

resources
(staff, tools)
Repeatable model KPAs
To move to this level concentrate on:
 Configuration management
 Quality assurance
 Sub-contract management
 Project planning
 Project tracking and oversight
 Measurement and analysis
A defined process
requirements

design methods design &

define system design

tools, staff etc

inspection code & unit

test tested modules
criteria
tools, staff etc.
test plans integrate/
system test
tools, staff etc.
System software
Repeatable to defined KPAs
Concentrate on
 Requirements development and technical solution
 Verification and validation
 Product integration
 Risk management
 Organizational training
 Organizational process focus (function)
 Decision analysis and resolution
 Process definition
 Integrated project management
 a managed process
requirements
directives

design defects
manage
design methods design &
define system design

tools, staff etc

system errors
code & unit
inspection tested modules
test
criteria

tools, staff etc.

test plans integrate/
system test

tools, staff etc.

system
software
Defined to managed KPAs
Concentrate on:
 Organizational process performance
 Quantitative project management
 Optimizing
Optimize
old control/development system
requirements directives
design defects manage
design methods design &
system design

system errors
define
tools, staff etc
inspection code & unit
criteria test tested modules
tools, staff etc.
test plans integrate/
system test
tools, staff etc.
system
software

SPM (5e) Software process

new control/development system
quality© The McGraw-Hill
Companies, 2009 32
Managing to optimizing: KPAs
concentrate on:
 Causal analysis and resolution
 Organizational innovation and deployment
Comparison Between ISO 9001 and SEI CMM

 ISO 9001 awarded by an international standards body:

◦ Can be quoted in official documents and communications.
 SEI CMM assessment is purely for internal use.

34
Comparison Between ISO 9001 and SEI CMM

 SEI CMM was developed specifically for software industry:

◦ Addresses many issues specific to software industry.
 SEI goes beyond quality assurance
◦ Aims for TQM.
◦ ISO 9001 correspond to SEI level 3.

35
Comparison Between ISO 9001 and SEI CMM

 SEI CMM provides a list of key areas:

◦ On which to focus to take an organization from one level to the other
 Provides a way for gradual quality improvements over
several stages.
◦ e.g trying to implement a defined process before a repeatable process:
 Counterproductive as managers are overwhelmed by schedule and budget
pressure.

36
CMMI (CMM Integration)

 CMMI is the successor of the CMM.

 The CMM was developed from 1987 until 1997.
 In 2002, CMMI Version 1.1 was released.
◦ Version 1.2 followed in August 2006.
 The goal of the CMMI to integrate many different models
into one framework.
◦ It was created by members of industry, government and the SEI.

37
Some questions about CMMI
 suitable only for large organizations
◦ e.g. need for special quality assurance and process improvement
groups
 defining processes may not be easy with new technology
◦ how can we plan when we’ve not used the development method
before?
 higher CMM levels easier with maintenance environments
 can you jump levels? (HP level 5 in India)
Remarks on Quality Model Usage
 Highly systematic and measured approach to software
development process which suits certain circumstances
◦ Negotiated software, safety-critical software, etc.
 What about small organizations?
 Typically handle applications such as internet, e-comm.
 Without an established product range,
 Without revenue base, experience on past projects, etc.
 CMM may be incompatible

39
 Summary
 Discussed the basic concepts of SEI CMM.
 Compared between ISO and SEI CMM.
 References :
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you
Software Project Management

Durga Prasad Mohapatra

Professor
CSE Deptt.
NIT Rourkela
Software quality cont…
ISO/IEC 15504 IT process assessment
 ISO/IEC 15504 is a standard for process assessment that
shares many concepts with CMMI. The two standards (i.e.
ISO/IEC 15504 and CMMI) should be compatible.
 It is designed to provide guidance on the assessment of
software development processes.
 To do this, there must be some benchmark or process
reference model which represents the ideal development
life cycle against which the actual processes can be
compared.
Process Reference Model
 A defined standard approach to development.
 Needs a defined set of processes that represent good
practice to be the benchmark, against which the processes
to be assessed can be judged.
 ISO 12207 is the default reference model.
 Could use other reference models in specific
environments.
 The processes are assessed on the basis of 9 process
attributes, as shown in next table.
ISO 15504 performance attributes
CMMI level ISO 15504

0. incomplete

initial 1.1.process performance – achieves defined outcome

repeatable 2.1 process management – it is planned and monitored

2.2 work product management – control of work products

ISO 15504 performance attributes – cont…
CMMI ISO 15504

Defined 3.1. Process definition

3.2. Process deployment

Managed 4.1. Process measurement

4.2. Process control

Optimizing 5.1. Process innovation

5.2. Process optimization

6
IS0 15504 Process Assessment
For each process in the relevant Process Reference Model
For each set of attribute level criteria
Assess whether:
N: not achieved 0-15%
P: partially achieved 15%-50%
L: largely achieved 50%-85%
F: fully achieved 85% or more
ISO 15504 performance indicators
This is just an example of how indicators for each level
might be identified
1.Performance
Descriptions of maximum and minimum expected input
values exist
2.1 Performance management
A plan of how expected input variable ranges are to be
obtained which is up to date
ISO 15504 performance indicators 2
2.2 Work product management
There are minutes of a meeting where the input
requirements document was reviewed and corrections were
mandated
3.1 Process definition
A written procedure for input requirements gathering exists
3.2 Process deployment
A control document exists that is signed as each part of the
procedure is completed
ISO 15504 performance indicators 2
4.1. Process measurement
Measurement data can be collected e.g. number of changes
resulting from review
4.2. Process control
Memos relating to management actions taken in the light of
the above
ISO 15504 performance indicators 3
5.1 Process innovation
Existence of some kind of ‘lessons learnt’ report at the
end of project
5.2. Process optimization
Existence of documents assessing the feasibility of
suggested process improvements and which show
consultation with relevant stakeholders
Quality Systems for Small Organizations
 Small organizations tend to believe:
◦ We are all competent people hired to do a job, we can’t afford
training.
◦ We all communicate with one another.
 Osmosis works because we are so close.
◦ We are all heroes:
 We do what needs to be done.
 Therefore rules do not apply to us.

12
Quality Systems for Small Organizations
 Often have problems:
◦ Undocumented requirements
◦ Inexperienced managers
◦ Documenting the product
◦ Resource allocation
◦ Training
◦ Peer reviews

13
Quality Systems for Small Organizations
 A two week CMM-based appraisal is probably excessive:
 Small organizations need to operate more efficiently at
lower levels of maturity
◦ Must first flourish if eventually they are to mature

14
Personal Software Process (PSP)
 Based on the work of Humphrey.
 PSP is a scaled down version of industrial software process:
◦ Suitable for individual use.
 Even CMM assumes that engineers use effective personal
practices.

15
Personal Software Process (PSP)
 A process is the set of steps for doing a job.
 The quality and productivity of an engineer are
◦ Largely determined by his process
 PSP framework:
◦ Helps software engineers to measure and improve the way they work.

16
Personal Software Process (PSP)
 Helps developing personal skills and methods.
◦ Estimating and planning method.
◦ Shows how to track performance against plans.
◦ Provides a defined process;
 Can be fine tuned by individuals.
 Recognizes that a process for individual use is different from that
necessary for a team project.

17
Time Management
 Track the way you spend time:
◦ Boring activities seem longer than actual.
◦ Interesting activities seem short.
 Record time for:
◦ Designing
◦ Writing code
◦ Compiling
◦ Testing

18
Personal Software Process (PSP)

Planning
Design
Code Logs
Compile
Test Project plan
Postmortem summary

19
PSP-Planning
 Problem definition
 Estimate max, min, and total LOC
 Determine minutes/LOC
 Calculate max, min, and total development times
 Enter the plan data in project plan summary form
 Record the planned time in Log

20
PSP-Design
 Design the program.
 Record the design in specified format.
 Record the Design time in time recording log.

21
PSP-Code
 Implement the design.
 Use a standard format for code text.
 Use coding standards and guidelines.
 Record the coding time in time recording log.

22
PSP-Compile
 Compile the program.
 Fix all the defects.
 Record compile time in time recording log.

23
PSP-Test/Postmortem
 Test:
◦ Test the program.
◦ Fix all the defects found.
◦ Record testing time in time recording log.
 Postmortem:
◦ Complete project plan summary form with actual time and size data.
◦ Record postmortem time in time record.

24
Personal Software Process (PSP)

PSP 3  Personal process

evolution
PSP 2  Personal quality management
 Design and code reviews
PSP 1 Personal planning
 Time and schedule
PSP 0  Personal measurement
 Basic size measures
25
Six Sigma
 Six sigma is a quantitative approach to eliminate defects:
◦ Applicable to all types of industry - from manufacturing, product
development, to service.
 The statistical representation of Six Sigma quantitatively
describes :
◦ How a process is performing?

26
Six Sigma
 To achieve six sigma:
◦ A process must not produce more than 3.4 defects per million
opportunities.
◦ 5 Sigma -> 230 defects per million.
◦ 4 Sigma -> 6210 defects per million.
 Six sigma methodologies:
◦ DMAIC (Define, Measure, Analyse, Improve, Control).
◦ DMADV: (Define, Measure, Analyse, Design, Verify).

27
Six Sigma Methodologies

 The methodologies are implemented by Green belt and

Black belt workers:
◦ Supervised by Master black belt worker.
 Pareto Chart:
◦ Simple bar chart to represent defect data
◦ Emphasis on identifying the problems that occur with greatest
frequency
 or incur the highest cost

28
Techniques to improve quality
 Inspection
 Walkthrough Already discussed
 Review
 Clean room software development
 Formal methods
 Testing
 Reliability
‘Clean-room’ software development
 Pioneered at IBM
 The term cleanroom was first coined at IBM by drawing
analogy to the semi-conductor fabrication units where the
defects are avoided by manufacturing in an ultra-clean
atmosphere.
 Relies heavily on walkthroughs, inspection and formal
verification for bug removal
 Programmers are not allowed to test any of their code by
executing the code other than doing some syntax testing
using a compiler 30
‘Clean-room’ software development
Ideas associated with Harlan Mills at IBM
 Three separate teams:
1. Specification team – documents user requirements and usage
profiles (how much use each function will have)
2. Development team – develops code but does not test it. Uses
mathematical verification techniques
3. Certification team – tests code. Statistical model used to decide
when to stop
Formal methods
 Mathematical notations such as VDM (Vienna Development
Method) and Z can be used to produce unambiguous
specifications.
 Can prove correctness of software mathematically (cf.
geometric proofs of Pythagoras’ theorem).
 Newer approaches use Object Constraint Language (OCL)
to add details to UML models.
 Aspiration is to be able to generate applications directly
from UML+OCL without manual coding – Model Driven
Architectures (MDA).
Verification versus Validation
 Verification is the process of determining whether the
output of one phase of software development conforms to
that of its previous phase;
◦ whereas validation is the process of determining whether a fully
developed software conforms to its requirements specification.
 Verification is carried out during the development process
to check if the development activities are being carried out
correctly,
◦ whereas validation is carried out towards the end of the development
process to check if the right product as required by the customer has
been developed.
Testing: the V-process model
 This is shown diagrammatically on the next slide
 It is an extension of the waterfall approach
 For each development stage there is a testing stage
 The testing associated with different stages serves
different purposes
◦ e.g. system testing tests that components work together correctly,
user acceptance testing tests that users can use system to carry
out their work
Testing: the V-process model
Black box versus glass box testing
 Glass box testing
◦ The tester is aware of the internal structure of the code; can test
each path; can assess percentage test coverage of the tests e.g.
proportion of code that has been executed
 Black box testing
◦ The tester is not aware of internal structure; concerned with
degree to which it meets user requirements
Levels of testing
 Unit testing
 Integration testing
 System testing
Testing activities
 Test planning
 Test suite design
 Test case execution and result checking
 Test reporting:
 Debugging:
 Error correction:
 Defect retesting
 Regression testing
 Test closure:
Test plans
 Specify test environment
◦ In many cases, especially with software that controls equipment, a
special test system will need to be set up
 Usage profile
◦ failures in operational system more likely in the more heavily used
components
◦ Faults in less used parts can lie hidden for a long time
◦ Testing heavily used components more thoroughly tends to reduce
number of operational failures

39
Management of testing
The tester executes test cases and may as a result find
discrepancies between actual results and expected results
– issues
Issue resolution – could be:
 a mistake by tester
 a fault – needs correction
 a fault – may decide not to correct: off-specification
 a change – software works as specified, but specification
wrong: submit to change control
Decision to stop testing
• The problem: impossible to know there are no more
errors in code
• Need to estimate how many errors are likely to be left
• Bug seeding – insert (or leave) known bugs in code
• Estimate of bugs left =
• (total errors found)/(seeded errors found) x (total seeded errors)
How many errors are still remaining?
 Seed the code with some known errors:
◦ artificial errors are introduced into the program.
◦ Check how many of the seeded errors are detected
during testing.

42
 Error Seeding
Let:
◦ N be the total number of errors in the system
◦ n of these errors be found by testing.
◦ S be the total number of seeded errors,
◦ s of the seeded errors be found during testing.

43
Error Seeding
n/N = s/S
N = S * n/s
remaining defects:
N - n = n * ((S - s)/ s)

44
Example
 100 errors were introduced.
 90 of these errors were found during testing
 50 other errors were also found.
 Remaining errors= 50 * (100-90)/90 = 6

45
Error Seeding - issues
 The kind of seeded errors should match closely with
existing errors:
◦ However, it is difficult to predict the types of errors that exist.
 Categories of remaining errors:
◦ can be estimated by analyzing historical data from similar projects.

46
Alternative method of error estimation
 Have two independent testers,A and B
 N1 = valid errors found by A
 N2 = valid errors found by B
 N12 = number of cases where same error found by A and B
 Estimate = (N1 × N2)/ N12
 Example: A finds 30 errors, B finds 20 errors. 15 are common
to A and B. How many errors are there likely to be?
 (30 X 20)/15 = 40 errors
Test automation
 Other than reducing human effort and time,
◦ Test automation also significantly improves the thoroughness of
testing.
 A large number of tools are at present available both in the
public domain as well as from commercial sources.

48
Types of Testing Tools
 Capture and playback
 Automated test script
 Random input test
 Model-based test
 Summary
 Discussed ISO/IEC 15504 Standard
 Discussed PSP.
 Briefly introduced Six sigma.
 Explained some techniques to improve software quality.
◦ Clean room software development
◦ Formal methods
◦ Testing
 References
1. B. Hughes, M. Cotterell, R. Mall, Software Project Management, Sixth Edition,
McGraw Hill Education (India) Pvt. Ltd., 2018.
2. R. Mall, Fundamentals of Software Engineering, Fifth Edition, PHI Learning Pvt. Ltd.,
2018.
Thank you