Project Management &

Metrics

Ms. Gagandeep Kaur

Assistant Professor
Department of Computer Science and Engineering
Chitkara University, Punjab
1
Management Spectrum

• In software engineering, the management spectrum describes the

management of a software project.
• The management of a software project starts from requirement analysis
and finishes based on the nature of the product; it may or may not end
because almost all software products face changes and require support.
• The management spectrum focuses on the four P’s:

1. People 3. Process
2. Product 4. Project
• Here, the manager of the project has to control all these P’s to have a
smooth flow in the progress of the project and to reach the goal.

2
First P - People

• The “people factor” is so important that the Software Engineering Institute

has developed a People Capability Maturity Model (People-CMM), in
recognition of the fact that
“Every organization needs to continually improve its ability to
attract, develop, motivate, organize, and retain the workforce needed to
accomplish its strategic business objectives.”

• Organizations that achieve high levels of People-CMM maturity have a

higher likelihood of implementing effective software project
management practices.

3
First P - People

• Depending on their roles and responsibilities, people involved in a

software project can be categorized into the following main categories or
stakeholders:
✔ Senior manager
✔ Project manager
✔ Software Engineer
✔ Customer
✔ End user

4
People - Stakeholders

• Senior managers who define the business issues that often have
significant influence on the project.
• Project (technical) managers who must plan, motivate, organize, and
control the practitioners who do software work.
• Practitioners/Software Engineers 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.
5
People – Team Leaders

• The MOI model of leadership

✔ 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 when they work within bounds established for a particular
software product or application.

6
People – Software Team

• Seven project factors that should be considered when planning the

structure of software engineering teams:
– Difficulty of the problem to be solved
– “Size” of the resultant program(s) in lines of code or function points
– Time that the team will stay together (team lifetime)
– Degree to which the problem can be modularized
– Required quality and reliability of the system to be built
– Rigidity of the delivery date
– Degree of sociability (communication) required for the project

7
Second P - Product

• Customers and software developers must meet:

– To define objectives and scope of the project.

– To consider alternative solutions and to select the best possible approach.

– To identify technical and management constraints.

• Objectives identify the overall goals for the product (from the customers’ point of
view) without considering how these goals will be achieved.
• Scope identifies the primary data, functions and behaviors that characterize the
product, and more important, attempts to bound these characteristics in a
quantitative manner.
• If scope and objectives are not defined, then it will be impossible:
– To define a reasonable and accurate estimate of cost.
– To assess possible risks and to define a manageable project schedule.

8
Product/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 data into output? Are any special performance
characteristics to be addressed?
9
Problem Decomposition

• Sometimes called partitioning or problem elaboration.

• Once scope is defined …
– It is decomposed into constituent functions
– It is decomposed into user-visible data objects

or
– It is decomposed into a set of problem classes
• Decomposition process continues until all functions or problem classes
have been defined

10
Third P - Process

• The project manager must decide which process model is appropriate

for:
– The customers who have requested the product and the people who
will do the work
– The characteristics of the product itself
– The project environment in which the software team works.
• When a process model has been selected, define a preliminary project
plan on the set of common process framework activities.

11
Third P – Process (contd.)

• Once a process framework has been established

– Consider project characteristics
– Determine the degree of rigor required
– Define a task set for each software engineering activity
⮚ Task set :
✔ Software engineering tasks
✔ Work products
✔ Quality assurance points
✔ Milestones

12
Fourth P - Project

• For a successful project, we must understand what can go wrong

• Projects get into trouble when …
– Software people don’t understand their customer’s needs.
– The product scope is poorly defined.
– Changes are managed poorly.
– The chosen technology changes.
– Business needs change [or are ill-defined].
– Deadlines are unrealistic and Users are resistant.
– Sponsorship is lost [or was never properly obtained].
– The project team lacks people with appropriate skills.
– Managers [and practitioners] avoid best practices and lessons learned.

• Manager acts to avoid these problems by using five-part commonsense

approach to software projects
13
Common Sense Approaches to Projects

1. 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.

2. 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.

14
Common Sense Approaches to Projects

3. 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.

4. Make smart decisions: In essence, the decisions of the project manager

and the software team should be to “keep it simple.”

5. Conduct a postmortem analysis: Establish a consistent mechanism for

extracting lessons learned for each project.

15
Metrics in Process and
Project Domains

16
Introduction

• Process metrics are collected across all projects and over long periods of
time. Their intent is to provide a set of process indicators that lead to
long-term software process improvement.
• Project metrics enable a software project manager to:

(1) assess the status of an ongoing project,

(2) track potential risks,
(3) uncover problem areas before they go “critical,”
(4) adjust work flow or tasks, and
(5) evaluate the project team’s ability to control quality of software
work products.

17
Process Metrics and Software Process
Improvement (contd.)

Figure1: Determinants for software quality and organizational effectiveness.

19
Process Metrics and Software Process
Improvement (contd.)

• Process sits at the center of a triangle connecting three factors that have a
profound influence on organizational performance and software quality.
• In addition, the process triangle exists within a circle of environmental
conditions that include the:
– development environment (e.g., integrated software tools),
– business conditions (e.g., deadlines, business rules), and
– customer characteristics (e.g., ease of communication and
collaboration)

20
Process Metrics and Software Process
Improvement (contd.)

• Process metrics can be either Public or Private.

• Examples of private metrics include
– defect rates (by individual),
– defect rates (by component), and
– errors found during development
• Public metrics generally assimilate information that originally was private
to individuals and teams.
• Project-level defect rates (absolutely not attributed to an individual),
effort, calendar times, and related data are collected and evaluated in
an attempt to uncover indicators that can improve organizational process
performance.
21
Process Metrics and Software Process
Improvement (contd.)
• Some process metrics are private to the software project team but public to
all team members.
• Examples include:
– defects reported for major software functions (that have been
developed by a number of practitioners),
– errors found during technical reviews, and
– lines of code or function points per component or function.
• Software process metrics can provide significant benefit as an organization
works to improve its overall level of process maturity. However, like all
metrics, these can be misused, creating more problems than they solve.
Hence, “Software Metrics Etiquette” are suggested.
22
Process Metrics and Software Process
Improvement (contd.)
“Software Metrics Etiquette” that is appropriate for both managers and practitioners as
they institute a process metrics program:
– Use common sense and organizational sensitivity when interpreting metrics
data.
– Provide regular feedback to the individuals and teams who collect measures
and metrics.
– Don’t use metrics to appraise individuals.

– Work with practitioners and teams to set clear goals and metrics that will be
used to achieve them.
– Never use metrics to threaten individuals or teams.
– Metrics data that indicate a problem area should not be considered “negative.”
These data are merely an indicator for process improvement.
– Don’t obsess on a single metric to the exclusion of other important metrics.
23
Project Metrics

• Project metrics and the indicators derived from them are used by a project
manager and a software team to adapt project workflow and technical
activities.
• The first application of project metrics on most software projects occurs
during estimation.
• Metrics collected from past projects are used as a basis from which
effort and time estimates are made for current software work.
• As a project proceeds, measures of effort and calendar time expended are
compared to original estimates (and the project schedule).
• The project manager uses this data to monitor and control progress.

24
Project Metrics (contd.)

• As technical work commences, other project metrics begin to have

significance.
• Production rates represented in terms of models created, review hours,
function points, and delivered source lines are measured.
• In addition, errors uncovered during each software engineering task are
tracked.
• As the software evolves from requirements into design, technical metrics
are collected to assess design quality and to provide indicators that will
influence the approach taken to code generation and testing.

25
Project Metrices (contd.)

• The intent of project metrics is twofold.

• First, these metrics are used to minimize the development schedule by
making the adjustments necessary to avoid delays and mitigate potential
problems and risks.
• Second, project metrics are used to assess product quality on an ongoing
basis and, when necessary, modify the technical approach to improve
quality.
• As quality improves, defects are minimized, and as the defect count goes
down, the amount of rework required during the project is also reduced.
• This leads to a reduction in overall project cost.

26
Metrics for Software Quality

27
Measures of Software Quality

1. Correctness:
– Is the degree to which the software performs its required function.
– The most common measure for correctness is defects per KLOC
(thousand line of codes), where a defect is defined as a verified lack
of conformance to requirements.
– When considering the overall quality of a software product, defects are
those problems reported by a user of the program after the program has
been released for general use.
– For quality assessment purposes, defects are counted over a standard
period of time, typically one year.

28
Measures of Software Quality

2. Maintainability: It is the ease with which a program can be

✔ Corrected, if an error is encountered
✔ Adapted, if the environment changes, or
✔ Enhanced, if the customer desires changes in requirements.
• There is no way to measure maintainability directly; therefore, you must
use indirect measures.
• A simple time-oriented metric is mean-time-to-change (MTTC), the time it
takes to analyze the change request, design an appropriate modification,
implement the change, test it, and distribute the change to all users. On
average, programs that are maintainable will have a lower MTTC.

29
Measures of Software Quality

3. Integrity:
• This attribute measures a system’s ability to withstand attacks (both
accidental and intentional) to its security.
• Attacks can be made on all three components of software: programs, data,
and documentation.
• To measure integrity, two additional attributes must be defined: threat and
security.
– Threat is the probability that an attack of a specific type will occur
within a given time.
– Security is the probability that the attack of a specific type will be
repelled.
30
Measures of Software Quality

3. Integrity (contd.):
• The integrity of a system can then be defined as:

• For example, if threat (the probability that an attack will occur) is 0.25 and
security (the likelihood of repelling an attack) is 0.95, the integrity of the
system is 0.9875 (very high).
• If, on the other hand, the threat probability is 0.50 and the likelihood of
repelling an attack is only 0.25, the integrity of the system is 0.625
(unacceptably low).

31
Measures of Software Quality

4. Usability
• If a program is not easy to use, it is often doomed to failure, even if the
functions that it performs are valuable.
• Usability is an attempt to quantify “user friendliness”.

32
Defect Removal Efficiency
• A quality metric that provides benefit at both the project and process level is
defect removal efficiency (DRE).
• In essence, DRE is a measure of the filtering ability of quality assurance
and control actions as they are applied throughout all process framework
activities.
• When considered for a project as a whole, DRE is defined in the following
manner:

• Here, E is the number of errors found before delivery of the software to the
end user and D is the number of defects found after delivery.
• As D increases, DRE decreases (i.e., becomes a smaller and smaller fraction)
• The ideal value of DRE is 1, which means no defects are found after delivery.
33
Product Metrics

34
Measures, Metrics and Indicators

• A measure provides a quantitative indication of the extent, amount,

dimension, capacity, or size of some attribute of a product or process.

• IEEE defines metric as “a quantitative measure of the degree to which a

system, component, or process possesses a given attribute.”

• An indicator is a metric or combination of metrics that provide insight

into the software process, a software project, or the product itself.

• An indicator provides insight that enables the project manager or software

engineers to adjust the process, the project, or the product to make things
better.
35
Measurement Process

A measurement process can be characterized by five activities:

1. Formulation. The derivation of software measures and metrics
appropriate for the representation of the software that is being considered.
2. Collection. The mechanism used to accumulate data required to derive
the formulated metrics.
3. Analysis. The computation of metrics and the application of
mathematical tools.
4. Interpretation. The evaluation of metrics results in an effort to gain
insight into the quality of the representation.
5. Feedback. Recommendations derived from the interpretation of
product metrics transmitted to the software team.
36
Measurement Principles

• The objectives of measurement should be established before data

collection begins.
• Each technical metric should be defined in an unambiguous manner.
• Metrics should be derived based on a theory that is valid for the domain
of application (e.g., metrics for design should draw upon basic design
concepts and principles and attempt to provide an indication of the
presence of an attribute that is deemed desirable).
• Metrics should be tailored to best accommodate specific products and
processes.

37
Goal Oriented Software Measurement

• The Goal/Question/Metric (GQM) Paradigm has been developed as a

technique for identifying meaningful metrics for any part of the software
process.
• GQM emphasizes the need to:

(1) establish an explicit measurement goal that is specific to the process

activity or product characteristic that is to be assessed
(2) define a set of questions that must be answered in order to achieve the
goal, and
(3) identify well-formulated metrics that help to answer these questions.

38
Goal Oriented Software Measurement

• Goal definition template can be used to define each measurement goal. The
template takes the form:
– Analyze {the name of activity or attribute to be measured} for the
purpose of {the overall objective of the analysis} with respect to {the
aspect of the activity or attribute that is considered} from the
viewpoint of {the people who have an interest in the measurement}in
the context of {the environment in which the measurement takes
place}.

39
Attributes of Effective Software Metrics

A set of attributes that should be encompassed by effective software metrics:

• Simple and computable. It should be relatively easy to learn how to derive
the metric, and its computation should not demand inordinate effort or time
• Empirically and intuitively persuasive. The metric should satisfy the
engineer’s intuitive notions about the product attribute under
consideration
• Consistent and objective. The metric should always yield results that are
unambiguous.

40
Attributes of Effective Software Metrics

• Consistent in its use of units and dimensions. The mathematical

computation of the metric should use measures that do not lead to bizarre
combinations of unit.
• Programming language independent. Metrics should be based on the
analysis model, the design model, or the structure of the program itself.
• Effective mechanism for quality feedback. That is, the metric should
provide a software engineer with information that can lead to a higher
quality end product

41
Metrics for Requirement Model

• Technical work in software engineering begins with the creation of the

requirements model.
• It is at this stage that requirements are derived and a foundation for design
is established.
• Therefore, product metrics that provide insight into the quality of the
analysis model are desirable.

42
Metrics for Requirement Model –
Function Point (FP) Metrics

• The function point (FP) metric can be used effectively as a means for measuring the
functionality delivered by a system.
• The FP metric can then be used to
– estimate the cost or effort required to design, code, and test the software;

– predict the number of errors that will be encountered during testing; and

– forecast the number of components and/or the number of projected source

lines in the implemented system.
• Function points are derived using an empirical relationship based on countable
(direct) measures of software’s information domain value and qualitative
assessments of software complexity.

43
Metrics for Requirement Model –
Function Point (FP) Metrics

Information domain values are defined in the following manner:

• Number of external inputs (EIs). Each external input originates
from a user or is transmitted from another application and provides
distinct application-oriented data or control information. Inputs are
often used to update internal logical files (ILFs). Inputs should be
distinguished from inquiries, which are counted separately.
• Number of external outputs (EOs). Each external output is derived
data within the application that provides information to the user. In
this context external output refers to reports, screens, error messages,
etc.
44
Metrics for Requirement Model –
Function Point (FP) Metrics

• Number of external inquiries (EQs). An external inquiry is defined as

an online input that results in the generation of some immediate
software response in the form of an online output (often retrieved from
an ILF).
• Number of internal logical files (ILFs). Each internal logical file is a
logical grouping of data that resides within the application’s
boundary and is maintained via external inputs.
• Number of external interface files (EIFs). Each external interface file
is a logical grouping of data that resides external to the application
but provides information that may be of use to the application.
45
Metrics for Requirement Model –
Function Point (FP) Metrics

Figure 2: SafeHome software data flow model example

✔ Three external inputs (EIs) - password, panic button, and activate/deactivate
✔ Two external inquiries (EQs) - zone inquiry and sensor inquiry.
✔ One internal logical file (ILF) - system configuration file.
✔ Two external outputs (EOs) - messages and sensor status.
✔ Four external interface files (EIFs) - test sensor, zone setting, activate/deactivate,
and alarm alert.

46
Metrics for Requirement Model –
Function Point (FP) Metrics

Figure 3: Computing function points

• To compute function points (FP), the following relationship is used:

• Where count total is the sum of all FP entries obtained from the above table.

47
Metrics for Requirement Model –
Function Point (FP) Metrics

The Fi (i = 1 to 14) are value adjustment factors (VAF) based on responses to the following
questions:
1. Does the system require reliable backup and recovery?
2. Are specialized data communications required to transfer information to or from the
application?
3. Are there distributed processing functions?
4. Is performance critical?
5. Will the system run in an existing, heavily utilized operational environment?
6. Does the system require online data entry?
7. Does the online data entry require the input transaction to be built over multiple screens
or operations?
Each of these questions is
8. Are the ILFs updated online?
answered using a scale that
9. Are the inputs, outputs, files, or inquiries complex? ranges from 0 (not important
10. Is the internal processing complex? or applicable) to 5
(absolutely essential).
11. Is the code designed to be reusable?
12. Are conversion and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the application designed to facilitate change and ease of use by the user?
48
Metrics for Requirement Model –
Function Point (FP) Metrics
Example of Function Point Analysis Computation

Assume a system has the following:

3 External Inputs (EI), 4 External Outputs (EO), 2 External Inquiries (EQ), 5 Internal
Logical Files (ILF), 3 External Interface Files (EIF)

Assign Function Weights

Function Type Low Complexity Average Complexity High Complexity

External Inputs (EI) 3 4 6
External Outputs (EO) 4 5 7
External Inquiries (EQ) 3 4 6
Internal Logical Files
7 10 15
(ILF)
External Interface Files
5 7 10
(EIF)

49
Metrics for Requirement Model –
Function Point (FP) Metrics
Assume all functions have average complexity, so:
• EI: 3×4=12
• EO: 4×5=20
• EQ: 2×4=8
• ILF: 5×10=50
• EIF: 3×7=21
Now, Compute count_total:
count_total = 12+20+8+50+21=111

Adjust for Complexity Factors

There are 14 General System Characteristics (GSC) that impact function points, each rated
from 0 (no influence) to 5 (strong influence). Suppose the total GSC score is 35.

The Value Adjustment Factor (VAF) is calculated as:

VAF=0.65+(0.01×count_total)
VAF=0.65+(0.01×35)=1.00
Compute Adjusted Function Points
FP= count_total × VAF
FP = 111×1.00=111
50
Metrics for Design Model

1. Architectural Design Metrics:

• Architectural design metrics focus on characteristics of the program architecture
with an emphasis on the architectural structure and the effectiveness of modules
or components within the architecture.
• There are three software design complexity measures: structural complexity, data
complexity, and system complexity.
• For hierarchical architectures (e.g., call-and-return architectures), structural
complexity of a module i is defined in the following manner:

where fout(i) is the fan-out of module i , refers to the number of other modules or
components that a specific module or component calls or uses.

51
Metrics for Design Model
1. Architectural Design Metrics (contd.):
• Data complexity provides an indication of the complexity in the internal interface
for a module i and is defined as

where v(i) is the number of input and output variables that are passed to and from
module i
• Finally, system complexity is defined as the sum of structural and data complexity,
specified as

• As each of these complexity values increases, the overall architectural complexity

of the system also increases. This leads to a greater likelihood that integration
and testing effort will also increase.

52
Metrics for Design Model

2. Methods for Object Oriented Design

• There are nine distinct and measurable characteristics of an OO design:
– Size
• Size is defined in terms of four views: population, volume, length, and
functionality
– Complexity
• How classes of an OO design are interrelated to one another
– Coupling
• The physical connections between elements of the OO design
– Sufficiency
• “the degree to which an abstraction possesses the features required of it, or
the degree to which a design component possesses features in its
abstraction, from the point of view of the current application.”
– Completeness
• An indirect implication about the degree to which the abstraction or design
component can be reused

53
Metrics for Design Model

2. Methods for Object Oriented Design (contd.)

– Cohesion
• The degree to which all operations working together to achieve a
single, well-defined purpose
– Primitiveness
• Applied to both operations and classes, the degree to which an
operation is atomic
– Similarity
• The degree to which two or more classes are similar in terms of
their structure, function, behavior, or purpose
– Volatility
• Measures the likelihood that a change will occur

54
Metrics for Testing

1. Halstead Metrics Applied to Testing:

Using the definitions for program volume V and program level PL, Halstead effort e
can be computed as:

The percentage of overall testing effort to be allocated to a module k can be

estimated using the following relationship:

where e(k) is computed for module k and the summation in the denominator is the sum
of Halstead effort across all modules of the system.

66
Metrics for Testing

1. Halstead Metrics Applied to Testing (contd.):

Halstead defines a volume ratio L as the ratio of volume of the most compact form of a
program to the volume of the actual program. In actuality, L must always be less than
1.

67
Practice Questions

1. What are the four P’s of the management spectrum in software engineering?
a) Planning, People, Process, Product
b) People, Process, Product, Project
c) People, Planning, Performance, Process
d) Project, Process, Productivity, People
Answer: b) People, Process, Product, Project

2. What is the main goal of software metrics?

a) To make programming languages easier to learn
b) To improve software quality and process efficiency
c) To increase hardware speed
d) To reduce software costs only
Answer: b) To improve software qual

72
Practice Questions

3. What does DRE (Defect Removal Efficiency) measure?

a) The number of users
b) The speed of the software
c) The ability to remove defects before delivery
d) The cost of software development
Answer: c) The ability to remove defects before delivery

4. What is another name for "Problem Decomposition"?

a) Partitioning
b) Integration
c) Debugging
d) Testing
Answer: a) Partitioning

73
THANKS

74