CHP 1

What is software and its importance

The product that software professionals build and then support over the long term.

Software encompasses: (1) instructions (2) data structures (3) documentation

Generic products

Stand-alone systems that are marketed and sold to any customer who wishes to buy them

Examples – PC software such as editing, graphics programs, project management tools

Customized products

Software that is commissioned by a specific customer to meet their own needs.

Examples – embedded control systems, air traffic control software, traffic monitoring systems.

Importance

 The economies of ALL developed nations are dependent on software.

 More and more systems are software controlled ( transportation, medical,
telecommunications, military, industrial, entertainment,)
 Software engineering is concerned with theories, methods and tools for professional
software development.
 Expenditure on software represents a significant fraction of GNP in all developed
countries.

Features of Software?
• Its characteristics that make it different from other things human being build.

Features of such logical system:

• Software is developed or engineered; it is not manufactured in the classical sense which has
quality problem.

• Software doesn't "wear out.” but it deteriorates (due to change). Hardware has bathtub
curve of failure rate (high failure rate in the beginning, then drop to steady state, then
cumulative effects of dust, vibration, abuse occurs).

• Although the industry is moving toward component-based construction (e.g. standard screws
and off-the-shelf integrated circuits), most software continues to be custom-built. Modern
reusable components encapsulate data and processing into software parts to be reused by
different programs. E.g. graphical user interface, window, pull-down menus in library etc.
Wear vs. Deterioration
increased failure
rate due to side effects
Failure
rate

change
actual curve

idealized curve

Time

Software Applications

1. System software: such as compilers, editors, file management utilities

2. Application software: stand-alone programs for specific needs.

3. Engineering/scientific software: Characterized by “number crunching”algorithms. such as

automotive stress analysis, molecular biology, orbital dynamics etc

4. Embedded software resides within a product or system. (key pad control of a microwave oven,
digital function of dashboard display in a car)

5. Product-line software focus on a limited marketplace to address mass consumer market.

(word processing, graphics, database management)

6. WebApps (Web applications) network centric software. As web 2.0 emerges, more
sophisticated computing environments is supported integrated with remote database and
business applications.

7. AI software uses non-numerical algorithm to solve complex problem. Robotics, expert system,
pattern recognition game playing
 Essential attributes
of a good software

Layered technology

A process is a collection of activities, actions and tasks that are performed when some work product
is to be created.

Five Activities of a Generic Process framework

• Communication: communicate with customer to understand objectives and gather

requirements

• Planning: creates a “map” defines the work by describing the tasks, risks and resources, work
products and work schedule.

• Modeling: Create a “sketch”, what it looks like architecturally, how the constituent parts fit
together and other characteristics.

• Construction: code generation and the testing.

• Deployment: Delivered to the customer who evaluates the products and provides feedback
based on the evaluation.

• These five framework activities can be used to all software development regardless of the
application domain, size of the project, complexity of the efforts etc, though the details will
be different in each case.
 • For many software projects, these framework activities are applied iteratively as a project
progresses. Each iteration produces a software increment that provides a subset of overall
software features and functionality.

Umbrella Activities

Complement the five process framework activities and help team manage and control progress,
quality, change, and risk.

• Software project tracking and control: assess progress against the plan and take actions to
maintain the schedule.

• Risk management: assesses risks that may affect the outcome and quality.

• Software quality assurance: defines and conduct activities to ensure quality.

• Technical reviews: assesses work products to uncover and remove errors before going to the
next activity.

• Measurement: define and collects process, project, and product measures to ensure
stakeholder’s needs are met.

• Software configuration management: manage the effects of change throughout the software
process.

• Reusability management: defines criteria for work product reuse and establishes mechanism
to achieve reusable components.

• Work product preparation and production: create work products such as models,
documents, logs, forms and lists.

Software Myths

Erroneous beliefs about software and the process that is used to build it.

• Affect managers, customers (and other non-technical stakeholders) and practitioners

• Are believable because they often have elements of truth,

but …

• Invariably lead to bad decisions,

therefore …

Examples:

• Insist on reality as you navigate your way through software engineering

• Myth 1: Once we write the program and get it to work, our job is done.

• Reality: the sooner you begin writing code, the longer it will take you to get done. 60% to
80% of all efforts are spent after software is delivered to the customer for the first time.

• Myth 2: Until I get the program running, I have no way of assessing its quality.
 • Reality: technical review are a quality filter that can be used to find certain classes of
software defects from the inception of a project.

• Myth 3: software engineering will make us create voluminous and unnecessary

documentation and will invariably slow us down.

• Reality: it is not about creating documents. It is about creating a quality product. Better
quality leads to a reduced rework. Reduced work results in faster delivery times.

• Many people recognize the fallacy of the myths. Regrettably, habitual attitudes and methods
foster poor management and technical practices, even when reality dictates a better
approach.

CHP 2

Software process models

 The waterfall model

o Plan-driven model. Separate and distinct phases of specification and development.
 Incremental development
o Specification, development and validation are interleaved. May be plan-driven or
agile.
 Integration and configuration
o The system is assembled from existing configurable components. May be plan-driven
or agile.
 In practice, most large systems are developed using a process that incorporates elements
from all of these models.
Waterfall model phases

 There are separate identified phases in the waterfall model:

 Requirements analysis and definition

 System and software design

 Implementation and unit testing

 Integration and system testing

 Operation and maintenance

 The main drawback of the waterfall model is the difficulty of accommodating change after
the process is underway. In principle, a phase has to be complete before moving onto the
next phase.

Waterfall model problems

 Inflexible partitioning of the project into distinct stages makes it difficult to respond to
changing customer requirements.

 Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.

 Few business systems have stable requirements.

 The waterfall model is mostly used for large systems engineering projects where a system is
developed at several sites.

 In those circumstances, the plan-driven nature of the waterfall model helps

coordinate the work.

Incremental development
Incremental development benefits

 The cost of accommodating changing customer requirements is reduced.

 The amount of analysis and documentation that has to be redone is much less than
is required with the waterfall model.

 It is easier to get customer feedback on the development work that has been done.

 Customers can comment on demonstrations of the software and see how much has
been implemented.

 More rapid delivery and deployment of useful software to the customer is possible.

Customers are able to use and gain value from the software earlier than is possible with a waterfall
process

Incremental development problems

 The process is not visible.

 Managers need regular deliverables to measure progress. If systems are developed

quickly, it is not cost-effective to produce documents that reflect every version of the
system.

 System structure tends to degrade as new increments are added.

 Unless time and money is spent on refactoring to improve the software, regular
change tends to corrupt its structure. Incorporating further software changes
becomes increasingly difficult and costly.

Reuse Oriented software

 Based on software reuse where systems are integrated from existing components or
application systems (sometimes called COTS -Commercial-off-the-shelf) systems).

 Reused elements may be configured to adapt their behaviour and functionality to a user’s
requirements

 Reuse is now the standard approach for building many types of business system

Types of reusable software

 Stand-alone application systems (sometimes called COTS) that are configured for use in a
particular environment.

 Collections of objects that are developed as a package to be integrated with a component

framework such as .NET or J2EE.

Web services that are developed according to service standards and which are available for remote
invocation
Design activities

 Architectural design, where you identify the overall structure of the system, the principal
components (subsystems or modules), their relationships and how they are distributed.

 Database design, where you design the system data structures and how these are to be
represented in a database.

 Interface design, where you define the interfaces between system components.

 Component selection and design, where you search for reusable components. If unavailable,
you design how it will operate.

A general model
of the design
process

Stages of testing
Testing stages

 Component testing

 Individual components are tested independently;

 Components may be functions or objects or coherent groupings of these entities.

 System testing

 Testing of the system as a whole. Testing of emergent properties is particularly

important.

 Customer testing

 Testing with customer data to check that the system meets the customer’s needs.

Software evolution

 Software is inherently flexible and can change.

 As requirements change through changing business circumstances, the software that

supports the business must also evolve and change.

 Although there has been a demarcation between development and evolution (maintenance)
this is increasingly irrelevant as fewer and fewer systems are completely new.
Software prototyping

 A prototype is an initial version of a system used to demonstrate concepts and try out design
options.

 A prototype can be used in:

 The requirements engineering process to help with requirements elicitation and

validation;

 In design processes to explore options and develop a UI design;

 In the testing process to run back-to-back tests.

Benefits of prototyping

 Improved system usability.

 A closer match to users’ real needs.

 Improved design quality.

 Improved maintainability.

 Reduced development effort.

Prototype development

 May be based on rapid prototyping languages or tools

 May involve leaving out functionality

 Prototype should focus on areas of the product that are not well-understood;

 Error checking and recovery may not be included in the prototype;

 Focus on functional rather than non-functional requirements such as reliability and

security

Throw-away prototypes

 Prototypes should be discarded after development as they are not a good basis for a
production system:

 It may be impossible to tune the system to meet non-functional requirements;

 Prototypes are normally undocumented;

 The prototype structure is usually degraded through rapid change;

  The prototype probably will not meet normal organizational quality standards.

Incremental development and delivery

 Incremental development

 Develop the system in increments and evaluate each increment before proceeding to
the development of the next increment;

 Normal approach used in agile methods;

 Evaluation done by user/customer proxy.

 Incremental delivery

 Deploy an increment for use by end-users;

 More realistic evaluation about practical use of software;

 Difficult to implement for replacement systems as increments have less functionality

than the system being replaced.

Incremental delivery advantages

 Customer value can be delivered with each increment so system functionality is available
earlier.

 Early increments act as a prototype to help elicit requirements for later increments.

 Lower risk of overall project failure.

 The highest priority system services tend to receive the most testing.

Incremental delivery problems

 Most systems require a set of basic facilities that are used by different parts of the system.
 As requirements are not defined in detail until an increment is to be implemented, it can be
hard to identify common facilities that are needed by all increments.
 The essence of iterative processes is that the specification is developed in conjunction with
the software.
 However, this conflicts with the procurement model of many organizations, where the
complete system specification is part of the system development contract.
The process improvement cycle

Process improvement activities

 Process measurement

 You measure one or more attributes of the software process or product. These
measurements forms a baseline that helps you decide if process improvements have
been effective.

 Process analysis

 The current process is assessed, and process weaknesses and bottlenecks are
identified. Process models (sometimes called process maps) that describe the
process may be developed.

 Process change

 Process changes are proposed to address some of the identified process

weaknesses. These are introduced and the cycle resumes to collect data about the
effectiveness of the changes.

The SEI process maturity framework identifies maturity levels that essentially correspond to the use
of good software engineering practice.
The SEI capability maturity model

 Initial

 Essentially uncontrolled

 Repeatable

 Product management procedures defined and used

 Defined

 Process management procedures and strategies defined

and used

 Managed

 Quality management strategies defined and used

 Optimising

 Process improvement strategies defined and used

CHP 3

Plan-driven and agile development

Plan-driven development

 A plan-driven approach to software engineering is based around separate

development stages with the outputs to be produced at each of these stages
planned in advance.

 Not necessarily waterfall model – plan-driven, incremental development is possible

 Iteration occurs within activities.

 Agile development

 Specification, design, implementation and testing are inter-leaved and the outputs
from the development process are decided through a process of negotiation during
the software development process.

Extreme programming

 A very influential agile method, developed in the late 1990s, that introduced a range of agile
development techniques.

 Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.

 New versions may be built several times per day;

 Increments are delivered to customers every 2 weeks;

 All tests must be run for every build and the build is only accepted if tests run
successfully.

Extreme programming practices (a)

 Extreme programming has a technical focus and is not easy to integrate with management
practice in most organizations.

 Consequently, while agile development uses practices from XP, the method as originally
defined is not widely used.

 Key practices

 User stories for specification

 Refactoring

 Test-first development

 Pair programming

Scrum

 Scrum is an agile method that focuses on managing iterative development rather than
specific agile practices.

 There are three phases in Scrum.

 The initial phase is an outline planning phase where you establish the general
objectives for the project and design the software architecture.

 This is followed by a series of sprint cycles, where each cycle develops an increment
of the system.

 The project closure phase wraps up the project, completes required documentation
such as system help frames and user manuals and assesses the lessons learned from
the project.
 Scrum sprint cycle

 Sprints are fixed length, normally 2–4 weeks.

 The starting point for planning is the product backlog, which is the list of work to be done on
the project.

 The selection phase involves all of the project team who work with the customer to select
the features and functionality from the product backlog to be developed during the sprint.
  Once these are agreed, the team organize themselves to develop the software.

 During this stage the team is isolated from the customer and the organization, with all
communications channelled through the so-called ‘Scrum master’.

 The role of the Scrum master is to protect the development team from external distractions.

 At the end of the sprint, the work done is reviewed and presented to stakeholders. The next
sprint cycle then begins.

Scrum benefits

 The product is broken down into a set of manageable and understandable chunks.

 Unstable requirements do not hold up progress.

 The whole team have visibility of everything and consequently team communication is
improved.

 Customers see on-time delivery of increments and gain feedback on how the product works.

 Trust between customers and developers is established and a positive culture is created in
which everyone expects the project to succeed.
CHP 4

Requirements engineering

 The process of establishing the services that a customer requires from a system and the
constraints under which it operates and is developed.

 The system requirements are the descriptions of the system services and constraints that are
generated during the requirements engineering process.

Types of requirement

 User requirements

 Statements in natural language plus diagrams of the services the system provides
and its operational constraints. Written for customers.

 System requirements

 A structured document setting out detailed descriptions of the system’s functions,

services and operational constraints. Defines what should be implemented so may
be part of a contract between client and contractor.

Functional and non-functional requirements

 Functional requirements

 Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.

 May state what the system should not do.

 Non-functional requirements

 Constraints on the services or functions offered by the system such as timing

constraints, constraints on the development process, standards, etc.

 Often apply to the system as a whole rather than individual features or services.

 Domain requirements

 Constraints on the system from the domain of operation

Functional requirements

 Describe functionality or system services.

 Depend on the type of software, expected users and the type of system where the software
is used.

 Functional user requirements may be high-level statements of what the system should do.

 Functional system requirements should describe the system services in detail.

Non-functional requirements

 These define system properties and constraints e.g. reliability, response time and storage
requirements. Constraints are I/O device capability, system representations, etc.

 Process requirements may also be specified mandating a particular IDE, programming

language or development method.

 Non-functional requirements may be more critical than functional requirements. If these are
not met, the system may be useless.

Non-functional classifications

 Product requirements

 Requirements which specify that the delivered product must behave in a particular
way e.g. execution speed, reliability, etc.

 Organisational requirements

 Requirements which are a consequence of organisational policies and procedures

e.g. process standards used, implementation requirements, etc.

 External requirements

 Requirements which arise from factors which are external to the system and its
development process e.g. interoperability requirements, legislative requirements,
etc.
Requirements engineering processes

 The processes used for RE vary widely depending on the application domain, the people
involved and the organisation developing the requirements.

 However, there are a number of generic activities common to all processes

 Requirements elicitation;

 Requirements analysis;

 Requirements validation;

 Requirements management.

 In practice, RE is an iterative activity in which these processes are interleaved.

Requirements elicitation

 Software engineers work with a range of system stakeholders to find out about the
application domain, the services that the system should provide, the required system
performance, hardware constraints, other systems, etc.

 Stages include:

 Requirements discovery,

 Requirements classification and organization,

 Requirements prioritization and negotiation,

 Requirements specification.

Problems of requirements elicitation

 Stakeholders don’t know what they really want.

 Stakeholders express requirements in their own terms.

 Different stakeholders may have conflicting requirements.

 Organisational and political factors may influence the system requirements.

 The requirements change during the analysis process. New stakeholders may emerge and
the business environment may change.

 Requirements discovery

 Interacting with stakeholders to discover their requirements. Domain requirements

are also discovered at this stage.

 Requirements classification and organisation

 Groups related requirements and organises them into coherent clusters.

 Prioritisation and negotiation

  Prioritising requirements and resolving requirements conflicts.

 Requirements specification

 Requirements are documented and input into the next round of the spiral.

Ethnography

 A social scientist spends a considerable time observing and analysing how people actually
work.

 People do not have to explain or articulate their work.

 Social and organisational factors of importance may be observed.

 Ethnographic studies have shown that work is usually richer and more complex than
suggested by simple system models.

Focused ethnography

 Developed in a project studying the air traffic control process

 Combines ethnography with prototyping

 Prototype development results in unanswered questions which focus the ethnographic

analysis.

 The problem with ethnography is that it studies existing practices which may have some
historical basis which is no longer relevant.

Stories and scenarios

 Scenarios and user stories are real-life examples of how a system can be used.

 Stories and scenarios are a description of how a system may be used for a particular task.

 Because they are based on a practical situation, stakeholders can relate to them and can
comment on their situation with respect to the story.

Scenarios

 A structured form of user story

 Scenarios should include

 A description of the starting situation;

 A description of the normal flow of events;

 A description of what can go wrong;

 Information about other concurrent activities;

 A description of the state when the scenario finishes.

Use cases

 Use-cases are a kind of scenario that are included in the UML.

 Use cases identify the actors in an interaction and which describe the interaction itself.

 A set of use cases should describe all possible interactions with the system.

 High-level graphical model supplemented by more detailed tabular description (see Chapter
5).

 UML sequence diagrams may be used to add detail to use-cases by showing the sequence of
event processing in the system.

SRS

Chapter Description

Preface This should define the expected readership of the document and describe
its version history, including a rationale for the creation of a new version
and a summary of the changes made in each version.

Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It
should also describe how the system fits into the overall business or
strategic objectives of the organization commissioning the software.

Glossary This should define the technical terms used in the document. You should
not make assumptions about the experience or expertise of the reader.

User requirements Here, you describe the services provided for the user. The nonfunctional
definition system requirements should also be described in this section. This
description may use natural language, diagrams, or other notations that
are understandable to customers. Product and process standards that
must be followed should be specified.

System architecture This chapter should present a high-level overview of the anticipated
system architecture, showing the distribution of functions across system
modules. Architectural components that are reused should be highlighted.

Chapter Description

System requirements This should describe the functional and nonfunctional requirements in
specification more detail. If necessary, further detail may also be added to the
nonfunctional requirements. Interfaces to other systems may be defined.

System models This might include graphical system models showing the relationships
 between the system components and the system and its environment.
Examples of possible models are object models, data-flow models, or
semantic data models.

System evolution This should describe the fundamental assumptions on which the system is
based, and any anticipated changes due to hardware evolution, changing
user needs, and so on. This section is useful for system designers as it may
help them avoid design decisions that would constrain likely future
changes to the system.

Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database
descriptions. Hardware requirements define the minimal and optimal
configurations for the system. Database requirements define the logical
organization of the data used by the system and the relationships between
data.

Index Several indexes to the document may be included. As well as a normal

alphabetic index, there may be an index of diagrams, an index of functions,
and so on.

CHP 5

Sequence diagrams

 Sequence diagrams are part of the UML and are used to model the interactions between the
actors and the objects within a system.

 A sequence diagram shows the sequence of interactions that take place during a particular
use case or use case instance.

 The objects and actors involved are listed along the top of the diagram, with a dotted line
drawn vertically from these.

 Interactions between objects are indicated by annotated arrows.

Class diagrams

 Class diagrams are used when developing an object-oriented system model to show the
classes in a system and the associations between these classes.

 An object class can be thought of as a general definition of one kind of system object.

 An association is a link between classes that indicates that there is some relationship
between these classes.

 When you are developing models during the early stages of the software engineering
process, objects represent something in the real world, such as a patient, a prescription,
doctor, etc.
 Generalization

 Generalization is an everyday technique that we use to manage complexity.

 Rather than learn the detailed characteristics of every entity that we experience, we place
these entities in more general classes (animals, cars, houses, etc.) and learn the
characteristics of these classes.

 This allows us to infer that different members of these classes have some common
characteristics e.g. squirrels and rats are rodents.

 In modeling systems, it is often useful to examine the classes in a system to see if there is
scope for generalization. If changes are proposed, then you do not have to look at all classes
in the system to see if they are affected by the change.

 In object-oriented languages, such as Java, generalization is implemented using the class

inheritance mechanisms built into the language.

 In a generalization, the attributes and operations associated with higher-level classes are also
associated with the lower-level classes.

 The lower-level classes are subclasses inherit the attributes and operations from their
superclasses. These lower-level classes then add more specific attributes and operations.

Detailed
Behavioral models

 Behavioral models are models of the dynamic behavior of a system as it is executing. They
show what happens or what is supposed to happen when a system responds to a stimulus
from its environment.

 You can think of these stimuli as being of two types:

 Data Some data arrives that has to be processed by the system.

 Events Some event happens that triggers system processing. Events may have
associated data, although this is not always the case.

Data-driven modeling

 Many business systems are data-processing systems that are primarily driven by data. They
are controlled by the data input to the system, with relatively little external event processing.

 Data-driven models show the sequence of actions involved in processing input data and
generating an associated output.

 They are particularly useful during the analysis of requirements as they can be used to show
end-to-end processing in a system.

Event-driven modeling

 Real-time systems are often event-driven, with minimal data processing. For example, a
landline phone switching system responds to events such as ‘receiver off hook’ by generating
a dial tone.

 Event-driven modeling shows how a system responds to external and internal events.

 It is based on the assumption that a system has a finite number of states and that events
(stimuli) may cause a transition from one state to another.

Model driven architecture

 Model-driven architecture (MDA) was the precursor of more general model-driven

engineering

 MDA is a model-focused approach to software design and implementation that uses a subset
of UML models to describe a system.

 Models at different levels of abstraction are created. From a high-level, platform

independent model, it is possible, in principle, to generate a working program without
manual intervention.
CHP 6

Architectural design

 Architectural design is concerned with understanding how a software system should be

organized and designing the overall structure of that system.

 Architectural design is the critical link between design and requirements engineering, as it
identifies the main structural components in a system and the relationships between them.

 The output of the architectural design process is an architectural model that describes how
the system is organized as a set of communicating components

Architectural design decisions

Architecture and system characteristics

Performance

 Localise critical operations and minimise communications. Use large rather than fine-grain
components.

Security

 Use a layered architecture with critical assets in the inner layers.

Safety

 Localise safety-critical features in a small number of sub-systems.

Availability

 Include redundant components and mechanisms for fault tolerance.

Maintainability

 Use fine-grain, replaceable components.

Architectural views

4 + 1 view model of software architecture

 A logical view, which shows the key abstractions in the system as objects or object classes.

 A process view, which shows how, at run-time, the system is composed of interacting
processes.

 A development view, which shows how the software is decomposed for development.

 A physical view, which shows the system hardware and how software components are
distributed across the processors in the system.

 Related using use cases or scenarios (+1)

Layered architecture

 Used to model the interfacing of sub-systems.

 Organises the system into a set of layers (or abstract machines) each of which provide a set
of services.

 Supports the incremental development of sub-systems in different layers. When a layer

interface changes, only the adjacent layer is affected.

 However, often artificial to structure systems in this way.

Name Layered architecture

Description Organizes the system into layers with related functionality associated
with each layer. A layer provides services to the layer above it so the
lowest-level layers represent core services that are likely to be used
throughout the system. See Figure 6.6.

Example A layered model of a system for sharing copyright documents held in

different libraries, as shown in Figure 6.7.

When used Used when building new facilities on top of existing systems; when
the development is spread across several teams with each team
responsibility for a layer of functionality; when there is a
requirement for multi-level security.

Advantages Allows replacement of entire layers so long as the interface is

maintained. Redundant facilities (e.g., authentication) can be
provided in each layer to increase the dependability of the system.

Disadvantages In practice, providing a clean separation between layers is often

difficult and a high-level layer may have to interact directly with
lower-level layers rather than through the layer immediately below
it. Performance can be a problem because of multiple levels of
interpretation of a service request as it is processed at each layer.
Repository architecture

 Sub-systems must exchange data. This may be done in two ways:

 Shared data is held in a central database or repository and may be accessed by all
sub-systems;

 Each sub-system maintains its own database and passes data explicitly to other sub-
systems.

 When large amounts of data are to be shared, the repository model of sharing is most
commonly used a this is an efficient data sharing mechanism.

Client-server architecture

 Distributed system model which shows how data and processing is distributed across a range
of components.

 Can be implemented on a single computer.

 Set of stand-alone servers which provide specific services such as printing, data
management, etc.

 Set of clients which call on these services.

 Network which allows clients to access servers.

Pipe and filter architecture

 Functional transformations process their inputs to produce outputs.

 May be referred to as a pipe and filter model (as in UNIX shell).

 Variants of this approach are very common. When transformations are sequential, this is a
batch sequential model which is extensively used in data processing systems.

 Not really suitable for interactive systems.