Software Measurements and types with example

1. INFORMATICS & COMPUTATIONAL SCIENCE PROGRAMME
UNIVERSITY COLLEGE OF SCIENCE
MOHANLAL SUKHADIA UNIVERSITY
(NAAC Accredited A Grade University)
UDAIPUR-313001(INDIA)
YEAR- 2017-18
BCA- V semester

2. SUBMITTED TO : Dr. Pooja Shrimali Mam
SUBMITTED BY : Ankit malvi
TOPIC :
SOFTWARE PROCESS AND
PROJECT METRICS:-
MEASURE,METRICS AND
INDICATOR

3. Contents
1.Measure
2.Metrics
3.Indicator
4.Need of metrics
5.Process and project
metrics
6.Metrics guidelines

4. SOFTWARE ENGINEERING
 Software is more than just a program code. A program is an
executable code, which serves some computational purpose.
Software is considered to be collection of executable
programming code, associated libraries and documentations.
Software, when made for a specific requirement is called software
product.
 Engineering on the other hand, is all about developing products,
using well-defined, scientific principles and methods.

5. SOFTWARE ENGINEERING
 Software engineering is an engineering branch associated with
development of software product using well-defined scientific
principles, methods and procedures. The outcome of software
engineering is an efficient and reliable software product.

8. Measure, Metrics and
Indicators

9. Measure
 Measure is a quantitative indication of the extent,
amount, dimension, or size of some attribute of a
product or process.

10. Metrics
 Metrics: The quantitative measure of the degree to which a
system, component, or process possesses a given attribute.
Relates several measures (e.g. average number of errors
found per person hour)
 Direct Metrics: Immediately measurable attributes (e.g. line
of code, execution speed, defects reported)
 Indirect Metrics: Aspects that are not immediately
quantifiable (e.g. functionality, quantity, reliability)
Example: length of a pipe is a direct measure.
the quality of the pipes can only be measured
indirectly by finding the ratio of the accepted pipes to the
rejected.

11. INDICATORS
 Indicators is a combination of metrics that provides
insight into the software process, project or 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.

12. Conclusion…
 A software engineer collects measures and
develops metrics so that indicators will be
obtained.

13. Why do we measure?
 To characterize
 To evaluate
 To predict
 To improve

14.  To characterize in an effort to gain an understanding “of
processes, products , resources and environment and to
establish baselines for comparisons with future
assessments.
 To evaluate “to determine status with respect to plans”.
 To predict by “gaining understandings of relationships
among processes and products and building models of
these relationships”.
 To improve by “identify[ing] roadblocks, root causes,
inefficiencies and other opportunities for improving
product quality and process performance.

15. NEED OF METRICS
We take metrics for a variety of reasons :-
 to measure the quality of a product
 to assess the productivity of the people building the product
 to assess the benefits (productivity and quality) of new
software tools
 to form a baseline so we can estimate for new tools
 to help justify requests for new tools or additional training

16. Process AND PROJECT METRICS

17. Process METRICS
 Process Metrics:-
Are collected across all projects and over long periods of
time. Their intent is to provide a set of process indicator
that lead to long term software process improvement.
 They are used for making strategic decisions.
 The only way to know how/where to improve any process is
to:-
- measure specific attributes of the project.
- develop a set of meaningful metrics based on these
attributes.
- use the metrics to provide indicators that will lead to a
strategy for improvement.

18. PROCESS METRICS

19. PROCESS METRICS
 Process at the center connecting 3 factors that
have a profound influence on software quality
and organizational performance.
 Process triangle exists within a circle of
environmental conditions that include the
development environment, business conditions
and customer characteristics.

20. PROCESS METRICS
 We measure the effectiveness of a software process by deriving
a set of metrics based on the outcomes of the process.
 Outcomes include
measures of errors uncovered before release of the
software
defects delivered to and reported by end-users
work products delivered (productivity)
human effort expended
calendar time expended
schedule conformance
other measures.

21. PROCESS METRICS
 Some process metrics are private metrics or public metrics.
 Private metrics:
The Private metrics are those metrics which are collected by
individual software professionals. They are mostly used by any
software professional to get an insight regarding how is his
productivity or any other parameter of interests to him.
For example, a test engineer may keep ‘errors found in a week’ as a
private metric. Similarly, for a development engineer, ‘lines of code
written in a week’ could be a private metric of interests to him. Also,
an IT professional may keep ‘Number of new technology studied in
a month’ as a private metric.

22. PROCESS METRICS
 Public metrics:
The public metrics has more meaning on a overall team basis.
The public metrics can be computed depending upon the private
metrics made public by the individual software professional. They
are more concerned with the project team rather than any individual
software professional.
The examples are, ‘Errors found per engineer-month’, ‘Lines of
code written per engineer-month’, etc.

23. SSPI
 A more rigorous approach: Statistical software process improvement
helps an organization to discover where they are strong and where they
are weak.
statistical software process improvement (SSPI):
1. All errors and defects are categorized by origin (flaw in spec, flaw in
logic, nonconformance to standards).
2. The cost to correct each error and defect is recorded.
3. The number of errors and defects in each category is counted and
ranked in descending order.
4. The overall cost of errors and defects in each category is computed.

24. SSPI
5. Resultant data are analyzed to uncover the categories that result in
the highest cost to the organization.
6. Plans are developed to modify the process with the intent of
eliminating (or reducing the frequency of) the class of errors and
defects that is most costly.

25. PROJECT METRICS
 Project metrics are used by a project manager and a software team to
adapt project work flow and technical activities.
 Occurred during:
• estimation monitor and control progress.
• production rates: pages of documentation, review hours, function
points, and delivered source lines
• errors
• technical metrics quality

26. PROJECT METRICS
 Project Metrics are the measures of Software Project and are used
to monitor and control the project.
 Project Metrics enables 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
5) Evaluate the project team’s ability to control quality of software
work products.

27. PROJECT METRICS
 The intent of project metrics are two folds: -
 to minimize the development schedule by making the
adjustments necessary to avoid delays and mitigate potential
problems.
 - to assess product quality on an ongoing basis and, when
necessary, modify the technical approach to improve quality.

28. PROJECT METRICS
 project metrics suggests that every project should measure:-
• Inputs – measures of the resources required to do the work
• Outputs – measures of the deliverables or work products
created during the software engineering process
• Results – measures that indicate the effectiveness of the
deliverables

29. PROJECT METRICS
 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.

30. Conclusion…
 Process metrics have long-term impact.
 Their intent is to improve the process itself.
 Project metrics often contribute to the development of process
metrics.

31. Metrics
ETIQUETTE
(Guidelines)
 Use common sense and organizational
sensitivity when interpreting metrics
data
 Provide regular feedback to the
individuals and teams who have
worked to 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

32. Metrics
ETIQUETTE
(Guidelines)
 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

34. INFORMATICS & COMPUTATIONAL SCIENCE PROGRAMME
UNIVERSITY COLLEGE OF SCIENCE
MOHANLAL SUKHADIA UNIVERSITY
(NAAC Accredited A Grade University)
UDAIPUR-313001(INDIA)
YEAR- 2017-18
BCA- V semester

35. SUBMITTED TO : Dr. Pooja Shrimali Mam
SUBMITTED BY : Akanksha
TOPIC :
SOFTWARE PROCESS AND
PROJECT METRICS:-
SOFTWARE MEASUREMENT

36. Contents
1. Software measurement
2. Types of measurement
3. Size-oriented metrics
4. Function-oriented
metrics
5. Extend function-point
metrics

37. SOFTWARE
MEASUREMENT
# SIZE-ORIENTED
METRICS
# FUNCTION-ORIENTED
METRICS
# EXTENTED FUNCTION-
POINT METRICS

38. SOFTWARE MEASUREMENT
 Software measurement can be used by software
engineers to help assess the quality of work products
and to assist in tactical decision making as a project
proceeds.
 Software measurement is a quantified attribute of a
characteristic of a software product or the software
process.
 It is a discipline within software engineering.

39. Direct Measures are the one which are
measured directly from the software project
itself. In the software concern, they are line
of code (LOC), memory size, execution
speed etc.
Direct Measures Indirect Measures
The Indirect measures are not measured
directly, like complexity, reliability,
maintainability etc.
Type Of Measurement

40. An example
 Two different project teams are working to record errors in a
software process
 Team A – Finds 342 errors during software process before release
 Team B- Finds 184 errors
All other things being equal….
Q. Which team do you think is more effective in finding errors?
…. Because you do not know the size or complexity of the projects,
you cannot answer this question….

41.  But if we normalize the measures, it is possible to compare the
two by creating software metrics.
 For normalization we have 2 ways-
~ Size-Oriented
~ Function Oriented Metrics

42. SIZE-
ORIENTED
METRICS

43. SIZE-ORIENTED METRICS
 The size oriented metrics are those metrics, which are computed
keeping size of the software as main consideration.
 Built on the past experiences of projects.
 The size of the software are usually expressed in terms of KLOC (
Thousand Line Of Code ).
 The table on the following slide gives various project data (
measures ) for three different projects executed over 3 successive
years.
 Using those project data one can come out with different size
oriented metrics.

44. SIZE-ORIENTED METRICS

45. SIZE-ORIENTED METRICS
 The four different metrics which can be computed from the previous table
are,:-
 Errors per KLOC(thousand lines of code)
 Defects per KLOC
 Cost per KLOC and
 Doc (documentation) per KLOC
In addition, other metrics:
 Errors per person-month
 LOC per person-month
 $ per page of documentation

46. ADVANTAGES
 Size-oriented metrics are not universally accepted as the best way to
measure the software process.
 Proponents of the LOC measure claims that :-
 LOC is an “artifact” of all software development projects that can
be easily counted
 Many existing software estimation models use LOC or KLOC as a
key input.
 A large body of literature and data based on LOC already exists

47. DISADVANTAGES
 On the other hand, opponents argue that:-
 Programming language-dependent
 Well-designed, but shorter programs are penalized.
 Does not easily accommodate non-procedural languages
 Difficult to develop a figure for LOC early in the development

48. FUNCTION-
ORIENTED
METRICS

49. FUNCTION-ORIENTED METRICS
 It use a measure of functionality delivered by the application as a
normalization value.
 Since ‘functionality’ cannot be measured directly, it must be
derived indirectly using other direct measures
 Function Point (FP) is widely used as function oriented metrics.
 FP derived using an empirical relationship based on countable
(direct) measures of software’s information domain and
assessments of software complexity.
 FP is based on characteristic of Software information domain and
complexity.
 Like LOC measure, FP is controversial.

50. Steps In Calculating FP


51. Software INFORMATION DOMAIN VALUES.
 Number of user inputs: user inputs.
 Number of user outputs: reports, screens, error messages, etc.
 Number of user inquiries: an on-line input that generates an immediate on-
line output response.
 Number of files: each logical (logical grouping of data) master file is
counted.
 Number of external interfaces: all machine readable interfaces (e.g. data
files on some storage media) that are used to transmit information to
another system are counted.

52. RAW FP

53. RATE COMPLEXITY FACTORS
For each complexity adjustment factor (F), give a rating on a scale
of 0 to 5
0 - No influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential

54. COMPLEXITY ADJUSTMENT FACTORS

55. COMPLEXITY ADJUSTMENT FACTORS
1. Does the system require reliable backup and recovery?
2. Are data communications required?
3. Are there distributed processing functions?
4. Is performance critical?
5. System to be run in an existing, heavily utilized
environment?
6. Does the system require on-line data entry?
7. On-line entry requires input over multiple screens or
operations?
8. Are the master files updated on-line?

56. COMPLEXITY ADJUSTMENT FACTORS
9. Are the inputs, outputs, files, or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversion and instillation included in the design?
13. Multiple installations in different organizations?
14. Is the application designed to facilitate change and ease-of-
use?

57. FP(FUNCTION POINT)

58. EXAMPLE(QUESTION)
 Compute the Function Point value for a project with the
following information
 domain characteristics:
Number of Users Inputs = 24
Number of Users Outputs = 16
Number of Inquiries = 22
Number of Files = 4
Number of External Interfaces = 2
Assume , the complexity weighting factor is average. And the
various complexity Adjustment Values as:-
4,2,0,4,3,4,5,3,5,5.4,3,5,5

59. solution
To Compute Function Point, the following equation is used :
 ∑ Fi = F1 + F2 + F3 + _ _ _ _ _ _ _ + F14
= 4 + 2 + 0 + 4 +3 + 4 + 5 + 3 + 5 + 5 + 4 + 3 + 5 + 5
= 52
 Complexity Adjustment Factor (CAF)
= 0.65 + 0.01 * ∑ ( Fi)
= 0.65 + 0.01 * 52
= 0.65 + 0.52
= 1.17

60. Function Point (FP) = Count_Total * Complexity Adjustment Factor
= 318 * 1.17
= 372.06
= 372

61. Example of Function-Oriented Metrics
 Errors per FP
 Defects per FP
 $ (COST) per FP
 Pages of documentation per FP
 FP per person month

62. FORMULAS
 Productivity = Function point / Effort
 Total page of Documentation= Technical Document + User
Document
 Documentation= page of Documentation / Function Point
 Cost per function point = cost / productivity

63. Advantages
Proponents claims that:-
 Programming language-independent
 Ideal for applications using conventional and nonprocedural
languages.
 Based on data which are known early in the evolution of a project
 As an estimation approach : FP is more attractive.

64. DISADVANTAGES
Opponents claims that:-
 Many computations are based on subjective rather than objective
data.
 Function Points have no physical meaning… it’s just a number.
 Counts of information domain can be difficult to collect after the
fact.

65. EXTENDED FUNCTION-
POINT METRICS

66. EXTENDED FUNCTION-POINT METRICS
 Function point was inadequate for many engineering and
embedded systems.
 The feature point metric counts a new software characteristic –
algorithms.
 Another function point extension – developed by Boeing
integrate data dimension of software with functional and control
dimensions. “3D function point”.
 “Counted, quantified, and transformed”

67. Feature Point 3D Feature point
Extended Function point Metrics

68. FEATURE POINT
 A function point extension called feature points.
 Feature point is a superset of the function point measure that can
be applied to systems and engineering software applications.
 Accommodate applications in which algorithmic complexity is
high(like real time, process control and embedded systems are the
examples of its.)

69. Feature point
The Feature point metrics and their related aspects are shows in table. the
feature points is computed by using the following equations:
feature Point = Count_Total x [0.65 + 0.01 x (F )]
feature Point = Count_Total x (complexity adjustment factor)
i
complexity adjustment factor (CAF) = [0.65 x 0.01  F ]i
Fi represents the ‘complexity adjustment
values’, where i =1 to 14

70. Feature point
Feature Point matrices include, one more characteristic that is ‘Algorithm’.
An Algorithm is defined as-
Step by step process to solve a problem.

71. 3D Function point Metrics
Data Dimension Control DimensionFunctional Dimension
Three dimensions

72. 3D Feature point:-
Data Dimensions
 The Data Dimension is evaluated similarly as the
function point is used. In this dimension, counts are
made for input, output, Inquire, external interfaces and
files.

73. 3D Feature point:-
Functional Dimensions
In the Functional Dimension, one or more characteristic.
Transformation is added into the characteristics of function points.
Transformation is the sequence of steps which transforms the input
and output.

74. 3D Feature point:-
CONTROL Dimensions
The Control Dimension adds one more characteristic, i.e.,
Transition and make it the total 7 characteristics.
This Dimension is measured by counting the total number of
transitions between states.
A State represents some externally observable mode of behavior and
a transmission occur as a result of some event that causes the
software or system to change its mode of behavior.

75. 3D Feature point

76. Complexity Weighted Value= Nil Wil + Nia Wia + Nih Wih
Nil , Nia, Nih represent
the number of
occurrence of element
i
Wil , Wia, Wih are
the corresponding
weights

77. 3D Feature point
 Complexity Weighted Value= Nil Wil + Nia Wia + Nih Wih
 Similarly F,E,O,Q,T and R can be find out.
 Extended Function-oriented Metrics are also Programming
Language independent.

78. 3D Feature point

79. 3D Feature point

80. 3D Feature point

81. CONCLUSION…
 Function points, feature points, and 3D point represent
the same thing – “functionality” or “utility” delivered by
software.

82. THANK YOU !!!