Software Estimation and

Scheduling
CO3: Student will be able to Plan, schedule and track the progress of
the projects.

1
Contents
• Management Spectrum, 3Ps (people, product and process)
• Process and Project metrics
• Software Project Estimation: LOC, FP, Empirical Estimation Models -
COCOMO II Model, Specialized Estimation Techniques, Object based
estimation, use-case based estimation
• Project scheduling: Defining a Task Set for the Software Project,
Timeline charts, Tracking the Schedule, Earned Value Analysis
• Self-learning Topics: Cost Estimation Tools and Techniques, Typical
Problems with IT Cost Estimates.

2
The Management Spectrum
• Describes the management of a software project
• The management spectrum focuses on the four P’s; people, product,
process and project.
• The manager of the project has to control all these P’s to have a smooth
flow in the progress of the project and to reach the goal.
• The four P’s of management spectrum are
• People
• Product
• Process
• Project

3
4
The People:
• Includes from manager to developer, from customer to end user.
• Software Engineering Institute has developed a People Management
Capability Maturity Model (PM-CMM),
“to enhance the readiness of software organizations to undertake increasingly complex
applications by helping to attract, grow, motivate, deploy, and retain the talent needed
to improve their software development capability”.
• Recruiting, selection, performance management, training, compensation,
career development, organization and work design, and team/culture
development.
• Organizations that achieve high levels of maturity in the people
management area have a higher likelihood of implementing effective
software engineering practices.

5
The Product:
• Before a project can be planned, product objectives and scope
should be established, alternative solutions should be considered,
and technical and management constraints should be identified.

6
The Process:
• A software process provides the framework from which a
comprehensive plan for software development can be established.
• A number of different tasks sets— tasks, milestones, work products,
and quality assurance points—enable the framework activities to be
adapted to the characteristics of the software project and the
requirements of the project team.

7
The Project:
• The project is the complete software project that includes
requirement analysis, development, delivery, maintenance and
updates.
• The project manager of a project or sub-project is responsible for
managing the people, product and process.
• A software project could be extremely complex and as per the
industry data the failure rate is high. Its merely due to the
development but mostly due to the steps before development and
sometimes due to the lack of maintenance.

8
Process and Project metrics

9
Process metrics
• These are the metrics pertaining to the Process Quality. They
measure efficiency and effectiveness of various processes.
• Process metrics are collected across all projects and over long periods
of time.
• Their intent is to provide a set of process indicators that lead to long-
term software process improvement.

10
 Determinants for software quality and organizational effectiveness

• The skill and motivation of

people
• The complexity of the product
• The technology (i.e., the
software engineering
methods and tools)

11
Project metrics
• These are the metrics pertaining to the Project Quality. They
measure defects, cost, schedule, productivity and estimation of
various project resources and deliverables.
• Project metrics enable a software project manager to
(1) assess the status of an ongoing project,
(2) track potential risks,
(3) uncover problem areas before they go “critical,”
(4) adjust work flow or tasks, and
(5) evaluate the project team’s ability to control quality of software work
products.

12
Software Project Estimation

13
Software Project Estimation
• Before the project can begin, the software team should estimate the work
to be done, the resources that will be required, and the time that will
elapse from start to finish.
• Once these activities are accomplished, the software team should establish
a project schedule that defines software engineering tasks and milestones,
identifies who is responsible for conducting each task, and specifies the
inter-task dependencies that may have a strong bearing on progress.
• Estimation of the size of software is an essential part of Software Project
Management. It helps the project manager to further predict the effort and
time which will be needed to build the project. Various measures are used
in project size estimation.
14
Important Factors
• Project complexity
• Project size
• Degree of structural uncertainty -refers to the degree to which
requirements have been solidified, the ease with which functions can
be compartmentalized

15
The Project Planning Process

16
Software Scope and Feasibility
• Software scope describes the functions and features that are to be
delivered to end users; the data that are input and output; the
“content” that is presented to users as a consequence of using the
software; and the performance, constraints, interfaces, and reliability
that bound the system.
• Scope is defined using one of two techniques:
1. A narrative description of software scope is developed after communication with
all stakeholders.
2. A set of use cases is developed by end users.

17
Project Resources

18
Reusable Software Resources
• Off-the-shelf components-existing software that can be acquired from
a third party or from a past project,
• Full-experience components-existing specifications, designs, code, or
test data developed for past projects that are similar to the software
to be built for the current project,
• Partial-experience components-existing specifications, designs, code,
or test data developed for past projects that are related to the
software to be built for the current project but will require substantial
modification,
• New components-components built by the software team specifically
for the needs of the current project.
19
20
Software Metrics
The five essential, essential, fundamental metrics:
• Size (LOC, etc.)
• Cost (in dollars)
• Duration (in months)
• Effort (in person‐month)
• Quality (number of faults detected)

21
Product Size Metrics
• Conventional metrics
• Size‐oriented metrics
• Function‐oriented metrics
• Empirical estimation models
• Object‐Oriented metrics
• Number of scenario scripts
• Number of key classes
• Number of support classes
• Average number of support classes per key classes
• User‐Case oriented metrics
22
Product Size Metrics (cont’d)
• Web engineering product metrics
• Number of static web pages
• Number of dynamic web pages
• Number of internal page links
• Number of persistent page links

23
Size Estimation
The methods to achieve reliable size and cost estimates:
• LOC‐based estimation
• FP‐based estimation
• Empirical estimation models
• COCOMO

24
LOC‐based Estimation
• The SLOC technique is an objective method of estimating or calculating
the size of the project.
• The project size helps determine the resources, effort, cost, and
duration required to complete the project.
• It is also used to directly calculate the effort to be spent on a project.
• We can use it when the programming language and the technology to
be used are predefined.
• This technique includes the calculation of lines of codes (LOC),
documentation of pages, inputs, outputs, and components of a software
program.

25
LOC‐based Estimation
The problems of lines of code (LOC)
• Different languages lead to different lengths of code
• It is not clear how to count lines of code
• A report, screen, or GUI generator can generate thousands of lines of
code in minutes
• Depending on the application , the complexity of code is different

26
LOC‐based Estimation ‐ Example

27
Example:

28
FP‐based Estimation
• Based on FP metric for the size of a product
• Based on inputs, outputs, data files, inquiries, and external interfaces
• Step 1: Classify each component of the product as simple, average , or
complex
• Assign the appropriate number of function points
• The sum of function pointers for each component gives UFP (unadjusted
function points)

29
The steps in function point analysis are:
1. Count the number of functions of each proposed type.
2. Compute the Unadjusted Function Points(UFP).
3. Find Total Degree of Influence(TDI).
4. Compute Value Adjustment Factor(VAF).
5. Find the Function Point Count(FPC).

30
1. Count the number of functions of each proposed type

Find the number of functions belonging to the following types:

• External Inputs: Functions related to data entering the system.
• External outputs: Functions related to data exiting the system.
• External Inquiries: They leads to data retrieval from system but don’t
change the system.
• Internal Files: Logical files maintained within the system. Log files are
not included here.
• External interface Files: These are logical files for other applications
which are used by our system.

31
2. Compute the Unadjusted Function Points(UFP)
• Categorize each of the five function types as simple, average or complex
based on their complexity.
• Multiply count of each function type with its weighting factor and find the
weighted sum.
• The weighting factors for each type based on their complexity are as
follows:

32
3. Find Total Degree of Influence
• Use the ’14 general characteristics’ of a system to find the degree of
influence of each of them.
• The sum of all 14 degrees of influences will give the TDI. The range of
TDI is 0 to 70.
• The 14 general characteristics are: Data Communications, Distributed
Data Processing, Performance, Heavily Used Configuration,
Transaction Rate, On-Line Data Entry, End-user Efficiency, Online
Update, Complex Processing Reusability, Installation Ease,
Operational Ease, Multiple Sites and Facilitate Change.
• Each of above characteristics is evaluated on a scale of 0-5.
33
0 = No influence,
1 = Incidental,
2 = Moderate,
3 = Average,
4 = Significant,
5 = Critical

34
The general characteristics and brief description of the 14 complexity adjustment
values above are shown below:

35
4. Compute Value Adjustment Factor(VAF)
• Use the following formula to calculate VAF
VAF = (TDI * 0.01) + 0.65

5. Find the Function Point Count

• Use the following formula to calculate FPC
FPC = UFP * VAF

36
Estimation of LOC from FP
• Basing on the size of the project in FP, you can estimate or calculate
the numbers of LOC by multiplying the average number of LOC/ FP for
a given language (AVC) by the total number of function points of the
project.
• To calculate the numbers of line of code, the following formula is used

37
38
Function Point Example
Information Weighting Factor
Domain Value Count Simple Average Complex
External Inputs 3 x 3 4 6 = 9
External Outputs 2 x 4 5 7 = 8
External Inquiries 2 x 3 4 6 = 6
Internal Logical Files 1 x 7 10 15 = 7
External Interface Files 4 x 5 7 10 = 20
Count total 50

• FP = count total * [0.65 + 0.01 * sum(Fi)]

• FP = 50 * [0.65 + (0.01 * 46)]
• FP = 55.5 (rounded up to 56)

39
40
Example 1: cont’d…..

41
42
Example 2: cont’d…..

43
Using FP for Initial Estimation…..

44
FP-Based Estimation……
• Assume FP of a system is: 375
• Average productivity for system of this type is: 6.5 FP/pm
• Labor rate is: $ 800 per month

Cost per FP is: 800/6.5 = $123

Total Estimated Cost is: $123 * 375 = $46,100
Total Estimated Effort is: 46,100/800 = 57.62 = 58 person-months

45
Using FP for Post-Project analysis…

46
Interpretation of the FP Number
• Assume that past project data for a software development group
indicates that
• One FP translates into 60 lines of object-oriented source code
• 12 FPs are produced for each person-month of effort
• An average of three errors per function point are found during analysis and
design reviews
• An average of four errors per function point are found during unit and
integration testing
• This data can help project managers revise their earlier estimates
• This data can also help software engineers estimate the overall
implementation size of their code and assess the completeness of
their review and testing activities
47
COCOMO
• COnstructive COst Model
• Empirical model
• Metrics such as LOC and FP are used as input to a model for determining
product cost and duration
• Well documented, and supported by public domain and commercial
tools;
• Widely used and evaluated
• Has a long pedigree from its first instantiation in 1981
• COCOMO I (81)
• COCOMO II

48
COCOMO types
There are three forms of the COCOMO
• Basic COCOMO (macro estimation) which gives an initial rough
estimate of man months and development time
• Intermediate COCOMO which gives a more detailed estimate for small
to medium sized projects
• Detailed COCOMO (micro estimation) which gives a more detailed
estimate for large project

49
Basic COCOMO
• The basic COCOMO technique is used to estimates the effort and cost
of a SW project by using only the lines of code.
• We use basic COCOMO when we need a rough estimate of effort,
such as during maintaining a project.
• There are three steps involved in estimating the effort using basic
COCOMO technique:
• S1- Estimating the total delivered lines of code.
• S2- Determine the effort constants based on the type of the project
• S3- Substituting values for lines of code and effort constants in a formula

50
There are three types of projects to be calculated effort.

• Organic Mode: Relatively small, simple software projects in which a

small team with good application experience work to a set of less
than rigid requirement.
• The organic projects must have sufficient and defined objectives.
• These are simple businesses and applications, such as a banking
system and inventory system

51
• Embedded Mode: A software project that must be developed within
a set of tight hardware, software and operational constraints.
• The embedded projects must have stringent and specialized HW, SW,
and human resources requirements.
• Organizations usually have less experience in developing such
projects.
• Examples of such projects includes real-time operating systems,
industrial automation systems, and sophisticated space and aviation
systems

52
• Semi-Detached Mode: An intermediate (in size and complexity)
software project in which teams with mixed experience levels must
meet a mix of rigid and less than rigid requirements.
• Semidetached projects are combination of the preceding two types of
SW projects.
• Examples: a new operating system, a database management system

53
Basic COCOMO
• Select the software project type and substitute the values of C and K
from the following table into the formulas below the table:

54
Basic COCOMO Example:
• Estimate the effort of an application (organic type) with 4 KLOC

• Ans:
• Ei = 3.2 * 4 1.05 = 3.2 * 4.28 14 person-months

55