Module 3 - Software Estimation Metrics

Software Metrics: Introduction & Terminologies

A software metric is a measure of software characteristics which are measurable or countable. It involves the continuous application of measurement-based techniques to the software development process and its products to supply meaningful and timely management information, and to improve that process and its products. The IEEE defines a metric as a quantitative measure of the degree to which a system component or process possesses a given attribute. Software metrics are highly valuable for measuring software performance, planning work items, and measuring productivity. They are closely tied to the four functions of management: Planning, Organization, Control, and Improvement.

Terminologies used in Software Metrics

The Management Spectrum (The 4 P's)

The management spectrum describes the management of a software project and how to make a project successful. It focuses on the four P's: People, Product, Process, and Project. The project manager must control all these P's to ensure a smooth flow in the project's progress and to reach the final goal.

• A. The People: Includes everyone from the manager to the developer, and the customer to the end user, though it mainly highlights developers. Highly skilled and motivated developers are so crucial that the SEI developed a People Management Capability Maturity Model (PM-CMM) to help attract, grow, motivate, and retain talent.
• B. The Product: Any software that has to be developed. To develop successfully, objectives, scope, alternative solutions, and constraints must be established. Without this, it is impossible to define reasonable cost estimates, assess risks, breakdown tasks realistically, or manage schedules.
• C. The Process: Provides the framework from which a comprehensive plan for software development can be established. It consists of different task sets (tasks, milestones, work products, QA points) that adapt to project characteristics, overlaid by independent umbrella activities.
• D. The Project: Encompasses everything in the total development process. The manager must control it, take necessary steps, and be concerned about common warnings to avoid project failure.

Metric Classification

Software metrics can be classified into three primary types based on what they are measuring: Processes, Products, and Projects.

• 1. Process Metrics: These are strategic, long-term metrics collected across all projects over long periods. Their intent is to provide indicators that lead to software process improvement, focusing on the quality achieved as a consequence of a repeatable or managed process. It involves categorizing errors by origin, recording the cost to correct them, and modifying the process accordingly.
• 2. Product Metrics: These are the explicit results of software development activities (e.g., deliverables, documentation) and focus on the quality of those deliverables. These metrics are combined across several projects to produce process metrics. Examples include measures of the Analysis Model, architectural complexity, data flow complexity, and internal algorithmic complexity.
• 3. Project Metrics: These are inputs into the software development activities (hardware, knowledge, people) used during estimation. They enable a project manager to assess the status of an ongoing project, track potential risks, adjust workflows, and evaluate the team's ability to control quality. Metrics from past projects form the basis for current effort and time estimates.

Software Measurement

Measurement of software can be done in different ways, divided primarily by who views the properties as most important:

Advantages & Disadvantages of Software Metrics

Advantages:

• Allows for comparative study of various design methodologies and helps in the preparation of software quality specifications.
• Aids in the verification of compliance with system requirements and specifications.
• Helps make inferences about the effort required in design and development, and gives an idea about code complexity.
• Provides feedback to managers about progress and quality during various phases of the SDLC and helps decide if a complex module should be divided further.

Disadvantages:

• Application is not always easy and can be difficult and costly.
• Verification and justification depend on historical/empirical data, whose validity is difficult to verify.
• Useful for managing products, but not appropriate for evaluating the performance of technical staff.
• Derivations are usually based on assumptions that are not standardized and depend heavily on available tools and working environments.
• Most predictive models rely on estimates of certain variables which are often not known precisely.

Software Project Estimation: Size-Oriented Metrics (LOC)

Size-oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size of the software that has been produced. The most common example is Lines of Code (LOC). It is one of the earliest and simpler metrics for calculating the size of a computer program and is generally used in calculating and comparing the productivity of programmers.

Key Characteristics of LOC

• In size-oriented metrics, LOC is considered to be the normalization value.
• It is an older method that was developed when languages like FORTRAN and COBOL were very popular.
• Productivity is defined as KLOC / EFFORT, where effort is measured in person-months.
• Size-oriented metrics are highly dependent on the programming language used. Because productivity depends on KLOC, assembly language code will falsely appear to have more "productivity" simply because it requires more lines. Conversely, the more expressive a programming language is, the lower the productivity appears in LOC terms.
• The LOC method does not apply to projects that deal with visual (GUI-based) programming since forms are used instead of traditional code lines.
• It requires that all organizations use the exact same method for counting LOC (e.g., deciding whether to count only executable statements or also comments), meaning a standard needs to be established. Because of these issues, these metrics are not universally accepted.

Computed Metrics Based on LOC/KLOC

Based on the LOC or KLOC (Kilo-Lines of Code) count, several other useful metrics can be computed for a project:

Cost Estimation Using LOC (Example)

Function-Oriented Metrics (FP)

Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization value. The most widely used function-oriented metric is the Function Point (FP). Function point metrics provide a standardized method for measuring the various functions of a software application. Computation is based on the characteristics of the software's information domain and complexity. Crucially, it measures functionality from the user's point of view—based on what the user requests and receives in return.

Information Domain Values

The FP count is derived by evaluating the software's information domain, which consists of five distinct parameters that are individually assessed for complexity:

• External Inputs (EI): Distinct input from the user (e.g., Input screens, tables).
• External Outputs (EO): Output screens, reports, error messages, etc.
• External Inquiries (EQ): Online input that generates some result (e.g., Prompts, interrupts).
• Internal Logical Files (ILF): Logical files (e.g., databases, directories) maintained within the system.
• External Interface Files (EIF): Data files or connections serving as an interface to other systems (e.g., shared databases, shared routines).

Measurement Parameter	Simple	Average	Complex
1. External Inputs (EI)	3	4	6
2. External Outputs (EO)	4	5	7
3. External Inquiries (EQ)	3	4	6
4. Internal Logical Files (ILF)	7	10	15
5. External Interfaces (EIF)	5	7	10

Note: The Count-total is calculated by multiplying the raw count of each parameter by its corresponding weighting factor based on complexity, then summing them up.

FP Calculation & Complexity Adjustment Values

The 14 Value Adjustment Factors (Fi) evaluate the system's operational and design needs:

1. Need for reliable backup/recovery?
2. Data Communication requirements?
3. Distributed data processing functions?
4. Is performance critical?
5. Execution in a heavily utilized operational environment?
6. Need for on-line data entry?
7. Input transaction over multiple screens?
8. Online update of master files?
9. Complex processing (inputs, outputs, files, inquiries)?
10. Complexity in internal processing?
11. Code designed to be reusable?
12. Involvement of conversion/installation ease?
13. Multiple sites/installations?
14. Facilitate change and operational ease?

Function Point Calculation Examples

Function Point (FP) vs. Lines of Code (LOC)

In general, people prefer the functional size of software (FP) over LOC because the size expressed using the FP metric stays constant regardless of which programming languages are used. Both metrics, however, are extendible/convertible to each other (a process known as backfiring).

Function Point (FP)	Lines of Code (LOC)
FP is specification based.	LOC is analogy based.
FP is language independent.	LOC is language dependent.
FP is user-oriented.	LOC is design-oriented.
Function Point is used for data processing systems.	LOC is used for calculating the size of the computer program.
Function Point can be used to portray the project time.	LOC is used for calculating and comparing the productivity of programmers.

COCOMO Model (Constructive Cost Estimation Model)

Proposed by Barry Boehm in 1981, COCOMO is an algorithmic software cost estimation model based on the study of 63 projects. It predicts the effort and schedule of a software product based on the size of the software (measured in LOC). The key parameters are Effort (amount of labor required, measured in person-months) and Schedule (amount of time required, proportional to effort put in).

COCOMO Project Categories

In COCOMO, projects are categorized into three types based on complexity and team familiarity:

Hierarchy of COCOMO Models

COCOMO consists of a hierarchy of three increasingly detailed and accurate forms:

COCOMO II

COCOMO II is the successor of COCOMO 81, developed in 1997 and published in 2000 to better suit modern software development projects. While the original COCOMO was highly successful, it did not apply well to newer software development practices. COCOMO II provides support for modern software life cycles and uses parameters derived from historical and current project data to link system size, project, and team factors to the effort required.

The 3 Stages of COCOMO II

COCOMO II encompasses three distinct estimation models tailored for different stages of the development lifecycle:

Empirical Estimation Models

Empirical estimation techniques are founded on making a studied guess regarding project parameters based on previous experience. The two most frequently used empirical techniques are:

Specialized Estimation Techniques

When projects have very short completion periods and continuous changes, standard decomposition techniques are abbreviated into specialized methods:

• A. Estimation for Agile Development: Requirements are set by user scenarios. Each scenario is considered independently and divided into software engineering tasks. Volume is estimated in LOC, FP, or use-case count, and effort is estimated separately. Because agile increments are short (3-6 weeks), this ensures scenarios fit existing resources and helps assign effort efficiently.
• B. Estimation of WebApp Projects: WebApps usually follow the agile process model but use an updated Function Point (FP) approach.
  • Inputs: Input screens, forms (CGI/Java), maintenance screens, tabs.
  • Outputs: Static Web pages, dynamic scripts (ASP, PHP, DHTML), reports.
  • Tables/Files: Logical databases, XML objects.
  • Interfaces: Logical files bound out-of-system.
  • Queries: Externally published or message-oriented interfaces (DCOM/COM).
  By gathering "predictor variables" (page count, media duration, linking complexity), empirical models can estimate page/media authoring and scripting effort.

Project Scheduling and Tracking

A project schedule is a mechanism used to communicate the sequence of tasks to be done and assign organizational resources to complete those tasks within a predefined time frame. Because a project is a group of many tasks with specific start and end dates, the schedule serves as a "Road map" for the project manager. The objective of software project planning is to provide a framework that enables the manager to make reasonable estimates of resources, cost, and schedule, attempting to define best-case and worst-case scenarios.

Project Scheduling Guidelines & Effort Distribution

Effective project scheduling relies on several basic principles to maintain control and clarity:

Work Breakdown Structure (WBS)

A Work Breakdown Structure includes dividing a large and complex project into simpler, manageable, and independent tasks. It uses a Top-Down approach, where the root of the tree is labeled by the Project name itself, and each node is recursively decomposed into sub-activities until they become undividable. The WBS provides the foundation for all project management work, including planning, cost/effort estimation, and scheduling.

Work Packages: Deliverables and Milestones

The WBS decomposes the project into smaller components and more manageable units of work called Work Packages (the lowest level). These make it possible to assign resources, develop a budget, and monitor progress.

• Deliverables: Tangible outcomes such as presentations, reports, plans, and the final application system.
• Milestones: A significant event or achievement that provides evidence that the deliverable has been completed or a phase is formally over. Having milestones helps reduce project risk.

Critical Path Method (CPM)

The Critical Path Method (CPM) is a technique used in project planning to schedule the on-time completion of a project. It helps determine the earliest time by which the whole project can be completed.

Activity-on-Node (AON) Representation

In a project network diagram, each node represents an activity and its time estimations. The standard node layout contains six key values:

Time Estimation & Identifying the Critical Path

• Forward Pass: Carried out to calculate the earliest dates on which each activity may be started (ES) and completed (EF). If an activity has multiple precedents, it considers the MAX(EF of precedents).
• Backward Pass: Carried out to calculate the latest dates on which each activity may be started (LS) and finished (LF) without delaying the end date of the project. If an activity precedes multiple activities, its LF is the MIN(LS of successors).
• Float: The difference between an activity's Earliest Start and Latest Start (or Earliest Finish and Latest Finish). It indicates how much the activity can be delayed without delaying the whole project.
• Critical Activities: If the float of an activity is zero, it is a critical activity and forms part of the Critical Path.

Advantages & Disadvantages of CPM

Program Evaluation and Review Technique (PERT)

Project Evaluation and Review Technique (PERT) is a procedure through which activities of a project are represented in their appropriate sequence and timing. Developed in the 1950s by the U.S. Navy to handle the Polaris submarine missile program, it is a scheduling technique used to organize, integrate, and manage uncertain activities within a project. It provides a blueprint for management planning and control by establishing a time network analysis, reporting information, and identifying the essential elements needed to complete the project on time.

The Three Estimates in PERT

Unlike CPM, which uses a single deterministic time estimate, PERT handles uncertainty by employing three distinct time estimates for each activity:

PERT Logic Network & Dummy Activities

A PERT chart is represented as a network diagram using nodes (representing events) and directional lines (indicating the sequence of tasks). The logic network shows task dependencies, the timescale, and overall workflow. PERT specifically utilizes dummy activities (represented by dotted lines)—tasks with no resource or completion time required that simply enforce an event dependency sequence.

PERT vs. CPM

While both are critical scheduling tools, they differ significantly in their approach to uncertainty and structure:

PERT	CPM
Used to manage uncertain activities.	Manages well-defined activities.
A technique of planning and control of time.	A method to control cost and time.
It is a probability model.	It is a deterministic model.
Event-oriented technique (network constructed based on events).	Activity-oriented technique (network constructed based on activities).
Uses three estimates.	Uses one estimate.
No chance of crashing as there is no certainty of time.	There may be crashing because of certain time bounds.
Uses dummy activities for representing sequence.	Does not use any dummy activities.
Suitable for Research and Development (R&D) projects.	Suitable for construction projects.

Project Tracking

The project schedule is a road map which defines the tasks and milestones that are to be tracked and controlled as the project proceeds. Tracking can be done in a number of different ways by experienced project managers:

• Calling periodic project status meetings where each team member reports the progress of their assignments/tasks.
• Evaluating the reviews during the software engineering process.
• Setting tentative project deadlines to see if they have been completed by the scheduled dates.
• Comparing the real start date to the intended start date for every project.
• Conducting informal meetings with resources to obtain their progress on given assignments.

TimeLine Charts / Gantt Charts

A Generalized Activity Normalization Time Table (GANTT) chart is a type of horizontal bar chart developed by Henry L. Gantt in 1917 as a production control tool. It is used for the graphical representation of a schedule, helping to plan, coordinate, and track specific tasks efficiently. Gantt charts are also known as timeline charts and can be developed for the entire project or individual functions.

• All tasks are listed in the leftmost column.
• Horizontal bars indicate the required time for the corresponding task.
• When multiple horizontal bars overlap on the calendar, it means concurrency can be applied for performing those tasks.
• Diamonds on the chart indicate project milestones.

Project Timetable (Example)

After generating a timeline chart, project tables are prepared listing tasks, start/end dates, and assignments.

Name of the task/activity	Scheduled Start Date	Actual Start Date	Scheduled End Date	Actual End Date	Effort/ Task Assigned
Requirement Analysis	21-07-2021	25-07-2021	28-07-2021	03-08-2021	Athrav, Saili
Architectural Design	30-07-2021	04-08-2021	04-08-2021	06-08-2021	Hamza, Muaaz
Procedural Design	06-08-2021	16-08-2021	07-08-2021	16-08-2021	Omkar, Krutika, Kunal
Coding	18-08-2021	25-08-2021	18-08-2021	27-08-2021	Pratiksha, Janvi, Aditya
Testing	27-08-2021	03-09-2021	29-08-2021	07-09-2021	Harsh, Omkar, Asmita

Earned Value Analysis (EVA)

During project tracking, developer status updates can often be subjective. Earned Value Analysis (EVA) provides a quantitative and objective method to measure project performance in terms of scope, time, and cost. EVA assesses progress based on "earnings" or money, using a common value scale (like dollars or work-hours) for every project task. By estimating the total hours to complete a project, every task is given an Earned Value based on its estimated percentage of the total.

Key Elements of EVA

EVA relies on three foundational metrics tracked up to a specified point in time:

Earned Value Calculations

Metric	Formula	Interpretation
Cost Variance (CV)	CV = EV - AC	If < 0, project is over budget. If > 0, under budget.
Cost Performance Index (CPI)	CPI = EV / AC	Measures value of work completed against actual cost. < 1.0 means costs are higher than budgeted; > 1.0 means less than budgeted.
Schedule Variance (SV)	SV = EV - PV	If < 0, project is behind schedule. If > 0, ahead of schedule.
Schedule Performance Index (SPI)	SPI = EV / PV	Measures progress achieved against progress planned. < 1.0 indicates less work completed than planned.
Estimated at Completion (EAC)	EAC = Total Budget / CPI	A forecast of how much the total project will cost based on current pacing.

Real-World Example