Software Quality Management
Software Quality Attributes
• Safety • Modularity
• Security • Complexity
• Reliability • Portability
• Resilience • Usability
• Robustness • Accessibility
• Understandability • Reusability
• Testability • Efficiency
• Adaptability • Learnability
Quality Control
• Examines the software development process
to ensure that all relevant procedures and
standards are being followed
• Two basic approaches
– quality reviews
– software measurement and assessment
Reviews
• Reviews are the principle means of validating both
process and product quality
• Basic procedure is to have a group of people
examine a process artifact to find potential
problems
• Common software review types include
– defect inspection and removal (product)
– progress reviews (product and process)
– quality reviews (product and standards)
Quality Reviews
• Group of knowledgeable people examines a
software component and its documentation
• Code, design models, specifications, test plans,
standards, etc. can be subjected to review
• Once an artifact has been reviewed and ‘signed
off’ by the reviewers, management has given its
approval to proceed to the next stage of
development
Quality Review Process
• Select a review team
• Arrange a time and place for the review
• Distribute documents to review
• Conduct the review
• Complete the review forms
• Decide whether to approve artifacts or have
them reworked and review them again
Review Purposes
• Quality function
– part of the general quality management process
• Project management function
– provide information to project managers
• Training and communication function
– product knowledge is shared among
development team members
Quality Review Results
• Purpose is the discovery of system defects and
inconsistencies
• Review comments need to be classified as
– no action (no changes to artifact are required)
– refer for repair (author needs to correct faults)
– reconsider overall design (problem identified
impacts other design components)
• Requirement and specification problems may
require involvement of client to resolve
Software Measurement and Metrics
• Software measurement is concerned with
deriving a numeric value for an attribute of
a software product or process
• This allows for object comparisons bewteen
techniques or processes
• The systematic use of measurement is
essential to process improvement programs
Software Metric
• Any type of measurement that relates to a
software system, process, or document
– LOC, person-months, function points
• Metrics allow for the quantification of the
software or a software process
• May be used to predict product attributes or
to control the software process
Predictor and Control Metrics
Software Software
process product
Control Predictor
measurements measurements
Management
decisions
Metrics Assumptions
• The software property of interest can be measured
• There is a known relationship between what we
want to measure and what we want to know
• The relationship has been formalized and
validated
• It may be difficult to relate what can be measured
to desirable quality attributes
Measurement Process
• The software measurement process may be
part of a quality control process
• Data collected during the measurement
process should be maintained as an
organizational strategic resource
• Establishing a measurement database allows
comparisons between and across projects
Product Measurement Process
• Choose measurement to be made
• Select components to be assessed
• Measure component characteristics
• Identify anomalous measurements
• Analyze anomalous components
Data Collection
• A good metrics program is based on a set of
identifiable product and process data
• Data should be collected immediately (not
retrospectively)
• Use automatic data collection if possible
– static product analysis
– dynamic product analysis
– process data collection
Automated Data Collection
• Instrumented software system
– monitors added to software to record necessary
data unobtrusively
• Usage data
– capture user inputs and transactions
• Fault data
– make use of electronic media to record faults as
they are uncovered
Data Accuracy
• Don’t collect unnecessary data
– decide the questions to be answered in advance and
only collect relevant data
• Tell people why data is being collected
– make sure people understand that the product and
process are being evaluated (not the employees)
• Don’t rely on people’s memory
– collect data as it is being generated, not after a project
is completed
Product Metric Classes
• Dynamic metrics
– measurements made on executing program
– help assess things like efficiency and reliability
• Static metrics
– measurements made of some system
representation
– help assess things like complexity,
understandability, and maintainability
Dynamic and Static Metrics
• Dynamic metrics
– closely related to software quality attributes
– it is fairly easy to measure response time (performance)
or number of failures (reliability)
• Static metrics
– are indirectly related to quality attributes
– you may need to use statistics to derive relationships
between static metrics and attributes like complexity or
maintainability
Static Metrics
• Fan-in
– number of functions that call a particular function
• Fan-out
– number of functions called by a particular function
• Length of code
– size of program (LOC or KLOC)
• Cyclomatic complexity
– measures control complexity inside program
• Fog index
– average word and sentence lengths in documents
Object-Oriented Static Metrics
• Depth of inheritance tree
– distance between root class and instances
• Method fan-in/fan-out
– wise to distinguish between method calls within a class
and between classes
• Weighted class methods per class
– number of methods in a class weighted by complexity
of each method
• Number of overriding operations
– superclass operations redefined in subclass
Customer Satisfaction
• PVM (valid problems per user month)
• How do you improve PVM?
– Reduce product defect injection rates during
development
– Improve support, usability, documentation,
communication, or training
– Increase sales of installed licenses (spreads same
number of problems over more user months)
Maintenance Metrics
• Defect arrivals by time interval
• Customer problem calls
• Backlog management index (BMI)
100% * (# problems fixed this month)/(# arriving this month)
• Percent of delinquent fixes
100% * (# fixes by that exceed fix time standards)/(total # fixes)
Measurement Analysis
• It is not always obvious what the data
means
• Data analysis is difficult
• Consult professional statisticians when
necessary
• Data analyses should take local
circumstances into account
Measurement Surprise
• Reducing the number of faults in a program may
lead to an increased number of help desk class
• Program is now perceived as more reliable and
may have a wider market (a lower percentage of
calls may net a larger number of calls)
• People are less willing to work around faults in a
system that has a reputation for reliability and this
may lead to more calls for help