SOFTWARE PRODUCT SOFTWARE ENGINEERING QUALITY SOFTWARE QUALITY - - PDF document

1

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE PRODUCT QUALITY

• Today:
• Software quality
• Quality Components - ”Good” software properties

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE ENGINEERING SOFTWARE QUALITY

• Today we talk about quality
• but what is quality?
• ”Suitable”
• ”Fulfills requirements”
• ”Customer is satisfied”
• ”Other attributes than price”
• ”Superiority, excellence”
• ”Has required and expected features”
• It seems difficult to find a ”perfect” single definition.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE QUALITY - QUALITY COMPONENTS

• Objective quality component: properties that can be

measured or approximated objectively

• Subjective quality component: customer satisfaction (”What

does the product feel like?”)

• Other: features which can not be (even subjectively)

evaluated at the time. This is related with future events which can not be predicted - unexpected circumstances, changes, etc.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE QUALITIES - PRODUCT AND PROCESS

• Product quality - the quality of the software product (including

user and technical documentation).

• Process quality - the quality of the software engineering

process used to produce the product.

• Users are (understandably) primarily interested in the product

qualities.

• The process qualities are used to achieve the product ones.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE PROPERTIES - EXTERNAL AND INTERNAL

• External properties are the ones that are visible to the users.
• Internal properties are the ones the ones that are visible to

the software developers.

• Users are (understandably) primarily interested in the external

properties.

• The internal properties are used to achieve the external ones.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Correctness

• A couple of years back in the Christmas issue of ITviikko-

magazine professor Jukka Paakki from Helsinki University wished for at least one error-free program.

2

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

A delayed Christmas gift

program Hello; begin writeln(”1+1=2”); end. #include <stdio.h> main() { printf ("1+1=2\n"); }

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

More error-free programs

program Hello3; begin writeln(”1+2=3”); end.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

More error-free programs

program Hello4; begin writeln(”1+3=4”); end.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Correct or incorrect?

program Hello; begin writeln(”1+1=3”); end.

• The problem of correctness is in that it does not depend on

the program alone but also on the expectations on the program.

• So, how can we say if any of the previously seen programs

was correct or incorrect?

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

How to identify correct programs?

• Sometimes this seems easy.
• But how to define correctness so that we could use the

definition to identify correct programs? (and do it correctly:)

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

Mathematical proofs

• Using logic or mathematics, prove that the program has some

properties.

• You can use a (hopefully correct) program to assist you in

making the proofs.

• Problem: These mathematical properties may appear to be

even more complex than the programs themselves.

3

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Correctness

• A program is functionally correct if it behaves according to the

functional specifications.

• The functional specifications may not always be available.
• The functional specification may be very informal.
• The functional specifications may contain ambiguities.
• Sometimes it is evident what is expected - is it fair to compare

the software with general expectations or its own help?

• Do we assume that the specifications are correct?

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Reliability

• A program is reliable, if the user can rely on the software.
• For reliability, the statistical approach could be used: What is

the probability that the software fails with a given task?

• The program may be reliable in a user’s point of view even if it

is not correct.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Robustness

• A program is robust, if it behaves reasonably (?) well even in

unexpected circumstances - i.e. it tolerates unexpected difficulties.

• Dealing with errors? E.g. program input is often different from

what is expected.

• The program may be reliable in a user’s point of view even if it

is not correct.

• A crucial property in some applications.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Performance

• Performance = efficiency.
• Efficiency: memory management, disk management, CPU

usage, ...

• Asymptotic behaviour: what happens when inputs grow

larger?

• Transaction processing systems:
• Throughput = how many transactions can be

processed in a given time slice (average or min)

• Response time = the time (max or average)

needed to process a transaction.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - User friendliness

• A software system is user friendly if the users find it easy to

use.

• A subjective quality.
• Incorrect, inefficient, and unreliable systems are not very user

friendly.

• A non-robust system may be user friendly.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Verifiability

• A software system is verifiable, if its properties can be verified

easily.

• The software properties can be verified using testing or formal

analysis.

4

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Maintainability

• A software system is maintainable, if it is easy to maintain.
• Corrective maintenance - removing errors (repairability)
• Adaptive maintenance - adapting the software to new or

changing environments (evolvability).

• Perfective maintenance - improving other software qualities

(evolvability).

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Evolvability

• A software system is evolvable, if it is easy to add new

functions or change old ones.

• Adding new functions or changing the old ones usually ”eats

up” some of the evolvability - after the change the software is usually less evolvable.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Reusability

• A software system is reusable, if it can be used to produce

another software system.

• Reusability is rare in practice.
• In addition to the program code, also other parts of the

software product, such as designs and documentation, can be reusable.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Portability

• A software system is portable, if it can be run (or it can be

made to run) in different environments.

• Portability across different hardware architectures.
• Portability across different operating systems.
• Portability across different hardware configurations.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Understandability

• How easy is it to understand the system’s structure and how it

works?

• Some tasks are more complex: it is easier to understand an
• rdinary text editor than an operating system.
• There is internal and external understandability.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Interoperability

• is the ability to co-operate with other systems.
• Exchange of data using data files.
• Exchange of data using some kind of a clipboard.
• Exchange of data using network.
• Standard interfaces
• Open system - open interfaces

5

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Productivity

• The efficiency of the software production process (internal).
• Huge differences between teams and individuals (starting

from the fact that some teams or individuals may not be able to complete some tasks at all).

• In producing new software one individual can easily be 2-4

times more productive than another.

• In maintaining old software one individual can in extreme

cases be 20-40 (or even more) times more productive than another.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Timeliness

• The ability to deliver a product in time.
• Does not happen too often.
• Result: Alpha versions, Beta versions, ”Early pre-prototype

test versions”, ...

• Which is better:

to deliver a defective product in time or to deliver a better product late? (Ok, this depends on the situation.)

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS - Visibility

• The software development process is visible, if it is easy to

see what has been done and what has happened.

• If all know what the state of the process is, it is easier to know

when to do what.

• When personnel changes (and in long projects it does),

visibility is very valuable.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

QUALITY COMPONENTS

• Correctness
• Reliability
• Robustness
• Performance
• User Friendliness
• Verifiability
• Maintainability
• Reusability
• Portability
• Understandability
• Interoperability
• Productivity
• Timeliness
• Visibility

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SOFTWARE METRICS

• Measurements which relate to a software system, process, or

related documentation

• Examples:
• size of a product in lines of code
• number of reported faults
• time required to produce a system component
• Control metrics measure the process
• Predictor metrics are measurements of a product attribute

which can be used to predict an associated product quality.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

ASSUMPTIONS FOR PREDICTOR METRICS

• We can accurately measure some property of the software.
• A relationship exists between what we can measure and what

we would like to know about the product’s behavioural attributes.

• This relationship is understood, has been validated, and can

be expressed in terms of a formula or a model. (This last assumption is often ignored.)

6

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

SIZE AND COUNT RELATED METRICS

• Number of Lines Of Code (LOC)
• Number of classes
• Number of comment lines
• Number of interfaces
• Number of modules
• Number of statements
• Number of variables
• There’s so many things you can count!

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

MORE SIMPLE METRICS

• Comment density: number of comment lines / number of all

lines

• Fan-in: number of other classes(module,etc.) using this class

(module,etc.)

• Fan-out: number of classes(module,etc.) such that this class

(module,etc.) uses them.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

COHESION–RELATED METRICS

• Cohesion means how well parts of some unit – say class –

belong together.

• For instance, it is possible to check if methods use the same
• variables. If they do, they seem to have something in

common.

• A number of cohesion-related metrics exists.

Software Engineering – http://www.cs.uta.fi/se University of Tampere, CS Department Jyrki Nummenmaa

COMPLEXITY METRICS

• McCabes cyclomatic complexity:

If G is the control flowgraph of program P, and G has e edges (arcs) and n nodes, then Cyclomatic number V(G) = e - n + 2. Intuitively the metrics measures the different ways the program execution can flow.

• Halstead metrics – based on the number of operators and
• perands.