2005 IAS, Universitt Stuttgart 1

SER
Objectives of chapter 2
To define the exact meaning of software engineering
To introduce the most important terms and acronyms related to it
To outline general software engineering principles and methods
To understand what are the major development stages in a software
project
Software Engineering for Real-Time Systems
2005 IAS, Universitt Stuttgart 2
SER Software Engineering for Real-Time Systems
2 Fundamentals
2.1 Terminology
2.2 Quality Characteristics
2.3 Software Development Phases
2.4 Summary
2005 IAS, Universitt Stuttgart 3
SER
What can I do, if ...
2.1 Terminology
Quality
characteristics
Procedure
Concept
Method
Reliability
Terms
are important
for a
common
understanding
2005 IAS, Universitt Stuttgart 4
SER
General Terms
2.1 Terminology
Definition Software:
Computer programs, procudures, rules and possible associated
documentation and data pertaining to operation of a computer system.
[IEEE 610.12]
Definition Software Product:
Self-contained result of a successfully completed software project, project
part or software process.
Definition Software System:
Part of the physical or intellectual world consisting of software elements
and a software structure in which the software elements are arranged.
Exterior view on software
(customers point of view)
Interior view on software
(developers point of view)
2005 IAS, Universitt Stuttgart 5
SER 2.1 Terminology
Definition Software Engineering:
Targeted provision and systematical use of principles, methods, concepts,
notations and tools for the partitioned, engineering-like development and
utilization of large software systems. Targeted means the consideration of
e.g. cost, time and quality.
[Balzert, Lehrbuch der Softwaretechnik]
Quality Cost
Time
Magic triangle:
Software
engineering
aims to
achieve the
optimum
2005 IAS, Universitt Stuttgart 6
SER
Characteristics
universal, abstract, general
constitute the theoretical basis
no statement about how the principle can be accomplished
independent of application domain or development phases
2.1 Terminology
Definition:
Principles are fundamental assumptions that can be taken as a basis for
actions.
[Balzert, Lehrbuch der Softwaretechnik]
Example
principle of structuring (basis of structured programming, e.g.)
2005 IAS, Universitt Stuttgart 7
SER
General principles of software engineering
Abstraction
Decomposition
Forming perspectives
2.1 Terminology
Abstraction
a generalization which is achieved by omitting properties
separation of essential and unimportant aspects
the decision on what unimportant is is not obvious and strongly depends
on the problem under consideration
especially in the early development stages abstractions are useful
in software development they concentrate on data and information flows
Advantages:
by omitting unimportant properties complexity can be reduced
the solution is getting more general and may be used in a broader context
2005 IAS, Universitt Stuttgart 8
SER
Decomposition
Delimiting elements from a whole
Separate consideration of each element
May be performed based on different aspects: hierarchy or modules
Always leads to some kind of structure, therefore the principle of
decomposition is also known as principle of structuring
2.1 Terminology
Advantages:
Complexity of elements is less than of the whole, i.e. decomposition results
in a better understanding and less errors
Elements may be realized in parallel
2005 IAS, Universitt Stuttgart 9
SER
Hierarchical decomposition:
Arranging elements in an order of precedence
Elements having the same level of precedence form a hierarchy level
One can distinguish between structure, semantics and temporal behavior
of a hierarchy
2.1 Terminology
precedence
Modular decomposition:
Creation of units with closed functionality
Definition of interfaces between the modules
Possibility of reuse as additional advantage
2005 IAS, Universitt Stuttgart 10
SER
Forming perspectives
Separate consideration or analysis of a circumstance from different points
of view
Seeing the same thing from different angles is the key ability of a good
system analyst an important to understand what the customer is expecting
2.1 Terminology
Advantages:
Consideration of all relevant aspects of a given problem
Less errors in early development stages
Example: Office automation
Economic perspective
Perspective of working place arrangement
Perspective of integration into existing EDP infrastructure
Perspective of user friendliness (one of the most important!)
2005 IAS, Universitt Stuttgart 11
SER
Definition:
Methods are systematically used, well-founded procedures for reaching
predefined goals (in general within the scope of predefined principles)
Balzert, Lehrbuch der Softwaretechnik]
2.1 Terminology
Characteristics
make principles ready to use
concrete in terms of separation into single steps
utilization and success has to be verifiable and measurable
state when and how which concept has to be used
methods are put in concrete form by procedures
Example
principle of structuring
associated method is structured programming, i.e.
designing programs by using sequences, selections and loops only
2005 IAS, Universitt Stuttgart 12
SER
General methods of software engineering
2.1 Terminology
Top-down method
Bottom-up method
Yo-yo approach
The direction of the development process being described allows to
distinguish between different method classes:
User sphere or view
Basis sphere or machine
Top-down Bottom-up
2005 IAS, Universitt Stuttgart 13
SER
Top-down method
Starting point: abstract and complete description of the system to be
developed
Decomposition into subsystems and concretion at each development step
Consistency between abstract an concrete levels must be guaranteed
Also known as outside-in method
2.1 Terminology
Advantages:
User sphere is the central point of the system development
Complete and precise specifications lead exactly to the expected system
The overall view facilitates finding appropriate abstraction levels and
getting a good system structure
Disadvantages:
Highly developed ability of abstract thinking is essential
Hard to achieve transitions towards more concrete levels
Realization-related problems (constraints due to hardware, operating
system, or programming language) can be detected at the very end only
2005 IAS, Universitt Stuttgart 14
SER
Bottom-up method
Starting point: concrete basis machine with known functionality
Step by step abstraction and combination of known elements to larger
system units
Last step consists of realizing the user machine
Also known as inside-out method
2.1 Terminology
Advantages:
The concrete starting point guarantees a solid basis for the system
development
Better chances that existing partial solutions are searched for and reused
Disadvantages:
Hard to match the user machine, which constitutes the actual objective of
the development, with what has been expected
Potential risk that low-level system components are created which later
turn out not to be relevant any more
2005 IAS, Universitt Stuttgart 15
SER
Yo-yo method
Pragmatic connection of top-down and bottom-up methods
Basically the same as top-down but switch to bottom-up allowed whenever
it is needed
Reason for switch: abstract description not possible or useful without
having considered some more concrete aspects and properties of the
system
2.1 Terminology
Advantages:
Allows flexible adaptation of the method to current situation
lower demand for abstract thinking ability
Disadvantages:
Decision of when to switch the development direction is arbitrary
2005 IAS, Universitt Stuttgart 16
SER 2.1 Terminology
Definition:
A concept is an abstraction allowing to model a defined fact from one or
several points of view.
[Balzert, Lehrbuch der Softwaretechnik]
Definition:
A notation represents one or several concepts by means of symbols.
[Balzert, Lehrbuch der Softwaretechnik]
Examples
Concepts of structured programming: sequence, selection, loop
Suitable notation: structure chart
2005 IAS, Universitt Stuttgart 17
SER 2.1 Terminology
Definition:
Procedures are practicable rules or instructions for using methods in a
specific way.
[Balzert, Lehrbuch der Softwaretechnik]
Characteristics
describe how to solve specific problems or problem classes
mainly consist of formal rules
often constitute a part of standards
mostly more practice-oriented than methods
Example
In PASCAL programs only the following control structures are
allowed:
begin-end, if-then, if-then-else, case-of, repeat-until, while-do,
for-to/downto-do
2005 IAS, Universitt Stuttgart 18
SER 2.1 Terminology
Definition:
Tools provide an automated support for methods, procedures, concepts
and notations.
[Balzert, Lehrbuch der Softwaretechnik]
Characteristics
force to follow methods, procedures, standards, concepts and notations
increase the productivity
in software development tools are necessary but not sufficient
Examples
compilers, debuggers
test systems like micro-controller emulators or network packet generators
CASE tools (Computer Aided Software Engineering)
2005 IAS, Universitt Stuttgart 19
SER 2.1 Terminology
Method
Concept Notation Procedure
Tool
Principle e.g. object orientation
e.g. object-oriented
analysis
e.g. objects,
classes,
attributes
e.g. UML e.g. IAS
Process
Model
e.g. Rational Rose
Correlation of the terms
2005 IAS, Universitt Stuttgart 20
SER
2 Fundamentals
2.1 Terminology
2.2 Quality Characteristics
2.3 Software Development Phases
2.4 Summary
Software Engineering for Real-Time Systems
2005 IAS, Universitt Stuttgart 21
SER 2.2 Quality Characteristics
Quality characteristics = development goals
How reliable is
the software?
Is the software
easy to use?
How efficient is
the software?
How easy can the
software be
modified?
How easy can the
software transfered
to another environment?
Are the required functions
available in the software?
Functionality
Reliability
Usability
Efficiency
Transferability
Maintainability
ISO/IEC
9126-1
2005 IAS, Universitt Stuttgart 22
SER 2.2 Quality Characteristics
Definition:
Functionality is the set of attributes that bear on the existence of a set of
functions and their specified properties. The functions are those that
satisfy stated or implied needs.
[ISO/IEC 9126:1991]
Subdivision in:
Suitability
appropriateness of the functions for specified tasks,
e.g. the search function of a text editor may be based on regular
expressions but wouldnt be suited for non-advanced users then
Accurateness
provision of right or agreed results or effects,
e.g. the correctness and the required accuracy of computed values
Interoperability
ability to interact with specified systems
2005 IAS, Universitt Stuttgart 23
SER 2.2 Quality Characteristics
Compliance
adherence to application related standards or conventions or regulations
in laws and similar prescriptions
Security
ability to prevent unauthorized access, whether accidental or deliberate,
to programs or data
2005 IAS, Universitt Stuttgart 24
SER 2.2 Quality Characteristics
Definition:
Reliability is the set of attributes that bear on the capability of software to
maintain its level of performance under stated conditions for a stated
period of time.
[ISO/IEC 9126:1991]
Subdivision in:
Maturity
frequency of failure by faults in the software
Fault tolerance
ability to maintain a specified level of performance in case of software
faults or of infringement of its specified interface
Recoverability
capability to re-establish its level of performance and recover the data
directly affected in case of a failure as well as the time and effort needed
for it
2005 IAS, Universitt Stuttgart 25
SER 2.2 Quality Characteristics
Definition:
Usability is the set of attributes that bear on the effort needed for use,
and on the individual assessment of such use, by a stated or implied set
of users.
[ISO/IEC 9126:1991]
Subdivision in:
Understandability
the users effort for recognizing the logical concept and its applicability
Learnability
the users effort for learning an application,
i.e. the introduction
Operability
the users effort for operation and operation control
2005 IAS, Universitt Stuttgart 26
SER 2.2 Quality Characteristics
Definition:
Efficiency is the set of attributes that bear on the relationship between
the level of performance of the software and the amount of resources
used, under stated conditions.
[ISO/IEC 9126:1991]
Subdivision in:
Time behavior
response and processing times and on throughput rates in performing
the function
Resource behavior
amount of resource used and the duration of such use in performing the
function
2005 IAS, Universitt Stuttgart 27
SER 2.2 Quality Characteristics
Definition:
Maintainability is the set of attributes that bear on the effort needed to
make specified modifications.
[ISO/IEC 9126:1991]
Analyzability
effort needed for diagnosis of deficiencies or causes of failures, or for
identification of parts to be modified
Changeability
effort needed for modification, fault removal or for environmental change
Stability
risk of unexpected effect of modifications
Testability
effort needed for validating the modified software
Subdivision in:
2005 IAS, Universitt Stuttgart 28
SER 2.2 Quality Characteristics
Example of a maintainable development: defining the
architecture of an embedded web server
Running on a micro-controller platform with Ethernet connectivity
Allows to serve HTML or XML documents from within a device to a
standard web browser
Incorporates an optimized implementation of needed Internet protocols
HTTP
TCP/IP
ARP
Ethernet
Option 1:
Whole protocol stack in a single
module
TCP
Option 2:
Each protocol layer in its own module
IP
ARP
Ethernet
HTTP
Hard to analyze because all layers
have to be regarded at once
Modifications are very likely to
cause side effects
Protocol layers can be inspected
changed and tested independently
of each other
2005 IAS, Universitt Stuttgart 29
SER
Definition:
Portability is the set of attributes that bear on the ability of software to be
transferred from one environment.
[ISO/IEC 9126:1991]
Adaptability
opportunity for its adaptation to different specified environments without
applying other actions or means than those provided for this purpose for
the software considered
Installability
effort needed to install the software in a specified environment
Conformance
adherence to standards or conventions relating to portability
Replacability
opportunity and effort using a software in the place of specified other
software in the environment of that software
Subdivision in:
2.2 Quality Characteristics
2005 IAS, Universitt Stuttgart 30
SER
Example of a portable development: migrating the
embedded web server to another micro-controller platform
HTTP
TCP/IP
ARP
Ethernet
Different micro-controller platform means there is different hardware
environment (CPU, memory resources, Ethernet chip, other peripherals)
But: most of the protocol layers dont access any hardware resources; the
Ethernet device driver constitutes the only exception
Option 1:
Whole protocol stack in a single
module
Option 2:
Each protocol layer in its own module
The whole software package is
getting involved
High probability of errors cropping
up while porting to new platform
Only the Ethernet device driver
needs to be touched
2.2 Quality Characteristics
TCP
IP
ARP
Ethernet
HTTP
2005 IAS, Universitt Stuttgart 31
SER 2.2 Quality Characteristics
Weighting of quality characteristics
quality characteristic compete
in general: accurateness is more important than efficiency
order of precedence depends on the system
Examples of competing quality characteristics
maintainabiliy, portability efficiency
resource consumption fault tolerance
2005 IAS, Universitt Stuttgart 32
SER 2.2 Quality Characteristics
Precedence of quality characteristics - examples
Dialog systems
accurateness, reliability
fault tolerance, usability, efficiency
security, changeability, portability, analyzability
Industrial automation systems
security
reliability, accurateness
efficiency, portability, changeability
fault tolerance, usability, analyzability
Operating systems
efficiency, reliability
accurateness, fault tolerance, analyzability
security, changeability, portability, usability
order of precedence
depending on kind of
system
2005 IAS, Universitt Stuttgart 33
SER
How to increase the system quality
attach great importance to a complete and careful project documentation
decompose the system into modules, hide information, keep interfaces
smart
structure the system, adapt it to environment and resources
use problem-oriented modeling and programming languages, take care for
testability and readability, minimize fault probability
consider the qualification of your staffing and plan training programs
2.2 Quality Characteristics
general measures
2005 IAS, Universitt Stuttgart 34
SER Software Engineering for Real-Time Systems
2 Fundamentals
2.1 Terminology
2.2 Quality Characteristics
2.3 Software Development Phases
2.4 Summary
2005 IAS, Universitt Stuttgart 35
SER
Overall view
2.3 Software Development Phases
Requirements
engineering
System
analysis
System and
software design
Implementation
Test
Requirements
specification
Problem
Phases can be
iterated and
may overlap
Xxx
Legend:
Development phase
Development result Yyy
System
model
Design
specification
Realized
system
Test
documentation
Maintenance,
enhancements
System
ready for use
2005 IAS, Universitt Stuttgart 36
SER
Requirements engineering
Finding out and describing the services the system is expected to provide
and the constraints under which it must operate
Consultation and negotiation with the system users
2.3 Software Development Phases
Examples of typical requirements:
required functions
description of correct and invalid input data as well as
the required output data in either cases
start-up and shutdown phase
optional system enhancements
documentation-related requirements
performance parameters
quality characteristics
major test scenarios
2005 IAS, Universitt Stuttgart 37
SER 2.3 Software Development Phases
Examples of constraints to be considered:
user profile
number of users
expertise of users
system environment
hardware performance
existing system software (operating system, common services)
existing software packages (other applications or software libraries)
Requirements engineering result:
Requirements specification
2005 IAS, Universitt Stuttgart 38
SER
System analysis
Aims to develop an understanding of the problem to be solved and the
system to be realized
Creation of a system model or set of system models (i.e. graphical
representations) which decompose the problem into partial problems
Investigation if the planned system is realizable (technical feasibility,
economic feasibility)
2.3 Software Development Phases
A system can be modeled in terms of:
its context and environment (external perspective)
its functionality, behavior or services (behavioral perspective)
its data or object structures or its architecture (structural perspective)
System analysis results:
System model or set of system models
2005 IAS, Universitt Stuttgart 39
SER
System and software design
planning of the method applied for solving the problem
description of the parallel processes, of how they have to be synchronized,
their relationships with each other (interfaces and data) and their
relationships with the technical process (external interfaces and events)
description of involved devices and computers
accomplishment of the requirements as defined by the requirements
specification
2.3 Software Development Phases
Design specification
Design result:
2005 IAS, Universitt Stuttgart 40
SER
Implementation
Software
realization of a program on the basis of the design specification using a
programming language
allocation of tasks and threads for the parallel processes
selection of appropriate control flow operators
selection of appropriate data types for the data, the interfaces and the
events
addition of comments to the program code
compiling, linking, loading and executing the realized programs
2.3 Software Development Phases
Hardware
realization of the hardware required by the design specification
creation or provision of needed devices
Program code and executables, assembled devices
Implementation results:
2005 IAS, Universitt Stuttgart 41
SER
Test
Unit test
regarding single systems parts
verification against design specification
Integration test
regarding the whole system
verification against design specification
System test
regarding the whole system
validation against requirements
performance benchmarks, optimizations
2.3 Software Development Phases
Test specification and reports
Test results:
2005 IAS, Universitt Stuttgart 42
SER
Maintenance and enhancements
Life span of huge systems may last longer than
2.3 Software Development Phases
the underlying hardware is available
the staff having been involved in the development is available
Maintenance tasks:
elimination of errors
enhancements due to new requirements
update of underlying hardware system or parts of it
General rule:
10 % of the development costs
= maintenance costs per year
2005 IAS, Universitt Stuttgart 43
SER
Documentation
documentation is a model of the system
every product is as good as is documentation
documentation has to be just in time and to keep track of the system
documentation has to be easy to access and to change
uniform way of description
user-specific documentation
2.3 Software Development Phases
2005 IAS, Universitt Stuttgart 44
SER Software Engineering for Real-Time Systems
2.1 Terminology
2.2 Quality Characteristics
2.3 Software Development Phases
2.4 Summary
2 Fundamentals
2005 IAS, Universitt Stuttgart 45
SER
Summary
Software Engineering means to achieve a high software quality while
keeping software costs at the very minimum
Software Engineering guides to a systematic development by adopting
principles, methods, concepts, notations and tools
Software quality has a great variety of aspects; different quality
characteristics often influence and compete each other
Software quality is not an absolute term but has to be defined a new in
every upcoming software project
There are characteristic assignments and activities to be performed during
a software development which can be summarized in development phases
Each development phase consists of a set of activities to be carried out
and a set of expected results at the end of the phase
2.4 Summary