24.3.2004Software Engineering 2004 Jyrki Nummenmaa 1 SOFTWARE PRODUCT QUALITY Today: - Software...
-
Upload
hortense-mason -
Category
Documents
-
view
214 -
download
0
Transcript of 24.3.2004Software Engineering 2004 Jyrki Nummenmaa 1 SOFTWARE PRODUCT QUALITY Today: - Software...
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
1
SOFTWARE PRODUCT QUALITY
• Today:- Software quality - Quality Components - ”Good” software properties
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
2
SOFTWARE ENGINEERINGSOFTWARE 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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
3
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
4
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
5
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
6
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
7
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
8
A delayed Christmas gift
program Hello;begin writeln(”1+1=2”);end.
#include <stdio.h>main() { printf ("1+1=2\n"); }
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
9
More error-free programs
program Hello3;begin writeln(”1+2=3”);end.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
10
More error-free programs
program Hello4;begin writeln(”1+3=4”);end.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
11
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?
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
12
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:)
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
13
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
14
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?
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
15
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
16
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
17
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
18
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
19
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
20
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).
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
21
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
22
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
23
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
24
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 ordinary text editor than an operating system.
• There is internal and external understandability.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
25
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
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
26
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
27
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 orto deliver a better product late?(Ok, this depends on the situation.)
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
28
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
29
QUALITY COMPONENTS
• Correctness• Reliability• Robustness• Performance• User Friendliness• Verifiability• Maintainability
• Reusability• Portability• Understandability• Interoperability• Productivity• Timeliness• Visibility
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
30
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
31
PREASSUMPTIONS FOR THE USE OF 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.)
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
32
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!
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
33
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
34
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.
24.3.2004 Software Engineering 2004Jyrki Nummenmaa
35
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 operands.