Sqp 2005 L4 Software Product Quality

2162ICT Software Quality Principles

Software Product Quality R.G. Dromey

© R.G.Dromey, Griffith University, 2005

SUMMARY Quality Model Framework Software Quality In-the-Small Software Quality In-the-Large

Quality Model Framework

Conceptual Model - Products Products are composed of  components Components have tangible  properties that impact quality

Quality Model Framework ●

Conceptual model products based on components and tangible properties

●

High-level quality attributes

●

Linkage of tangible component properties to quality attributes

Elements of Quality Model Components

Tangible QualityCarrying Properties

Components

Tangible QualityCarrying Properties

Nature of Tangible Properties Implies

Tangible Property

EXAMPLE:

Quality Attribute(s)

(For Software-System Interface Modules)

Transmission Retry Mechanism Implemented

Implies Reliability, Fault-tolerance

Quality-Determining Factors Choice of Components

Component Properties Way Components Composed

Quality

Tangible Quality-Carrying Properties Functional Properties QualityCarrying Properties Non-functional Properties

QUALITY - The Big Picture Non-Functional QualityCarrying Properties to satisfy QRs

Functionality Needed to satisfy QRs Supporting

Core Functionality Needed to Satisfy FRs Functional QualityCarrying Properties to satisfy QRs

Refining What We Mean By Quality

Terminology and Framework Software exhibits properties Some of these properties are desirable We call the desirable properties quality attributes

CRITICAL QUESTION Who has to be satisfied with software?

ANSWER The interest groups are: Clients and sponsors ● Users ● Developers ● Maintainers ●

Quality Attributes – Quality attributes are the vehicle through which different interest groups express their needs of software – Software exhibits a set of behaviours and it has a set of uses that map onto the needs of different interest groups

SOFTWARE Behaviours and Uses SOFTWARE

Behaviour Set

Behaviour-1

Quality Attributes

... ...

Usage Set

Behaviour-N

Use-1

Quality Quality Attributes Attributes

...

Use-2

...

Use-N

Quality Attributes

CRITICAL QUESTION Why do we want to build a model of software product quality in the first place?

ANSWER • to assess/prescribe software products,

quality

of

• to understand what is entailed in constructing quality software, • to enhance the behaviours and facilitate the uses of software,

ANSWER • to use such material train/educate people how produce quality software,

to to

• to provide a framework that can be extended to meet particular domain/application-specific quality needs

First Axiom of SPQ Choice of Components

Components Properties

Way components are composed

Software Product Quality

Second Axiom of SPQ

Software exhibits certain behaviours and uses that correspond directly to its quality attributes.

Second Axiom of SPQ SOFTWARE

Behaviours

Functionality

Reliability

Uses

Efficiency

Usability

Maintainability

Portability

Reusability

Quality Attribute Refinement

Case Study - Usability • To  illustrate  the  processes  of  definition  and  characterisation  we  will  now  explore  one  quality  attribute (usability) in slightly more depth.     • Our  intent  is  not  to  give  a  comprehensive  software  product  quality  characterisation  for  usability but rather to illustrate the process.      • Our  starting  point  is  to  list  (see  below)  a  set  of  properties  that  define/characterise  or  are  manifestations of usability. 

Case Study - Usability  

Usability

. .

Learnability - easy to learn how to use Transparency- easy to understand/ remember how to use functionality Operability – easy and efficient to apply functionality Responsiveness- performs all functions in a timely fashion Customisability- can customise interface, palettes, etc to user needs Foreign-language Provision – can change the language of interface Command-context sensitivity – shows commands useable in context Operational directness – provision for most direct command execution Hot-keyed – are short-cut key options for frequently used functions Consistency – commands consistent with environs (e.g Widows-95)

Case Study - Usability • Behaviours and uses are candidates for being the  top­level  determinates  of  usability.  We  may  also  have  some  behaviours  acting  as  subordinate  behaviours of others, etc.     • To accommodate this we must systematically ask  for  each  property  whether  it  contributes  to  or  determines each behaviour or use.    

Case Study - Usability In  order  to  arrange  these  properties  into  an  appropriate  hierarchy  using  the  definition/characterisation  strategy  we  have  described  we  first  classify  the  properties  as  either  behaviours,  uses  or  software  characteristics  according  to  our  definitions  of  these  terms  (see  below).   

Usability

. .

Learnability - use Transparency- software characteristic Operability – use Responsiveness - behaviour Customisability- use Command-context sensitivity – software characteristic Operational directness – software characteristic Hot-keyed – software characteristic Consistency- software characteristic

Case Study - Usability • For  example  we  must  ask  does  customisability  contribute to learnability, to operability and so on.    • Software  characteristics,  in  turn  characterise  behaviours and uses.     • Again  a  similar  process  is  applied.  A  possible  definitional  hierarchy  that  is  an  outcome  of  this  whole process is shown below.   Consistency Transparency Learnability

Command-context sensitivity

Usability Customisability Operability

Responsiveness Command Execution Directness Hot-keyed

• What we have provided here is a long way short  of a comprehensive specification of usability.  

Third Axiom of SPQ

Tangible quality-carrying properties of software components contribute to one or more high-level intangible quality attributes.

Fourth Axiom of SPQ

Associated with each tangible qualitycarrying property of a component is a verifiable empirical statement that links the property to a high-level quality attribute .

Nature of Tangible Properties Implies

Tangible Property

EXAMPLE:

Quality Attribute

(For Software-System Interface Modules)

Transmission Retry Mechanism Implemented

Implies Reliability, Survivability

(s)

Component Properties Internal Properties Component Contextual Properties

Contextual Properties Component A

Component A

Redundant Relationship

Composed With

Component B

Component B Possesses Redundancy Property

Quality In-The-Small

Components Various statements, and what they are made up of: e.g. if-statements, guards, loops,etc Data/representations e.g. variables, types, etc

High-level Quality Attributes – – – – – – –

Functionality Reliability Efficiency Maintainability ISO-9126 Portability Usability Reusability, Process-maturity

Question “What tangible quality-carrying properties need to be built into a variable so that it does not detract from the quality of a program?”

Quality-Carrying Properties VARIABLE:

Variable

Assigned

Correctness

Functionality, Reliability

Precise

Correctness

Functionality, Reliability

Single-Purpose

Correctness

Functionality, Reliability

Encapsulated

Contextual

Maintainability, Reuse

Utilized

Contextual

Maintainability, Reuse

Self-descriptive

Descriptive

Maintainability, Reuse

Documented

Descriptive

Maintainability, Reuse

Question “What tangible quality-carrying properties need to be built into an expression so that it does not detract from the quality of a program?”

Quality-Carrying Properties EXPRESSION:

Expression

Computable

Correctness

Functionality, Reliability

Side-effect Free

Contextual

Reliability

Effective

Internal

Efficiency

Adjustable

Internal

Maintainability, Reuse

Assignment Quality Variable

:=

Expression

Tangible Quality-Carrying Properties • • •

Properties of Variables Properties of Expression Properties of Assignment

Quality-Carrying Properties Assignment: Ineffective

Quality Impact Contextual

Efficiency,Maintainability

Correctness

Reliability, Functionality

Assignment

Incomplete

Automated Inspection Tools like Purify, Insight and PASS-C can implement a lot of this model These tools act like a “quality compiler” Need back up with Formal Inspections

PASS-C Sample Output Total Loc processed   Total quality defects  Quality defects / KLoc    •    •    •  

Quality Attributes   Defects Functionality  65  Reliability  402  Efficiency  151  Maintainability   1206  Portability  148 ***Reliability Profile***  Times Fired   Rule  4  Rule 6    82  Rule 6    2  Rule 11    12  Rule 15    2  Rule 18    48  Rule  25    18  Rule 28    62  Rule 29    •    •    •  

***Maintainability Profile***  Times Fired   Rule  56  Rule 1    133  Rule 2    20  Rule 3    •    •    •  

:  :  : 

13129  1210  92.16 

Product Attributes   Defects Correctness   423  Structural  348  Modularity  199  Descriptive   240

Rule Description Hidden Loops  Uninitialized Variables  Loops that Make No Progress  Redundant Conditional Assignment  Premature Initialization  Duplicate Output  Unassigned Address Parameter  Function Side Effects 

Rule Description Redundant Declarations  Global Variables  Poor Naming Conventions 

Evaluation of Quality-in-the-Small Model –

This sort of model can provide a specification of software quality only at the intra-module level

–

Need extensions to handle the quality requirements of large, complex, realtime and embedded systems

Quality In-The-Large

Needs for Complex Systems Must handle a whole range of quality problems that relate to issues like: e.g. survivability, interoperability, usability, etc.

Tangible Properties for Quality Requirements The tangible properties of software needed to deal with these sort of quality requirements are associated with: within modules of various kinds across architecture of system within data of various kinds

Making The Model Workable ●

There are a large number of tangible properties to account for

●

Only a small number of these properties are relevant to any given module or data type

●

Need to break up problem

Making The Model Workable ●

Classify Modules and data according to their broad roles

●

Associate tangible quality-carrying properties with each class member

●

Link to high-level quality requirements

Module Classifications Property 1 Software-Hardware

Module Types

Property 2 ••• Property N

Software-Software Coms

• • Computation

Property1 Property 2 ••• Property N

Module Classifications EXAMPLES ● Software-Hardware Interface module ● Software-System Interface module ● Software -Database Interface module ● Computation/calculation module ● File-processing module ●

•••

COMPONENT- (Module/Object, etc) With Quality Engineered-In Functionality to satisfy FR’s

COMPONENT

Functionality to satisfy QR’s

Non-functional Q-C properties to satisfy QR’s

Software-Hardware Interface Modules Quality-Carrying Propeties Initialization on startup, restart or error recovery Periodic check for operational status parameterized

SoftwareHardware Interface Software Modules Hardware Interface Modules

Quality Attributes Survivability, reliability Flexibility

Periodic Check for Operational Status Implemented

Survivability

Reporting & resolution when device is not operating

Usability, survivability, reliability

Documented allowable range values for each input from device

Correctness, reliability

All operational states of device resolved and complete

Correctness, reliability

All interactions/operations for each hardware device encapsulated in one module/subsystem

Maintainability, flexibility

All architectural details of device encapsulated & parameterized

Maintainability, flexibility

Software-System Interface Modules Quality-Carrying Properties Transmission retry mechanism implemented

SoftwareSystem Interface Software Modules Hardware Interface Modules

Retry mechanism parametered Periodic check for operational status implemented

Quality Attributes Survivability , reliability

Flexibility

Survivability

Transmission failure reporting mechanism implemented

Usability, survivability, reliability

Transmission failure resolution procedure implemented and complete

Correctness, survivability, reliability

All operational states resolved and complete

Correctness, reliability

Data Classifications EXAMPLES ● communication data (messages) ● computation data ● operator input data ● addressing data ● security data ● shared data ●

•••

Communication Data Quality-Carrying Properties Specified common format (XXX) used for position & data packing and block transmissions

Communication Software Data Hardware Interface Modules

Quality Attributes Maintainability, interoperability

Message contains label indicating the type of data it contains

Maintainability, interoperability

Permissible range values for all data in message identified

Reliability

Common Technical Glossary for referencing message labels identified

Maintainability,

Data representations in a message will comply with a nominated, contract specified standard XXX

Maintainability, interoperability

Purpose and format of each data item in a message shall be identified

Maintainability

Each specified data item in a message shall be set

Correctness, reliability

Conclusions –

Gains only when systematic use of tangible product properties.

–

Component-based quality model gives systematic way to tackle problem. Then can build and assure quality software.

–

With software quality you get a return commensurate with what you put in!

–

Will discuss later building quality requirements across architecture

Popper’s Advice The study of products is vastly more important than the study of production even for understanding production and its methods