Modeule 3 : Software Estimation Metrics

Software Measurement :

There is line : You can't control what you can't measure." — Tom DeMarco

 Software Measurement is the process of assigning numbers or symbols to attributes

of software entities (like code, designs, test cases, or processes) according to clearly
defined rules, to better understand, analyse, and control the software development and
maintenance process.
 Measurement is the process of assigning a numerical value to an attribute of a software product,
process, or project. Eg Measuring the size of software in terms of Lines of Code (LOC)
 Here we measure characteristics of software which are quantifiable or countable.

 In traditional engineering (civil, mechanical), measurement uses direct physical

quantities like length, mass, temperature. Measurement is the act of collecting data
using rules.
 In software engineering, physical measures are rare — we cannot directly ―weigh‖ or
―measure‖ a program like a bridge or a circuit.

 So, software measurement often uses indirect measures to describe things like:

 Size of code (Lines of Code)

 Complexity of design (Cyclomatic complexity)
 Functionality delivered (Function Points)
 Quality (Defect density)

Measurement Process Steps:

[Link] suitable measures and metrics for the software representation you are working on
(requirements, design, code, test).
[Link] the relevant data (e.g., lines of code, number of modules, number of defects).
[Link] the metrics using formulas.
[Link] the metrics — compare them with standards or past data.
[Link] results — understand what the numbers reveal about the software’s quality, cost,
risk, or schedule.
[Link] action — modify the requirements, design, source code, tests, or even your process if
needed.
The output of measurement is product metrics — quantitative data derived from your
models, code, or test cases.

Always define why you’re measuring something before you start. Collect only useful metrics
— not every possible number.
Software Metrics :

A software metric is a quantitative measure of a software product derived from software

measurement, it is a numerical value that represents an attribute of a software product,
process, or project.

A metric is a quantitative measure derived from measurements. It helps in evaluating a specific attribute of
software.

Eg. Defect density = Number of defects / KLOC

(Here, LOC is measured, and the metric is defect density)

IEEE Standard Glossary of Software Engineering Terminology defines metric as ―a quantitative measure of
the degree to which a system, component, or process possesses a given attribute.‖

Metrics are the computed values that help analyse that data and make better decisions.

Why Important?

 Better planning: Estimate time, cost, people.

 Better tracking: Compare planned vs actual.
 Better quality: Find defects early.
 Better management: See trends & improve future projects.

Eg. Software Measurement → Raw data

 E.g., Lines of Code = 5000

Software Metric → Computed measure

 E.g., Defect Density = Number of Defects / KLOC

If there are 25 defects in 5 KLOC, then Defect Density = 5 defects/KLOC.
Categories of Software Metrics:

Types of Software Metrics :

1. Process Metrics

 Process metrics measure the efficiency and effectiveness of the software development process.
 They help you analyze how well the development activities are being carried out.
 Used to monitor and improve the software development process.
 Used to detect inefficiencies, bottlenecks, or frequent reworks.

Metric Description CMS Example

Effort Total developer hours spent 120 hours to develop "Quotation Module"
Defect Rate Number of defects per KLOC 3 bugs per 1000 LOC in enquiry process
Rework Effort Time spent on fixing mistakes 10 hours spent fixing bugs in ―project status‖ page
LOC or FP developed per person-
Productivity 800C per person/month
month

2. Product Metrics
Product metrics are used to measure features or characteristics of the final software product, such as its
size, performance, reliability, and maintainability.

To assess the quality of the software system.

To support testing, quality assurance, and customer satisfaction.

Metric Description CMS Example

Size LOC or FP of the software CMS has 12,000 LOC or 350 FP
Complexity Logical complexity of the code High complexity in auto-quotation generator
Usability Ease of use for end-users Is the contractor able to fill enquiry form easily?
Reliability Number of failures per time period Login module crashes 2 times/week
Performance Response time, throughput Report page loads in 2 seconds

[Link] Metrics
Project metrics deal with the management and progress of the overall project – including resources,
timelines, risks, and costs.

To manage and track the progress of the project. To help in planning, scheduling, and risk management.

Metric Description CMS Example

Cost Total money spent ₹5,00,000 for CMS development
Schedule Variance Delay or ahead of schedule CMS delivery delayed by 10 days
Team Size Number of people involved 4 developers, 1 tester
 Metric Description CMS Example
Risk Exposure Level of risk in the project High risk: tight deadline and new tech
Customer Satisfaction Feedback or rating Builder gives CMS 4.5/5 rating after use

Example: Website redesign project planned for 4 months → finished in 5 → shows schedule
slippage.

 You need to report progress to a client.

 Product metric: 20 screens, 15,000 LOC

 Process metric: 85% bugs found during code reviews
 Project metric: On track — 60% done, 55% time used

Eg.. You’re developing an Online Event Registration Portal for your college.

 Measurement: You count:

 Total LOC: 4,500

 Total defects found in testing: 18

 Metric: You calculate:

 Defect Density = 18 / 4.5 KLOC = 4 defects per KLOC

Type of
Focus Area Key Question Answered Example
Metric
Process Software development
How efficiently are we building it? Defect rate, productivity
Metric process
Product Size, usability,
Final software system How good is the software product?
Metric performance
Project Are we on time, within budget, and Cost, team size,
Project management
Metric organized? schedule

Indicator

 An indicator is a visual or descriptive representation that combines multiple metrics to support

decision-making.
 Example: A project health indicator (Green = on track, Yellow = risk, Red = behind schedule) based
on metrics like effort, schedule, and defects.

 Definition: Metric or set of metrics that gives actionable insight.

 Example: Rising defect density indicates declining quality.
 Indicators guide managers to adjust the project or process.
Real-World Example

 Scenario: Online Food Ordering App

 Measures: 50,000 LOC, 20 defects
 Metric: 0.4 defects/KLOC
 Indicator: Low defect density → Good quality
 Diagram: Flowchart: Measures → Metrics → Indicators → Decision
 A lower defect density indicates better code quality.
 A higher defect density may indicate more testing or quality issues

Term Meaning Example

Measurement Raw value collected 10,000 LOC
Metric Processed/derived value Defect density = 1.2 bugs/KLOC
Indicator Interpreted or visual summary Project status: "At risk"

Software Type Acceptable Defect Density

High-quality product 0.1 – 0.5 bugs/KLOC
Standard product 0.5 – 1.0 bugs/KLOC
Risky / Poor quality > 1.0 bugs/KLOC

Importance of measurement and metrics in Software Engineering

1. Helps in Planning
 Accurate effort, cost, and time estimation needs measurements and metrics.
2. Quality Assurance
 Product metrics like defect density help track and improve quality.
3. Monitoring Progress
 Metrics like schedule variance or effort deviation help assess project health.
4. Decision-Making
 Indicators help project managers take action (e.g., add resources, delay delivery).
5. Process Improvement
 Analyzing metrics over time helps improve software development processes (e.g.,
reduce rework or defects).
6. Communication
 Metrics and indicators help communicate status to stakeholders clearly.

Based on past similar projects or expert judgment, we estimate that:

 Login Module → 800 LOC

 Dashboard Module → 2000 LOC
 Report Generator → 4000 LOC
Software Project Estimation :
 Def : Project estimation in software engineering means predicting the effort, cost, time,
and resources needed to deliver a software product.

a) Why estimate?

 To predict cost, effort, time, and resources needed.

 To help plan and manage software projects.
 To set realistic deadlines.
 To decide project feasibility.
 To help clients make budget decisions.

b) When to estimate?

 Early stage: During requirement analysis (rough estimate for feasibility).

 Before development: For budgeting, staffing, scheduling.
 During project: To re-estimate if requirements change.
 End of project: For comparison with initial estimates (to improve future estimation).

c) Challenges in estimation:

 Unclear or changing requirements.

 New/untested technology.
 Lack of historical data.
 Human bias (over-optimism or pessimism).
 Complex dependencies between tasks.

 Without realistic estimates, projects can:

 Run over budget

 Miss deadlines
 Fail to deliver promised functionality

 The size and complexity of requirements give you the first clues about how big the
project will be.
 Eg. If the requirement says, ―The system must handle online payments, generate
invoices, support mobile login, and send SMS notifications,‖ → each of these features
adds to the project size.

Project Estimation Techniqes :

1. Post / Delay Estimation

Meaning:

 Done late in the project life cycle, usually after design or partial coding, when more details are
known
  At this point, the design is stable, requirements are clarified, and early uncertainties are reduced.

When used:

 Projects with unclear requirements at the start.

 When accurate estimates are needed after architecture/design is ready.

Advantages:

 High accuracy (uncertainties are minimized).

 Estimates are based on actual progress, prototypes, or partial deliverables.

Disadvantages:

 Not useful for early budgeting.

 May be too late to adjust major project constraints (schedule, staffing).

Example:
After design is complete, you calculate LOC = 12,000.
Productivity = 500 LOC / PM
Effort = 12,000 ÷ 500 = 24 PM.

2. Base Estimation

Meaning:

 use historical (past-project) data or a project baseline as the reference. You map the current project to
a similar past project and scale the historical numbers for differences (size, complexity).

When used:

 Early phases when you have reliable historical projects to compare with (same domain, technology).
 Works best when new project is similar to old ones.

Pros / Cons: quick and often more realistic than pure guesswork if you have good historical data; poor if
analog is not actually similar.

Example:
Last ye car’s e-commerce site took 6 months (5 developers).
New project = 20% more features → Estimated duration = 6 × 1.2 = 7.2 months (same team size).

3. Decomposition Estimation

Meaning:

 Split the system into smaller work items (modules, functions, tasks), estimate each item and roll up to
the project total. This is the most common practical technique for detailed planning
 Two approaches:

 Top-down: Estimate overall, then split into parts.

  Bottom-up: Estimate each part, then total it.

When used:

 Complex projects where direct estimation is hard.

 When modules/tasks are clearly defined.

Example:
M1 = 4,600 LOC
M2 = 6,900 LOC
M3 = 8,600 LOC
Total = 20,100 LOC
Productivity = 500 LOC / PM
Effort = 20,100 ÷ 500 = 40.2 PM

What you did is Direct Estimation :

Direct Estimation:

 You directly estimate the LOC (Lines of Code) for modules.

 Then you directly relate LOC to effort and time.
 You might use PERT (optimistic, most likely, pessimistic) to handle uncertainty.
 This depends heavily on the developer’s or team’s experience.
 Example: “Module A is about 5000 LOC, so it will take 5 PM…‖

Pros:

 Quick if you have good experience with similar work.

 Easy for small to medium projects.

Cons:

 Highly subjective.
 Not reliable if you don’t have past data.
 Not good for very large or complex systems.

Indirect Estimation

 You don’t estimate LOC directly.

 Instead, you use abstract measures of size — like Function Points (FP), Use Case Points, Object
Points, or Story Points (Agile).
 Then, you convert these abstract units to effort, time, or LOC using historical productivity data.
 This is more systematic, repeatable, and works better for projects where:

 LOC is hard to estimate upfront.

 Requirements are better described by what the system does rather than how much code there
is.
4. Empirical Estimation

 Empirical estimation uses mathematical/statistical models based on data from past projects to
predict the effort, cost, and schedule of a new project.
 It relies on real-world project experience and quantitative relationships between software size and
effort.

Key Features:

1. Based on analysis of historical project data.

2. Uses formulae derived from regression/statistical analysis.
3. Can be applied early in the software life cycle if approximate size is known.
4. Gives more objective and repeatable results compared to purely expert judgement.

Function Point Analysis (FPA)

Introduction

 Proposed by: Allan Albrecht at IBM in 1979.

 Purpose: Measure software size based on the functionality delivered to the user, independent of
programming language.
 Useful for early estimation when LOC is unknown.
 Unit of measurement: Function Point (FP). Size is measured in Function Points (FP), not LOC.

Why Use FPA?

 LOC depends on programming language → FP measures what the software does, not how it’s
coded.
 Works well for business applications, MIS systems, and large-scale software.

Step 1: Identify Components

Count the following:

1. External Inputs (EI) – Data entering the system (forms, screens).user registration form,product
search form,add to cart form
2. External Outputs (EO) – Data leaving the system (reports, messages),confirmation mail,order
summary page,invoice generation.
3. External Inquiries (EQ) – User requests that require a response without updating data,product
availability check,order status check.
4. Internal Logical Files (ILF) – Logical groups of data maintained within the [Link]
data,product backlog,order data
5. External Interface Files (EIF) – Logical groups of data used for reference but maintained by other
[Link] gateway interface,third party shipping service gateway.

Step [Link] Weights

Each component is classified as Low, Average, or High complexity with a standard weight table.
  In Function Point Analysis, each of the five information domain components has
predefined weighfactors based on its complexity:

Component Simple Average Complex

External Input 3 4 6
External Output 4 5 7
External Inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10

Step 3 : calculate UFP

How to calculate UFP :

External Input : 3*3=9

External Output : 3*4=12
External Inquiries : 3*2=6
Internal Logical Files : 3*7=21
External Interface Files : 5*2 =10
Total UFP : 9+12+06+21+10 =50

Step 4: Value Adjustment Factor (VAF)

A factor that adjust the UFP based on general system characteristics which include
consideration like performance,usability and complexity.

Rate 14 General System Characteristics (e.g., performance, reusability) from 0 to 5.

FP=UFP*(0.65+0.01*sum of GSC’s)
GSC- "We’re the system designers. The client has certain needs — each GSC tells us how complex the
system will be. We give ratings to decide how much adjustment is needed for effort estimation."

Sum all ratings → Total Degree of Influence (TDI)

GSC(General system characteristics) :

1. Data Communications
2. Distributed Data Processing
3. Performance
 4. Heavily Used Configuration
5. Transaction Rate
6. Online Data Entry
7. End-User Efficiency
8. Online Update
9. Complex Processing
10. Reusability
11. Installation Ease
12. Operational Ease
13. Multiple Sites
14. Facilitate Change

Eg. Online shopping system

GSC Question to Ask Rating

1 Data Communications Need to connect to payment gateways, courier API?
2 Distributed Data Processing Will different systems (inventory, payment) process data?
3 Performance Must be fast during peak hours?
4 Heavily Used Configuration Will it run on specific servers/OS?
5 Transaction Rate Many transactions per minute?
6 On-Line Data Entry Users enter orders, payments online?
7 End-User Efficiency Easy navigation, search filters?
8 On-Line Update Database updates instantly after purchase?
9 Complex Processing Price calculation, discounts, shipping rules?
10 Reusability Components reused for mobile app?
11 Installation Ease One-click deployment possible?
12 Operational Ease Admin dashboard for easy control?
13 Multiple Sites Multiple warehouses / servers?
14 Facilitate Change Easy to update product catalog?

You rate the 14 General System Characteristics (GSCs), each from 0 to 5, and
CALCULATE SUM OF GSC’S.

Degree of Influence (DI) — the sum of the 14 GSC ratings.

Total GSC or DI= 30

Then,

VAF=0.65+(0.01×30)
=0.65+0.30=0.95

FP=UFP*VAF OR FP=UFP*(0.65+0.01*sum of GSC’s)

FP=50×0.95=47.5

When Conversion Happens:

 After you calculate total FP,

 Then use LOC to estimate effort (using productivity or COCOMO)

FP → LOC Conversion

 Each language has a LOC per FP factor (industry average).

Example:
o C = 128 LOC / FP
o Java = 53 LOC / FP
o Python = 21 LOC / FP

Formula :

1. Example:

 AFP = 300
 Language = Java (53 LOC/FP)

FP → Productivity (if Effort is given)

 Productivity can be calculated directly from FP and Effort:

6. Advantages

 Independent of programming language.

 Useful early in the life cycle.
 Standardized and widely used.

Limitations:

 Needs trained estimators for accurate counts.

  May not suit algorithm-heavy scientific software.

COCOMO Model (Constructive Cost Model)

 Proposed by Barry W. Boehm in 1981.
 Purpose: Estimate effort, cost, and time required to develop a software project.
 Based on historical project data and regression analysis.
 Predicts Person-Months (PM) based on size in KLOC (thousand lines of code).

When used:

 When size can be estimated early.

 When proven formulas exist.

In the COCOMO (Constructive Cost Model), all software projects are not the same —
they differ greatly in their complexity, constraints, and environment. To make effort
estimation realistic, Barry Boehm divided software projects into three broad categories:
Organic, Semi-Detached, and Embedded.
The type depends mainly on project size, team experience, and project [Link] type has unique
features that affect the effort, time, and cost needed to develop the software.

1. Organic mode :
 The Organic mode represents projects that are relatively simple and routine. These projects are
characterized by small, experienced teams working in a familiar domain, solving problems that have
clear solutions.
 Requirements are well understood from the start, and there are very few surprises during
development. For instance, a simple payroll system or inventory management software for a small
business falls under the Organic type.
 The people involved usually have good experience with the tools and techniques needed, and they
have done similar projects before. Since the team is small and communication is easy, coordination
overhead is minimal.
 The environment is stable and there are few constraints, these projects require relatively less effort for
planning and oversight, which is why the effort exponent for Organic mode is low (1.05). This
means effort increases almost linearly with project size
 Size: Small to medium projects (up to ~50 KLOC)
 Example: A payroll system for a small company, a student management system for a college.

Semi-Detached mode :
 The Semi-Detached mode applies to projects that lie between simple and very complex.
 In these projects, some parts of the system may be familiar to the team, while other parts are new or
moderately challenging.
 The team is usually larger than in Organic mode and is often mixed: some developers have high
expertise, while others may be less experienced or new to the domain. This makes coordination a bit
 more complicated, and the project manager must pay attention to communication, integration, and
guidance.
 Projects in this category are larger than typical Organic projects and may include parts that require
creative solutions. An example of a Semi-Detached project could be developing a compiler, a
database management system, or a moderately complex embedded system that interfaces with
hardware but does not have extreme real-time or safety-critical requirements.
 Since these projects have moderate complexity and some uncertainty, the COCOMO effort exponent
is slightly higher (1.12). This means that as the size of the project increases, the effort grows more
than linearly because managing complexity, integrating components, and ensuring quality take extra
work.
 Size: Medium to large projects (~50–300 KLOC)
 Example: An inventory control system for a big retail chain, an e-commerce platform with payment
integration.

Embeded Mode :
 The Embedded mode is the most complex and demanding type in the COCOMO classification.
 Projects in this category have tight constraints, strict performance requirements, and must interact
closely with hardware or other systems.
 Often, these projects are developed in environments where failures can have serious consequences —
such as military software, aircraft control systems, medical device controllers, or any real-time
software that must function correctly under strict safety or timing conditions.
 Unlike Organic projects, the requirements in Embedded projects can be very strict and may keep
changing due to evolving safety standards or hardware limitations.
 The development environment may be less flexible because the software must fit into very specific
hardware configurations with limited resources. Because of this, such projects need large teams of
highly experienced developers, domain experts, and rigorous testing, documentation, and validation at
every stage.
 The effort grows rapidly with project size because each increase in functionality often adds many
interdependencies and risks.
 In the COCOMO model, the Embedded mode therefore has the highest effort exponent (1.20),
reflecting this steep growth in effort for larger systems.
COCOMO model is still valuable today — it reminds us that not all software projects are equal,
and each type deserves its own planning approach.
 Size: Large projects (> 300 KLOC)
 Example: Air traffic control systems, spacecraft control software, real-time military applications.

Mode a1 a2 b1 b2
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
These were given by Barry Boehm from historical data.

Effort= a1 *(KLOC) exp a2 PM

Tdev= b1 * (Effort) exp b2 months

1. a1,a2,b1,b2 = constants depending on project type.

[Link] (Person-Months)
This is the total effort needed to develop the software — measured in person-months (PM).
Example: 100 PM means 1 person for 100 months

[Link]

KLOC is estimated time to develop the software,in months.

Means Kilo Lines of Code — i.e., 1 KLOC = 1,000 lines of code.

After estimating Effort (person-months) and Time (months), you can find productivity:

Eg.1

 Mode: Semi-Detached
 Lines of Code: 30,000 LOC
 So, KLOC = 30
 Calculate Effort,Time,

[Link] Effort :
a1=3.0, a2=1.12, b1=2.5, b2=0.35
Effort = a1*(KLOC) exp a2

[Link] Development time :

Time (months)= b1×(Effort) exp b2
= 2.5 *(118.8) exp 0.35

3. Calculate Average team size :

Average Team Size=Effort/Time

Staff size = 9 people

[Link] Productivity :

Productivity=KLOC/Time (months)
 Mode A1 A2 B1 B2 Characteristics
Organic 2.4 1.05 2.5 0.38 Small, simple projects with experienced teams (e.g., payroll system).
Semi-
3.0 1.12 2.5 0.35 Medium complexity, mixed team experience (e.g., compiler).
detached
Complex, real-time systems with strict constraints (e.g., flight control
Embedded 3.6 1.20 2.5 0.32
software).

Example (Basic COCOMO)

Eg.1

Given:

 Project Type = Organic

 Estimated Size = 32 KLOC
 Constants: a = 2.4, b = 1.05, c = 2.5, d = 0.38

Step 1: Effort

Step 2: Development Time

Step 3: People Required

Types of COCOMO

1. Basic COCOMO

 A quick and rough estimation model that uses only software size (measured in KLOC =
thousands of lines of code) and the project type (Organic, Semi-Detached, or Embedded).
 Early stage, when only the approximate size of the project is known
 Eg. If a project is estimated to have 30 KLOC and is Semi-Detached, you can directly
compute the effort in person-months.

2. Intermediate COCOMO –

 Adds Cost Drivers (e.g., product reliability, complexity, team experience).

 Extends the basic model by adding Cost Drivers that reflect real-world factors affecting
effort.
  Cost Drivers include:

 Product attributes: reliability, complexity

 Computer attributes: execution time constraints, storage constraints
 Personnel attributes: analyst capability, programmer experience
 Project attributes: use of tools, schedule constraint

 More realistic than Basic COCOMO, as it considers technical and human factors.

3. Detailed COCOMO –

 Further includes phase-wise breakdown of effort for analysis.

 Most refined version. Breaks down the software development process into phases (e.g.,
requirements, design, coding, testing) and applies the intermediate model to each phase
separately.
 Features:

 Includes all cost drivers from Intermediate COCOMO.

 Gives phase-wise distribution of effort and cost.
 Helps in scheduling, tracking, and risk analysis.

 Used for large, critical projects where detailed planning is required

Advantages

 Simple and quick for early estimates.

 Based on historical and real project data.
 Can be adapted (Intermediate & Detailed) for more accuracy.

Limitations:
 Requires accurate size estimation early.
 Constants are based on old data — may need calibration for modern tools/languages.
 Not ideal for projects with rapidly changing requirements.

COCOMO vs Function Points

Let’s compare these two:

Aspect COCOMO Function Points (FP)

What it
Effort, Cost & Schedule Software Size, then effort
estimates
Input LOC (estimated) Functionality delivered to user
Uses mathematical formulas based on project mode
How it works Counts inputs, outputs, files, interfaces, inquiries
(organic, semi-detached, embedded)
Example Uses LOC, project complexity, team experience, Counts EI, EO, EQ, ILF, EIF then adjusts for
Aspect COCOMO Function Points (FP)
factors hardware constraints technical complexity
Direct or
Direct (needs LOC estimate) Indirect (does not need LOC upfront)
Indirect?
Good when you can estimate LOC or have Good for business applications, when requirements
Typical usage
historical data are clear but code size is not known

So, COCOMO is still direct (because you must first estimate LOC), while FP is indirect because it starts
from functional scope and converts that into LOC and then effort.

 Indirect: More systematic, works better for large/business systems

 COCOMO: Popular parametric LOC-based model
 FP: Good for early-stage estimation when code size is unknown

Problems for practice :

Problem 1 — LOC Based Estimation

(For Direct LOC Method)

An IT company is developing a desktop application.

 Estimated size = 25,000 LOC

 Average programmer productivity = 500 LOC / Person-Month
 Average developer salary = ₹45,000 per month

Tasks:

1. Calculate Effort (in Person-Months)

2. Calculate Development Time (in months) if 5 developers are working.
3. Calculate Total Cost of development.

1. Effort (Person-Months)
Effort = LOC ÷ Productivity = 25,000 ÷ 500 = 50 PM
2. Development Time (with 5 developers)
Time = Effort ÷ Team Size = 50 ÷ 5 = 10 months
3. Total Cost
Cost = Salary per PM × Effort = ₹45,000 × 50 = ₹22,50,000
(Checks out the same as ₹45,000 × 5 devs × 10 months = ₹22,50,000)

Answer : Effort = 50 PM, Time = 10 months, Cost = ₹22,50,000.

Problem 2 — Base Estimation Method

(For analogy/experience-based estimation)

A previous project had the following details:

 LOC developed = 20,000

 Effort required = 40 Person-Months
The new project is expected to have 28,000 LOC. Assume same productivity as the previous project.

Tasks:

1. Estimate Effort for the new project.

2. If the team consists of 6 developers, find the development time.
3. If average salary per developer per month = ₹50,000, find total cost.

Ans :

1. Effort
Previous productivity = 20,000 LOC / 40 PM = 500 LOC/PM
New Effort = 28,000 ÷ 500 = 56 Person-Months
2. Development Time (6 developers)
Time = Effort ÷ Team Size = 56 ÷ 6 = 9.33 months ≈ 9 months 10 days
3. Total Cost
Cost = Salary × Person-Months = ₹50,000 × 56 = ₹28,00,000 (₹28 lakh)

Summary: Effort = 56 PM, Time = ~9.33 months, Cost = ₹28,00,000.

Problem 3 — Function Point & COCOMO

A web-based online shopping platform has the following Function Point details:

Function Type Count Weight (Average)

External Inputs (EI) 40 4
External Outputs (EO) 25 5
External Inquiries (EQ) 20 4
Internal Logical Files (ILF) 8 10
External Interface Files (EIF) 5 7

 Value Adjustment Factor (VAF) = 1.10

 Language: Java (Average 50 LOC per FP)
 Productivity = 600 LOC / Person-Month
 COCOMO mode: Semi-Detached with parameters:

a = 3.0, b = 1.12 (Effort Equation: Effort = a × (KLOC)^b)

Tasks:

1. Calculate Unadjusted Function Points (UFP).

2. Calculate Adjusted Function Points (AFP).
3. Convert AFP to LOC.
4. Calculate Effort (Person-Months) using productivity.
5. Calculate Effort using COCOMO Semi-Detached mode.
6. If each developer earns ₹55,000 per month, calculate total cost for both methods.
7. If team size = 8 developers, calculate development time in months for both methods.
ANS :

Here are the worked steps and answers:

1. UFP
= 40×4 + 25×5 + 20×4 + 8×10 + 5×7
= 160 + 125 + 80 + 80 + 35 = 480
2. AFP
= UFP × VAF = 480 × 1.10 = 528
3. LOC (Java ~50 LOC/FP)
= 528 × 50 = 26,400 LOC (i.e., 26.4 KLOC)
4. Effort via productivity (600 LOC/PM)
Effort = LOC ÷ Productivity = 26,400 ÷ 600 = 44 Person-Months
5. Effort via COCOMO (Semi-Detached)
Effort = a × (KLOC)^b = 3.0 × (26.4)^(1.12) ≈ 117.31 Person-Months
6. Total Cost @ ₹55,000 per PM

 Productivity method: 44 × 55,000 = ₹24,20,000

 COCOMO method: 117.31 × 55,000 ≈ ₹64,51,792

7. Development Time with team size = 8

 Productivity method: 44 ÷ 8 = 5.50 months

 COCOMO method: 117.31 ÷ 8 ≈ 14.66 months

Summary:

 UFP = 480, AFP = 528, LOC = 26,400

 Effort: 44 PM (productivity) vs 117.31 PM (COCOMO)
 Cost: ₹24.2 lakh vs ₹64.52 lakh
 Time (8 devs): 5.5 months vs 14.66 months.

 Project Scheduling and tracking

Project scheduling
Project Scheduling is the process of planning activities, allocating resources, setting timelines, and defining the
sequence of tasks to ensure that the project is completed on time, within budget, and with the required quality
standards.

Issues in Project Scheduling

1. Unclear Goals & Scope (Scope Creep)

 Project objectives are not well-defined.

 Frequent requirement changes cause delays and cost overruns.

2. Poor Planning & Scheduling

  Inaccurate time/cost estimates.
 Ignoring task dependencies leads to unrealistic schedules.

3. Resource Constraints

 Limited skilled manpower, tools, or budget.

 Overallocation of resources reduces efficiency.

4. Risk Management Failures

 Unexpected risks (technical failures, vendor issues, external factors) are not considered.
 Lack of contingency or backup plans for emergencies.

5. Ineffective Communication

 Misunderstanding between team, management, and stakeholders.

 Leads to confusion and duplication of work.

6. Poor Tracking & Monitoring

 Lack of proper progress-tracking methods (Gantt, PERT, CPM).

 Delays detected late, making corrective actions difficult.

7. Team Issues

 Lack of motivation, role conflicts, absenteeism.

 High employee turnover disrupts progress.

8. Quality Problems

 Focus only on deadlines, ignoring testing/quality checks.

 Results in rework and client dissatisfaction.

9. Budget Overruns

 Underestimated costs or uncontrolled expenses increase project cost.

10. Stakeholder Pressure

 Unrealistic expectations from clients or management can lead to stress and project failure.

What is Project Scheduling?

1. Project Scheduling is the responsibility of the project manager.

2. A project schedule communicates which tasks are needed and when they must be performed.
3. The project manager breaks down the total project work into different activities (WBS – Work
Breakdown Structure).
4. The project manager estimates the time and resources required to complete activities and organizes
them into a logical sequence.
 5. Effective project scheduling leads to project success, reduced cost, and increased customer
satisfaction.

A work breakdown structure (WBS) is a way to organize work into smaller, more manageable
pieces. According to the Project Management Body of Knowledge (PMBOK), WBS is a
―deliverable-oriented hierarchical decomposition of the work to be executed by the team.‖

Work breakdown structure diagrams are a very popular project management tool, typically used
in project management techniques such as the critical path method (CPM) or the Program
Evaluation Review Technique (PERT).

Project Scheduling Process

1. Identify all the functions/modules required to complete the project.

2. Break down large functions into small activities (WBS structure).
3. Determine the dependencies among various activities.
4. Allocate resources to activities.
5. Assign people to conduct different activities.
6. Plan the start and finish dates for activities.
7. Create an Activity Network and represent the schedule with a Bar Chart or Gantt Chart.

Basic Principles of Project Scheduling

1. Compartmentalization – Divide the project into manageable activities and tasks.

2. Interdependency – Some tasks occur in sequence, others can occur in parallel.
3. Time Allocation – Each task must have a start date and a completion date.
4. Effort Validation – Ensure the right number of people/resources are allocated to each task.
5. Defined Responsibilities – Each task is assigned to a specific team member.
6. Defined Outcomes – Each task should result in a clear work product.
7. Defined Milestones – A milestone is achieved when one or more work products are completed and
reviewed for quality.

Important term
[Link] :

 A network is a graphical representation of the project.

 It shows activities (tasks) and their dependencies (sequence/order).
 Helps in finding project duration, critical path, floats, etc.

2. Event (Node)

 An event = a point in time marking the start or finish of an activity.

 Represented by a circle (or node).
 Events themselves don’t consume time/resources.
 Example: ―Start of Project‖ or ―Completion of Task A‖.
3. Activity (Arrow)

 An activity = a specific task/job that consumes time and resources.

 Represented by an arrow from one event to another.
 Example: ―Coding a module‖, ―Testing‖, ―Design‖.

(i) ----A----> (j) where

 (i) = Start event
 (j) = End event
 A = Activity label

4. Types of Activities

1. Real Activity → actual work (takes time/resources).

2. Dummy Activity → shown as a dotted arrow, doesn’t consume time/resources.

 Used only to show dependency/sequence.

3. Critical Activity → lies on the critical path (zero float).

4. Non-Critical Activity → has float, can be delayed without affecting project end date.

5. Predecessor & Successor

 Predecessor = an activity that must be completed before another starts.

 Successor = an activity that follows another.
 ―Design Database (A)‖ is a predecessor of ―Develop Application (B)‖.
 ―Develop Application (B)‖ is successor of ―Design Database (A)‖.

Project Scheduling Techniques

1. Critical Path Method (CPM)

 Critical Path Method (CPM) is a method used in project planning, generally for
project scheduling for the on-time completion of the project.
 The project has many paths, but the project finishes only when the longest path is done. That’s why
the longest path is called the critical path. Its duration is the minimum possible time to complete
the project
 It is the task/activity that can't be delayed otherwise the completion of the entire
project will be delayed. It must be completed on time before starting the other
dependent tasks.
 It tells us the minimum time to complete the project and shows critical tasks (tasks
with zero float).
o Tasks A, B, C, D.
o Tasks B and D can only start after Task A completes.
o Task C is independent.
o If Task A is delayed, B and D are also delayed → A is on the critical path
Eg

 A = 4, B = 3, C = 2, D = 5
 Dependencies: A → B, A → D, C independent

Paths:

 A→B=7
 A → D = 9 (longest, critical path)
 C=2

Project time = 9 days

 Tasks A & D = critical (no float)

 Task B = float = 2 days (since project needs 9 but B finishes in 7)
 Task C = float = 7 days (it only takes 2, but project is 9)
 If a critical task is delayed → the whole project is delayed.
 If a non-critical task is delayed, it may still be okay, as long as the delay is within its float.

Eg.

Let’s assume:

 A = 5 days
 B = 4 days
 D = 6 days
 C = 8 days

Now paths:

1. A → D = 5 + 6 = 11 days
2. A → B = 5 + 4 = 9 days
3. C = 8 days (independent)
4. Longest = A → D = 11 days
So Critical Path = A → D

Step-by-Step Example

Project Activities:
Duration
Activity Predecessor
(days)

A - 3

B A 4

C A 2

D B 5
 Duration
Activity Predecessor
(days)

E C 3

F D, E 2

Step 1: Draw the Network Diagram

A(3)
/ \
B(4) C(2)
| \
D(5) E(3)
\ /
F(2)

Step 2: Find All Paths & Durations

1. A → B → D → F = 3 + 4 + 5 + 2 = 14 days
2. A → C → E → F = 3 + 2 + 3 + 2 = 10 days

Step 3: Identify the Critical Path

 Longest path = A → B → D → F = 14 days

 This is the Critical Path.
 Any delay in A, B, D, or F will delay the whole project.

Step 4: Note Float

 Path A→C→E→F = 10 days (shorter than 14).

 It has 4 days float (14 – 10).
 So, C or E can be delayed up to 4 days without affecting project completion.

Conclusion :

 Critical Path = Longest path in the network.

 Project duration = 14 days.
 Critical tasks = A, B, D, F (float = 0).
 Non-critical tasks = C, E (float = 4).

2. PERT Chart (Program Evaluation and Review Technique)

 A network-based project scheduling technique used when activity durations are uncertain.
 Activities are represented as nodes/arrows, showing dependencies.
 PERT is used when activity durations are uncertain.
 It uses three time estimates for each task:

Time Estimates:

 Optimistic (O): Minimum possible time if everything goes well.

  Pessimistic (P): Maximum possible time if problems occur.
 Most Likely (M): Normal expected time.

Formula :

 It is Probabilistic model – Useful for R&D projects.

 Identifies the critical path and estimates completion time.

Steps:

1. List project activities.

2. Identify dependencies.
3. Draw the network diagram.
4. Estimate O, M, P for each activity.
5. Calculate TE.
6. Find the critical path and total project duration.

Advantages: Handles uncertainty, useful for R&D, identifies critical activities.

Limitations: Complex, requires accurate estimates

Example
Activity Predecessor O (days) M (days) P (days)

A - 2 4 6

B A 3 5 9

C A 4 6 8

D B, C 2 3 4

Step 1: Calculate Expected Time (TE)

 A: (2 + 4×4 + 6)/6 = (2 + 16 + 6)/6 = 24/6 = 4 days

 B: (3 + 4×5 + 9)/6 = (3 + 20 + 9)/6 = 32/6 ≈ 5.3 days
 C: (4 + 4×6 + 8)/6 = (4 + 24 + 8)/6 = 36/6 = 6 days
 D: (2 + 4×3 + 4)/6 = (2 + 12 + 4)/6 = 18/6 = 3 days

Step 2: Draw the Network

A(4)
/ \
B(5.3) C(6)
\ /
D(3)
Step 3: Find Paths & Durations

1. A → B → D = 4 + 5.3 + 3 = 12.3 days

2. A → C → D = 4 + 6 + 3 = 13 days

Step 4: Critical Path

 Longest path = A → C → D = 13 days

 So, Project duration = 13 days.

Key Difference from CPM:

 CPM → Uses fixed, known activity times. ―Deterministic‖ (fixed times)

 PERT → Uses three time estimates (O, M, P) for uncertainty. ―Probabilistic‖ (uncertain times).

3. Gantt Chart

 A bar chart that represents project activities against a time scale.

 Shows task start/finish dates, duration, and progress.
 Horizontal Bars: Represent tasks with start and end dates.
 Timeline: Shows the duration of tasks.

Steps:

1. List all tasks.

2. Arrange in sequence.
3. Estimate start and end dates.
4. Draw bars on the timeline.
5. Update regularly to track progress.
Advantages: Simple, easy to understand, shows task duration clearly.
Limitations: Complex for large projects, does not show dependencies as clearly as PERT/CPM.

4. Task List

 A simple project scheduling technique.

 A structured list of all activities in a project, used to assign responsibilities and track progress.
 Can be created using Word/Excel.

Contents of a Task List:

 Task ID/Number
 Task Name
 Start Date
 Duration / End Date
 Dependencies
 Assigned Resources
 Status

Task ID Task Name Duration Dependency Resource Status

T1 Requirement Analysis 5 days – Analyst Completed
T2 System Design 7 days T1 Designer In Progress
T3 Coding 15 days T2 Developer Not Started
T4 Testing 7 days T3 Tester Pending
T5 Deployment 3 days T4 Engineer Pending

Advantages:

 Provides a clear roadmap of project activities.

 Helps prioritize work.
  Easy to assign responsibilities.
 Useful for progress tracking and reporting.

Fast Tracking :

 Definition: Performing activities in parallel (overlapping tasks) that were originally planned in
sequence.
 Example: Start coding while design is still being reviewed.
 Advantages: Saves time, faster delivery.
 Disadvantages: Increases risk of rework and errors if dependent tasks overlap.

Crashing :

 Definition: Adding extra resources to critical path activities to finish them faster.
 Example: Assigning more developers to coding, or running overtime shifts.
 Advantages: Reduces project duration, effective when deadlines are strict.
 Disadvantages: Increases cost, may cause resource conflicts.