SOFTWARE Engineering

Course Code: CSE-1005

MODULE – 4
(Process and Product Metrics)
Agenda

 Product Metrics,
 Metrics for the Requirements Model,
 Metrics for the Design Model,
 Architectural Design Metrics,
 Metrics for Software Quality.
Product Metrics

 Product metrics show how users interact with your product. They’re
derived from measurements and often have a numeric component of
time, ratio, rate, etc.
 Feature usage tracks how a user engages with a given feature, which
can provide insight into what aspects of your product deliver the most
value or critical actions in the customer journey. Tracking whether
users repeatedly return to your product helps you understand
whether your business is growing sustainably.
Metrics vs. KPIs vs. OKRs

 You might often hear the terms “metrics,” “KPIs,” and “OKRs” used interchangeably. While they
are related, each serves a distinct purpose in helping organizations measure success.
 Metrics are quantifiable measures that track specific processes or activities, such as
retention rate or daily active users. Or General measurable data that tracks progress.
 Key performance indicators (KPIs) are metrics tied to strategic business objectives that
help track performance. Imagine your goal is to improve user engagement; your KPIs might
be the number of daily active users and the average session duration per user. Or A critical
metric that tracks success towards a specific goal.
 Objectives and key results (OKRs) comprise a goal-setting framework that combines
qualitative objectives with quantitative results. Companies often use them for short-term,
high-impact goals. If we have the same objective (increase user engagement), our key result
could be “increase daily active users by 20% in the next six months.” or A goal-setting
framework that connects objectives with measurable results.
Why do product metrics matter?
 Product metrics give you information on how to improve your product. You progressively
measure, experiment, and assess to iterate and improve your product. Tracking product metrics
before and after you make changes tells the impact of those changes.
 Simply tracking metrics will not explain the “why” behind results. Dig deeper to understand the
customer behaviors and product experiences impacting your key metrics.
Product metrics can inform product decisions about:
 Pricing
 Pay model
 Feature mix
 Onboarding flows
 User interface
 Ideal customers
 Messaging
Types of product metrics
 Product metrics show how users interact with your product. Your team can use these metrics to
better understand what users find helpful, what keeps them coming back, and the best way to
take them on a successful journey to becoming loyal customers. Tracking product metrics helps
you monitor your business to make informed adjustments and continue to grow it.
 Product metrics can be divided into five main types: acquisition, activation, engagement,
retention, and monetization. The first four represent the general user lifecycle through your
product, whereas monetization can overlap with several stages in the customer lifecycle.

 Acquisition metrics, like the number of new signups and qualified leads, measure when
someone first starts using your product or service. They’re great for understanding what
marketing channels are working best for your company.
 Activation metrics, like activation rate and time to activate, reflect how well you’re moving
users from acquisition to that critical aha moment where they discover why your product is
valuable to them and, in turn, provide value to your business.
 Engagement metrics, like monthly active users and feature usage, measure how (and how
often) users interact with your product. Example interactions include sharing a song or editing
their profile. Users who engage with your product are considered active users. Increasing the
number of daily, weekly, and monthly active users is essential for company growth—but only if you
measure them accurately.
 Retention metrics, like retention rate, free-to-paid conversions, and churn rate, gauge how
many of your users return to your product over a certain period. These are critical metrics for your
company’s growth. It doesn’t matter how fast you fill the top of your funnel if users leak out the
bottom just as fast.
 Monetization metrics, like net revenue retention, monthly recurring revenue, and average
revenue per user, capture how well your business turns engagement into revenue.
 Below is a comprehensive list of
metrics that contribute to
overall product performance.
By examining a few key metrics
from each category, you can
gain a clear understanding of
how your product is performing.
Here’s a list of 15 metrics,
organized by type, that the
Amplitude team recommends
tracking.
Metrics for the Requirements Model

1) Function-based Metrics
2) Metrics for Specification Quality
1) Function-based Metrics

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

 The basic and primary purpose of the functional point analysis is to measure and provide the
software application functional size to the client, customer, and the stakeholder on their request.
Further, it is used to measure the software project development along with its maintenance,
consistently throughout the project irrespective of the tools and the technologies.
Following are the points regarding FPs
 1. FPs of an application is found out by counting the number and types of functions used in
the applications. Various functions used in an application can be put under five types, as
shown in Table:
14 General System
Characteristics (GSCs)
2. FP characterizes the complexity of the software system and hence can be used to depict
the project time and the manpower requirement.
3. The effort required to develop the project depends on what the software does.
4. FP is programming language independent.
5. FP method is used for data processing systems, business systems like information
systems.
6. The five parameters mentioned above are also known as information domain
characteristics.
Based on the FP measure of software many other metrics can be computed:

1.Errors/FP
2.$/FP.
3.Defects/FP
4.Pages of documentation/FP
5.Errors/PM.
6.Productivity = FP/PM (effort is measured in person-months).
7.$/Page of Documentation.

8. LOCs of an application can be estimated from FPs. That is, they are interconvertible. This
process is known as backfiring. For example, 1 FP is equal to about 100 lines of COBOL
code.
2) Metrics for Specification Quality
Metrics for the Design Model

 Metrics measures quantitative assessment that focuses on countable values most

commonly used for comparing and tracking the performance of a system. Metrics are
used in different scenarios like analyzing models, designing models, source code,
testing, and maintenance.

What are Metrics?

Metrics for the design model of the product focus on evaluating various aspects of the
design process and the resulting model.
 These are essential for evaluating the design model’s quality, efficiency,
maintainability, and overall effectiveness.
 Metrics for design modeling allow developers or software engineers to evaluate or
estimate the design quality and include various architecture and component-level
designs.
 Complexity Metrics
 1. Cyclomatic Complexity
Cyclomatic complexity measures the number of independent paths through a
program’s source code. The Cyclomatic complexity is a useful metric to indicate
the complexity of a software system. Without the use of complexity metrics, it is
very difficult and time-consuming to determine complexity in designing products
where risk cost emanates. Even continuous complexity analysis makes it difficult
for the project team and management to solve problems. Measuring Software
complexity leads to improved code quality, increased productivity, meeting
architectural standards, reduced overall cost, increased robustness, etc.
Formula:
Cyclomatic complexity V(G) = E – N + 2
 2. Depth of Inheritance Tree (DIT): It measures the levels in the inheritance
hierarchy for a class or module. A DIT can indicate increased complexity as
changes to the base classes can impact multiple levels of derived classes.
 3. Coupling: This quantifies the number of classes that are coupled to a
particular class. It suggests strong dependencies, which can increase the
complexity and reduce the flexibility of the product.

 4. Weighted Methods per Class (WMC): This calculates the sum of

complexities of methods within a class. It provides an estimate of the overall
complexity of the class based on the size and the complexity of its methods.

 5. Component Dependency Metrics: These are used to analyze the

dependencies between different components within the design. Metrics
such as fan-in and fan-out can indicate the complexity due to tight coupling.

 6. Architectural Complexity: This evaluates the overall complexity of the

architecture itself. High architectural complexity implies increased development
and maintenance efforts.
 Quality Metrics
Quality metrics for the design model focus on evaluating aspects that contribute to
the overall quality, maintainability, and effectiveness of the design. They help to
ensure that the design meets requirements, easy to understand, and is
maintainable. Here are some commonly used quality metrics:

1. Modularity: This measures how well the design can be divided into cohesive
and loosely coupled modules,

2. Complexity: Evaluate the complexity of the design model using metrics

like cyclomatic complexity or the number of classes/ interfaces per package/
module.

3. Abstraction: Assess the level of abstraction in the design, indicating how

well the design captures the essential aspects while hiding the unnecessary
details.

4. Coupling: Measures the degree of interdependence between the modules.

5. Cohesion: This evaluates how well elements within a module belong
together. High cohesion means that the elements within the module are
closely related.

6. Maintainability: Assesses how easily design can be understood, modified, and

extended over time. This includes ease of making changes and code
readability.

7. Compatibility: Measures the compatibility of the design with the

existing systems. This involves assessing the adherence to the standards and
design patterns.

8. Reusability: Measures how easily the components within the design can
be reused in other parts of the system. This may include the number of
reusable components.

9. Testability: Measures how easily the design can be tested to ensure

correctness and reliability. This includes the ease of writing the unit tests
and integration tests.

10. Scalability: Measures how well the design can accommodate growing
Performance Metrics
Performance metrics focus on evaluating how well the design supports the
expected performance characteristics of the software system. These help in
assessing the efficiency, scalability, responsiveness, and resource utilization of the
design. Here are some commonly used performance metrics:

1. Scalability: It measures how well the design model accommodates the

increase in workload. This includes evaluating the ability to handle large
datasets, higher user loads, or increased complexity without significant
degradation in performance.

2. Response Time: The time taken by the design model to respond to a user
request. This metric is important for assessing the responsiveness of the
product.

3. Throughput: Measure of the rate at which the design model can process tasks
within a given time frame. This metric is important for systems handling large
volumes of transactions.
4. Resource Utilization: Evaluation of the resources such as CPU, memory,
and network bandwidth consumed by the design model during the
operation. Efficient resource utilization ensures optimal performance.

5. Latency: The time taken for a request to travel from the source to the
destination and back. Low latency is critical for real-time applications where
timely responses are important.

6. Memory Usage: Involves the memory assessment of the design model as

efficient memory management ensures optimal performance and minimizes
resource contention.

7. Energy Efficiency: This involves energy assessment of the design model.

This is important for mobile devices.

8. Maintainability: This relates to how easy is to maintain and modify the

design model over time. This includes metrics like code complexity,
modularity, and ease of debugging.
Usability Metrics
Usability metrics for the design model of the product focus on evaluating how
user-friendly and effective is the design in meeting user expectations. It helps to
ensure that the design model supports efficient navigation and overall user
satisfaction. Here are some key usability metrics for the design model of the
product:

1. Efficiency: Evaluates how quickly a user can complete the tasks once they
are familiar with the design model. This includes metrics like task completion
time and number of steps required to complete common actions.

2. Effectiveness: Evaluate the accuracy with which the users can achieve their
goals using the design model. It includes metrics like error rates and task
success rates.

3. Learnability: This measures how easy it is for first-time users to understand

and navigate the design model. This can be assessed through the time taken
to complete basic tasks and ease of understanding navigation pathways.
4. Satisfaction: Measures user satisfaction of the design model. This can be
assessed through user feedback, user surveys, and qualitative assessment of
user experiences.

5. Visual Design Clarity: Evaluate the clarity of visual elements within the
design model. This involves assessing the layout, iconography, and color
scheme.

6. Accessibility: Measures the extent to which the design model is accessible

to users with special needs. This involves assessing compliance with
accessibility standards (e.g., WCAG), support for assistive technologies, and
ease of use for users with impairments.

7. Navigation: Evaluate the clarity and organization of the design model’s

navigation structure. This includes assessing the ease of finding information
and consistency in navigation.

8. Task Complexity: Measures the complexity of tasks performed using the

design model.
Cost Metrics
Cost metrics for the design model of the product are important for evaluating the financial
implications associated with developing and maintaining the product. This helps
stakeholders understand and manage costs effectively throughout the product lifecycle.
Here are key cost metrics relevant to the design model:

1. Development Cost: Measures the total expenses incurred during the design phase.
This includes salaries of designers, software tools and licenses, and other development
expenses.

2. Equipment Costs: This includes the costs associated with specialized tools,
equipment, and software used in the design process.

3. Testing Costs: Measures the expenses related to building prototypes, conducting

testing, and validating the design model. This includes material costs and labor costs
for testing.

4. Maintenance Costs: Measures the ongoing costs to maintain and support the design
model. This includes costs for updates, bug fixes, and user support.

5. Training Costs: Measures the expenses related to training personnel on effectively

using the design model. This includes training sessions and external training services.
Architectural Design Metrics

 In designing a product, it is very important to have efficient management

of complexity. Complexity itself means very difficult to understand. We
know that systems are generally complex as they have many
interconnected components that make them difficult to understand. Glass
and Card are two scientists who have suggested three design complexity
measures. These are given below :
1. Structural Complexity
 Structural complexity depends upon fan-out for modules. It can be defined
as :
S(k) = f2 out(k)
Where
fout represents fanout for module k (fan-out means several modules
that are subordinating module k).
SOFTWARE Engineering

Course Code: CSE-1005

MODULE – 5
(Managing Software Projects)
COCOMO Model
• COCOMO Model
• Types of COCOMO
Model
 Software Project Planning
The Constructive Cost Model (COCOMO)
Constructive Cost model
(COCOMO)

Basic Intermediate Detailed

Model proposed by
B. W.
Boehm’s
through his
Software Project Planning

COCOMO applied
to

Semidetach
Organi ed mode Embedde
c d
mode mode
 Software Project Planning
Mode Project size Nature of Project Innovation Deadline of Development
the project Environment

Organic Typically Small size project, Little Not tight Familiar & In
experienced developers house
2-50 KLOC
in the familiar
environment. For example,
pay roll, inventory projects
etc.

Semi Typically Medium size project, Medium Medium Medium

detache Medium size team,
50-300 KLOC
d Average previous
experience on similar
project. For example:
Utility systems like
compilers, database
systems, editors etc.

Embedde Typically Large project, Real Significant Tight Complex

d time systems, Complex Hardwar
over 300 interfaces, Very little e/
previous experience. For custome
KLOC
example: ATMs, Air Traffic r
The comparison
Control etc. of three COCOMO modes Interface
s
required
 Software Project Planning
Basic Model

Basic COCOMO model takes the

form
bb
E  ab (KLOC)
db
D  cb (E)
where E is effort applied in Person-Months, and D is the
development time in
months. The coefficients ab, bb, cb and db are given in table.
 Software Project Planning

Software ab bb cb db
Project

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Basic COCOMO coefficients

 Software Project Planning
When effort and development time are known, the average staff size
to complete the project may be calculated as:

Average staff E
size (SS)  D
Persons
When project size is known, the productivity level may be
calculated as:

Productivi KLOC
ty (P)  E KLOC / PM
 Software Project Planning
Example: 4.5

Suppose that a project was estimated to be 400

KLOC. Calculate the effort and development time
for each of the three modes i.e., organic,
semidetached and embedded.
 Software Project Planning
Solution

The basic COCOMO equation take the

form:
E  ab (KLOC) bb
db
D  cb (KLOC)
Estimated size of the project = 400
KLOC

(i) Organic mode

E = 2.4(400)1.05 = 1295.31
PM
D = 2.5(1295.31)0.38 = 38.07
PM
 Software Project Planning
(ii) Semidetached mode

E = 3.0(400)1.12 = 2462.79
PM
D = 2.5(2462.79)0.35 = 38.45
PM
(iii) Embedded mode

E = 3.6(400)1.20 = 4772.81
PM
D = 2.5(4772.8)0.32 = 38
PM
 Software Project Planning
Example: 4.6

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

team has average experience on similar type of projects. The project
schedule is not very tight. Calculate the effort, development time,
average staff size and productivity of the project.
 Software Project Planning
Solution

The semi-detached mode is the most appropriate mode; keeping in

view the size,
schedule and experience of the development team.

Henc E = 3.0(200)1.12 = 1133.12

e PM
D = 2.5(1133.12)0.35 = 29.3
PM

Average staff E
size (SS)  D
Persons
1133.12
 29.3  38.67Persons
 Software Project Planning

Productivi KLOC  0.1765 KLOC /

ty  E 1133.12 PM
200

P  176 LOC /
PM
 Software Project
Planning
Intermediate Model
Cost drivers
(i) Product Attributes
 Required s/w reliability

 Size of application database

 Complexity of the product

(ii) Hardware Attributes

 Run time performance

constraints

 Memory constraints

 Virtual machine volatility

 Turnaround time
 Software Project Planning
(iii Personal Attributes
)
 Analyst capability

 Programmer capability

 Application experience

 Virtual m/c experience

Programming language

(iv experience Project Attributes

)
 Modern programming
practices
 Use of software tools
 Required development
Schedule
 Software Project
Planning
Multipliers of different cost
drivers
Cost Drivers RATINGS
Very low Low Nominal High Very Extra
high high
Product Attributes

RELY 0.75 0.88 1.00 1.15 1.40 --

DATA -- 0.94 1.00 1.08 1.16 --

CPLX 0.70 0.85 1.00 1.15 1.30 1.65

Computer Attributes

TIME -- -- 1.00 1.11 1.30 1.66

STOR -- -- 1.00 1.06 1.21 1.56

VIRT -- 0.87 1.00 1.15 1.30 --

TURN -- 0.87 1.00 1.07 1.15 --

 Software Project
Cost Drivers Planning RATINGS
Very low Low Nominal High Very Extra
high high
Personnel Attributes

ACAP 1.00 0.86 0.71

1.46 1.19 --

AEXP --
1.29 1.13 1.00 0.91 0.82
PCAP 0.86 0.70 --
1.42 1.17 1.00
VEXP --
1.21 1.10 1.00 0.90 --
LEXP 1.14 1.07 1.00 0.95 -- --
Project Attributes

MODP --
1.24 1.10 1.00 0.91 0.82
TOOL 1.24 1.10 1.00 0.91 0.83 --
SCED
1.23 1.08 1.00 1.04 1.10 --

Table 5: Multiplier values for effort

calculations
 Software Project Planning
Intermediate COCOMO
equations
bi
E  ai *
(KLOC)
c (E) d i EAF
i
D
Project ai bi ci di

Organic 3.2 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

Table 6: Coefficients for intermediate

COCOMO
Example Problem:
For a given Semidetached project was estimated with a size of 300 KLOC. Calculate the
Efforts, Schedule Time for development by Considering developer having Very High
Application Experience and Very low Experience in programming?

b
E=a*(KLOC) * (EAF)

Where EAF = 0.82*1.14 =0.9348

1.12
E = 3.0*(300) *(0.9348) = 1668.07
0.35
D = 2.5*(1668.07) = 33.55
 The Management Spectrum

The
The 4 P’s of project management Software to
The most be built
important
of a
element
successful
People project.

Product

The set of All work

framewor The required to
k make a product
activities
Managemen
t Spectrum

Proces Project
s
 The Management Spectrum
1.People
• This is virtually any type of stakeholder who is involved in the project. The most
important element of a successful project.

• People of a project include from manager to developer, from client to End user.
however principally people of a project highlight the developers.

People Capability Maturity Model (People-CMM),

• Staffing, • Competency analysis and

• Communication and coordination, development,
• Work environment, • Career development,
• Performance management, • Workgroup development,
• Training, • Team/culture development,
• Compensation, • and others..,
 The Management Spectrum
1. People
Cont’d People

The Team The Software

Stakeholders Leaders Team
• Senior managers
• Project
(technical)
managers
• Practitioners
• Customers
• End users
 The Management Spectrum
1.People Cont’d
Stakeholders
• Senior managers who define the business issues that often have a significant
influence on the project.

• Project (technical) managers who must plan, motivate, organize, and control the
practitioners who do software work.

• Practitioners who deliver the technical skills that are necessary to engineer a
product or application.

• Customers who specify the requirements for the software to be

engineered and other
stakeholders who have a peripheral interest in the outcome.

• End-users who interact with the software once it is released for production use.
 The Management Spectrum
1. People
Cont’d
Team
• A Software Engineering Team Leader is responsible for their
Leader
team’s execution, the quality they produce, the speed and cadence
at which they produce, but most importantly, they are responsible
for the team’s culture, environment, and overall growth of the people
on it.
The MOI Model

Motivation. The ability to encourage (by “push or pull”) technical people to produce to
their best
ability.
Organization. The ability to mold existing processes (or invent new ones) that will enable
the initial concept to be translated into a final product.
Ideas or innovation. The ability to encourage people to create and feel creative even when
they must work within bounds established for a particular software product or application.
 The Management Spectrum
1.People Cont’d
The Software Team
The seven project factors should be
considered when planning the structure of
software engineering teams
• The difficulty of the problem to be solved

• The time that the team will stay together (team lifetime)

• The degree to which the problem can be modularized

• The required quality and reliability of the system to be built

• The rigidity of the delivery date

• The degree of sociability (communication) required for the project

 The Management Spectrum
2. The Product
• The software product is software that has been developed and maintained for the benefit of
a user base and often to satisfy a need in the market.

3. Software Scope
The first software project management activity is the determination of software
scope.
Scope is defined by answering the following questions

• Context. How does the software to be built fit into a larger system, product, or business
context, and
what constraints are imposed as a result of the context?

• Information objectives. What customer-visible data objects are produced as output

from the software? What data objects are required for input?
• Function and performance. What function does the software perform to transform input
 The Management Spectrum
2. The Product Cont’d

2. Problem Decomposition
• Problem decomposition, sometimes called partitioning or problem elaboration, is an
activity that sits at the core of software requirements analysis.
• It involves breaking down a complexproblem or system into smaller parts that are
more manageable and easier to understand.

• The smaller parts can then be examined and solved, or

designed individually, as they are simpler to work with.

The decomposition process continues until all functions or problem classes have been
defined.
If a problem is not decomposed, it is much harder to
solve
 The Management Spectrum
3. The Process
• The framework activities that characterize the software process are
applicable to all
software projects.

• The problem is to select the process model that is appropriate for the software
to be
engineered.

The team
(1)The must decide
customers which
who have process
requested modeland
the product is the
most appropriate
people forwork,
who will do the

(2)The characteristics of the product itself, and

(3)The project environment in which the software team works.

 The Management Spectrum
3. The Process Cont’d
Melding the Product and the
Process The generic framework
activities:
• Communication,

• Planning,

• Modeling,

• Construction,

• and Deployment
• Each major product function is listed in
the left-hand column. Framework
activities are listed in the top row.
 The Management Spectrum
4. The Project
• A project is a well-defined task, which is a collection of several operations done in order to
achieve a goal (for example, software development and delivery).

Projects get into trouble when (John Reel,1999)

1. Software people don’t understand their6. Deadlines are unrealistic.

customer’s needs. 7. Users are resistant.
2. The product scope is poorly defined. 8. Sponsorship is lost [or was never properly
obtained].
3. Changes are managed poorly.
9.The project team lacks people with
4. The chosen technology changes. appropriate
5. Business needs change [or are ill-defined]. skills.
10. Managers [and practitioners] avoid best
practices and lessons learned.
 The Management Spectrum
4. The Project Cont’d
Common-sense Approach To Projects
• Start on the right foot. This is accomplished by working hard (very hard) to understand the problem
that is to be solved and then setting realistic objectives and expectations.

• Maintain momentum. The project manager must provide incentives to keep turnover of personnel
to an absolute minimum, the team should emphasize quality in every task it performs, and senior
management should do everything possible to stay out of the team’s way.

• Track progress. For a software project, progress is tracked as work products (e.g., models, source
code, sets of test cases) are produced and approved (using formal technical reviews) as part of a quality
assurance activity.

• Make smart decisions. In essence, the decisions of the project manager and the software team should
be to “keep
it simple.”

• Conduct a postmortem analysis. Establish a consistent mechanism for extracting lessons learned for each
project.
 The Management Spectrum
To Get to the Essence of a Project

• Why is the system being developed?

• What will be done?

• When will it be accomplished?

• Who is responsible?

• Where are they organizationally located?

• How will the job be done technically and managerially?

• How much of each resource (e.g., people, software, tools, database)

will be
needed?
 The Management Spectrum
Critical Practices
• Formal risk management

• Empirical cost and schedule

estimation
• Metrics-based project management

• Earned value tracking

• Defect tracking against quality

targets
• People aware project management