IT 604(B) • Unit II

Software Metrics, Estimation and Project Planning

Complete RGPV exam-oriented notes on measures, metrics, software quality, reliability, LOC and Function Point estimation, COCOMO, project tracking, scheduling and reverse engineering.

Start Unit 2 Notes
Home › Software Engineering › Unit 2

1. Measures, Metrics and Indicators 14 Marks

Measure

A measure is a quantitative value obtained by directly observing an attribute of a software product, process or project.

Examples: number of defects, development effort, lines of code, execution time and cost.

Metric

A metric is a quantitative measure that indicates the degree to which a software system, process or component possesses a given attribute.

Examples: defects per KLOC, productivity per person-month and test coverage percentage.

Indicator

An indicator is a metric or combination of metrics that provides insight for project control, quality assessment or management decision-making.
Raw Project Data | v Direct Measures | v Calculated Metrics | v Management Indicators | v Decision and Corrective Action
TermMeaningExample
MeasureDirect quantitative value50 defects
MetricCalculated quantitative relation5 defects/KLOC
IndicatorInterpretation used for decisionsDefect density is above acceptable limit

2. Software Metrics 14 Marks

Software metrics are quantitative measurements used to evaluate software products, development processes and projects.

Objectives

  • Estimate cost and effort.
  • Measure productivity.
  • Assess software quality.
  • Monitor project progress.
  • Identify risks and problems.
  • Support process improvement.
  • Improve planning and decision-making.

Types

  • Product metrics: Measure size, complexity, performance, quality and maintainability.
  • Process metrics: Measure effectiveness and efficiency of software processes.
  • Project metrics: Measure cost, effort, schedule, resources and progress.

Characteristics of a Good Metric

  • Simple and clearly defined
  • Objective and repeatable
  • Easy to collect
  • Relevant to project goals
  • Consistent across projects
  • Actionable
  • Economical to measure

3. Metrics in the Process Domain 7 Marks

Process metrics evaluate and improve the activities used to develop software.

Examples

  • Defect removal efficiency
  • Average review time
  • Testing effectiveness
  • Rework percentage
  • Change request processing time
  • Process cycle time
  • Requirements stability
  • Defects introduced in each phase
Defect Removal Efficiency (DRE) = E / (E + D) × 100

E = defects found before delivery
D = defects found after delivery
If 90 defects are detected before delivery and 10 after delivery:
DRE = 90 / (90 + 10) × 100 = 90%

4. Metrics in the Project Domain 7 Marks

Project metrics help managers plan, monitor and control software projects.

Common Project Metrics

  • Planned and actual effort
  • Planned and actual cost
  • Schedule variance
  • Resource utilization
  • Productivity
  • Number of unresolved defects
  • Requirement changes
  • Milestone completion
  • Risk exposure
Productivity = Software Size / Development Effort
Schedule Variance (%) = (Actual Time − Planned Time) / Planned Time × 100

5. Software Measurement Process 14 Marks

Software measurement is the systematic process of assigning numerical values to software attributes according to defined rules.
Define Measurement Goals | v Select Metrics | v Define Collection Method | v Collect Data | v Analyze and Interpret | v Take Corrective Action

Measurement Principles

  • Measure only what supports a clear goal.
  • Define each metric precisely.
  • Collect reliable and consistent data.
  • Use metrics for improvement, not punishment.
  • Interpret metrics in context.
  • Compare similar projects only.
  • Review and refine the measurement system.

6. Metrics of Software Quality 14 Marks

Software quality metrics quantify characteristics that determine how well software satisfies stated and implied requirements.
Quality FactorMeaningPossible Metric
CorrectnessDegree to which requirements are satisfiedDefects/KLOC
ReliabilityProbability of failure-free operationMTTF, failure rate
EfficiencyResource usage and performanceResponse time, memory use
IntegrityProtection against unauthorized accessSecurity incidents
UsabilityEase of learning and useTask completion time
MaintainabilityEase of correction and modificationMean time to change
TestabilityEase of testingTest coverage
PortabilityEase of moving to another environmentPorting effort
ReusabilityUse of components in other systemsReuse percentage
Defect Density = Number of Defects / Software Size
Test Coverage (%) = Tested Items / Total Items × 100

7. Software Reliability 14 Marks

Software reliability is the probability that software will operate without failure for a specified period under specified conditions.

Important Terms

  • Failure: Observable incorrect behavior of software.
  • Fault: Defect in software that may cause failure.
  • Error: Incorrect internal state produced by a fault.
  • Failure rate: Number of failures per unit time.
  • MTTF: Mean Time To Failure.
  • MTTR: Mean Time To Repair.
  • MTBF: Mean Time Between Failures.
MTBF = MTTF + MTTR
Availability = MTTF / (MTTF + MTTR) × 100
For constant failure rate λ: Reliability R(t) = e−λt
If MTTF = 90 hours and MTTR = 10 hours:
MTBF = 100 hours
Availability = 90%

Reliability Improvement

  • Formal reviews
  • Defensive programming
  • Automated testing
  • Fault tolerance
  • Continuous monitoring
  • Root-cause analysis

8. Software Estimation Techniques 14 Marks

Software estimation predicts the size, effort, cost, resources and schedule needed to complete a software project.

Major Approaches

  • Expert judgment
  • Analogy
  • Top-down estimation
  • Bottom-up estimation
  • Algorithmic models
  • Size-based estimation
  • Three-point estimation
Three-Point Estimate = (Optimistic + 4 × Most Likely + Pessimistic) / 6

Steps

  1. Define project scope.
  2. Estimate software size.
  3. Select an estimation method.
  4. Estimate effort and duration.
  5. Estimate resources and cost.
  6. Consider risks.
  7. Review and refine the estimate.

9. Lines of Code Estimation 14 Marks

LOC estimation measures software size by estimating the number of source code lines required to implement the system.

Advantages

  • Simple to understand.
  • Useful with historical productivity data.
  • Supports effort and defect-density calculation.
  • Used in COCOMO.

Limitations

  • Language dependent.
  • Difficult to estimate early.
  • Penalizes concise code.
  • Does not directly measure functionality.
  • Generated and reused code create ambiguity.
Productivity = LOC / Person-Month
Cost per LOC = Total Project Cost / LOC
If a 20 KLOC project requires 10 person-months, productivity = 2 KLOC per person-month.

10. Function Point Estimation 14 Marks

Function Point Analysis measures software size according to user-visible functionality, independent of programming language.

Five Function Types

  • External Inputs (EI)
  • External Outputs (EO)
  • External Inquiries (EQ)
  • Internal Logical Files (ILF)
  • External Interface Files (EIF)
ComponentLowAverageHigh
External Input346
External Output457
External Inquiry346
Internal Logical File71015
External Interface File5710
UFP = Sum of (Count × Weight)
VAF = 0.65 + 0.01 × ΣFi
FP = UFP × VAF

11. Function Point Numerical Example 14 Marks

Assume all components have average complexity.

ComponentCountWeightResult
External Inputs10440
External Outputs6530
External Inquiries4416
Internal Logical Files31030
External Interface Files2714
UFP = 40 + 30 + 16 + 30 + 14 = 130

Suppose ΣFi = 35.

VAF = 0.65 + (0.01 × 35) = 1.00
Adjusted FP = 130 × 1.00 = 130 Function Points

12. COCOMO Model 14 Marks

COCOMO, or Constructive Cost Model, is an empirical software estimation model used to estimate effort, development time and staffing from software size.

Project Modes

  • Organic: Small and simple projects.
  • Semi-detached: Medium projects with mixed experience.
  • Embedded: Complex projects with strict constraints.

Levels

  • Basic COCOMO: Uses only size.
  • Intermediate COCOMO: Uses size and cost drivers.
  • Detailed COCOMO: Applies cost drivers phase by phase.

13. Basic COCOMO Equations 14 Marks

Effort (E) = a × (KLOC)b person-months
Development Time (D) = c × (E)d months
Average Staff = E / D
Modeabcd
Organic2.41.052.50.38
Semi-detached3.01.122.50.35
Embedded3.61.202.50.32

Intermediate COCOMO

Effort = a × (KLOC)b × EAF

14. Basic COCOMO Numerical Example 14 Marks

Estimate effort and development time for an organic project of 32 KLOC.

Effort = 2.4 × (32)1.05 ≈ 91.4 person-months
Development Time = 2.5 × (91.4)0.38 ≈ 13.9 months
Average Staff = 91.4 / 13.9 ≈ 6.6 persons
Therefore, the project requires approximately 91 person-months, 14 months and an average team of 7 persons.

15. Project Scheduling 14 Marks

Project scheduling is the process of identifying project activities, estimating their duration, defining dependencies and assigning resources over time.

Steps

  1. Identify project activities.
  2. Create a Work Breakdown Structure.
  3. Estimate effort and duration.
  4. Identify dependencies.
  5. Assign resources.
  6. Define milestones.
  7. Prepare a network or Gantt chart.
  8. Determine the critical path.
  9. Monitor and revise the schedule.

Important Terms

  • Activity
  • Milestone
  • Dependency
  • Critical path
  • Slack

16. Gantt Chart 7 Marks

A Gantt chart is a bar chart that shows project activities against calendar time.
Activity Week 1 Week 2 Week 3 Week 4 Week 5 Requirements █████ Design █████ Coding █████████ Testing █████ Deployment ███

Advantages

  • Easy to understand.
  • Shows start and finish dates.
  • Displays overlapping activities.
  • Helps track progress.

Limitations

  • Complex dependencies may not be clear.
  • Large projects create very large charts.

17. PERT and CPM 14 Marks

PERT

Program Evaluation and Review Technique is a network-based scheduling method that uses probabilistic activity times.
Expected Time (TE) = (O + 4M + P) / 6
Variance = ((P − O) / 6)2

CPM

Critical Path Method is a network scheduling technique that uses deterministic activity times to identify the longest path and minimum project duration.
BasisPERTCPM
TimeProbabilisticDeterministic
FocusTime uncertaintyTime-cost optimization
Suitable forResearch and new projectsWell-defined projects
EstimatesThree time estimatesSingle time estimate

18. Project Tracking 14 Marks

Project tracking is the continuous comparison of actual project performance with planned cost, schedule, effort, quality and scope.

Activities

  • Monitor milestone completion.
  • Compare planned and actual effort.
  • Measure schedule variance.
  • Track cost and resource usage.
  • Monitor defects and quality.
  • Review risks and requirement changes.
  • Prepare status reports.
  • Take corrective action.
Project Plan | v Collect Actual Data | v Compare Plan vs Actual | v Identify Variance | v Corrective Action

19. Earned Value Analysis 7 Marks

  • PV: Planned Value
  • EV: Earned Value
  • AC: Actual Cost
Schedule Variance (SV) = EV − PV
Cost Variance (CV) = EV − AC
Schedule Performance Index (SPI) = EV / PV
Cost Performance Index (CPI) = EV / AC
SPI below 1 means the project is behind schedule. CPI below 1 means the project is over budget.

20. Reverse Engineering 14 Marks

Software reverse engineering is the process of analyzing an existing software system to identify its components, relationships, design and higher-level representation.
Existing Source Code | v Code Analysis | v Recover Data and Control Structure | v Recover Design | v Recover Architecture / Requirements

Objectives

  • Understand undocumented software.
  • Recover design and architecture.
  • Support maintenance.
  • Identify reusable components.
  • Assist migration and modernization.
  • Detect security weaknesses.

Advantages

  • Reduces understanding effort.
  • Supports legacy-system maintenance.
  • Improves documentation.
  • Enables reengineering.

Limitations

  • Can be expensive and time-consuming.
  • Recovered information may be incomplete.
  • Legal and licensing restrictions must be respected.

21. Important Comparisons 14 Marks

LOC vs Function Point

BasisLOCFunction Point
MeasuresSource code lengthUser-visible functionality
Language dependenceLanguage dependentLanguage independent
Early estimationDifficultPossible from requirements
UseTechnical productivityBusiness application size

Product, Process and Project Metrics

Metric TypeFocusExamples
ProductSoftware characteristicsSize, complexity, defect density
ProcessDevelopment methodDRE, review effectiveness, cycle time
ProjectManagement performanceCost, schedule, effort, resource use

Unit 2 Quick Revision

  • A measure is direct, a metric is calculated and an indicator supports decisions.
  • Product metrics measure software; process metrics improve activities; project metrics control management.
  • DRE shows the percentage of defects removed before delivery.
  • Reliability is the probability of failure-free operation.
  • MTBF equals MTTF plus MTTR.
  • LOC is language dependent; Function Point is language independent.
  • Function Point uses EI, EO, EQ, ILF and EIF.
  • COCOMO estimates effort and time using KLOC.
  • Organic, semi-detached and embedded are COCOMO modes.
  • PERT uses three time estimates; CPM identifies the critical path.
  • Reverse engineering recovers higher-level information from existing software.

Important RGPV Exam Questions

Long Answer Questions

  1. Differentiate measures, metrics and indicators with examples.
  2. Define software metrics and explain their types and objectives.
  3. Explain process metrics and project metrics.
  4. Describe the software measurement process.
  5. Explain important metrics of software quality.
  6. Define software reliability and explain MTTF, MTTR, MTBF and availability.
  7. Explain different software estimation techniques.
  8. Explain LOC estimation with advantages and limitations.
  9. Explain Function Point Analysis with calculation steps.
  10. Solve a numerical problem based on Function Point estimation.
  11. Explain the COCOMO model and its project modes.
  12. Solve a numerical problem using Basic COCOMO.
  13. Explain project scheduling, Gantt chart, PERT and CPM.
  14. Explain project tracking and Earned Value Analysis.
  15. Define reverse engineering and explain its process.

Short Answer Questions

  1. Define measure, metric and indicator.
  2. What is defect density?
  3. Define DRE.
  4. What is software reliability?
  5. Define MTTF and MTBF.
  6. What is LOC?
  7. Name the five Function Point components.
  8. What is VAF?
  9. Define COCOMO.
  10. What are the three COCOMO modes?
  11. What is a milestone?
  12. Define critical path.
  13. What is schedule variance?
  14. Define reverse engineering.
Exam Tip: LOC, Function Point, COCOMO, reliability and PERT answers should include formulas, symbol meanings, calculation steps and final units.

Download Study Resources

Unit 2 PDF

Printable Unit 2 notes will be available soon.

Coming Soon

Numerical Practice

LOC, FP, COCOMO and PERT problems will be available soon.

Coming Soon

Important Questions

Expected Unit 2 questions will be available soon.

Coming Soon

Frequently Asked Questions

A measure is a direct value such as 50 defects, while a metric combines measures, such as 5 defects per KLOC.
DRE = E divided by E plus D, multiplied by 100.
MTBF = MTTF + MTTR.
Function Point measures user-visible functionality rather than source-code lines.
Organic, semi-detached and embedded.
PERT uses probabilistic times, whereas CPM generally uses deterministic times.
Its purpose is to understand existing software and recover design, architecture, data structures and documentation.