Chapter 1: Introduction to Software

Engineering
Software failures are a consequence of two factors:
1. Increasing demands
- Systems must be built and delivered more quickly
- New capabilities are required
- Existing methods cannot cope
- new techniques must be developed to meet new demands

2. Low expectations

A professionally developed software system is more than a single program. The system
usually consists of several separate programs and configuration files that are used to set up
these programs.
It may include:
- system documentation
- user documentation

Professional software Amateur software

no one else will use it other people will use and
so you don’t have to worry about writing other engineers will change it
program guides

CHALLENGES facing software engineering:

- increasing diversity
- demands for reduced delivery times
- developing trustworthy software

SOFTWARE ENGINEERING SYSTEM ENGINEERING

Concerned with all aspect s of software Concerned with all aspects of computer-
production based systems developments including
 hardware, software, and process
engineering

Kinds of software products

1. Generic products - stand-alone systems that are produced by a development
organization and sold on the open market
2. Customized (or bespoke) products - systems that are commissioned by
a particular customer

Software engineering
Characteristics:
- maintainability
- dependability & security
- efficiency
- acceptability

3 issues that affect different types of software

1. Business and social change
2. Security and trust
3. Heterogeneity (diversity)

Software process
Activities common to software processes:
1. Software specifications
2. Software development
3. Software validation
4. Software evolution
Different types of systems need different development processes.
Example:
- real-time software in an aircraft must be completely specified before development begins
- in e-commerce systems, the specification and the program are usually developed together
TYPES of applications:
Standalone applications: application systems that run on a local computer
Interactive transaction-based applications: applications that execute on a remote
computer and that are accessed by users
Embedded control systems: software control systems that control and manage hardware
devices
Batch processing systems: systems that are designed to process data in large batches
(phone billing systems)
Entertainment systems: primarily for personal use and user entertainment
Systems for modelling and simulation: developed by scientists and engineers to model
physical processes or situations
Data collection systems: systems that collect data from their environment using a set of
sensors and send that data to other systems for processing

Software engineering ethics

- Confidentiality
- Competence
- Intellectual property rights
- Computer misuse
Chapter 2: Software processes
Software processes must include 4 activities fundamental to software engineering:
1. Software specifications
2. Software design and implementation
3. Software validation
4. Software evolution

Software process models

For large systems, it makes sense to combine some of the best features of the waterfall
and the incremental models. You need to have information about the essential system
requirements to design a software architecture to support these requirements.

Parts of the system which are difficult to specify in advance, such as the user interface,
should always be developed using an incremental model.

Sub-systems within a larger system may be developed using different approaches. Parts of
the system that are well understood can be specified and developed using a waterfall model.
WATERFALL model
- is an example of a plan-driven process

Because of the costs of producing and approving documents, iterations can be costly and
involve significant rework. Therefore, after a small number of iterations, it is normal to freeze
parts of the development, such as the specification, and to continue with the later
development stages. Problems are left for later resolution, ignored, or programmed around.
This premature freezing of requirements may mean that the system won’t do what the user
wants. It may also lead to badly structured systems as design problems are circumvented by
implementation tricks.

In principle, the waterfall model should only be used when the requirements are well
understood and unlikely to change radically during system development.
INCREMENTAL model
- based on the idea of developing an initial implementation, exposing this to user comment
and evolving it through several versions until an adequate system has been developed

 By developing the software incrementally, it is cheaper and easier to make changes in

the software as it is being developed

Incremental development has 3 benefits, compared to the waterfall model:

1. The cost of accommodating changing customer requirements is reduced
2. It is easier to get customer feedback on the development work that has been done
3. More rapid delivery and deployment of useful software to the customer is possible,
even if all the functionality has not been included

From a management perspective, the incremental approach has 2 drawbacks:

1. The process is not visible. Managers need regular deliverables to measure progress
2. System structure tends to degrade as new increments are added. Unless time and
money are spent on refactoring to improve the software, regular change tends to
corrupt its structure

The problems of incremental development become particularly acute for large, complex,
long-lifetime systems, where different teams develop different parts of the system. Large
systems need a stable framework or architecture and the responsibilities of the different
teams working on parts of the system need to be clearly defined with respect to that
architecture. This must be planned rather than developed incrementally.
REUSE-ORIENTED SOFTWARE ENGINEERING
Reuse-oriented approaches rely on a large base of reusable software components and an
integrating framework for the composition of these components. Sometimes, these
components are systems, referred as commercial off-the-shelf (COTS) systems, that may
provide specific functionality such as word processing or a spreadsheet.

The intermediate stages in a reuse-oriented process are different. These stages are:
1. Component analysis - given the requirements specification, a search is made for
components to implement that specification
2. Requirements modification - the requirements are analysed using information
about the components that have been discovered
3. System design with reuse - the framework of the system is designed, or an existing
framework is reused
4. Development and integration - software that cannot be externally procured is
developed, and the components and COTS systems are integrated to create the new
system

There are 3 types of software components that are used in a reuse-oriented process:
1. Web services that are developed according to service standards
2. Collections of objects that are developed as a package to be integrated with a
component framework such as .NET or J2EE
3. Stand-alone software systems that are configured for use in a particular environment.
Process activities
The 4 process activities of specification, development, validation, and evolution are
organized differently in different development processes. In the waterfall model, they are
organized in sequence, whereas in incremental development they are interleaved.

1. Software specification
- is the process of understanding and defining what services are required from the system
and identifying the constraints on the system’s operation and development

There are 4 activities in the RE process:

- Feasibility study
- Requirements elicitation and analysis
- Requirements specification
- Requirements validation

2. Software design and implementation

- converting a system specification into an executable system
 Stages of testing

Defect testing and debugging are different processes. Testing establishes the existence of
defects. Debugging is concerned with locating and correcting these defects.

3. Software validation
- is intended to show that a system both conforms to its specification and that it meets the
expectations of the system customer

The stages software validation testing process are:

1. Development testing - the components making up the system are tested by the
people developing the system
2. System testing - system components are integrated to create a complete system
3. Acceptance testing - the system is tested with data supplied by the system customer
rather than with simulated test data

4. Software evolution
Coping with change
There are 2 approaches that are used to reduce the costs of rework:
1. Change avoidance
2. Change tolerance

PROTOTYPING
- an initial version of a software system that is used to demonstrate concepts

A software prototype helps in the:

1. Requirements engineering process, where it can elicit and validate system requirements
2. System design process, where it is used to explore particular software evolutions and
support user interface design

To reduce prototyping costs and accelerate the delivery schedule, you may leave some
functionality out of the prototype. You may decide to relax non-functional requirements such
as response time and memory utilization. Error handling and management may be ignored
unless the objective of the prototype is to establish a user interface.

Developers are sometimes pressured by managers to deliver throwaway prototypes,

particularly when there are delays in delivering the final version of the software. However,
this is usually unwise:
- it may be impossible to tune the prototype to meet non-functional requirements, such as
performance, security, and robustness
- rapid change during development inevitably means that the prototype is undocumented
- changes made during prototype development will probably have degraded the system
structure
INCREMENTAL DELIVERY
- is where some of the developed increments are delivered to the customer and deployed for
use in an operational environment

Advantages:
- customers can use the early increments as prototypes and gain experience that informs
their requirements for later system increments
- customers do not have to wait until the entire system is delivered before they can gain
value from it
- as the highest-priority services are delivered first, the most important system services
receive the most testing

Disadvantages:
- most systems require a set of basic facilities that are used by different parts of the system
- iterative development can also be difficult when a replacement system is being developed.
- 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

There are some types of system where incremental development and delivery is not the best
approach. These are very large systems where development may involve teams working in
different locations, some embedded systems where the software depends on hardware
development and some critical systems where all the requirements must be analysed to
check for interactions that may compromise the safety or security of the system
BOEHM’S SPIRAL MODEL

Each loop is split into 4 sectors:

Objective setting: specific objectives for that phase of the project are defined
Risk assessment and reduction: for each of the identified project risks, a detailed analysis
is carried out. Steps are taken to reduce the risk
Development and validation: after risk evaluation, a development model for the system is
chosen
Planning: the project is reviewed, and a decision made whether to continue with a further
loop of the spiral.

The main difference between the spiral model and other software process models is its
explicit recognition of risk.
RATIONAL UNIFIED PROCESS (R.U.P)
a phased model that identifies four discrete phases in the software process. However, unlike
the waterfall model where phases are equated with process activities, the phases in the RUP
are more closely related to business rather than technical concerns.

Inception: identify all external entities that will interact with the system
Elaboration: develop an understanding of the problem domain, establish an architectural
framework for the system, develop the project plan, and identify key project risks
Construction: involves system design, programming, and testing
Transition: is concerned with moving the system from the development community to the
user community and making it work in a real environment

The practice perspective on the RUP describes good software engineering practices that are
recommended for use in systems development.
There are 6 recommended practices:
1. Develop software iteratively
2. Manage requirements
3. Use component-based architectures
4. Visually model software
5. Verify software quality
6. Control changes to software
 Chapter 3: Agile software
development
The philosophy behind agile methods is reflected in the agile manifesto that was agreed on
by many of the leading developers of these methods. This manifesto states:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile methods success:

1. Product development where a software company is developing a small or medium-sized
product for sale.
2. Custom system development within an organization, where there is a clear commitment
from the customer to become involved in the development process and where there are not
a lot of external rules and regulations that affect the software.
The difficulty is realizing agile methods is present because:
1. Although the idea of customer involvement in the development process is an attractive
one, its success depends on having a customer who is willing and able to spend time with
the development team and who can represent all system stakeholders.
2. Individual team members may not have suitable personalities for the intense involvement
that is typical of agile methods.
3. Prioritizing changes can be extremely difficult, especially in systems for which there are
many stakeholders. Typically, each stakeholder gives different priorities to different changes.
4. Maintaining simplicity requires extra work. Under pressure from delivery schedules, the
team members may not have time to carry out desirable system simplifications.
5. Many organizations, especially large companies, have spent years changing their culture
so that processes are defined and followed. It is difficult for them to move to a working model
in which processes are informal and defined by development teams.

Another non-technical problem—that is a general problem with incremental development

and delivery—occurs when the system customer uses an outside organization for system
development. The software requirements document is usually part of the contract between
the customer and the supplier. Because incremental specification is inherent in agile
methods, writing contracts for this type of development may be difficult.

Consequently, agile methods must rely on contracts in which the customer pays for the time
required for system development rather than the development of a specific set of
requirements. So long as all goes well, this benefits both the customer and the developer.
However, if problems arise then there may be difficult disputes over who is to blame and
who should pay for the extra time and resources required to resolve the problems.

There are two questions that should be considered when considering agile methods and
maintenance:
1. Are systems that are developed using an agile approach maintainable, given the
emphasis in the development process of minimizing formal documentation?
2. Can agile methods be used effectively for evolving a system in response to customer
change requests?

The key document is the system requirements document, which tells the software engineer
what the system is supposed to do. Without such knowledge, it is difficult to assess the
impact of proposed system changes.
 The main difficulty after software delivery is likely to be keeping customers involved
in the process. Although a customer may be able to justify the fulltime involvement of
a representative during system development, this is less likely during maintenance
where changes are not continuous. Customer representatives are likely to lose
interest in the system.

The other problem that is likely to arise is maintaining continuity of the development
team. Agile methods rely on team members understanding aspects of the system
without having to consult documentation.

PLAN-DRIVEN AND AGILE DEVELOPMENT

A plan-driven software process can support incremental development and delivery.

To decide on the balance between a plan-based and an agile approach, you have to answer
a range of technical, human, and organizational questions:

Detailed specification: if you need a very detailed plan before starting, use a plan-driven
approach.
Incremental delivery: if you can deliver software in parts and get quick feedback, consider
agile methods.
System size: agile works best with small, co-located teams. Large systems may need a
plan-driven approach.
System type: systems requiring extensive analysis (e.g., real-time systems) usually need a
detailed design and plan-driven approach.
System lifetime: long-lifetime systems may need more design documentation, though agile
critics say such documentation is rarely updated.
Technology support: agile relies on good tools for tracking changes. Without good tools,
more design documentation might be necessary.
Team organization: distributed or outsourced teams may need detailed design documents
for communication.
Cultural issues: traditional engineering cultures prefer plan-based development and
extensive documentation over agile’s informal approach.
Team skill levels: agile methods may require higher skill levels. With less skilled teams, a
detailed design by the best people may be necessary.
Regulation compliance: systems needing external approval usually require detailed
documentation.
EXTREME PROGRAMMING (XP)

Extreme programming (XP) incorporates several practices that align with agile principles:
1. Incremental development: small, frequent system releases based on simple customer
stories guide the inclusion of functionality in each increment.
2. Customer involvement: continuous customer engagement with the development team,
where the customer representative defines acceptance tests.
3. Focus on people: practices like pair programming, collective code ownership, and
sustainable working hours emphasize people over processes.
4. Embracing change: regular system releases, test-first development, refactoring, and
continuous integration accommodate and encourage change.
5. Maintaining simplicity: constant refactoring and simple designs prevent code degeneration
and avoid overcomplicating the system for future changes.
Testing in XP
The key features of testing in XP are:
 test-first development
 incremental test development from scenarios
 user involvement in the test development and validation
 use of automated testing frameworks

Pair programming
Advantages:
- supports the idea of collective ownership and responsibility for the system
- acts as an informal review process because each line of code is looked at by at least two
people
- it helps support refactoring, which is a process of software improvement

Agile project management

Advantages of Scrum:
 The product is broken down into a set of manageable and understandable chunks.
 Unstable requirements do not hold up progress.
 The whole team has 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.
 Chapter 4: Requirements
Engineering
User requirements and system requirements may be defined as follows:
1. User requirements are statements, in a natural language plus diagrams, of what services
the system is expected to provide to system users and the constraints under which it must
operate.
2. System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements document is sometimes
called a functional specification.
FUNCTIONAL REQUIREMENTS
- describe what the system should do

Examples:
 A user shall be able to search the appointments lists for all clinics.
 The system shall generate each day, for each clinic, a list of patients who are expected
to attend appointments that day.

NON-FUNCTIONAL REQUIREMENTS
- are not directly concerned with the specific services delivered by the system to its users

Non-functional requirements can originate from three main sources: product characteristics,
organizational policies, and external factors.

Product requirements - these specify constraints on the software's behaviour, including:

- Performance (speed, memory usage)
- Reliability (acceptable failure rates)
- Security
- Usability

Organizational requirements - these are derived from the policies and procedures of the
organizations involved:
- Operational process (system usage)
- Development process (programming languages, development environment)
- Environmental (operating environment of the system)

External requirements - these come from outside the system and its development process,
such as:
- regulatory requirements (compliance for system approval by regulators like central banks)
Metric for specifying non-functional requirements
SOFTWARE REQUIREMENTS DOCUMENT
- is an official statement of what the system developers should implement

Users of a requirements document

REQUIREMENTS SPECIFICATION
 Chapter 5: System Modeling

CONTEXT MODEL

INTERACTION MODEL

Use case model

Sequence diagram

Structural Model

Class diagram
Generalization

Aggregation
 Chapter 6: Architectural design
ARCHITECTURAL VIEWS
There are 4 fundamental architectural views:
Logical view: shows the key abstraction in the system as objects or object classes
Process view: shows how, at run-time, the system is composed of interacting processes
Development view: shows how the software is decomposed of interacting processes
Physical view: shows the system hardware and how software components are distributed
across the processors in the system

ARCHITECTURAL PATTERNS
- a stylized, abstract description of good practice, which has been tried and tested in different
systems and environments

Web application architecture using MVC pattern

Layered architecture
- supports the incremental development of systems

Layered architecture of the LIBSYS system

Repository architecture
- is suited to applications in which data is generated by one component and used by another
(control systems, management information systems, CAD systems).
Client-server architecture
- is concerned with the static structure of a system and does not show its run-time
organization

A client server architecture for a film library

Pipe-and-filter architecture
- is a model of the run-time organization of a system where functional transformations
process their inputs and produce outputs
APPLICATION ARCHITECTURES
You can use models of application architectures in several ways, as a:
- starting point for the architectural design process
- design checklist
- way of organizing the work of the development team
- means of assessing components for reuse
- vocabulary for talking about types of applications

Transaction processing systems

- are designed to process user requests for information from a database, or requests to
update a database

Software architecture of an ATM system

Language processing systems
- translate a natural language into another representation of that language and, for
programming languages, may also execute the resulting code
 Chapter 7: Design implementation
IMPLEMENTATION ISSUES

Reuse
is possible at several different levels:
1) Abstraction level: you don’t reuse software directly but rather use knowledge of
successful abstractions in the design of your software.
2) Object level: you directly reuse objects from a library rather than writing the code
yourself. To implement this type of reuse, you must find appropriate libraries.
3) Component level: Components are collections of objects and object classes that operate
together to provide related functions and services. An example of component-level reuse is
where you build your user interface using a framework. You add connections to the data to
be displayed and write code to define specific display details such as screen layout and
colours.
4) System level: reuses entire application systems. This usually involves some kind of
configuration of these systems. This may be done by adding and modifying code or by using
the system’s own configuration interface. Most commercial systems are now built in this way
where generic COTS (commercial off-the-shelf) systems are adapted and reused.

The COSTS associated with reuse:

- time spent in looking for software to reuse and assessing whether it meets your needs
- costs of buying the reusable software
- adapting and configuring the reusable software components or systems to reflect the
requirements of the system that you are developing
- integrating reusable software elements with each other and with the new code that you
have developed
Configuration management
the general process of managing a changing software system

There are 3 fundamental configuration management activities:

Version management - where support is provided to keep track of the different versions of
software components. Version management systems include facilities to coordinate
development by several programmers. They stop one developer overwriting code that has
been submitted to the system by someone else.
System integration - where support is provided to help developers define what versions of
components are used to create each version of a system. This description is then used to
build a system automatically by compiling and linking the required components.
Problem tracking - where support is provided to allow users to report bugs and other
problems, and to allow all developers to see who is working on these problems and when
they are fixed.

Host-targeted development
where software is developed on one computer, but runs on a separate machine

A software development platform should provide a range of tools to support software

engineering processes. These may include:
 an integrated compiler and syntax-directed editing system that allows you to create, edit,
and compile code (IntelliJ)
 a language debugging system
 graphical editing tools (diagram.io)
 testing tools (Junit)
 project support tools that help you organize the code for different development projects
For distributed systems, you need to decide on the specific platforms where the components
will be deployed. Issues that you must consider in making this decision are:
1. Hardware and software requirements of a component - If a component is designed for a
specific hardware architecture, or relies on some other software system, it must be deployed
on a platform that provides the required hardware and software support
2. Availability requirements of the system - high-availability systems may require
components to be deployed on more than one platform. This means that, in the event of
platform failure, an alternative implementation of the component is available
3. Component communications - if there is a high level of communications traffic between
components, it usually makes sense to deploy them on the same platform or on platforms
that are physically close to one other. This reduces communications latency, the delay
between the time a message is sent by one component and received by another.
 Chapter 8: Software testing
Testing has 2 distinct goals:
- demonstrate that the software meets its requirements
- discover situations in which the software’s behaviour is incorrect or does not conform to its
specifications.

The first goal leads to validation testing, where you expect the system to perform correctly
using a given set of test cases that reflect the system’s expected use.
The second goal leads to defect testing, where the test cases are designed to expose
defects.
Verification: to check that the software meets its stated functional and non-functional
requirements.
Validation: to ensure that the software meets the customer’s expectations

The goal of verification and validation processes is to establish confidence that the software
system is ‘fit for purpose’.
Inspections
When you inspect a system, you use knowledge of the system, its application domain, and
the programming language to discover errors.
There are 3 advantages of software inspection over testing:
1. During testing, errors can mask (hide) other errors.
2. Incomplete versions of a system can be inspected without additional costs.
3. Consider broader quality attributes of a program, such as compliance with standards,
portability, and maintainability.

Inspections are not good for discovering defects that arise because of unexpected
interactions between different parts of a program, timing problems, or problems with
system performance. Furthermore, especially in small companies or development
groups, it can be difficult and expensive to put together a separate inspection team as
all potential members of the team may also be software developers.

‘traditional’ testing process, as used in plan driven development

Commercial software must go through 3 stages of testing:

1. Development testing: where the system is tested during development to discover bugs
and defects
2. Release testing: where a separate testing team tests a complete version of the system
before it is released to users.
3. User testing: where users or potential users of a system test the system in their own
environment.
Development testing
- carried out by the development team

During development, testing may be carried out at three levels of granularity:

1. Unit testing, where individual program units or object classes are tested. Unit testing
should focus on testing the functionality of objects or methods.
2. Component testing, where several individual units are integrated to create composite
components. Component testing should focus on testing component interfaces.
3. System testing, where some or all of the components in a system are integrated and the
system is tested as a whole. System testing should focus on testing component interactions.

Development testing is primarily a defect testing process, where the aim of testing is to
discover bugs in the software

Unit testing
- the process of testing program components, such as methods or object classes.

Choosing unit test cases

Testing is expensive and time consuming, so it is important that you choose effective unit
test cases. Effectiveness means:
1. The test cases should show that the component that you are testing does what it is
supposed to do.
2. If there are defects in the component, these should be revealed by test cases.

There are two strategies here that can be effective in helping you choose test cases:
- Partition testing: where you identify groups of inputs that have common characteristics
and should be processed in the same way. You should choose tests from within each of
these groups.
- Guideline-based testing: where you use testing guidelines to choose test cases. These
guidelines reflect previous experience of the kinds of errors that programmers often make
when developing components.
System testing
- involves integrating components to create a version of the system and then testing the
integrated system.
- checks that components are compatible, interact correctly and transfer the right data at the
right time across their interfaces

There are 2 differences between component testing and system testing:

- reusable components that have been separately developed and off-the-shelf systems may
be integrated with newly developed components
- components developed by different team members or groups may be integrated at this
stage. System testing is a collective rather than individual process.
When you integrate components to create a system, you get emergent behaviour.
This means that some elements of system functionality only become obvious when you put
the components together.
This may be planned emergent behaviour, which must be tested.
E.g. you may integrate an authentication component with a component that updates
information. You then have a system feature that restricts information updating to authorized
users. Sometimes, however, the emergent behaviour is unplanned and unwanted. You must
develop tests that check that the system is only doing what it is supposed to do.

***
SYSTEM TESTING SHOULD FOCUS ON TESTING THE INTERACTIONS BETWEEN THE
COMPONENTS AND OBJECTS THAT MAKE UP A SYSTEM
***

Because of its focus on interactions, use case–based testing is an effective approach to

system testing.
Test-Driven Development
- develop the code incrementally, along with a test for that increment.
- you don’t move on to the next increment until the code that you have developed passes its
test.
- introduced as part of agile methods such as Extreme Programming

An illustration of the TDD process

Benefits of TDD include:

code coverage: every code segment should have at least one associated test
regression testing: regression tests check that changes to the program have not introduced
new bugs
simplified debugging: When a test fails, it should be obvious where the problem lies. The
newly written code needs to be checked and modified
system documentation: tests act as a form of documentation

One of the most important benefits of test-driven development is that it reduces the costs of
regression testing. Regression testing involves running test sets that have successfully
executed after changes have been made to a system.
Regression testing is very expensive and often impractical when a system is manually
tested, as the costs in time and effort are very high. In such situations, you must try and
choose the most relevant tests to re-run and it is easy to miss important tests.
The solution to this is making use of automated testing.
Release testing
- the process of testing a particular release of a system that is intended for use outside of the
development team
- release is for customers and users

There are 2 important distinctions between release testing and system testing:
1. A separate team that has not been involved in the system development should be
responsible for release testing.
2. System testing by the development team should focus on discovering bugs in the
system (defect testing). The objective of release testing is to check that the system
meets its requirements and is good enough for external use (validation testing).

Release testing, therefore, must show that the system delivers its specified functionality,
performance, and dependability, and that it does not fail during normal use. It should
consider all the system requirements, not just the requirements of the end-users of the
system.
Requirements-based testing
- a systematic approach to test case design where you consider each requirement and
derive a set of tests for it
- requirements-based testing is validation rather than defect testing—you are trying to
demonstrate that the system has properly implemented its requirements

EXAMPLE:
If a patient is known to be allergic to any medication, then prescription of that medication
shall result in a warning message being issued to the system user.
If a prescriber chooses to ignore an allergy warning, they shall provide a reason why this
has been ignored

1. Prescribe two drugs that the patient is allergic to. Check that two warnings are correctly
issued
2. Set up a patient record with a known allergy. Prescribe the medication to that the patient
is allergic to, and check that the warning is issued by the system

Scenario testing
- an approach to release testing where you devise typical scenarios of use and use these to
develop test cases for the system.
Performance testing
- is concerned both with demonstrating that the system meets its requirements and
discovering problems and defects in the system

Experience has shown that an effective way to discover defects is to design tests around the
limits of the system. In performance testing, this means stressing the system by making
demands that are outside the design limits of the software. This is known as stress testing.

Circumstances may arise through an unexpected combination of events where the load
placed on the system exceeds the maximum anticipated load. In these circumstances, it is
important that system failure should NOT cause data corruption or unexpected loss of user
services.
Stress testing checks that overloading the system causes it to ‘fail-soft’ rather than collapse
under its load.

User testing
- process in which users or customers provide input and advice on system testing

User testing is important because influences from the user’s environment have an impact on:
- reliability
- performance
- usability
- robustness

There are 3 types of user testing:

Alpha testing – users work with the development team to test the software at the
developer’s site
Beta testing – a release is made available to users to allow experiments and to raise
problems that they discovered with the system developers
Acceptance testing – customers test a system to decide whether or not it is ready to be
accepted from the developers and deployed
Acceptance testing process