1

Module 2: Planning – scope,

milestones & deliverables
 2

Topics to be covered
● Planning
● Scope
● Milestones
● Deliverables
Planning
3

● It is the first and foremost activity to achieve desired results.

● It is used establishment of objectives and analysis of present
limitations for attaining such goals.
Planning Example 4
 5

Planning Objectives
● To Reduce Uncertainty.
● To Bring Cooperation and
Coordination.
● To Bring Economy in Operation.
● To Anticipate Unpredictable
Contingencies.
● To Achieve the Predetermined Goals.
● To Reduce Competition.
 6

Meaning of Planning
● What should be done
● How it should be done
● Who will be responsible
● Where the action is to be taken
● Why its done
7
Scope Planning
8

● Scope refers to the combined

objectives and requirements needed to
complete a project.
● The scope of a project allows
managers to estimate costs and the
time required to finish the project.
 9

Scope Definition

● Project scope is the part of project

planning that involves determining and
documenting a list of specific project
goals, deliverables, features, functions,
tasks, deadlines, and ultimately costs.
 10

Steps in Scope Definition

● 1. Identify the project needs

● 2. Confirm the objectives and goals of the Project
● 3. Project Scope description
● 4. Expectations and acceptance
● 5. Identify constraints
● 6. Identify necessary changes
Scope Project Requirements 11

● Functional Requirements
● Non-Functional Requirements
● Technical Requirements
● Business Requirements
● User Requirements
● Regulatory requirements
 12

An Example of Requirements
The following represents one possible example of each
type of requirement as they would be applied to a bank’s
external ATM.
● ATM functional requirement: The system will enable the
user to select whether or not to produce a hard-copy
transaction receipt before completing a transaction.
● ATM non-functional requirement: All displays will be in
white, 14-point Arial text on black background.
● ATM technical requirement: The ATM system will
connect seamlessly to the existing customer’s database.
 13

Contd..
● ATM user requirement: The system will complete a
standard withdrawal from a personal account, from
login to cash, in less than two minutes.
● ATM business requirement: By providing superior
service to our retail customers, Monumental Bank’s
ATM network will allow us to increase associated
service fee revenue by 10% annually on an ongoing
basis.
● ATM regulatory requirement: All ATMs will connect
to standard utility power sources within their civic
jurisdiction, and be supplied with an uninterrupted
power source approved by the company.
 14

Milestones

● Milestones are used as signal posts for: a project's start or end date, a
need for external review or input, a need for budget checks, submission
of a major deliverable, and much more.
 15

Milestone questions asked

● Is this a task or a deliverable?

● Will this impact the final deadline?
● Is this an important moment in the project
that will indicate forward progress?
● Does this need to be reviewed by
stakeholders?
● Is this an event that impacts the project?
 16

Milestones Examples
● Start and end dates for project phases
● Key deliveries
● Client and stakeholder approvals
● Important meetings and presentations
● Key dates or outages that may impact your
timeline
Milestones - Make the deliverables project
milestones!
17

● Monitor deadlines
● Spotlight important dates
● Identify potential project bottlenecks
 18

Deliverables

● A deliverable is any unique and verifiable

product, result, or capability to perform a
service that must be produced to complete
a process, phase, or project.
Some deliverables are common for every 19

project, such as:

● Project plan
● Project budget
● Project charter
DELIVERABLES FOR IT PROJECTS 20

● Requirement specification (document)

● User interface
● Backend development
● Set up of Test system
● Set up of Live system
● Data migration
● User training
 Example: A Customer relationship
management (CRM system) with the following
21

objectives:

● Standardize how the employees work with

the clients of the company
● Reduce the expenses for some transactions
● Enhance client data authenticity
Thus the expected project results: 22

● Regulations describing how employees should

work with the clients
● A software product that automates those
regulations
● Employees that are trained to work with that
software product
● A functioning support service for software users
Deliverables vs. Milestones 23

● The main difference between deliverables

and milestones is that milestones don’t
require a product to be delivered to the
customer, client, or project sponsor.
● A milestone can be any threshold during
which a project transitions to another phase.
● For example, the completion of the
foundation of the house is a milestone, but
does not require any submission to the
client, customer, or project sponsor, hence it
is not a deliverable.
 MILESTONE DELIVERABLE

•Milestones are the end-point •Deliverables are project

of a process activity. results delivered to
customers.

•Significant event or a point •Measurable and tangible

in a project outcome of the project.

•Checkpoints throughout the •Developed in alignment with

life of the project the goals of the project
 Work Breakdown Structure
•Decomposes the total scope of work required to deliver a
product, service, or project into smaller, more manageable
components
•Interdependencies among tasks may be defined using a
task network
•Identifies the project tasks that make up the critical path of
your project
•Enables to plan your resources, timelines, and priorities
Work Breakdown Structure
•The top level of your WBS represents the project's final deliverable, or
end product. It represents the project scope statement.
•The lower levels break down the scope into more detailed
deliverables and tasks.
•All these sub-elements can have time and cost estimates associated
with them.
•When combined, they form a total estimate of what’s required to
complete the project within its defined scope.
Work Breakdown Structure

•Process-oriented WBS
•Decomposes work into the processes needed to accomplish it, such as
requirements, design, development, and testing
•Clarifies what needs to be done and who will do it
•Deliverable-oriented WBS
•Decomposes work into tangible products or services, such as database
schema, and user manuals
•Gives an overview of the deliverables required for a project
Project Scheduling
Project scheduling is the process of deciding how the work in a project will be
organized as separate tasks, and when and how these tasks will be executed.

You estimate the calendar time needed to complete each task, the effort
required and who will work on the tasks that have been identified.

You also have to estimate the resources needed to complete each task, such as
the disk space required on a server, the time required on specialized hardware,
such as a simulator, and what the travel budget will be.
 Project Scheduling Activities
Split project into tasks and estimate time and resources required to
complete each task.

Organize tasks concurrently to make optimal

use of workforce.

Minimize task dependencies to avoid delays

caused by one task waiting for another to complete.

Dependent on project managers intuition and experience.

Project Scheduling
Project Schedule Representation
Graphical notations are normally used to illustrate the project
schedule.

These show the project breakdown into tasks. Tasks should not
be too small. They should take about a week or two.

Bar charts are the most commonly used representation for

project schedules. They show the schedule as activities or
resources against time.
Risk Management and
Metrics & Measurement

35
 36

Risk Management
Topics to be covered
37

- What is a risk?
- What is risk
management?
- Risk Management
Process
- How to identify risk?
- Risk Analysis
- Risk Planning
- Risk Monitoring
- Risk metrics and
measurements
What is Risk? 38

An unpredictable occurrence or situation that has a

positive or negative impact on the objectives of a
project.
The opportunity to be vulnerable to the negative effects
of future events or possible future problems.
What is Risk Management 39

Risk management is about

identifying threats and
designing strategies to mitigate
their impact on a project.

A chance (risk) is a likelihood

that there will be some adverse
circumstances
- Product risk
- Process risk
- Business risk
 Risk Management Process 40

In Risk management,

• Risk identification – what are the risks to a

project?

• Risk analysis – which ones are really

serious?

• Risk planning – what shall we do?

• Risk monitoring – has the planning

worked?
Risk Management Process 41
Risk Identification 42

How to identify
risks?

- Use of checklists
- Brainstorming
- Interviewing
Types of risks 43

- Technology risks.

- People risks.

- Organisational risks.

- Requirements risks.

- Estimation risks.
 Risks Analysis/Prioritization 44

- Assessing the probability and severity

of every risk.
- Probability: high or very high, moderate, very low, low
- Risk effects: serious, catastrophic, tolerable or
insignificant.
- Risk probability may be qualitative and quantitative

Risk exposure (RE) RE= (potential damage) x (probability of occurrence)

 45

R.No Impact Occurrences Risk Exposure

R1 3 2 6
R2 4 1 4
R3 1 5 5
R4 5 4 20
R5 2 2 4
R6 3 5 15
R7 4 1 4
R8 1 4 4
R9 3 3 9
R10 5 2 10

45
Risk Monitoring 46

• Review each defined risk

regularly to assess whether it is
becoming less or more likely or
not.
• Assess even how the
consequences of the risk have
changed.
• Increasing main risk should be
addressed at progress meetings
with management.
 Summary 47

• For a success of a project, good project management is essential .

• Many types of risks causes problems for management
• significant activities are planning, estimating and scheduling should
be monitored.
• Planning and estimating are iterative processes
until meeting the requirements of the project.
 48

Measurement & Metrics

 Goal of metrics 49

● To improve product quality and

development-team productivity
● Concerned with productivity and
quality measures
- measures of SW development output as
function of effort and time
- measures of usability
 Terms used 50

• Measure ● Indicator
quantitative expression of an A metric that provides/adjust
attribute of a product or process (improve) the process or project

• Measurement ● Process indicator

the act of determining a measure Allow assessment of process in
terms of what works and what
• Metrics doesn’t
quantitative measure of the degree
to which a system, component or ● Project Indicator
process possesses an attribute Adjust the task, uncover problem
areas, evaluated the team
 Metrics for… 51

· process - used to develop the SW

· project - specific SW development

project

· product - SW produced
 Typical Project Metrics 52

● Effort/time per software

engineering task
● Errors uncovered per review
hour
● Scheduled vs. actual
milestone dates
● Changes (number) and their
characteristics
● Distribution of effort on
software engineering tasks
 53

Software Measurement

● S/W measurement can be

categorized in two ways:

▪ Direct measures of the software process (e.g.,

cost and effort applied) and product (e.g., lines
of code (LOC) produced, etc.)

▪ Indirect measures of the product (e.g.,

functionality, quality, complexity, etc.)
 Direct &
54

Indirect measures

● Direct measure of process: Indirect measures of product:

○ cost and effort – functionality
– quality
● Direct measure of product:
– complexity
○ lines of code (LOC) – reliability
○ execution speed – maintainability
○ defects per time period
Size-Oriented Metrics 55
55

Function-Oriented Metrics
 56

Consolidation of metrics

● Individual metrics combined

to develop project metrics
● Project metrics consolidated
to create process metrics
● How to combine metrics from
different projects?
Software Project Planning

● A Software Project is the complete methodology of programming

advancement from requirement gathering to testing and support,
completed by the execution procedures, in a specified period to
achieve intended software product.
Need of Software Project Management

● The most significant is that the underlying technology changes and

advances so generally and rapidly that experience of one element
may not be connected to the other one.
● All such business and ecological imperatives bring risk in software
development; hence, it is fundamental to manage software projects
efficiently.
Software Project Manager

● Software manager is responsible for planning and scheduling

project development.
● They manage the work to ensure that it is completed to the required
standard. They monitor the progress to check that the event is on
time and within budget.
● The project planning must incorporate the major issues like size &
cost estimation scheduling, project monitoring, personnel selection
evaluation & risk Management.
To plan a successful software project, we
must understand:
● Scope of work to be completed
● Risk analysis
● The resources mandatory
● The project to be accomplished
● Record of being followed
Various Project Planning Activities
Software Project planning starts before technical work start. The various
steps of planning activities are:
Cost Estimation

Several estimation procedures have been developed and are having the following
attributes in common.
1. Project scope must be established in advanced.
2. Software metrics are used as a support from which evaluation is
made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and
schedule estimates.
6. Acquire one or more automated estimation tools.
Uses of Cost Estimation

1. During the planning stage, one needs to choose how many engineers
are required for the project and to develop a schedule.
2. In monitoring the project's progress, one needs to access whether the
project is progressing according to the procedure and takes corrective
action, if necessary.
Cost Estimation Models
A model may be static or dynamic.

● In a static model, a single variable is taken as a key element for

calculating cost and time.
● In a dynamic model, all Variable aré interdependent, and there is
no/basic Variable.
Static, Single Variable Models:
● When a model makes use of single variables(unique element) to
calculate desired values such as cost, time, efforts, etc. is said to be a
single variable model.
● The most common equation is:
Static, Single Variable Models:
The Software Engineering Laboratory established a model called SEL model,
for estimating its software production. This model is an example of the
static, single variable model.
Static, Multivariable Models:

● These model depends on several Variables describing various

aspects of the software development environment.
● In some model, several variables (user participation, customer
oriented changes, memory constraints) are needed to describe the
software development process, and selected equation combined
these variables to give the estimate of time & cost.
● These models are called multivariable models.
 Static, Multivariable Models:

● WALSTON and FELIX develop the models at IBM provide the

following equation gives a relationship between lines of source code
and effort:

● In the same manner duration of development is given by

Example:

Compare the Walston-Felix Model with the SEL model on a software

development expected to involve 8 person-years of effort.
1.Calculate the number of lines of source code that can be produced.
2.Calculate the duration of the development.
3.Calculate the productivity in LOC/PY
4.Calculate the average manning
Solution:
 COCOMO Model (Constructive Cost Estimation
Model)
● Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.
● COCOMO is one of the most generally used software estimation models in
the world.
● COCOMO predicts the efforts, development time and schedule of a software
product based on the size of the software.
● The necessary steps in this model are:
1. Get an initial estimate of the development effort from evaluation of
thousands of delivered lines of source code (KLOC).
2. Determine a set of 15 multiplying factors from various attributes of
the project.
3. Calculate the effort estimate by multiplying the initial estimate with
all the multiplying factors i.e., multiply the values in step1 and step2.
 COCOMO Model (Constructive Cost Estimation
Model)
● The initial estimate (also called nominal estimate) is determined by an
equation of the form used in the static single variable models, using
KLOC as the measure of the size.
● To determine the initial effort E, in person-months the equation.

E=a*(KLOC)b

The value of the constant a and b are depends on the project type.
● COCOMO includes
1. Basic COCOMO Model
2. Intermediate COCOMO Model
3. Complete or Detailed COCOMO Model
 COCOMO Model (Constructive Cost Estimation
Model) - 3 types
● In COCOMO, projects are categorized into three types:
1. Organic
2. Semi detached
3. Embedded

1. Organic: A development project can be treated of the organic

type, if the project deals with developing a well-Understood
application program, the size of the development team is
reasonably small, and the team Members are experienced in
developing similar methods of projects.
Examples of this type of projects are simple business systems,
simple inventory management systems, and data processing
systems.
COCOMO Model (Constructive Cost Estimation
Model) - 3 types
2. Semi detached: A development project can be treated with semi
detached type if the development consists of a Mixture of experienced
and inexperienced staff. Team members may have finite experience in
related systems but may be unfamiliar with some aspects of the order
being developed.
Example of Semi detached system includes developing a new operating
system (OS), a Database Management System (DBMS), and complex inventory
management system.
3. Embedded: A development project is treated to be of an embedded type,
if the software being developed is strongly coupled to complex hardware,
or if the stringent regulations on the operational method exist.
Example: ATM, Air Traffic control.
COCOMO Model (Constructive Cost Estimation
Model) - 3 types
Project Size Nature of the Innovation Deadline of the
Project Project

Organic 2-50 KLOC Small sized, Less Not tight

Experienced innovation Schedule
developers.

Semidetached 50-300 KLOC Medium Sized Medium Medium

Projects and Innovation Schedule
Medium Sized
Team

Embedded Over 300 KLOC Large Projects Significant Tight Schedule

and Real time Innovation
Systems
3 COCOMO MODELS

● According to Boehm, software cost estimation should be done through

three stages:

1.Basic Model

2.Intermediate Model

3.Detailed Model
Basic COCOMO Model:
● The basic COCOMO model provide an accurate size of the project parameters.
● The following expressions give the basic COCOMO estimation model:
E=ab(KLOC)bbPM
D=cb(E)db Months
P=E/D
Where,
E is the Effort Applied expressed in person months (PM).
D is the development Time expressed in months (M).
KLOC is the estimated size of the software product indicate in Kilo Lines of Code.
ab, bb ,cb,db are constants for each group of software products.
Basic COCOMO Model:

Software Project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
Basic COCOMO Model: Effort Estimation

● Estimation of development effort For the three classes of software

products, the formulas for estimating the effort based on the code
size are shown below:
1.05
1. Organic: E = 2.4(KLOC) PM
1.12
2. Semi-detached: E = 3.0(KLOC) PM
1.20
3. Embedded: E = 3.6(KLOC) PM
● The effort is somewhat superliner in the
size of the software product.
● Thus, the effort required to develop a product
increases very rapidly with project size.
Basic COCOMO Model: Development Time
Estimation

● For the three classes of software products, the formulas

for estimating the development time based on the effort
are given below:
0.38
1. Organic: D= 2.5(E) Months
0.35
2. Semi-detached: D= 2.5(E) Months
0.32
3. Embedded: D= 2.5(E) Months
Example Problems

1. Suppose a project was estimated to be 400

KLOC. Calculate the Effort and development
time for each of the three model. I.e., organic,
semi detached and embedded.
Example Problems

2. A project size of 200 KLOC is to be developed. Software

development team has average experience on similar type of
projects. The project schedule is not very tight. Calculate the
Effort, development time, average staff size, and productivity
of the project.
Intermediate COCOMO Model:
● The basic Cocomo model considers that the effort is only a function of
the number of lines of code and some constants calculated according to
the various software systems.
● The intermediate COCOMO model recognizes these facts and refines
the initial estimates obtained through the basic COCOMO model by
using a set of 15 cost drivers based on various attributes of software
engineering.
Intermediate COCOMO Model:
Classification of 15 Cost Drivers and their attributes:
1. Product attributes
1. Required software reliability extent
2. Size of the application database
3. The complexity of the product
2. Hardware attributes
1. Run-time performance constraints
2. Memory constraints
3. The volatility of the virtual machine environment
4. Required turnabout time
3. Personal attributes
1. Analyst capability
2. Software engineering capability
3. Applications experience
4. Virtual machine experience
5. Programming language experience
4. Project attributes
1. Use of software tools
2. Application of software engineering methods
3. Required development schedule
 Intermediate COCOMO Model:

Each Cost driver is rated for the given project Environment:

Very Low Low Normal High Very High Extra High

>1
<1

Where,

EAF- Efficient Adjustment Factor (can be calculated by multiplying all the values that have been obtained after categorizing each cost drive)
Intermediate COCOMO Model:

Software Project ai bi ci di

Organic 3.2 1.05 2.5 0.38

Semi Detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32
Detailed COCOMO Model:
● Detailed COCOMO incorporates all qualities of the standard version with an
assessment of the cost drivers.
● The detailed model uses various effort multipliers for each cost driver property.
● In detailed cocomo, the whole software is differentiated into multiple modules, and
then we apply COCOMO in various modules to estimate effort and then sum the effort.
● The Six phases of detailed COCOMO are:
1.Planning and requirements
2.System structure
3.Complete structure
4.Module code and test
5.Integration and test
6.Cost Constructive model
● The effort is determined as a function of program estimate, and a set of cost drivers
are given according to every phase of the software lifecycle.
SIZE METRICS

● To calculate the size of the program or the size of the process what we
are using in the project.
● Allows for estimation Effort, time scale and total number of faults that
a process has. (This is the difficult area of project Planning)
● The common methods used for Size Estimation are
- Line of Code (LOC)
- Functional Count (FC) or Function Point Analysis (FPA)
LOC (LINE OF CODE)

● LOC is any line of program text that is not comments or blank lines,
regardless of number of statements on the line. It includes all lines
containing program headers, declarations, executable and non
executable statements.
● Used for size estimation
● But LOC is language and technology dependent, therefore bad software
design might cause excessive LOC.
LOC- EXAMPLE
void selSort( int x[], int n) {
//Below function sorts an array in ascending
order
int i, j, min, temp;
for (i = 0; i < n - 1; i++) {
min = i;
for (j = i + 1; j < n; j++)
if (x[j] < x[min])
min = j;
temp = x[i];
x[i] = x[min];
x[min] = temp;
}
}

The function shown above contains 12 lines of code (LOC).

NOTE: comments and blank lines are ignored
Functional Point (FP) Analysis or Functional
Count

● Allan J. Albrecht initially developed function Point Analysis in 1979 at

IBM and it has been further modified by the International Function
Point Users Group (IFPUG).
● FPA is used to make estimate of the software project, including its
testing in terms of functionality or function size of the software
product.
● However, functional point analysis may be used for the test estimation
of the product. The functional size of the product is measured in terms
of the function point, which is a standard of measurement to measure
the software application.
Objectives of FPA

● The basic and primary purpose of the functional point analysis is to

measure and provide the software application functional size to the
client, customer, and the stakeholder on their request.
● Further, it is used to measure the software project development along
with its maintenance, consistently throughout the project irrespective
of the tools and the technologies.
Special Features of FPA or FC

● Independent to the language.

● Estimate development Effort in the early phases
● Directly linked with the requirements.
● FPA used on users external view of the system.
Principle of FPA

● FPs of an application is found out by counting the number and types of

functions used in the applications.
● Various functions used in an application can be put under five types
Types of FP Attributes
Measurements Parameters Examples

● Number of External Inputs(El) Input screen and tables (Transactional

Functional type)

● Number of External Output (EO) Output screens and reports

(Transactional Functional type)

● Number of external enquiries (EQ) Prompts and interrupts. (Transactional

Functional type)

● Number of internal files (ILF) Databases and directories (Data

Functional type)

● Number of external interfaces (EIF) Shared databases and shared routines.

(Data Functional type)
FP At a glance
 FPA

● FP characterizes the complexity of the software system and hence can

be used to depict the project time and the manpower requirement.
● The effort required to develop the project depends on what the
software does.
● FP is programming language independent.
● FP method is used for data processing systems, business systems like
information systems.
● The five parameters mentioned above are also known as information
domain characteristics.
● All the parameters mentioned above are assigned some weights that
have been experimentally determined and are shown in Table
FPA

1. To calculate the Unadjusted Functional Points (UFP)

2. To calculate the Adjusted Functional Points (AFP)

AFP= UFP x CAF

Where,

CAF- Complexity Adjustment Factor

Measurement Parameter Weighting Factors
Low Average High
● Number of External Inputs(El) 3 4 6
● Number of External Output (EO) 4 5 7
● Number of external enquiries (EQ) 3 4 6
● Number of internal files (ILF) 7 10 15
● Number of external interfaces (EIF) 5 7 10
Example Problem

EI = 10 (Low Complexity), EO = 13 (High Complexity)

EQ = 4 (Avg. Complexity), EQ = 2 (High Complexity)
ILF = 2 (Avg. Complexity), EIF = 9 (Low Complexity)
 SOLUTION:
EI = 10 x 3 = 30 EQ = 2 x 6 = 12
EO = 13 x 7 = 91 ILF = 2 x 10 = 20
EQ = 4 x 4 = 16 EIF = 9 x 5 = 45

Therefore the Total UFP = 30 + 91 + 16 + 12 + 20 + 45

= 214
 Example Problem
CAF= 0.65 + 0.01 * ΣFi

Where,
ΣFi = Total Complexity Adjustment Value
Fi = Degree of influence and are based on responses to the standard question
and varies on the scale of 0 to 5

0 1 2 3 4 5
No influence incidental moderate Average Significant Essential
The standard function or no. of factors to be considered (Fi)
1. Does the system required reliable backup recovery?
AVERAGE F1 = 3
2. Is Data Communication required?
MODERATE F2 = 2
3. Is distributing processing is there or not?
MODERATE F3 = 2
4. Is performance critical in the system?
ESSENTIAL F4 = 5
5. Is online Data Entry available?
AVERAGE F5 = 3
ΣFi= 3 + 2 + 2 + 5 + 3 = 15
CAF= 0.65 + (0.01 X ΣFi)
= 0.65 + (0.01 X 15)
= 0.8
TOTAL AFP = UFP * CAF
= 214 * 0.8
= 171
 Difference between LOC and Function Point :
Function Point (FP) Line of Code (LOC)

Function Point metric is specification-based. LOC metric is based on analogy.

Function Point metric is language

LOC metric is dependent on language.
independent.

Function Point metric is user-oriented. LOC metric is design-oriented.

Function Point metric is extendible to Line of

It is changeable to FP (i.e. backfiring)
Code.

Function Point is used for data processing LOC is used for calculating the size of the
systems computer program

Function Point can be used to portray the LOC is used for calculating and comparing
project time the productivity of programmers.
EXAMPLE PROBLEM 2

Perform Function Point Analysis (FPA) for an online word processor

with the following data. The components of the system are identified
with User Input -27, User Output -38, User Inquiry -21, Internal Logical
Files- 32, and External Interface files -19. The associated weights are
considered ‘simple’ for user inputs and outputs, ‘average’ for inquiries,
and ‘complex’ for internal and external files.
The total Degree of Influence (DI) / Cost Factor (CI) is 55.
Estimate the function points for the given system.
EXAMPLE PROBLEM 3

Assume that your company informed you to understand the concept of

logistics and its significance in business operations. As a business analyst,
you need to perform Function Point Analysis (FPA) for a logistics
application with the following data.
The components of the system are identified with User Input - 19, User
Output - 25, User Inquiry - 25, Internal Logical Files - 24, and External
Interface files - 19. The associated weights are considered ‘average’ for user
inputs and outputs, ‘simple’ for inquiries, and complex for internal and
external files. The total degree of influence (DI) / Cost Factors (CI) is 60.
Estimate the FPA for the given application based system and explain the
cost factors that can be applied for the same.
EXAMPLE PROBLEM 4

Assume that the size of an organic type software

product has been estimated to be 32000 lines of
source codes. Assume that the average salary of
software engineers be 15000/- p.m. Determine the
effort required to develop the software product and
the nominal development.
EXAMPLE PROBLEM 5
 FP USING TOTAL COUNT (TC) FACTOR

Step 1: To calculate Total Count (TC) Factor i.e.

addition of all individual multiplication of
respective weight factors and amount of parameter.

Step 2: Calculate Function Point (FP) by using given

formula.
 COCOMO Model II (Constructive Cost Estimation
Model)

COCOMO II is actually a hierarchy of estimation models that

address the following areas: ( Revised version of the original
COCOMO)
● Developed at University of Southern California under the
leadership of Dr. Barry Boehm
● Categories of application / project identified by COCOMO II
End User Programming
Infrastructure Sector
Intermediate Sectors
COCOMO Model II (Constructive Cost Estimation
Model)
LEVELS OF COCOMO II
● Early Prototyping level / Application composition model - Used during the
early stages of software engineering, when prototyping of user interfaces,
consideration of software and system interaction, assessment of performance,
and evaluation of technology maturity are paramount.
Use for Application composition projects
Estimates based on object points and a simple formula is used for effort
estimation

● Early design stage model - Used once requirements have been stabilized and
basic software architecture has been established.
Use for Application generators, infrastructure & system integration projects
Estimates based on function points that are then translated to LOC

● Post-architecture stage model - Used during the construction of the software.

Estimates based on LOC
COCOMO Model II (Constructive Cost Estimation
Model)

● Application Composition Estimation Model allows one to

estimate the cost, and effort at stage 1 of the COCOMO II
Model.
● In this model, size is first estimated using Object Points.
Object Points are easy to identify and count.
● Object Points define screen, reports, and third-generation
(3GL) modules as objects.
● Object Point estimation is a new size estimation technique
but it is well suited in Application Composition Sector.
Estimation of Efforts

The following steps are

taken to estimate the
effort to develop a
project:
 COCOMO Model II (Constructive Cost Estimation
Model)

1. Access Object Counts

● Estimate the number of screens, reports and 3GL components that will
comprise this application.
● Like function points, the object point is an indirect software measure that is
computed using counts of the number of
(1) screens (at the user interface)
(2) reports
(3) components likely to be required to build the application
 COCOMO Model II (Constructive Cost Estimation
Model)

2. Classify Complexity Levels of Each Object

● We have to classify each object instance (e.g., a
screen or report) into simple, medium and difficult
complexity level depending on values of its
characteristics. Complexity levels are assigned
according to the given table.
COCOMO Model II (Constructive Cost Estimation
Model)
COCOMO Model II (Constructive Cost Estimation
Model)
 COCOMO Model II (Constructive Cost Estimation
Model)

3. Assign Complexity Weights to Each Object

The weights are used for three object types i.e, screens,
reports and 3GL components. Complexity weight are
assigned according to object’s complexity level using
following table.
COCOMO Model II (Constructive Cost Estimation
Model)
 COCOMO Model II (Constructive Cost Estimation
Model)

4. Determine Object Points

Add all the weighted object instances to get one number
and this is known as object point count.
Object Point = Sigma (number of object instances) *
(Complexity weight of each object instance)
 COCOMO Model II (Constructive Cost Estimation
Model)
5. Compute New Object Points (NOP)

NOP = (object points) x [ (100 - %reuse) / 100]

where NOP is defined as new object points.
 COCOMO Model II (Constructive Cost Estimation
Model)

6. Calculate Productivity rate (PROD)

Productivity rate is calculated on the basis of

information given about developer’s experience and
capability. For calculating it, we use following table.
PROD= NOP/ PERSON-MONTH
COCOMO Model II (Constructive Cost Estimation
Model)
 COCOMO Model II (Constructive Cost Estimation
Model)

7. Compute the estimated Effort

Effort to develop a project can be calculated as:

ESTIMATE EFFORT= NOP/PROD
EXAMPLE PROBLEM 1

Consider a database application project with the following constraints

(i) The application has four screens with four views each and seven data tables for
three servers and four clients.
(ii) Application may generate two reports of six section each from seven data tables
for two servers and three clients.
(iii) 10% reuse of object points.
(iv) Developer’s experience and capability in similar environment is low.
Calculate the object point count, New object point and effort to develop such project.
SOLUTION

Step 1: Number of screens = 4 and Number of

reports = 2
Step 2: For screens,
Number of views = 4
Number of data tables = 7
Number of servers = 3
Number of clients = 4
By using above given information and table
(For Screens),

Complexity level for each screen =

medium
SOLUTION

For reports,
Number of sections = 6
Number of data tables = 7
Number of servers = 2
Number of clients = 3
By using above given
information and table (For
Reports)
Complexity level for each
report = difficult.
SOLUTION

Step 3: By using complexity weight table we

can assign complexity weight to each object
instance depending upon their complexity
level.
Complexity weight for each screen = 2

Complexity weight for each report = 8

SOLUTION

Step 4:
Object point count = sigma (Number of object instances) *
(its Complexity weight) = 4 * 2 + 2 * 8 = 24

Step 5:
%reuse of object points = 10% (given)
NOP = [object points * (100 – %reuse)] / 100
= [24 * (100 -10)]/100 = 21.6
SOLUTION

Step 6:
Developer’s experience and capability is
low (given) Using information given about
developer and productivity rate table
Productivity rate (PROD) of given
project = 7

Step 7:
Effort = NOP / PROD
= 21.6/7
= 3.086 person-month
EXAMPLE PROBLEM 2

Use the COCOMO model to estimate the effort required to

build a software for a simple ATM that produces 12 screens,
10 reports and will require approximately 80% of new
software components.
Assume average complexity and average developer/
environment maturity.
Use the application composition model with object points.
 COCOMO Model II (Constructive Cost Estimation
Model)

EARLY DESIGN MODEL : Estimates can be made after the requirements have been agreed.
Based on a standard formula for algorithmic models
PM = A x (Size^b) x M where
M = PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED;
A = 2.94 in initial calibration
Size in KLOC
B varies from 1.1 t o1.24 depending on novelty of the project development flexibility, risk
management
 COCOMO Model II (Constructive Cost Estimation
Model)

REUSE MODEL: Takes into account black box code that is reused without change and code that
has to be adapted to integrate it with new code. There is 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.

When code has to be understood and integrated:

ESLOC = ASLOC * (1 AT/100) *AAM.

ASLOC is the number of lines of generated code

AT is the percentage of code automatically generated.
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.
 COCOMO Model II (Constructive Cost Estimation
Model)

POST ARCHITECTURE MODEL : Used once the system architecture has been designed and more
information about the system is available. The code size is estimated as :

•Number of lines of new code to be developed.

•Estimates of equivalent number of lines of new code computed using the reuse model.

•An estimate of the 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.
 COCOMO Model II (Constructive Cost Estimation
Model)

Source Lines of Code (SLOC/LOC)

The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code (SLOC).
SLOC is defined such that:
● Only Source lines that are DELIVERED as part of the product are included test drivers and other support
software is excluded
● SOURCE lines are created by the project staff code created by applications generators is excluded.
● One SLOC is one logical line of code.
● Declarations are counted as SLOC.
● Comments are not counted as SLOC
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.