KAIST SE lab

Chapter 2 Software Qualities

KAIST SE lab

S/W Development
Process

Technology

Resources

Quality/Productivity

Product

KAIST SE lab

Software Qualities
Definitions

DoD, 1985, ``The degree to which the attributes of the software enable it to perform its intended end use.'' ISO, 1986, ``The totality of features and characteristics of a product The or service that bear on its ability to satisfy specified or implied needs.'' Kitchenham, 1986, Fitness Kitchenham 1986 ``Fitness for needs '' needs.
Conformance to its specification: Is it a good solution? Fitness for its intended purpose: Does it address the right problem?

KAIST SE lab

Software Characteristics
The characteristic that perhaps sets software apart from other engineering products the most is that software is malleable. The malleability of software is often misused. Softwares malleability sometimes leads people to think that it can be changed easily. ( Even without extra cost!) A change in software must be viewed as a change in the ______ rather than i th _____. th th in the

KAIST SE lab

Software Characteristics
Its creation is human intensive: It requires mostly engineering rather than manufacturing. th th f t i Q: How is engineering different from manufacturing? In traditional engineering disciplines, the engineer has tools for g g p , g describing the qualities of the product distinctly from the design of the product. In SE, it is not so clear. The qualities of the software product are often intermixed in specifications with the qualities of the design. Q: What does it mean by the underlined above?

KAIST SE lab

Why software quality is different yp q y from other types of quality?

Software has no physical existence. The lack f knowledge of client needs at th start. Th l k of k l d f li t d t the t t The change of client needs over time. The rapid rate of change in both h/w and s/w s/w. The high expectation of customers, particularly w.r.t. adaptability.

KAIST SE lab

Some Insights about Quality

Quality Quality Quality Quality Q li Quality is not absolute is multidimensional is subject to constraints (people, money, time, tool) i about acceptable compromises is b bl i criteria are not independent

KAIST SE lab

Quality Factors

User

Sponsor S

Maintainer

KAIST SE lab

Internal and External Quality

Distinction is not sharp External Quality: Visible to the users of the system Internal Q li I l Quality: Concerns the developers of the system

KAIST SE lab

Product and Process Qualities

Closely related: use a process to produce the s/w product. Product quality:

Functionality Usability Efficiency Reliability, etc Effectiveness of methods, tools Use of standards Management, etc

Process quality

10

KAIST SE lab

Representative Qualities
Correctness, Reliability and Robustness Performance User Friendliness Verifiability V ifi bili Maintainability Reusability Portability Understandability Interoperability Productivity Timeliness Ti li Visibility

11

KAIST SE lab

Correctness, Reliability and Robustness

Open used interchangeably, meaning that the degree of the p g y, g g application's performing its functions as expected.

Correctness
Correct if the program behaves according to the specification of the functions. p Assumption :
4 A specification of th system is available. ifi ti f the t i il bl 4 It is possible to determine unambiguously if a program

meets the specification.

12

KAIST SE lab

Reliability
= dependability: reliable if the user can depend on it. A measure of the frequency and criticality of product failure Failure: An unacceptable effect or behavior under permissible operating conditions conditions. Can define in terms of statistical behavior: MTTF, MTBF Relative, (Q: What about correctness?) , (Q )

13

KAIST SE lab

Robustness
Robust if it behaves reasonably, even in circumstances that were not anticipated in the requirements specification. A function of a number of factors such as

The range of operating conditions conditions. The possibility of unacceptable results with valid input. The acceptability of effects when the product is given invalid input.

Q: Relation to correctness Q: Relation to reliability

14

KAIST SE lab

Performance
Equates performance with efficiency(space, time). Affects the usability of the system. Evaluation

Measurement ( M t (monitoring) it i ) Analysis Simulation

Q: When do we need to estimate performance? Application of performance to process --> Productivity

15

KAIST SE lab

User Friendliness
Ease to use Ease with which the system can be configured and adapted to the hardware environment.

Verifiability
Verifiable if its properties can be verified safely. Performed either by formal analysis methods or through testing.

16

KAIST SE lab

Maintainability
Maintenance

Corrective Adaptive Perfective

Software evolution ( instead of maintenance) Repairability and Evolvability

17

KAIST SE lab

Maintainability(Cont.)
Repairability

Repairable if a software system allows the correction of defects with a limited amount of work. Q Q: How many hours needed to fix an error in the maintenance phase? Right modularization promotes repairability. Q: Why? Improved through the use of proper tools: HL PL CASE etc PL, CASE, etc. Modified over time
To provide new functions. To change existing functions.

Achieved by modularization Decreased with each release of a new version Q: Thus, what we may need?

18

KAIST SE lab

Reusability
Use existing components to build a new product. Examples: Scientific libraries, X window, Motif, etc Reuse levels

People P l Requirements Design Code

Object-oriented technology: best buy Application to A li ti t process

Software methodology Life cycle model

19

KAIST SE lab

Portability
Portable if it can run in different environments

hardware platforms software platforms

Understandability

An internal product quality. Object-oriented paradigm claims ease to understand. j p g

20

KAIST SE lab

Interoperability
Ability of a system to coexist and cooperate with other systems Open system concept

Productivity

A quality of th software production process lit f the ft d ti Difficult to measure: simple metric: SLOC

21

KAIST SE lab

Timeliness
Ability to deliver a product on time. Requires

careful scheduling, accurate work estimation and clearly specified milestones.

Visibility

Visible if all of its steps and its current status are documented. Allows to weigh the impact of their actions and thus guides them in making decisions.

22

KAIST SE lab

Quality Requirements in S Q lit R i t i Specific ifi Application Areas

Information Systems Real-time Systems Distributed Systems Embedded Systems E b dd d S t

23

KAIST SE lab

Information Systems
Storage and retrieval of data Examples: banking systems, library-cataloging systems, etc. Qualities

Data integrity D t i t it Security Data availability Transaction performance

24

KAIST SE lab

Real-time Systems
Respond within a predefined and strict time periods Examples: factory-monitoring systems, missile guidance systems, mouse-handling software Control-oriented Control oriented Scheduling

Deadline Priority

Hard and soft real-times Quality Q lit

Respond time requirements (correctness criterion)

25

KAIST SE lab

Distributed Systems
The degree of distribution

Data Control Hardware

Examples: middleware in client/server systems, groupware, etc. Qualities

System availability

26

KAIST SE lab

Embedded Systems
Software is one of many components. Has no interface to end-user. Examples: Airplanes, robots, microwave ovens, dishwashers, automobiles,etc. automobiles etc

27

KAIST SE lab

Discussions
Discuss the relationship between testing and quality? What is 6Sigma? Even though 6 Sigma is widely used in manufacturing industry why is the reason why 6 Sigma is not industry, easy to apply in software industry?

28

KAIST SE lab

References
Reference: ISO9126 Software Quality Page [Link]

29

KAIST SE lab

Q&A

30

KAIST SE lab

Chapter 3 Software Engineering Principles

31

KAIST SE lab

Software Engineering Principles

Tools Methodologies Methods & Techniques Principles

Relationship between principles techniques, methodologies and tool principles,

32

KAIST SE lab

Software Engineering Principles

Rigor and formality Separation of concerns Modularity Abstraction Anticipation of changes Generality Incrementality

33

KAIST SE lab

Rigor and Formality

Rigor is a necessary complement to creativity. Enhances creativity. Q: How? The highest degree is formality Q: Relationship between rigor and formality formality. Q: What is the advantage of formality over rigor? Q: Traditionally, what is only one phase of s/w development Q: where a formal approach has been used? Application of p pp process

Example: Rigorous documentation of s/w process Improves reusability, maintainability, etc.

34

KAIST SE lab

Separation of Concerns
A way to deal with inherent complexity Various ways in which concerns may be separated

In time

Example :

In terms of qualities

Example :

In different views of the software

Example :

In terms of size

Example : E l

In terms of responsibility

35

Example : Q: May we miss some global optimization due to the separation of concerns?

KAIST SE lab

Modularity
Divided into simpler pieces, called modules Top-down and bottom-up Three goals

Decomposability
Divide and conquer

Composability
Starting bottom up from elementary components

Capability of understanding
Each part of a system separately Related to maintenance

To achieve these goals

36

High cohesion and low coupling High cohesion: The degree of relatedness to other modules Low coupling: The degree of the relatedness among internal elements of the module.

KAIST SE lab

Abstraction
A process whereby we identify the important aspects of a phenomenon and ignore its details. Special case of separation of concerns History y

Mnemonic Macro functions Functions and procedures Loops, selection Abstract data types Objects Design patterns Object frameworks

Helps us concentrate on the problem to solve rather than the way to instruct the machine on how to solve it.

37

KAIST SE lab

Software Engineering Paradigm Evolution

Assembly programming Procedureoriented programming Objectoriented programming

Componentbased SE Service-oriented Service oriented programming

SE R&D progress
Program Design Analysis Testing Maintenance

38

Goal of Evolutions Improve productivity & quality!

KAIST SE lab

Anticipation of Change
Software undergoes changes constantly. Likely changes should be isolated in specific portions. Affects maintainability, evolvability, reusability.

39

KAIST SE lab

Generality
Not necessarily more complex to solve a generalized problem. Have more potential to be reused. Already provided by some off-the-shelf packages. More costly in terms of

Speed of execution Memory requirements Development time

40

KAIST SE lab

Incrementality
A process that proceeds in a stepwise fashion. Evolutionary process Incremental system testing (thread testing)

41

KAIST SE lab

Case Study in Compiler Construction(1/2)

Rigor and formality problems are related to the semantic aspects of the language, which are usually defined ______., rather than the syntactic aspects, aspects which are usually defined by BNF BNF.

42

KAIST SE lab

Case Study in Compiler Constrcution(2/2)

Modularity Consists of three phases: - Lexical analysis -S Syntax analysis l i - Code generation Abstraction A major part of the compiler construction abstracts away from the peculiarities of the particular processor that must run the object code. I J bj t d In Java, JVM!

43

KAIST SE lab

Case Study in System Engineering

What does the design of an elevator system have to do with software engineering? Rigor and formality Separation of concerns Modularity Abstraction Others, anticipation of change, generality, and incrementality

44

KAIST SE lab

Discussions
How are SE principles being pursued in SE research?

45