CSE3050 – Software Project

Management

SCHOOL OF CSE & IS,

PRESIDENCY UNIVERSITY,
BANGALORE

1
SOFTWARE PROJECT EFFORT AND COST
ESTIMATION

2
• Software cost estimation based on past performance.
• Historical data used to identify cost factor.
Methods:
1. Top-down
• Focuses on system level costs
• Computing resources & personnel to develop the system
• Costs of Configuration management
• Quality assurance
• System Integration
• Testing
• Publications
2. Bottom-up
• Estimates the cost to develop each module or subsystem.
• Combine overall cost.

3
TECHNIQUES:
• Expert Judgment
• Delphi Cost Estimation
• Work breakdown structure
• COCOMO Model

4
1. EXPERT JUDGMENT
• Most widely used estimation technique
• Top-down estimation technique
Example:
Process control system -> 10 months & $1 million cost
New system -> 25% more activities -> increase our time and cost.
• Same computer and external sensing/controlling devices & same people
available to develop the new system.
• Reduce our estimate by 20%.
Advantages:
1. Experience
2. Expert Confident that the project is similar to previous one.
3. Group of experts prepare a consensus estimate.
4. Minimize individual oversights.

5
EXPERT JUDGMENT Contd..
DISADVANTAGES
• Interpersonal group dynamics may have on individuals in the group.
• Political Consideration
• Dominance of an overly assertive group member.

6
2. DELPHI COST ESTIMATION
• Developed by rand Corporation in 1948.
• Without Introducing the adverse side effects of group meetings.
1. A coordinator provides each estimator with the system Definition
document.
2. Estimators study the definition and complete their estimate
anonymously.
3. Coordinator prepares and distributes a summary of the estimators
response.
4. Estimators complete another estimate, again anonymously using the
results from the previous estimate.
5. The process is iterated for as many rounds as required. No group
discussion is allowed during the entire process.

7
VARIATION OF DELPHI COST
ESTIMATION
• Coordinator provides each estimator with a system definition and an
Estimation form
• Coordinator calla a group meeting and discuss the estimation issues with
each other
• Estimators complete their estimators anonymously
• The Coordinator prepares a summary of estimates, but does not record any
rationale
• The Coordinator calls a group meeting to focus on issues where the
estimation vary widely
• Estimators complete another estimate, again anonymously. The process
repeated so many round.

8
WORK BREAK DOWN STRUCTURE
• Bottom-up Estimation
• Hierarchical chart -> individual parts of the system
• WBS -> product hierarchy/process hierarchy

Product Hierarchy
Identifies the product components and how its interconnected

Process Hierarchy
Identifies the work activities and the relationship among those activities.

9
PRODUCT WBS
PROJECT

TASK 1 TASK 2 TASK 3

SUB TASK 1.1 SUB TASK 2.1 SUB TASK 3.1

Work Package Work Package Work

2.1.1 2.1.2 Package 2.1.3

10
RISK MANAGEMENT

11
Introduction
• Risks are unforeseen or unplanned happenings, which, when they
occur, devastate or at least adversely affect our future plans.

12
• Risks can be categorized as external and internal
• If a risk to the project arises due to an aspect being dealt with by the project team, then it is an internal
risk.
• Now, suppose that this particular training is not available from any training service provider, then in
that case, the risk becomes an external risk

Causes of risks
• For any good project manager, it is of utmost importance that he first of all makes a list of risks which
his project faces.
• Quality Constraints - where the quality standards are not well defined, or achieving them becomes
challenging
• Resource availability - Limited availability of key resources such as skilled personnel, tools, or
infrastructure can delay the project.
• Disinterest - Lack of motivation or interest from the team or stakeholders
• Attrition - Loss of key team members during the project can lead to delays, (Skilled)
• Scope creep - Continuous or uncontrolled growth in a project’s scope can lead to budget overruns, missed
deadlines

13
• Cost constraints - Budget limitations can hinder the project’s ability to secure the necessary resources,
tools, or talent.

• Bad Negotiation - Poor negotiations with vendors, clients, or stakeholders can lead to unfavorable
contracts, resource delays, or budget shortfalls.

• Unrealistic estimate Overestimating or underestimating the time, cost, or resources needed for the
project can result in failures or overruns.

• Human Error Poor Management : Mistakes made by team members, whether in coding, planning, or
execution, can delay the project and affect quality.

14
Risk Categories
• Budget risks –
• Remedial action must be taken as soon as the project shows the risk of cost overrun
• Time(Schedule) risks –
 lack of proper communication,
 Customer requirements are completely misunderstood,
 Resulting in an inappropriate product being delivered to the customer,
 Complete rework is required to prepare the software.
• Resource risks - It is not a good idea to keep a paid reserve on the project – Increase Cost.
• Quality risks - risk. The quality of the product may be poor due to
Bad software design or bad software construction.
• Technology risks - With the rapid introduction of new products into the market,
Older products quickly become obsolete.

Risk Analysis
• Based on the analysis, you then need to sort risks and put them in order. Risks with high
probability and high impact will be put on top of this list, while risks with low impact and
low probability will be put at the bottom. The project manager will then be better prepared
to deal with all kinds of risks in a systematic manner

15
Risk Analysis

• Based on the analysis, you then need to sort risks and put them in order.
• Risks with high probability and high impact will be put on top of this list,
• Risks with low impact and low probability will be put at the bottom.
• The project manager will then be better prepared to deal with all kinds of risks

16
SOFTWARE CONFIGURATION
MANAGEMENT

17
Introduction

• Configuration management is needed on software projects because numerous artifacts are

produced during the entire product development life cycle.
• (code files, design documents, requirements, and testing results)
• A build of the software product is kept at a central location and each new piece of software
being developed is integrated with the existing build.

Configuration Management
• Change control for different versions of information items is what makes configuration
management a difficult area.
• Some common tags for item identification include
• Project name
• Year and time stamp
• Document name
• Document number
• Author
• Activity identifier
• Document type
• Version number

18
Configuration Management techniques

• Following are some techniques and best practices that are extremely useful:

1. Centralized configuration management system

2. Secured access mechanism with role-based access control
3. Continuous integration of software build with smoke test facility
4. Easy branching mechanism to branch out an entire software version
5. Audit facility

19
PROJECT MONITORING AND CONTROL

20
Introduction
• Projects are inherently dynamic in nature.
• The process model will set steps to be followed for completing all project tasks and thus
help in planning the project.

Project Monitoring
• A project plan consists of a project schedule and project budget apart from other plan
components like communication plan, quality plan, configuration plan, resource plan, etc
• Monitor against Project Plan
• Measure Task Progress and status reports
• Identify Deviations
• Performance Indicators
• Monitor against Project Schedule
• Periodic Management
• Earned value Management
• Measure Resource utilization
• Measure Resource Loading
• Monitor skills
• Monitor risks

21
Project Control Techniques

Resource Leveling - Resource leveling is one technique that is employed to resolve resource
conflicts during project execution.
Schedule Optimization - Using PERT/CPM methods, we can determine the critical path of the
project. But before drawing the critical path, the project manager should ascertain that there is
no unnecessary slack in the project plan.
• Schedule optimization can also be done during execution.
Resource Optimization
• When the company bid for a project, it would have taken the profit margin for the project.
During project execution, however, there are many factors that threaten to eat into the profit
margin.

Project Monitoring and Control artifacts

• Project monitoring provides project process and work product data that we can use to make
decision and control the project so that later on it can be kept on track despite derailings in
the past.
• PERT/CPM charts, network diagrams, resource charts, EVM, etc.

22
Project Monitoring and control in Iterative Model

• Since duration of each iteration is small (a few weeks to 2–3 months), impact on an
individual iteration due to any unforeseen circumstances is not that severe.
Performance Measurements:
Some of these measures include the following:
• Feature points delivered per iteration
• Number of defects found per iteration
• Productivity of team in terms of delivering features per person per iteration
Risks
• Iterations are generally time boxed. You need to complete a certain number of feature points
(feature points are a number assigned to a feature depending on the size of the feature and
its complexity) in the iteration duration.
• Otherwise agile environments are pretty stable and devoid of risky propositions. There is
no such thing as resource allocation in these projects. Each person in these projects has his
role well defined.

23
Project closure

24
Introduction

• After successful execution of a project, things come to a close.

• How satisfying the journey has been is determined from all
 The status reports and
 Feedback from the customer.
• All along, there could have been moments of anxiety, discovery, joys, and sorrows.
• Source Code Management
• Project Data Management
• Project Closure in Iterative Model
• Lessons learned
• Resource release
• Data structures

25
Formulas:
• These types of questions will test you on your understanding of the meaning of various EVM
metrics:
Planned Value (PV) — how much work was scheduled to date
Earned Value (EV) — how much work was completed to date
Actual Cost (AC) — the amount of money spent so far
Budget at Completion (BAC) — the total budget for the project
Estimate at Completion (EAC) — the estimated total amount of money needed to be put into the
project based on the information available as today
Estimate to Completion (ETC) — how much more do we need to put into the project to complete it
Variance at Completion (VAC) — the difference between the estimated total cost and the original
budget
Cost Performance Index (CPI) — ratio between EV and AC, to reflect whether the project work is
under / on / over budget in relative terms
Schedule Performance Index (SPI) — ratio between EV and PV, to reflect whether the project work
is ahead of / on / behind schedule in relative terms
To Complete Performance Index (TCPI) — the efficiency needed to finish the project on budget, it
is the ratio between budgeted cost of work remaining and money remaining

26
• SV = EV – PV
• CV = EV – AC
• SPI = EV/PV
• CPI = EV/AC
• VAC = BAC – EAC
• EAC = BAC/CPI
If we believe the project will continue to spend at the same rate up to now (e.g. the delay is
caused by reasons which is likely to continue)
• EAC = AC + (BAC-EV)
If we believe that future expenditures will occur at the original forecasted amount (no more
delays of the same kind in future)
• EAC = AC + [(BAC-EV)/(SPI*CPI)]
If we believe that both current cost and current schedule performance will impact future cost
performance
• EAC = AC + New Estimate
If we believe the original conditions and assumptions are wrong

27
THANK YOU

28