Advanced Software Engineering

By Melese E.
Unit 4 – Software Metrics and Quality Assurance
 Software Metrics
 Measurement is the process by which numbers or symbols are assigned to
the attributes of entities in the real world
 A measure provides a quantitative indication of the extent, amount,
dimension, capacity, or size of some attribute of a product or process
 Measurement is the act of determining a measure
 The IEEE Standard Glossary of Software Engineering Terminology [IEE93b]
defines metric as “a quantitative measure of the degree to which a system,
component, or process possesses a given attribute.”
 A software metric relates the individual measures in some way
 A software engineer collects measures and develops metrics so that indicators will be
obtained.
 An indicator is a metric or combination of metrics that provides insight into
the software process, a software project, or the product itself.
 Project manager or software engineer uses indicators to adjust the process, the project, or
the product to make things better.
Unit 4 – Software Metrics and Quality Assurance
 Effort – the amount of resources (person-time) required to develop or
maintain software product
 Effort Estimation – predicting the amount of effort required to the
software project
 Most resources to be estimated are dependent on each other.
 The human resource estimate is dependent on the time given for the
development and vice versa
 The goal of estimation is to determine a set of parameters that provide a
high level of confidence you will be able to deliver an acceptable product
within the bounds of the project constraints
 Developing a realistic estimates for software projects is an error-prone
process because
 actual effort, schedule, resources, cost, product features, and quality
attributes are often quite different than the estimated parameters
Unit 4 – Software Metrics and Quality Assurance
 Size Metrics – why size?
 Estimates of factors such as effort, schedule, resources, cost, and
quality attributes are based on estimated
 product attributes such as size
 Project constraints
 Adjustment factors
 Most estimation models – use some measure of size of the product as
the fundamental product attribute on which effort, schedule, resources,
quality factors and cost estimations are based
 Product size as a primary factor of estimation because
 Size has strong causal relationship to other product attributes
 Size can be measured more objectively than others
 Some measures of size can be estimated more accurately from requirements than
others
Unit 4 – Software Metrics and Quality Assurance
 Size Metrics – Line of Code
 There are two basic types of software size metrics
 Lines of Code (LOC), Function Point (FP)
 Lines of Code
 Is the measure of the size of the software in terms of the total number
of lines of code in the source code
 Has some difficulties
 LOC is dependent on the programming language used
 It is difficult to estimate lines of code early in the project; it is difficult to relate
changes to the requirements to changes in estimated lines of code
 Calculating productivity as lines of code generated per programmer - month may
encourage programmers to write lots of poor quality lines of code rather than
fewer lines of high - quality code
 Modern development methods such as model-driven development, object based
programming, reuse of library components, and use of open source components
make the relationship between lines of code and project attributes less relevant
and less precise than in the past
Unit 4 – Software Metrics and Quality Assurance
 Size Metrics – Function Points
 Function Point (FP)
 Calculated by counting the number of different kinds of inputs, outputs, internal files, queries,
and interfaces in a system to be estimated
 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)
 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
 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
 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
 For each of these types – weight is given for simple, average and complex categories
called weighting factors. Then the average of the three is calculated for each FPs.
Unit 4 – Software Metrics and Quality Assurance
 Size Metric – Function Points
 Function Point (FP)
 After counting the FPs in each FP types, then the following formula is
used after the adjustment factors are calculated
 FP = count total * [0.65 + 0.01 * σ 𝑭𝒊] – where Fi is the adjustment factors
 For each information domain value
 Estimated Count*weight = FP count => where weight is the average of
weighting factor for each information domain value. weight = 4 for EI & EQ, 5
for EO, 10 for ILF, 7 for EIF
 Where Estimated Count is the box on the left and the FP count is the box on
the right
 Then add all the FP counts of the
information domain values to get
the count total
 Then multiply the count total
by the adjustment factor
=> estimated FPs
Unit 4 – Software Metrics and Quality Assurance
 Size Metrics – Function Points
 Function Point (FP)
 The adjustment factors are based on the rating (0 not important to 5 absolutely
essential) for the answers of the following 14 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?
8. Are the ILFs updated online?
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 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?
 The adjustment factor is (0.65 + 0.001*σ 𝐹𝑖)
Unit 4 – Software Metrics and Quality Assurance
 Software Size – used for estimating effort, schedule, cost
 A project estimate is only as good as the estimate of the size of the
work to be accomplished.
 Accuracy of estimation (effort, cost etc.. ) is predicated on
 the degree to which you have properly estimated the size of the product to be built;
 the ability to translate the size estimate into human effort, calendar time, and dollars
 the degree to which the project plan reflects the abilities of the software team; and
 the stability of product requirements and the environment that supports the
software engineering effort
 Using either of the size estimation models (independent variables), other
product attributes (effort, cost, duration ..) can be estimated using any of the ff
approaches:-
 Decomposition techniques
 By decomposing a project into major functions and related software engineering activities, cost and
effort estimation can be performed
 Empirical estimation models
 A model is based on experience (historical data) and takes the form
 d = f(Vi) where d is estimated value (effort, cost, duration) and Vi is the independent variable
(LOC or FP)
Unit 4 – Software Metrics and Quality Assurance
 Decomposition Techniques – for effort .....
 LOC vs FP
 If LOC is used – the decomposition is absolutely essential and is often taken to
considerable levels of details.
 If FP is used - each of the information domain characteristics—inputs, outputs, data files,
inquiries, and external interfaces as well as the complexity adjustment values are
estimated
 In either case, you need to estimate optimistic, most likely and pessimistic
size for each decomposition parts using historical data or intuition,
 Count LOC for each function – in the case of LOC
 Count FPs for each information domain value – in the case of FP
 A three-point or expected value can then be computed
 S = (Sopt + 4Sm + Spess)/6 – this formula gives heaviest credence to the “most likely”
 Then historical productivity data are applied (previous person-month
experience measured in LOC, FP )
Unit 4 – Software Metrics and Quality Assurance
 Decomposition Techniques – for effort .....
 Using LOC – get a refined decomposition of the system
 Then calculate the estimated LOC for each functionality
 The following table shows after the expected value for each of the functions is calculated. For
example Three-dimensional geometric analysis ->
 Optimistic 4600LOC, most likely 6900 and pessimistic 8600 => applying the formula
 S = (4600+4x6900 + 8600)/6 = 6800LOC – the same way the LOC is calculated for the other functions
 Estimated Lines of code for the entire software package is then the sum of the LOCs = 33200

 Assuming historical data of productivity is

620 LOC/pm, the estimated effort is 54
PMs
 From this – estimated cost based on the
current average developer salary, estimated
number of staffs based on the time constraint,
estimated duration (if not constrained) based
on the number of staffs available can be
calculated
 Assuming $8000 salary per month - $431000
cost, approximately $13 per line of code
Unit 4 – Software Metrics and Quality Assurance
 Decomposition Techniques – for effort....
 Using FP
 For each of the information domain characteristics, optimistic,
most likely and pessimistic counts are estimated
 Estimated count = (Sopt + 4Sm + Spess)/6
 For each information domain characteristics, an estimated
complexity weight is associated
 FP count = estimated count * average weight
 Total count is the sum of all information domain FP count
total = 320
 Then Adjustment Factor for each question is estimated –
the sum of all questions = 52
 0.65+0.01x 52 = 1.17
 Then FP estimated = 320 x 1.17 = 375
 If the organizations historical productivity for this type of
system is 6.5FP/pm, then estimated effort is 58 person-
months
 Then if $8000 salary per month - $461000 total cost – approximately
$1230 per FP
Unit 4 – Software Metrics and Quality Assurance
 Decomposition Techniques – for effort ....
 The techniques discussed are focused on the problem
(software) functionalities or information domain
characteristics
 Estimation can also be done process wide – based on all
activities in the selected software development process –
this is called process oriented estimation
 the process is decomposed into a relatively small set of tasks
and the effort required to accomplish each task is estimated
 First the software functions needs to be identified and for each functions in
each process activities – effort is estimated
 The estimation of each activity can be done independently of LOC or FP –
person-month can be directly estimated
Unit 4 – Software Metrics and Quality Assurance
Based on the
process – 46
person-month is
the effort

 Other Decomposition techniques

 Use case based estimation – similar to FP
 Two or more size estimations may be performed on same project – and these
estimates may be divergent from the average of the estimates – the reason
why
 the scope of the project is not adequately understood or has been misinterpreted by
the planner or
 productivity data used for problem-based estimation techniques is inappropriate for the
application, obsolete (in that it no longer accurately reflects the software engineering
organization), or has been misapplied
Unit 4 – Software Metrics and Quality Assurance
 Empirical Estimation Model – for effort .....
 Uses empirically derived formulas to predict effort as a function of LOC or FP
 The model (formula) is derived from the data collected form a limited sample of projects
completed.
 Such model is derived using regression analysis on data collected from past
software projects
 Where E is effort in person-months; A, B, and C are empirically derived constants; and Ev is
the estimation variable either LOC or FP
 Among many LOC empirical models

 Among many FP empirical models

 dfd
Unit 4 – Software Metrics and Quality Assurance
 Empirical Estimation Model – for effort ....
 The COCOMO II Model – COnstructive COst MOdel
 Is a hierarchy of estimation models that address the following areas
 Application Composition Model – Used during the early stages of software
engineering, when prototyping of user interfaces, consideration of software and
system interaction, assessment of performance, and evaluation of technology
maturity are paramount.
 Early Design Stage Model – Used once requirements have been stabilized and
basic software architecture has been established.
 Post-architecture Stage Model – Used during the construction of the software
 COCOMO – requires sizing information – either of the ff three is used
 Object points – indirect software measure that is computed using
 Screens – user interface level
 Reports
 Components likely to be required to build the application
 Function points
 Lines of source code (LOC)
Unit 4 – Software Metrics and Quality Assurance
 Empirical Estimation Model
 The COCOMO II – Using Object Points
 Objects of type (screens, reports, and components) are identified
 Each of the objects (screens and reports) are classified into three complexity level
 Simple, Medium and Difficult
 Count object in each category
 Each category has weights to associate
 To classify objects, the following criteria is used
 Complexity is a function of the number and source of the client and server data tables that
are required to generate the screen or report and the number of views or sections presented
as part of the screen or report
 Multiply the counts in each complexity category by the corresponding weight
and then sum all the results to get total Object point count
 When component-based development or general software reuse is to be applied, the
percent of reuse (%reuse) is estimated and the object point count is adjusted:
 NOP = (Object Points) x [(100 - %reuse)/100] where NOP is defined as new object point
 To derive an estimate of effort, find the “productivity rate” for different levels of developers
 PROD is NOP per person-month from the past
 where person-month = (experience + environment )/2
 Then find the effort estimate => Effort = NOP/PROD
 Unit 4 – Software Metrics and Quality Assurance
 Halstead’s Metrics (Halstead’s SW Science)
 According to Halstead, a computer program is an implementation of an algorithm
considered to be a collection of tokens which can be classified as either
operators or operands
 All Halstead’s metrics are functions of the counts of these tokens (operators and operands)
 The following base measures can be collected by counting the tokens
 n1: Number of distinct operators
 n2: Number of distinct operands
 N1: total number of occurrences of operators
 N2: total number of occurrences of operands
 In addition, -
 n1∗ : Number of potential operators – minimum possible number of operators
 n2* : Number of potential operands – minimum possible number of operands
 The last two base measures – would be embodied in the programming language
itself – for example since any C program must contain at least the main function
 n1∗ = 2 – since at least two operators must appear for any function, one for the name of the
function and one to serve as an assignment or grouping symbol
 n2* = represents the number of parameters, without repetition which needs to be passed to the
function
Unit 4 – Software Metrics and Quality Assurance
 Halstead’s Metrics (Halstead’s SW Science)
 Based on the five base quantities, Halstead defines the following metrics
 N = N1 + N2 where N refers to length of a program P
 n = n1 + n2 where n refers to vocabulary of a program P
 V = N * 𝐥𝐨𝐠 𝟐 𝒏 where V refers to volume of a program P
 The volume V of a program P is defined as
 A suitable measure for the size of any implementation of any algorithm
 A count of the number of mental comparisons required to generate a program
 V* = (2 + n2∗) 𝐥𝐨𝐠 𝟐 𝟐 + n2∗ - where V* is potential (minimal) volume of program P
 L = V* / V – where L refers to program level
 D = 1 / L – where D refers to program difficulty
 L' = (2/n1)*(n2/N2) – where L' refers to language level
 E = V/L – where E refers to programming Effort - the unit of measurement of E is claimed
by Halstead to be an elementary mental discrimination
 T = E/S – where T refers to programming time – S is the Stroud number, defined as the
number of elementary discriminations performed by the human brain per second
 The S value for software scientists is set to 18
 T is in seconds
Unit 4 – Software Metrics and Quality Assurance
 Halstead’s Metrics (Halstead’s SW Science)
 Program Volume (V) - The unit of measurement of volume is the standard unit for size
"bits." It is the actual size of a program if a uniform binary encoding for the vocabulary is used
 Program Level(L) - The value of L ranges between zero and one, with L=1 representing a
program written at the highest possible level (i.e., with minimum size).
 Program Difficulty(D) - The difficulty level or error-proneness of the program is
proportional to the number of the unique operator in the program
 Program Effort(E) - The unit of measurement of E is elementary mental discriminations
 Program Length(N) - According to Halstead,The first Hypothesis of software science is that
the length of a well-structured program is a function only of the number of unique operators
and operands
 Potential Minimum Value(V*) - The potential minimum volume V* is defined as the volume
of the most short program in which a problem can be coded.
 Vocabulary (n) - The size of the vocabulary of a program, which consists of the number of
unique tokens used to build a program
 Language Level (L') - Shows the algorithm implementation program language level. The same
algorithm demands additional effort if it is written in a low-level program language. For
example, it is easier to program in Pascal than in Assembler
Unit 4 – Software Metrics and Quality Assurance
Cyclomatic Complexity
 is a software metric that provides a quantitative
measure of the logical complexity of a program.
 The calculated value is used in test case preparations –
how many distinct test cases are needed to ensure
that all program statements are executed
 To understand how to calculate Cyclomatic
complexity
 Prepare Flow Graph notation of the program
 Depicts logical flow control of a program
Unit 4 – Software Metrics and Quality Assurance
Cyclomatic Complexity
 Considering the ff flowchart – to develop a flow graph
use the ff rules
 Node – One or more procedural statements (sequence of
process symbols and a decision symbol can map to a single
node)
 Predicate node – a node that contains a condition
 Note: in the case compound conditions, each condition is
represented by a separate node ((a OR b) is represented by two
nodes)
 Edge or link – flow of control analogous to flowchart arrows
 Region – area bounded by edges and nodes
Unit 4 – Software Metrics and Quality Assurance
Unit 4 – Software Metrics and Quality Assurance
 Cyclomatic complexity
 An independent path is any path through the program that introduces at least
one new set of processing statements or a new condition.
 Path 1: 1-11
 Path 2: 1-2-3-4-5-10-1-11
 Path 3: 1-2-3-6-8-9-10-1-11
 Path 4: 1-2-3-6-7-9-10-1-11
 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 is not an independent path since it is the combination of
existing independent paths
 In cyclomatic complexity
 The number of regions of the flow graph corresponds to the cyclomatic complexity.
 Cyclomatic complexity V(G) for a flow graph G is defined as
 V(G) = E – N + 2 where E is the number of edges and N is the number of nodes
 Cyclomatic complexity V(G) for a flow graph G is also defined as
 V(G) = P + 1 where P is number of predicate nodes
 V(G) gives us the upper bound for the number of independent paths that form
the basis set => the number of tests that must be designed and executed to
guarantee coverage of all program statements
Unit 4 – Software Metrics and Quality Assurance
 Metrics for Object-Oriented Design – the following
are the nine distinct and measurable characteristics of OO
design
1. Size – defined in terms of the ff views
 Population – static count of OO entities such as classes and operations
 Volume – the dynamic count OO entities at a instant in time
 Length – the measure of interconnected design elements
 Functionality – indirect indication of the value delivered to the customer by the
OO system
2. Complexity – how classes of OO design are interconnected to each
other
3. Coupling – the number of collaborations between classes or the
number of messages passed between objects
4. 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
Unit 4 – Software Metrics and Quality Assurance
 Metrics for Object-Oriented Design
5. Completeness – The only difference between completeness and sufficiency is
“the feature set against which we compare the abstraction or design component”
 Sufficiency is against the current application
 Completeness – “what properties are required to fully represent the problem domain object”
 It may be adequate for the current application but may not be complete to
represent for other organizations application that is on the same problem domain
6. Cohesion – the cohesiveness of a class is determined by examining the degree to
which “the set of properties it possesses is part of the problem or design domain”
7. Primitiveness – is the degree to which an operation is atomic, that is, the
operation cannot be constructed out of a sequence of other operations contained
within a class. A class that exhibits a high degree of primitiveness encapsulates only
primitive operations
8. Similarity – The degree to which two or more classes are similar in terms of
their structure, function, behavior, or purpose is indicated by this measure
9. Volatility – Volatility of an OO design component measures the likelihood that a
change will occur
Unit 4 – Software Metrics and Quality Assurance
 Metrics for Object-Oriented Design
 Class Oriented Metrics
 Weighted Methods per Class (WMC) – the sum of the complexity measure of each methods of a
class is computed in a suitable complexity metrics
 Depth of the Inheritance Tree (DIT) – the maximum length from the node to the root of the tree
(from super class to last subclass in the hierarchy
 Number of Children (NOC) – the subclasses that are immediately subordinate to a class in the
class hierarchy (number of direct subclasses of a class)
 NOC increases, reuse increases
 NOC increase may also mean
 Inappropriate subclass may exist and/or
 The amount of testing increases
 Coupling between Object Classes (CBO) – the number of collaborations of a class with others
 CBO increases, reusability of the class decreases
 Response for a Class (RFC) – a set of methods that can potentially be executed in response to a
message received by an object of that class
 RFC increases, testing effort increases
 Lack of Cohesion in Methods (LCOM) – the number of methods that access one or more of the
same attributes
 If no methods access the same attribute, then LCOM = 0
 It LCOM is high, it means there are two or more methods that need to be merged into one method
Unit 4 – Software Metrics and Quality Assurance
 Quality Assurance
 Software Quality can be defined as an effective software process applied in a
manner that creates a useful product that provides measurable value for those
who produce it and those who use it.
 ISO 9126 Quality Factors
 Functionality – The degree to which the software satisfies stated needs as indicated by the
following sub-attributes: suitability, accuracy, interoperability, compliance, and security
 Reliability – The amount of time that the software is available for use as indicated by the
following sub-attributes: maturity, fault tolerance, recoverability
 Usability – The degree to which the software is easy to use as indicated by the following
sub-attributes: understandability, learnability, operability
 Efficiency – The degree to which the software makes optimal use of system resources as
indicated by the following sub-attributes: time behavior, resource behavior
 Maintainability – The ease with which repair may be made to the software as indicated by
the following sub-attributes: analyzability, changeability, stability, testability
 Portability – The ease with which the software can be transposed from one environment
to another as indicated by the following sub-attributes: adapt-ability, installability,
conformance, replaceability
 There are also some other group of factors published by different authors
Unit 4 – Software Metrics and Quality Assurance
 Quality Assurance
 Elements of Software Quality Assurance - SQA encompasses a broad range of concerns
and activities that focus on the management of software quality. These can be summarized as
 Standards – SQA is to ensure that standards that have been adopted are followed and that all work products
conform to them
 Reviews and Audits – technical reviews and audits to ensure that quality guidelines are being followed for the
software engineering work
 Testing – The job of SQA is to ensure that testing is properly planned and efficiently conducted so that it has
the highest likelihood of achieving its primary goal
 Error/defect collection and analysis – SQA collects and analyzes error and defect data to better understand
how errors are introduced and what software engineering activities are best suited to eliminating them
 Change management - SQA ensures that adequate change management practices have been instituted
 Education
 Vendor Management – the SQA ensures that which type of the following should the vendor used
 Shrink-wrapped packages (off-the-shelf)
 tailored shell – provides a basic skeletal structure that is custom tailored to the needs of a purchaser
 Contracted software – based on the specification of the customer
 Security management – SQA ensures that appropriate process and technology are used to achieve software
security.
 Safety – SQA may be responsible for assessing the impact of software failure and for initiating those steps
required to reduce risk
 Risk management – SQA organization ensures that risk management activities are properly conducted and
that risk-related contingency plans have been established
Unit 4 – Software Metrics and Quality Assurance
 Quality Assurance
 SQA tasks
 Preparing an SQA plan for the project
 Participating in the development of the project’s software process
description
 Reviewing SE activities to verify compliance with the defined SW process
 Auditing designated SW work products to verify compliance with those
defined as part of the SW process
 Ensuring that deviations in SW work and work products are
documented and handled according to a documented procedure
 Recording any non-compliance and reporting it to senior management
 Goal – SQA tasks are undertaken to achieve the following goals
 Requirements quality
 Design quality
 Code quality
 Quality control effectiveness
Unit 4 – Software Metrics and Quality Assurance

Quality Assurance
 Each quality goal have attributes and metrics for
the attributes
Unit 4 – Software Metrics and Quality Assurance

Quality Assurance
Unit 4 – Software Metrics and Quality Assurance

Quality Assurance
Thanks