SOFTWARE ENGINEERING

1
SOFTWARE ENGINEERING SOFTWARE PRODUCT QUALITY

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

2
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.

3
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.

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.

5
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.

6
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.

7
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?

8
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 users point of
  view even if it is not correct.

9
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 users point of
  view even if it is not correct.
• A crucial property in some applications.

10
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.

11
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.

12
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.

13
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).

14
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.

15
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.

16
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.

17
QUALITY COMPONENTS - Understandability

• How easy is it to understand the systems
  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.

18
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

19
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.

20
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.)

21
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.

22
QUALITY COMPONENTS

• Correctness
• Reliability
• Robustness
• Performance
• User Friendliness
• Verifiability
• Maintainability

• Reusability
• Portability
• Understandability
• Interoperability
• Productivity
• Timeliness
• Visibility

23
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
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
  products 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.)

25
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
• Theres so many things you can count!

26
MORE SIMPLE METRICS

• Comment density number of comment lines / number
  of all lines
• Fan-in number of other classes(module,etc.)
  using this classes(module,etc.)
• Fan-out number of classes(module,etc.) such that
  this classes(module,etc.) uses them.

27
COHESIONRELATED 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.
• A number of cohesion-related metrics exists, see
  for instance the Jstyle help. (We will use Jstyle
  as an example tool).

28
COMPLEXITY METRICS

• McCabes cyclomatic complexityIf 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
• Halstead metrics based on the number of
  operators and operands.
• Also here, see Jstyle documentation.