UNIT-3

Defining Good Data

📌 1. Definition

In software engineering, "good data" refers to the accurate, relevant, consistent, and usable data collected during
software measurement. This data serves as the foundation for metrics and models that guide decision-making,
quality control, and process improvement.

📊 2. Relation to Software Measurements & Metrics

Criteria Explanation in Software Context

Accuracy Data truly represents what it claims (e.g., defect counts are real and not estimated).

Consistency Data must be available in same formats across everywhere , like code size in KLOC only

Relevance Only useful data is collected (e.g., collecting number of failed test cases when evaluating test effectiveness).

Timeliness Data up to date like weekly reports

Completeness No missing values in critical fields (e.g., developer name, date, defect severity).

🧠 3. Usage in Software Modelling

Software process and product models (e.g., COCOMO, Function Point Analysis, Reliability Growth Models) rely
heavily on good data. Poor data leads to:

 Inaccurate cost/time estimations

 Wrong predictions about system reliability or performance

 Ineffective project planning or risk analysis

Example: In COCOMO II, if effort data from past projects is unreliable or inconsistent, any effort prediction will be
flawed.

🔍 4. Characteristics of Good Measurement Data

Valid, reliable, reproducible, repeatable, accurate, timely

🚧 5. Consequences of Bad Data

Wrong decisions, wrong predictions or data models, wasted resources, bad quality control, low
stakeholder trust

Data Collection for Incident Reports

📌 1. Definition

Incident reports – documentations of unplanned events that disrupt normal operation — such as defects, failures,
crashes, or performance issues.
Data collection for incident reports involves gathering accurate, complete, and structured data about these events to
analyse root causes, identify trends, and improve software quality.

📊 2. Relation to Software Measurements & Metrics

Metric Formula / Use

Defect Density Defects / KLOC

MTBF (Mean Time Between Failures) Total Uptime / Number of Failures

MTTR (Mean Time to Repair) Total Repair Time / Number of Incidents

Defect Removal Efficiency (DRE) (Defects found before release / Total Defects) × 100

📝 3. Key Data Fields to Collect

Field Description

Incident ID Unique identifier

Date and Time When the incident occurred

Reported By Person/team reporting it

Impact level (e.g., Critical, High,

Severity/Priority
Medium, Low)

Which part of the software was

Affected System/Module
affected

Description Summary of what went wrong

Steps to Reproduce How to replicate the issue

Resolution/Action Taken How it was fixed or mitigated

Duration from report to

Time to Resolve
resolution

(e.g., Open, In Progress, Resolved,

Status
Closed)

Attachments/Logs Screenshots, logs, test cases, etc.

📦 4. Tools for Incident Data Collection

 Manual Forms or Spreadsheets (small teams or startups)

 Issue Tracking Systems:

Jira, GitHub Issues, ServiceNow, etc.
  Automated Logging:
Error logs, crash dumps, monitoring systems like Splunk etc.

🔄 5. Using Incident Data in Modelling

 Root Cause Analysis Models (like Fishbone diagrams or 5 Whys) rely on detailed incident records.

 Process Improvement Models (like CMMI) use incident data to identify areas of inefficiency or risk.

⚠️6. Challenges in Data Collection

Challenge Example/Explanation

Incomplete Data Missing logs or vague descriptions

Inconsistent Terminology Different teams using different labels for severity

Human Bias Underreporting or downplaying incidents

Lack of Automation Manual entry can be error-prone

Topic: How to Collect Data

📌 1. Definition

In software engineering, data collection refers to the systematic process of gathering quantifiable or qualitative
information about software processes, products, or resources. This data is essential for computing software metrics
and building models to support decision-making and improvements.

📋 2. Types of Data to Collect

Type Examples

Product Data Lines of code, functions, features

Process Data Time taken for each phase, number of reviews, delays

Resource Data Team size, effort (person-hours), tools used

Quality Data Bugs, MTBF, MTTR, defect density

Incident Data Documentation about unplanned events that hampered prod development

3. Methods of Data Collection

Method Description & Example

Manual Entry forms, spreadsheets, logs

Automated Tools IDE data collection plugins, CI/CD tools

Issue Tracking Systems Jira , servicenow, github issues

Method Description & Example

Surveys & Feedback Collect qualitative data like user satisfaction or team feedback

Log Analysis Analyze runtime logs, crash dumps, server logs for failures and performance issues

Version Control Systems Git, SVN – used to collect commit frequency, code churn, developer activity

Test Management Tools Selenium, JUnit, TestRail – collect pass/fail data, test coverage

🧩 4. Steps in a Good Data Collection Process

1. Define Objectives
→ What metrics or models do you need the data for? (e.g., effort estimation, defect prediction)

2. Identify Data Sources

→ Github rep, logs, surveys, jira tickets

3. Choose Data Collection Methods

→ Manual, automated, or hybrid depending on context.

4. Automate Where Possible

→ Reduces human error

5. Validate and Clean Data

→ Remove duplicates, fix inconsistencies, fill missing values.

6. Store in Central Repository

→ Use databases or dashboards for easy access and analysis.

Reliability of Data Collection Procedures & Analyzing Software

Measurement Data
1: Reliability of Data Collection Procedures
🧠 What is Reliability in Data Collection?

Reliability  consistency, dependability, accuracy, availability, timely

Results  better decision making , planning, resource allocation etc.

✅ Key Qualities of Reliable Data:

Criterion Description

Repeatability Same person, same method → same results

Reproducibility Different people, same method → similar results

Objectivity Free from individual bias; uses standard tools and definitions

Consistency Uniform across projects, teams, tools, and time

Accuracy Data matches the actual values/measurements from the software process

🧰 How to Ensure Reliability in Data Collection:

 1. Define Clear Measurement Goals
→ Use GQM (Goal-Question-Metric) approach

2. Standardize Procedures
→ Use templates, guidelines, and consistent definitions

3. Train Personnel
→ All team members understand how and what to record

4. Use Automated Tools to reduce human error

→ Reduce human error

5. Implement quality control measures

6. Perform Reviews to validate and cross check data

→ Validate whether data collection is being followed correctly

7. Minimize bias and subjectivity

 Minimize bias and subjectivity in data collection by using objective criteria and standardized measures.
Avoid leading questions, ambiguous language, or subjective judgments that could influence data collection
outcomes.

8. Maintain Metadata
→ Document when, how, and by whom data was collected

🚫 Risks of Unreliable Data:

 Wrong decisions

 Models (like COCOMO, DRE, MTBF) become invalid

 Loss of stakeholder confidence

2: Analyzing Software Measurement Data

🧮 What is Analysis in this Context?

Data analysis  interpreting measurement data to identify trends, detect problems, evaluate performance, and
support project planning or prediction models.

🧰 Common Techniques to Analyze Measurement Data:

Technique Use Case / Example

Mean, median, standard deviation (e.g., average defects per

Descriptive Statistics
module)

Trend Analysis Observe changes over time (e.g., test coverage over sprints)

Correlation Analysis Identify relationships (e.g., more LOC → more defects?)

Pareto Analysis 80/20 rule: Focus on areas causing the most problems

Control Charts Monitor process stability (used in statistical process control)

Outlier Detection Find anomalies in effort, defects, or time taken

Technique Use Case / Example

📈 Visualization Tools:

 Line charts – for trends (defect rate, velocity)

 Bar graphs – comparisons across modules/teams

 Pie charts – proportion of defect types

 Scatter plots – correlation analysis

 Dashboards – real-time visibility of multiple KPIs

📋 Outputs of Analysis:

 Quality Reports

 Performance benchmarks

 bottlenecks

 Model Calibration (e.g., tuning COCOMO parameters)

✅ Topic: Statistical Distributions and Hypothesis Testing

PART 1: Statistical Distributions
A statistical distribution describes how values of a variable (e.g., defects, development time, response time) are
spread or distributed over a range & time.
They are essential in software measurement for modeling uncertainty, predicting performance, and assessing
quality.

🎯 Importance in Software Engineering:

 Models variability in software metrics (e.g., defect arrival rate, resolution time).

 Helps in probabilistic models like reliability estimation.

 Foundation for hypothesis testing and statistical analysis.

📊 Common Distributions Used:

Distribution Use Case in Software Engineering

Normal Distribution (Gaussian) Many software metrics (like test scores, LOC) approximate this.

Poisson Distribution Models number of defects/failures over time.

Exponential Distribution Models time between failures or incidents.

Binomial Distribution Used when measuring success/failure (e.g., test case pass/fail).

Log-normal Distribution Used for modeling file sizes, effort, or task durations.

📍 Example:

 If defect occurrence follows a Poisson distribution, we can predict how many defects to expect in a week.
  Time to next failure in a system is modeled using exponential distribution in reliability models.

PART 2: Hypothesis Testing

Hypothesis Testing
Hypothesis testing compares two opposite ideas about a group of people or things and uses data from a small part of
that group (a sample) to decide which idea is more likely true. We collect and study the sample data to check if the
claim is correct.

For example, if a company says its website gets 50 visitors each day on average, we use hypothesis testing to look at
past visitor data and see if this claim is true or if the actual number is different.

Defining Hypotheses

 Null Hypothesis (H₀): The starting assumption. For example, "The average visits are 50."

 Alternative Hypothesis (H₁): The opposite, saying there is a difference. For example, "The average visits are
not 50."

Key Terms of Hypothesis Testing

To understand the Hypothesis testing firstly we need to understand the key terms which are given below:

 Significance Level (α): numerical value that decides the acceptable margin of error Usually 0.05 (5%).

 p-value: The chance of seeing the data if the null hypothesis is true. If this is less than α, we say the claim is
probably false.

 Test Statistic: test results of a small group of people that is used to predict.

 Critical Value: The cutoff point to compare with the test statistic.

 Degrees of freedom: A number that depends on the data size and helps find the critical value.

Types of Hypothesis Testing

Hypothesis Testing process

Step 1: State the Hypotheses

This is the foundational step where you define two opposing statements about the population you are studying.

 Null Hypothesis (H₀): This is the default assumption, It's the hypothesis you are trying to disprove or find
evidence against.

o Example: H₀: The average height of men is equal to the average height of women.

 Alternative Hypothesis (H₁ or Hₐ): It's the opposite of the null hypothesis.

o Example: H₁: The average height of men is not equal to the average height of women (two-tailed
test).

o Example: H₁: The average height of men is greater than the average height of women (one-tailed
test).

Step 2: Choose the Significance Level (α)

The significance level, denoted by alpha (α), is the probability of rejecting the null hypothesis when it is actually
true. This is also known as a Type I error. It's a threshold for how much risk you're willing to take of making a wrong
decision.

 Common Choices: The most common values for α are 0.05 (5%), 0.01 (1%), or 0.10 (10%).

 Importance: This value must be chosen before data collection and analysis to maintain objectivity.

Step 3: Select the Appropriate Statistical Test

The choice of statistical test depends on several factors related to your data and hypotheses:

 Type of Data: Is your data continuous (e.g., height, temperature) or categorical (e.g., gender, yes/no
responses)?

 Distribution of Data: Is the data normally distributed?

 Sample Size: Are you working with small or large samples?

 Number of Groups: Are you comparing one group to a known value, two groups to each other, or more than
two groups?

 Relationship between Groups: Are the groups independent or dependent (paired)?

Common Tests:

 t-tests: For comparing means (one-sample, independent samples, paired samples).

 Z-tests: For comparing means when population variance is known and sample size is large.

 Chi-square tests: For analyzing categorical data (e.g., goodness-of-fit, independence).

  ANOVA (Analysis of Variance): For comparing means of three or more groups.

Step 4: Collect Data and Calculate the Test Statistic

 Data Collection: Gather data using appropriate sampling methods that are representative of the population
you're studying.

 Calculate Test Statistic: Based on your chosen statistical test and your collected data, compute the test
statistic. This value quantifies how much your sample results deviate from what would be expected if the
null hypothesis were true.

Step 5: Determine Critical Region

 Critical Region Method:

o Critical Value: This is a threshold value that defines the "rejection region." If your calculated test
statistic falls into this region, it's considered extreme enough to reject the null hypothesis.

Step 6: Interpret the Results and Draw a Conclusion

 State: Clearly state whether you rejected or failed to reject the null hypothesis.

 Contextualize: Explain what this means in terms of your specific problem or research question.

 Limitations: Acknowledge any limitations of your study or data.

✅ Topic: Classical Data Analysis Techniques

📌 Definition

Classical data analysis techniques involve traditional statistical methods used to summarize, interpret, and draw
conclusions from software measurement data. These techniques help identify patterns, understand process behavior,
and support data-driven decisions in software engineering.

🧰 Common Classical Data Analysis Techniques

Technique Description Example in Software Engineering

Summarizes the central tendency and spread Mean defect count, median resolution time,
Descriptive Statistics
of data. standard deviation of LOC

Frequency
Shows how often each value appears. Number of modules with 0, 1, 2, … defects
Distribution

Line charts for trends, bar charts for module-

Data Visualization Uses charts to visually interpret data.
wise defects

Measures the strength of relationship between

Correlation Analysis Correlation between LOC and number of bugs
two variables (−1 to +1).

Predicts the value of a variable based on

Regression Analysis Predicting testing effort based on project size
others.

Trend Analysis Identifies patterns over time. Defect discovery trend across sprints

Monitor process stability over time using Track whether defect injection rate is under
Control Charts
statistical limits. control
Technique Description Example in Software Engineering

Finds abnormal data points that differ Sudden spike in resolution time for a
Outlier Detection
significantly from others. particular release

Pareto Analysis Identifies the few key factors that cause most
80% of defects come from 20% of modules
(80/20 Rule) of the problems.

🎯 Why Use Classical Techniques?

 Easy to implement and understand

 Require less computational power

 Ideal for small to medium datasets

 Provide baseline understanding before using advanced modeling (e.g., machine learning)

⚠️Limitations

Limitation Example

Assume normal distributions Many real-world software data is skewed

Sensitive to outliers Mean may not reflect true central tendency

Cannot handle complex patterns Can miss interactions between multiple variables

Data Analysis Techniques

1. Descriptive Statistics
🔹 What it does:

Descriptive statistics are used to summarize and describe the main features of a dataset. They help in understanding
the central tendency, dispersion, and distribution of software metrics like defects, effort, code size, etc.

🔹 Key Metrics:

 Mean (average)

 Median (middle value)

 Mode (most frequent value)

 Range (max − min)

 Standard Deviation (variability)

📌 Example:

Imagine you're analyzing the number of defects found in 5 modules:

  Mean = (5+3+7+5+10) / 5 = 6 bugs

 Median = middle value = 5

 Mode = most frequent value = 5

 Range = 10 − 3 = 7

 Standard deviation ≈ 2.45 (shows moderate spread)

➡ Use: Tells the QA manager what the typical defect count is and how much variation exists.

2. Frequency Distribution
🔹 What it does:

A frequency distribution shows how often each value (or range of values) appears in a dataset.

Goal  organize data, categorize data, helps to spot patterns

📌 Example:

Bug Severity Frequency:

Severity Frequency

Critical 4

High 8

Medium 15

Low 10

➡ Use: The team can focus more on High and Critical bugs first.

3. Trend Analysis
🔹 What it does:

Trend analysis identifies changes in measurement over time. It is commonly used in agile, DevOps, and QA
processes.

Goalmonitor performance, progress, quality over periods of time.

📌 Example:

Bug count in successive releases:

Sprint Bugs Found

1 12

2 10
Sprint Bugs Found

3 8

4 6

5 4

➡ Observation: decreasing bugs → good progress.

4. Correlation Analysis
Correlation analysis checks how strongly two variables are related. It produces a value between -1 and +1:

 +1 → strong positive correlation

 0 → no correlation

 −1 → strong negative correlation

Goal used to identify cause-effect patterns or predict future behavior.

📌 Example: Suppose you have data on lines of code (LOC) and defects:

Module LOC (x) Defects (y)

A 200 5

B 400 9

C 600 14

 Correlation coefficient (r) = +0.98 → strong positive correlation btw LOC & defects.

➡ Use: Bigger modules tend to have more defects.

5. Pareto Analysis (80/20 Rule)

🔹 What it does:

Based on the Pareto Principle: 80% of the effects come from 20% of the causes. In software, this often means a few
modules cause most of the defects.

📌 Example: Bug distribution by module:

Module Bugs

A 30

B 20

C 10

D 5

E 2
Total bugs = 67
Top two modules (A + B) = 50 bugs ≈ 75% of all bugs

➡ Use: Focus testing/review efforts on Modules A and B.

6. Outlier Detection
Defn data points significantly different from the other.

Indicate  special causes, errors, critical anomalies.

📌 Example:

Time taken (in hours) to fix defects: 3, 4, 4, 5, 3, 4, 50

➡ "50" is an outlier, suggesting an unusually hard-to-fix bug.

Might be a critical defect or indicate a flawed process.

1. Size Properties of Software Size & Code Size

Definition

Software size properties refer to the various dimensions used to measure how large or complex a software system is
across its lifecycle—from requirements to code.

1. Lines of Code (LOC):

Lines of code measure the number of lines in the source code of a software program. It's one of the most widely used
metrics for measuring software size. However, it can be influenced by factors like coding style and programming
language, making it less consistent across different projects.

2. Function Points (FP):

Function points measure the size of software based on its functionalrequirements. They quantify the functionality
provided by the software in terms of inputs, outputs, inquiries, internal logical files, and external interface files.
Function points are language-independent and provide a more abstract measure of software size compared to LOC.

3. Object Points (OP):

Object points are similar to function points but focus on object-orientedsoftware. They measure the size of software
based on the number and complexity of classes, methods, and other objects in the software design. Object points
provide a more detailed measure of size for object-oriented systems.

4. Source Lines of Code (SLOC):

Software Measurements Metrics And Modelling 52 Source lines of code measure the number of lines in the source
code excluding comments and blank lines. It's a more refined version of LOC that excludes non-executable lines,
providing a more accurate measure of code size.

5. Physical Lines of Code (PLOC):

Physical lines of code measure the number of lines in the source code including comments and blank lines. While less
commonly used for measuring software size, PLOC provides insight into the overall size of the source code, including
documentation and comments.

6. Executable Statements:
Executable statements measure the number of statements in the source code that are executed during program
execution. It provides a measure of the complexity and functionality of the software, focusing on the logic and
control flow of the program.

7. Halstead Metrics:

Halstead metrics quantify software size based on the number of distinct operators and operands in the source code.
They include measures such as program length, program vocabulary, volume, difficulty, and effort. Halstead metrics
provide insights into the complexity and effort required to develop and maintain the software.

8. Cyclomatic Complexity:

Cyclomatic complexity measures the complexity of a software program based on the number of linearly independent
paths through its control flow graph. It provides a measure of the software's structural complexity, indicating the
number of possible execution paths and potential points of failure.

9. Information Content:

Information content measures the amount of information encoded in the software, such as the number of unique
identifiers, data structures, or algorithms. It provides a measure of the richness and complexity of the software's
design and implementation.

10. Component Count:

Component count measures the number of individual components or modules in the software, such as classes,
functions, or modules. It

3. Applications

 Project planning and scheduling

 Budgeting and cost estimation

 Productivity and quality metrics

 Performance benchmarking

4. Advantages

 Estimation, analysis of softwares

 Supports better resource allocation

 Better risk assessment

 Assists in scope management

5. Example / Limitation

A system with high documentation size but low code size may indicate poor automation or over-documentation. Size
properties alone can't always represent complexity or effort accurately.

3. Design Size
1. Definition

Quantitative measurement of the scope, scale, and complexity of a software system's design. It's a critical metric
because it provides insights into the effort, cost, quality, and maintainability of the software even before the coding
phase begins.

Why is Design Size Important?

 Early Estimation: early and accurate estimations of development effort, cost, and schedule.
  Quality Assurance: By measuring design size, potential design flaws (e.g., excessive complexity, high
coupling, low cohesion) can be identified early, leading to improved software quality and reduced defects.

 Progress Tracking: It helps in tracking the progress of the design phase and provides a basis for comparison
between different design alternatives.

 Benchmarking: Design size metrics enable benchmarking against industry standards or past projects, aiding
in process improvement.

 Risk Management: Identifying large or complex design elements can highlight potential risks that need to be
addressed.

How is Design Size Measured?

1. Structural Metrics: focus on the structural properties of the design, such as:

o Number of Classes/Modules/Components: count of the primary building blocks of the system. More
classes usually indicate a larger design.

o Depth of Inheritance Tree (DIT): high DIT can indicate complexity and potential issues with
understanding and maintenance.

o Number of Attributes per Class: Measures the number of properties within a class.

o Number of Operations per Class: Measures the number of methods/functions within a class.

o Fan-in/Fan-out:

 Fan-in: The number of modules that call a given module. High fan-in can indicate high reuse
but also a critical component whose changes could impact many others.

 Fan-out: The number of modules that a given module calls. High fan-out can suggest a
complex module with many responsibilities.

2. Complexity Metrics: measures the complexity of the design:

o Coupling: Measures the degree of interdependence between modules or classes. Lower coupling is
generally desired as it indicates more independent and reusable components. Metrics like CBO
(Coupling Between Objects) count the number of other classes a class is coupled to.

o Cohesion: Measures how well the elements within a module belong together. Higher cohesion is
desired as it indicates a module with a clear, single responsibility. Metrics like LCOM (Lack of
Cohesion in Methods) assess how methods within a class are related to its attributes.

o Cyclomatic Complexity: While often applied to code, the underlying logic and control flow can be
analyzed at the design level, especially with detailed design models. It measures the number of
linearly independent paths through a program's source code.

3. Function-Oriented Metrics (Function Points - FP):

o Function Point Analysis  estimate software size based on the functionality delivered to the user,
rather than lines of code.

 Inputs: Data entering the system.

 Outputs: Data exiting the system.

 Inquiries: inputs that result in data retrieval.

 Internal Logical Files: User-identifiable logical data groups maintained within the system.

 External Interface Files: User-identifiable logical data groups accessed by the system but
maintained by another system.
 4. Object-Oriented Design Metrics (Chidamber & Kemerer metrics suite): This suite is specifically designed for
object-oriented systems and includes:

o Weighted Methods per Class : Sum of the complexity of all methods in a class.

o Depth of Inheritance Tree

o Number of Children : Number of immediate subclasses of a class.

o Coupling Between Objects

o Response for a Class: Number of methods that can be invoked in response to a message to an object
of the class.

o Lack of Cohesion in Methods

3. Applications

 Software evaluation  budget, timeline, resources reqd, decision making

 Effort estimation and developer assignment before starting dev process

 Complexity and risk analysis

 Early detection of scalability and integration issues

4. Advantages

 Language and implementation independent

 Decision making

 Supports parallel development through component breakdown

5. Example / Limitation

Two systems might have the same number of classes, but different interaction complexity. Design size alone may not
capture performance bottlenecks or external dependencies.

4. Requirements Analysis and Specification Size

1. Definition

It involves understanding stakeholder needs, identifying system functionalities, Use cases, and clarifying
constraints. The goal is to produce a clear, complete, consistent, and unambiguous set of requirements that serve
as the foundation for design and development.

This refers to the amount and complexity of user and system requirements collected and documented during the
requirements phase.

2. Key Characteristics

 Number of Functional  This involves simply counting each distinct functional requirement. For example:
"The system shall allow users to log in," "The system shall display product details."

 Non-Functional Requirements performance, security, reliability, scalability, maintainability requirements.

 Number of use cases Counting the number of use cases defined for the system,

 user stories user stories e.g., "As a customer, I want to search for products by category" are a direct
measure of functional scope

 Length of the SRS document

  Traceability links with design and test cases

3. Applications

 Initial effort

 Resource allocation

 budget estimation

 Test case development planning

 Scope management and version control

 Communication with stakeholders

4. Advantages

 Early Estimation: Provides input for estimating project effort, cost, and schedule. The size of the
requirements is a primary driver of the overall software development effort.

 Progress Tracking: Enables tracking the completion of the requirements phase and identifying potential
delays.
 Quality Assurance: For instance, an unusually high number of requirements for a simple system might
indicate over-specification or "gold-plating."
 Risk Identification: Large requirements sets can be identified as high-risk areas, requiring more careful
management.
 Benchmarking: Allows comparison of requirements size across different projects to understand patterns and
improve estimation models.

5. Functional Size Measures and Estimators

Functional Size Measures
Several methods have been developed to measure functional size. The most prominent ones are ISO-standardized:

1. Function Point Analysis (FPA):

Core Idea: FPA counts and weights five types of "user functions" based on their complexity (low, average, high):

 External Inputs (EIs): Data or control information entering the system from outside its boundary (e.g., a data
entry screen, a file import)

 External Outputs (EOs): Data or control information leaving the system to outside its boundary (e.g., reports,
error messages).
 External Inquiries (EQs): Interactive requests that result in data retrieval from internal logical files (e.g., a
search function).
 Internal Logical Files (ILFs): User-identifiable logical data groups maintained within the system's boundary
(e.g., a customer database table).
 External Interface Files (EIFs): User-identifiable logical data groups accessed by the system but maintained by
another system (e.g., a shared corporate database).

Every components is counted and assigned a complexity rating (simple, average, complex). These weighted counts
are summed to get an "Unadjusted Function Point Count." This count is then adjusted by a "Value Adjustment
Factor" (VAF) based on 14 General System Characteristics (GSCs) like data communication, distributed processing,
performance, etc., resulting in the final Function Point (FP) count
2. COSMIC (Common Software Measurement International Consortium)

Core Idea: COSMIC measures functional size by identifying and counting "data movements" across the software
boundary. It defines a "functional process" as a unique set of processes triggered by a functional user and performing
a single purpose.

Four Data Movement Types:

 Entry (E): A data group moved from a functional user (human, hardware, or another software) into the
functional process.

 Exit (X): A data group moved from the functional process to a functional user.

 Read (R): A data group moved from persistent storage within the system into the functional process.

 Write (W): A data group moved from the functional process to persistent storage within the system.

Process: The functional size is simply the sum of all identified data movements (each data movement counts as 1
COSMIC Function Point - CFP). There is no complexity adjustments like in FPA

Strengths: More objective and less subjective than FPA, better suited for a wider range of software types (especially
real-time and embedded), simpler counting rules.

Limitations: Less historical data available compared to FPA, still gaining widespread adoption.

Functional Size Estimators

Functional size measures, once calculated, serve as the primary input for functional size estimators. These
estimators are models or techniques that translate the measured functional size into other project attributes, most
commonly effort (person-hours/months) or cost.

Algorithmic Cost Models (e.g., COCOMO):

 Concept: These models use mathematical formulas to predict effort, schedule, and cost. Functional size (e.g.,
Function Points, COSMIC FPs) is often a key input parameter.

Example (Simplified COCOMO II):

o Effort = A * (Size)^B * Product Factors

o Where A and B are constants derived from historical data, Size is in functional size units (e.g., FPs),
and Product Factors are multipliers for aspects like required reliability, development flexibility, team
experience, etc.

How they work: Historical data from past projects (their measured functional size and actual effort) are used to
calibrate the model's parameters. When a new project's functional size is known, the model can estimate its likely
effort.

Productivity Rates:
 Concept: This is a simpler approach where a historical average of "functional size units delivered per unit of
effort" (e.g., Function Points per person-month, COSMIC FPs per person-hour) is used.

 Calculation: Estimated Effort = Functional Size / Average Productivity Rate

 Strengths: Easy to understand and apply.

 Limitations: Highly dependent on the stability and relevance of historical data. Assumes that future projects
will have similar characteristics and environmental factors as past ones. Productivity can vary significantly
based on team skill, technology, domain, etc.

Analogy-Based Estimation:
  Concept: This method involves finding one or more past projects that are similar in functional size and
characteristics to the current project. The effort/cost of those analogous projects is then used as a basis for
estimating the new one.

 Role of Functional Size: Functional size provides an objective basis for identifying "similar" projects. For
instance, if a new system is estimated to be 500 FPs, you'd look for past projects around 500 FPs in similar
domains.

 Strengths: Intuitive, leverages real-world experience.

 Limitations: Relies heavily on the availability of good historical data and the ability to accurately identify
truly analogous projects.

Expert Judgment / Delphi Method:

 Concept: While not strictly a formula, expert judgment often implicitly uses functional size. Experienced estimators
might mentally map the functional scope to past experiences and provide an estimate. The Delphi method involves
multiple experts providing estimates anonymously, iteratively refining them until a consensus is reached.

6. Applications of Size Measures

1. Key Applications

 Effort Estimation – Assign correct resources and time

 Resource allocation

 Cost Estimation – Predict total expenditure

 Project Planning – Define milestones and resource allocation

 Testing – Estimate number of test cases and testing time

 Productivity Tracking – Measure output against effort

 Benchmarking – Compare systems or vendors

2. Advantages

 Increases planning accuracy

 Improves risk assessment

 Encourages better documentation and control

 Supports data-driven decision-making