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.
Ask Questions of the coordinator.
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
11
Software effort estimation
techniques

12
 SOFTWARE PROJECT EFFORT
AND COST ESTIMATION
• Software projects are costly as software professionals are expensive to
hire.
• The optimal usage of time of these high-salaried people requires careful
project planning to minimize wastage of time of these high-cost resources.
• Therefore, an accurate effort and cost estimate is of paramount importance
for software projects.
• With regard to effort for a software project, there are two aspects. One is to
provide a good effort estimate and present it to the customer. The other
aspect is to use it to form the project team based on the skills required
for the project and the kind of budget that will be available for the
project so that the right kind of people can be staffed for the project within
the specified budget.

13
 Effort Estimation Techniques
• Actual effort data from past projects provide good guidance as to
what the effort required for the given project could be.
• Comparing data available for current project with past executed
projects should provide this valuable estimated effort information.
Scenarios:
• 1. Much relevant project data are available for the current project but not
much information about previous projects.
• 2. Previous project data are available for the project but not much
information about the current project.
• 3. Project data are available for the current project as well as that of
previous projects.
• 4. Some project data are available for the current project.
• 5. No project data are available for both current as well as previous
projects.

14
 Choosing a Suitable Effort Estimate Technique
• Different effort estimation techniques can be used depending on
the situation.
• If you have good information available for the current project
but no data available for previous projects, the best technique
for effort estimation will be the COCOMO model, because this
model uses project size information from lines of code (LOC) as
well as project attributes available from current project
information.
• COCOMO also uses industry averages for environment factor
calculations.
• Therefore, if no previously executed project information is
available then the COCOMO model is the best.

15
 Function point analysis (FPA)
• If we have data available for both current as well as previous
projects then the function point analysis (FPA) technique is a good
option.
• It also uses historical (PAST)project data to derive productivity for
projects.
• Therefore, in cases where we have both project as well as
previously executed projects data, FPA can be used. Otherwise this
technique is difficult to use if both these pieces of data are not
available.

16
 Wide Band Delphi model
• If we have some or all data available for the current
project, then the Wide Band Delphi model is the
best.

17
18
Function point analysis (FPA)
The process for calculation is as follows:
1. Determine type of function count
2. Identify scope and boundary of count
3. Determine unadjusted FP count
4. Determine value adjustment factor
5. Calculate adjusted FP count

19
 FPA
For function count calculations, three types of function
count are defined:
• development project FP count,
• enhance project FP count, or
• application FP count.
• Depending on the type of project in hand (development,
enhancement, or application type of project), the suitable function
count type (FP count type) is chosen.
• FP count type is used for determining how the number of FPs will
be summed up.

20
• An unadjusted FP count consists of five function types.
These types are grouped into two, namely, data functions
and transaction functions.
• Data functions are internal logical files and external interface files.
• Transaction functions are external inputs, external outputs, and
external inquiries.
• These functions are defined with descriptions like User Identifiable,
Control Information, Elementary Process, Data Element Type
(DET), and Record Element Type (RET).

21
22
23
 Wide Band Delphi
• The Wide Band Delphi technique is based on
conducting brainstorming sessions with the project
team and arriving at consensus figures for effort
estimates.
• In the first session the raw estimates are discussed
just to get the basis on which the estimate was made.
• In the next two sessions, estimates are taken from other
team members. Finally, the estimate for each task is
normalized.

24
 Wide Band Delphi
• The Wide Band Delphi technique is commonly applied
on small to medium-sized projects and where the
project team is composed of people who have been
around and have worked with each other for some time.

25
• The optimistic estimate is the expected amount of work
or time needed to perform an activity
• The Pessimistic Estimate - longest duration, or highest
cost, to complete the work.
• Likely Estimate -Estimate for both favorable and
unfavorable conditions, with some risks occurring.

26
• pessimistic estimate is the one where a team member’s
estimate is the highest (in terms of number of man
months).
• The likely estimate is the average of the most common
estimate figure.
• In most cases, the likely estimate is the estimate given by
the person who has been assigned to the task for which
the effort estimate is being made.
• The optimistic estimate is the one where a team
member’s estimate is the lowest (in terms of number of
man months).

27
 COCOMO - Constructive Cost Model
• COCOMO is one of the original effort estimation models
developed by software engineering experts.
• It is also a very popular technique for effort estimation
for software projects.
• COCOMO uses project assumptions, definitions, and
many cost factors in assessing( evaluating) an estimate
for any project.
• It uses source LOCs required to build the software as the
volume of work to be done for which the effort estimate
is made.

28
Basic COCOMO

29
30
 Intermediate COCOMO
• In intermediate COCOMO, we make an effort estimate for the
project with the product size along with the cost drivers.
• The cost driver set includes assessment of attributes for product,
project, hardware, and the project team’s experience and skills.
• These attributes are categorized as product attributes, which include
required reliability, application database size, and application
complexity.

31
32
• How each of the cost drivers impacts the effort estimate is assessed
by assigning appropriate weights to these attributes.
• To assign these weights, first a six-point scale is created with
scales of very low, low, nominal, high, very high, and extra high.
• The values for these scales vary from a low of 0.70 to a high of
1.60.
• For any project, each of the attributes is given relevant values
based on this scale.
• These attribute values are industry standard but at what scale value
any attribute falls is decided by the estimating person

33
34
35
36
1. Organic
A software project is said to be an organic type if the team size required is adequately small,
the problem is well understood and has been solved in the past and also the team members
have a nominal experience regarding the problem.
2. Semi-detached
A software project is said to be a Semi-detached type if the vital characteristics such as team
size, experience, and knowledge of the various programming environments lie in between
organic and embedded. The projects classified as Semi-Detached are comparatively less
familiar and difficult to develop compared to the organic ones and require more experience
better guidance and creativity. Eg: Compilers or different Embedded Systems can be
considered Semi-Detached types.
3. Embedded
A software project requiring the highest level of complexity, creativity, and experience
requirement falls under this category. Such software requires a larger team size than the
other two models and also the developers need to be sufficiently experienced and creative to
develop such complex models.

37
 Effort Estimation for Waterfall Model–Based Planning
• One important consideration for effort estimation for a project
with the waterfall model is calculating effort estimation for
different phases of the software life cycle
• This can be done in two ways. Effort estimate for a phase can be
calculated by summing up effort required for all tasks associated
with that phase. An effort estimate for all phases can also be
calculated from total effort required for the project by
allocating percentage of effort for each phase.
• Thus, if total effort required for the project is 1500 man hours, and
if requirement management comprises 15% of total effort, then the
effort estimate for requirement management will be 225 man hours
(1500 × 15/100). Likewise, an effort estimate for other phases can
be calculated.

38
39
Effort Estimation for Iterations Model–Based
Planning

40
 Cost Estimation
• Once you have the effort estimate for the project,
calculating costs for the project is required .
• Here we are assuming that the project is based on a
fixed cost–fixed duration basis.
• Suppose for a project the effort figure is 13 man
months and a man month rate of $4,000 is applied.
The project cost comes to $52,000.
• The project manager always has to keep an eye on the
productivity (efficiency) of the staff so that the money
spent on salary has a good return value.

41
• Moreover, the salary of software professionals is not
directly linked to their productivity; two software
professionals with the same years of experience and
same skill sets but with different productivity levels
may get the same salary.
• Similarly, the salary for different professionals with same
productivity may be different. This creates a problem in
calculating project expenses.

42
43
44
45
• There are two types of projects: time and material based and
fixed schedule–fixed costs based. Fixed cost–fixed schedule based
projects are the ones where requirements are concrete (actual or
tangible) and most of the project details are clear.
• Costing for such projects is also clear in the beginning of the project.
But not all projects have enough clarity to start with. Many
projects start with lots of doubts, ambiguities, and uncertainties.
• In such cases, costing and scheduling is very difficult to make.
Hence, these projects are executed on a time and material costs
basis.
• The customer agrees on recurring (regular) payment of time spent by
a project team on his/her project. Generally, the recurring payment is
in the form of a monthly fee.

46
47
 Schedule Estimation
• The effort for the project is calculated first, followed
by the schedule.
• Once the schedule is made, the schedule duration
will be the difference between the date when the
project starts and date when the project ends.
• From the PERT/CPM view, the project duration will be
the difference between start date of the earliest
project task and end date of the latest project task.

48
 Resource Estimation
• After making the schedule, we estimate the resource
requirements.
• In order to do this, we should first get the list of tasks
on the project.
• For each task, we need to identify the required skills
and level of experience.
• A list of all skills and minimum necessary experience
required for each task should be marked.
• For each task we need to identify the resources
available in the organization.

49
 Project Closure
• After successful execution of a project, things come to a close
• As per the contract, the final deliverables have to be handed
over to the customer before the project deadline.
• Before the closure of the project, you need to check if all
deliverables are going to be achieved before the set deadline.
• The deliverables include the tested software product,
user/training manuals, user training, and
installation/implementation of the software product at client site.
It may also include product release information if the project is to
develop a software product with many iterations and is built
incrementally.

50
51
 Source Code Management
• Many versions of the source code get generated as requirements,
and designs get changed during the software development life
cycle.
• During testing, many bugs are discovered and they are fixed. The
final source code thus has seen a lot of change, and which version
will be shipped to customer needs to be identified (Figure 8.2).

52
• The configuration management system should be kept up to
date with all source code changes .
• Sometimes, developers keep a local copy of the source code on
their machines and forget to update the configuration management
system with the changes they have made in the source code.
• Similarly, the user manuals and documents are sometimes not
updated with the changes in code, which results in shipping wrong
documentation to the customer.
• So it should be made sure that the correct version of the source
code along with the documentation is shipped to the customer.

53
 Project Data Management
• Software service providers as well as internal teams maintain a large
pool of project data for new projects .
• So when an existing project comes to an end, it is very important to
archive(record) project data.
• The archived data help in estimating effort, schedule, costs, and
quality level for new projects. This information is very valuable for
new projects.
• Providing project data as a performance indicator to the customer not
only boosts customer confidence about ability (skill) of the project
team, but it also helps in increasing productivity, project goal clarity,
and reducing schedule and costs when future projects actually get
executed.

54
 Project Data Management
• Software service providers as well as internal teams maintain a large
pool of project data for new projects. So when an existing project
comes to an end, it is very important to archive project data.

• The archived data help in estimating effort, schedule, costs, and

quality level for new projects. This information is very valuable for
new projects.

• Providing project data as a performance indicator to the customer not

only boosts customer confidence about ability of the project team, but
it also helps in increasing productivity, project goal clarity, and
reducing schedule and costs when future projects actually get
executed.

• Similarly, having historical data about similar projects helps in

setting goals for and estimating the new project.

55
 Project Closure in Iterative Model
• Software vendors are always keen to launch new versions of their software
product in the opportunity time window lest the opportunity is lost. This
results in some problems on the software development front.
• Iteration closure is often a messy affair if care and restraint are not
exercised. Due to market pressure, top management is under pressure to
incorporate all the requested features in the release.
• But it is clearly not feasible to do so. It is better to prioritize features based
on market demand and effort required to make them. So release planning
should be a part of the iteration planning at the beginning of the
iteration.
• Features with high demand but requiring lesser effort should ideally
be included first in the iteration. If time permits, then go for adding
another feature.
• Keep doing it until you do not have any time left for adding any more
features.
• Care should also be taken not to compromise on quality.

56
 Lessons Learned
• In life, people learn from doing things, and when
they become older, they become much wiser as they
accumulate all the learning over the years.
• Now when they apply this learning in their
assignments, they are much more effective. They
tend to do things better and are generally more
productive.

57
• Learning is a continuous process, and it should be done
whenever someone gets a chance to do things or see
others doing things.
• Projects are an excellent platform for learning.
• Each project has many new things that people may not
have done earlier in their lives.
• Not only the project team members but also the
organization learns from a project.
• Such learning should be documented so that it can
be referenced for future projects

58
• In a software project, we have many kinds of documents.
We have project management-related documents such as
project plan, communication plan, project schedule,
effort estimate, cost estimate, resource plan, and resource
allocation.
• Then, we have requirement documents, design
documents, user manuals, and maintenance manuals
from life-cycle management.
• We also have contract documents, statements of work,
and legal documents from contract management

59
• Due to change requests, we will have many versions of
different life-cycle documents. All of these documents go
in the configuration management system.
• But most documents from contract management and
project management do not go in the configuration
management system.
• At the most project plan, project schedule, work
breakdown structure, and resource plan go in the
configuration management system.

60
• Communication documents are the ones that contain
the most unstructured and informal documentation.
Nevertheless, e-mails and instant messages contain very
useful pieces of information.
• Once the project is over, all these good pieces of
information get lost.
• There should be some mechanism to extract this
information and store it on the configuration management
system, or rather knowledge management system, so that it
is permanently available to the entire organization and not
just one project. This information should be stored as
lessons learned on a project.

61
62
63
THANK YOU

64